2011/2/26 Stefano D'Angelo <zanga.m...@gmail.com>: > 2011/2/25 David Robillard <d...@drobilla.net>: >> On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote: >>> On 02/25/2011 08:57 PM, David Robillard wrote: >>> >>> >> 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. >> >> 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. > > 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
Oops, I meant, to replace GLib in SLV2. Stefano _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev