This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gh_scm2doubles and friends


Hello,

    Mikael> I think your suggested interface is too complex.  One of
    Mikael> the goals of the gh interface is that it should be easy to
    Mikael> use.

I agree that gh should be easy to use.  What's easy to use is a matter
of taste.  I'm back and forth on what's easier to use: a single call
with flags, or lots of different routines that do almost the same
thing.  I generally like fewer routines that are a little more
complex.

My goal is that gh_ should handle all of the "type casting" so that
the user routine doesn't worry about the difference between vectors,
and the different types of uniform-arrays.  I think that's in line
with the rest of the gh_ (eg. gh_scm2double which takes any number and
returns it as a double).  I also think that the internal
representation of the data should be hidden from the user function.
The current interface doesn't do that completely.

If I understand, gh is going to be proposed as a RFI, so I think that
copy in/copy out should be directly handled inside of gh.

I built code similar to your examples, which is what got me thinking
about a more general interface.  Here are some of the differences
between your examples and what I suggested:

** example 1: This works fine for copy in/copy out as long as myvect
   is a normal vector.  It will crash and burn a UVE.

** example 3: This works fine for a UVE of the correct type, but if
   crashes on anything else.

Most of the gh_ interface routines handle all of the type coersion for
the user.  I'm suggesting that the vector routines should try to
do the same thing.

One of the advantages of what I'm suggesting is that a particular
implementation may return a pointer directly to the memory allocated
for the scheme vector (when possible).  There are some problems with
the exact semantics that I've proposed, but I think it's a good
starting point for discussion.

Changing subject a little bit.  There's a problem with the current
gh_scm2doubles interface.  Consider the code:

>From scheme:
(define myvect (make-vector 5))
(example make-vector)

In C:
SCM example(SCM myvect) {
    double mem[3];
    double *m = gh_scm2doubles(myvect,mem);
    ...
}

The current interface will over-write memory and be be very hard to
debug.  At the least I think a third argument is needed to give the
maximum number of elements that can be copied:

SCM example(SCM myvect) {
    double mem[3];
    double *m = gh_scm2doubles(myvect,mem,3);
    ... 
}

Obviously, you can do the check yourself with gh_length, but I think
it should be part of the copying routine.

Cheers,

Clark