2011/2/26 David Robillard <[email protected]>: > On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote: >> 2011/2/25 David Robillard <[email protected]>: >> > 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, but this is not high priority for me at the moment. Once the new >> NASPRO release is out I can consider whether to do the work, since I >> want to port SLV2 to Windows right after. >> >> The decision, however, depends on whether Dave would like that or not. > > Sure. Sounds good, probably a good choice, and it would be nice if your > work - originally intended to escape slv2 - could be used by it to make > a better general solution instead :)
You got the idea. :-D _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
