26 Feb
2011
26 Feb
'11
6:44 p.m.
On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote:
2011/2/25 David Robillard <d(a)drobilla.net>et>:
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 :)
Like you, I think releasing the current state of things is a higher
priority though. Plenty enough improvement and new libraries lately as
it is, time to kick it out the door and get it on users machines. We can
look into this.. y'know.. later.
-dr
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, 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. 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.