Re: [Chicken-users] Re: FFI to libgmp questions

[felix]

>
>Ok, I think after careful inspection of the code you have provided,
>I understand how my example did not work. The only reason I even went down
>this road in the first place was because the FFI examples in the manual use
>C_alloc, so I was led to believe it should be more commonly used than what
>it should. Also, C_alloc isn't explained very well in the manual(in fact, not
>too many of the C_* calls are--especially what context to use them in).


You are perfectly right. I will try to improve that. The use of `C_alloc()' in
the callback examples is actually a bit fishy: it just works, because the
`callin' invocation will do a GC and rescue the data allocated from the
C-stack into the normal heap. I will change this.

>
>> BTW, I will add two new foreign type specifiers:
>> 
>> (c-pointer X)
>>   The same as (pointer X), but more consistent, because `pointer'
>>   is not the same as `c-pointer'.
>
>I don't understand, I thought you already had this. Page 32 of the pdf manual
>talks about it under "Foreign type specifers".

Oh, it's nothing new. It's absolutely equivalent to `(pointer X)'. But `pointer'
(without an additional type) is not equivalent to 'c-pointer', so I thought
this syntax might be more intuitive.

>Is there a generic way to convert a C pointer(to a dynamic piece of memory 
>which
>might or might not be an array of similar object) to any type into the
>scheme equivalent and free the memory too?
>
>For example, suppose I have a function:
>
>struct foo* make_foo_array(int num);
>
>This will allocate an num sized array of type struct foo and return
>it. How do I cleanly represent this array in terms of the gc and the scheme
>type that it will eventually become? The copier function pointer->c-string
>made a lot of sense because it automatically copied the zero-delimited
>string into the garbage collector and made it a "c-string" type which
>was understood in the scheme code to copy the result into the gc.
>
>How is this done for a function like make_foo_array?


Generally any result of type `c-pointer' (or `(c-pointer X)', or `(pointer X)')
will be represented as a boxed machine-pointer object, that is, a one-element
data-structure containing the pointer itself. If you want to represent it
differently (say as a vector of pointers), you can write a conversion procedure
and define a special foreign type with explicit conversion:

(define-foreign-type ptr-array ptr-array->ptr ptr->ptr-array)

As long as you provide conversion procedures, you can transform your
arguments and result to/from foreign code as you like. The basic FFI
just provides special handling of strings, byte-vectors and SRFI-4 
number-vectors.
For your own converters, you have to do the freeing per hand of course.

>
>I'm sorry for all of the questions, but I'm a little confused as to when
>it is ok to use set-finalizer! and when you have to write the copy and
>free yourself. 

>


Well, it *is* confusing! The documentation is rather weak. And I'm not 
particularly
good in explaining these things. 
To add to the confusion, let me say that the foreign type `scheme-object'
has some interesting properties: It allows you to

1) Construct arbitrary Scheme data in statically or dynamically allocated 
  memory:

(declare
  (foreign-declare 
"static C_word my_vector[] = { C_make_header(C_VECTOR_TYPE, 3), C_fix(1), 
C_fix(2), C_fix(3) };" ) )

(define v ((foreign-lambda* scheme-object () "return(my_vector);")))

(gc)

(print v)

  [Note that mutating these objects can be tricky, because of generational GC]

2) Allows unboxed pointers

Since the garbage collector ignores pointers pointing outside of the
heap, you can simply return normal C pointers, and pass them around
normally. If you print them, you are likely to see garbage, or have the 
application crashed, but for certain lowlevel code this might be
useful, albeit a little bit dirty.

>
>I _really_ appreciate the time that you all are spending with me as I figure
>this stuff out.
>


You are welcome.


cheers,
felix