[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] Guile FFI: resizable vector problem
From: |
Tom Lord |
Subject: |
Re: [Pika-dev] Guile FFI: resizable vector problem |
Date: |
Sat, 31 Jan 2004 13:18:32 -0800 (PST) |
> From: Andreas Rottmann <address@hidden>
> > Andreas Rottmann <address@hidden> writes:
> >> The next thing I ran into: Guile has dropped resizable vectors some
> >> time ago. A rationale can be found in [0]. The argument seems sound to
> >> me, so what about Pika -- won't resizable vectors yield the same
> >> problem wrt to threading? For now, I'll just work around that by
> >> making scm_set_n_vector_elts() create a new vector.
> > Pika's FFI will handle resizable vectors and threading fine because
> > users never get pointers to the vector contents -- they can only do
> > vector-ref and vector-set! operations on them.
> > Having scm_set_n_vector_elts create a new vector and copy elements
> > would be the Right Thing to do for this.
> OK. Another thing: What about defining SCM_FEATURE_ macros, e.g.:
> #define SCM_FEATURE_CHAR_BUCKYBITS 1 /* for Pika */
> #define SCM_FEATURE_CHAR_BUCKYBITS 0 /* for Guile Pika FFI */
> We can use those in the testcases, to check only for supported
> features. This is also usable for applications that want to use the
> Pika FFI and use features as available, but still stay portable across
> the different FFI implementations.
This makes sense for the "first plan" -- extracting a "portable FFI"
from the Pika native FFI, and supporting that portable FFI as a way to
write extensions to Guile.
I think that initially, the portable FFI should not deal with
buckybits at all. If C code says to Scheme "Hey, gimme that
character converted to a C value", and the character happens to have
non-0 buckybits, then Scheme should reply "Sorry, can't do it."
The rationale for that is that so few implementations deal with
buckybits that they are a low priority for a portable FFI. At the
same time, many implementations will have _some_ kinds of characters
that aren't easilly converted to C values in a portable way -- so the
possibility that asking for a character can return an error is worth
building in to the portable FFI.
-t
Re: [Pika-dev] Guile FFI: resizable vector problem, Tom Lord, 2004/01/31