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] |
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