[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dev-serveez] guile adventures
From: |
stefan |
Subject: |
Re: [dev-serveez] guile adventures |
Date: |
Fri, 13 Jul 2001 17:08:27 +0200 (CEST) |
On Fri, 13 Jul 2001, Martin Grabmueller wrote:
> I think the correct data type to use would be homogeneous numeric
> vectors, of which there are two implementations in the upcoming
> version 1.6 (one is the classic uniform array implementation, the
> second is the SRFI compliant version.) In older versions, there are
> only uniform arrays, which I personally dislike because the
> implementation is weird, the documentation confusing and the interface
> strange. The pro for the old implementation is that it is tightly
> integrated with Guile's runtime system, whereas the SRFI version is an
> add-on module, which makes interfacing from C code more difficult
> (unless you link against guile-srf-srfi-4.la in addition to libguile.)
>
> You should probably check out some recentish documentation (for
> example at www.glug.org, srfi.schemers.org for SRFI-4) and then ask
> more questions 8-)
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 ?
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...
* 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.
* 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.
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.
Please correct me if any of the above statements might be wrong. Also tell
what you think about this matter...
Cheers,
address@hidden