Re: [dev-serveez] guile adventures

[Martin Grabmueller]

> From: stefan <address@hidden>
> Date: Fri, 13 Jul 2001 17:08:27 +0200 (CEST)
> 
> As far as I realized things there are several possibilities to pass and
> operate on binary datain Guile.
> 
>  * 1. strings
>    The documentation states that you can have any data within strings. No
>    trailing `\0' or anything likely. Since string are *very*
>    mature in Guile I would like to prefer this. Problems I see: Is there a
>    limit for string lengths which is too less for larger serveez buffers ?

Strings (and normal vectors as well) are limited to contain 2^24-1
elements in Guile.  For Serveez buffers, this will be enough, I suppose.

>    It is overkill to convert the buffers right at the borderline between
>    serveez and guile. Is this right ? I guess when calling gh_scm2chars()
>    and gh_str2scm() the buffers get once more malloc'ed and copied...

Yes, that's right.  There is only a possibility to create strings from
alread malloc()ed memory, but the GC will attempt to free() that
memory once the string is found to be garbage, so it's not much use.

>  * 2. uniform vectors
>    Just another kind of strings. We won't use the srfi-4 thingie since it
>    is not yet even released. We want to stay compatible with the 1.4
>    release. With uniform vectors I assume the same problems about the
>    conversion.

Correct.

>  * 3. smob
>    The most performant solution would be a small object pointing to a
>    structure like this:
>    struct svz_binary_data {
>      unsigned char * data;
>      unsigned long length;
>      int garbage;
>    }
>    The problem about this is garbage collection (when really creating the
>    data pointer in guile). But I think it is explained in the guile
>    documentation, just some work. Yet another problem will be the accessor
>    function from guile, even more work.

Hm, I think smobs are quite easy to use, and not that much work.
Guile's conservative GC takes a lot of burden from you, because you
don't have to tell him where you store variables (as long as it's on
the stack.)

> Thus I conclude for myself, that the smobs will be the perfect solution
> if it would not be soooooo much work. That's why I currently use the
> string implementation ignoring the waste of memory and cpu time.

A possibility would be to rip out the SRFI-4 part of CVS Guile which
implements unsigned 8-bit vectors.  That wouldn't be too much work,
and would give you all necessary accessors.

Regards,
  'martin