26 Feb
2011
26 Feb
'11
3:12 p.m.
2011/2/26 Stefano D'Angelo <zanga.mail(a)gmail.com>om>:
2011/2/25 David Robillard <d(a)drobilla.net>et>:
Oops, I meant, to replace GLib in SLV2.
Stefano
On Fri, 2011-02-25 at 21:09 +0100, Olivier
Guilyardi wrote:
Given the discussions we had already, NASPRO core could be a viable alternative.
Pros:
- no dependencies apart from libc and libm
- size (181K without stripping on Arch Linux x86-64, -O2)
- high portability, little and confined platform-specific code,
compiler-specific (symbol visibility, etc.) code confined to a small
header
- gracefully handles platform-specific conventions (i.e., ':' vs ';'
in path variables, zero-length prefixes in path variables under *nix,
directory separators, etc.)
- total amount of code is circa 7.5k lines, including comments and
public headers
- UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
counting is supported
- thread safety (e.g., data types are synchronized at a very granular
level, but allow you to have more coarse synchronization if you want)
- extremely low memory footprint
- locale-independent asprintf() and vasprintf(), C99 level (except
"%lc" and "%ls" conversions, possibly they are not even needed if
using UTF-8)
- semi-serious, integrated and as-lightweight-as-it-can-be
error/message reporting mechanism
- precise and well defined error checking and error codes
- includes directory traversal, dynamic loading
- well documented
Cons:
- not yet released
- no real test suite and not extensively tested
- currently implemented data types: doubly linked lists and AVL trees only
- not yet ported to non POSIX platforms (i.e., Windows)
- API/ABI are "stable enough", but can't guarantee for total stability
in the next future (i.e., no big changes will happen, yet something
might change)
- no locale-independent sscanf() or similar
- no UTF16-BE support/conversion
- till now, a one man effort
That is, it is certainly possible to make it become viable to replace
SLV2 On 02/25/2011 08:57 PM, David Robillard wrote:
Glib was the most effective route of getting the job done - rewriting
the few bits that are required is not an effective use of my time right
now (it's not exposed in the API, so it's not a compatibility issue, and
there's a ton of more pressing LV2 things that need doing).
I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
unoffensive a dependency as they come. On mobile, I guess that meg or so
actually makes a difference.
Replacing glib will not be very difficult, very little of it is used:
just a balanced BST, dynamic array, and ideally a hash table or trie
other appropriate structure for string interning (the BST would do for
this part, with a bit of a performance cost). Good old-fashioned data
structure implementation is my favourite thing to do, but unfortunately
there is no shortage of more pragmatic things that need doing ;)
Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
just tearing the required bits out of glib itself. Sqlite has an
in-memory hash table IIRC. Code abounds.
Present a viable alternative, and I'll switch sord/slv2 to it, but I
have no good reason to invest time in reinventing glib right now. > It's a few months ago now that I
investigated LV2. IIRC, at that time I
> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
> changing IIUC :)
You never asked. I would have changed it... but I am not psychic ;)
It's not always easy to discuss about religious matters, such as licenses ;)
That said there is another big problem. This glib dependency, it's way too heavy
for mobile deployment.