Re: [Chicken-users] Chicken C interface
On 2013-06-05 23:36, Felix wrote: From: Dan Leslie d...@ironoxide.ca [...] Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Note that this code is not correct: C_alloc allocates on the C stack and the data will be invalid once the function returns (Sorry). If this works, then it is just coincidental! [...] Hello, when I first saw that code I thought that this must be incorrect, too. Then I checked the CHICKEN documentation for foreign-safe-lambda and read: This is similar to foreign-lambda, but also allows the called function to call Scheme functions and allocate Scheme data-objects. Now I'm confused. Of course C_alloc allocates on the stack and of course this can likely break if a function just returns some pointer to stack allocated data. However C_return could magically copy the return value to the second generation heap or similar trickery to actually make foreign-safe-lambda and C_alloc interoperate correctly or one could perhaps use a special call ABI to prevent stack corruption upon return from a foreign-safe-lambda and salvage stack allocated objects. Is any such strategy actually implemented? But maybe the documentation is just misleading and wanted to say something about temporary allocation for the lifetime of the function instead. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On Thu, Jun 6, 2013 at 11:34 AM, Thomas Chust ch...@web.de wrote: On 2013-06-05 23:36, Felix wrote: From: Dan Leslie d...@ironoxide.ca [...] Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Note that this code is not correct: C_alloc allocates on the C stack and the data will be invalid once the function returns (Sorry). If this works, then it is just coincidental! [...] Hello, when I first saw that code I thought that this must be incorrect, too. Then I checked the CHICKEN documentation for foreign-safe-lambda and read: This is similar to foreign-lambda, but also allows the called function to call Scheme functions and allocate Scheme data-objects. Now I'm confused. Of course C_alloc allocates on the stack and of course this can likely break if a function just returns some pointer to stack allocated data. However C_return could magically copy the return value to the second generation heap or similar trickery to actually make foreign-safe-lambda and C_alloc interoperate correctly or one could perhaps use a special call ABI to prevent stack corruption upon return from a foreign-safe-lambda and salvage stack allocated objects. Is any such strategy actually implemented? From what I understand, this is exactly what foreign-primitive does: wraps C_return in a CPS, keeping the stack-allocation alive. I posted a question on a similar topic a while back: http://lists.gnu.org/archive/html/chicken-users/2012-03/msg00034.html K. But maybe the documentation is just misleading and wanted to say something about temporary allocation for the lifetime of the function instead. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 11:46, Kristian Lein-Mathisen wrote: [...] From what I understand, this is exactly what foreign-primitive does: wraps C_return in a CPS, keeping the stack-allocation alive. [...] Hello, well, kind of. Since compiled CHICKEN code is fully CPS transformed you don't wrap something in a CPS context, you wrap anything that isn't natively in CPS with a function that calls it and passes the result to the values continuation. foreign-lambda and friends create such wrappers, foreign-primitive doesn't create a wrapper, it just expects the code to be in CPS style, which means that the code may never return at all. C_return is, in that case, just syntactic sugar for invoking the values continuation. Since the code in a foreign-primitive never returns, things allocated in the nursery (ie. on the stack) live on forever, or rather until the next minor garbage collection comes around, transfers anything that's still referenced into the second generation heap and throws away the nursery (ie. almost the entire stack). Therefore foreign-primitive can do allocation in the nursery, but foreign-lambda can't. However, foreign-lambda could still allocate directly in the second generation heap or transfer nursery-allocated values directly into the heap upon return before the stack context is destroyed. The question is whether such magic is present for foreign-safe-lambda, as the documentation may indicate, or whether that is not the case, as Felix has indicated with his earlier message :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
I did not read your question properly, sorry! Thanks for the clarification, I didn't know foreign-lambda were the one that had to do the CPS-conversion. Does that mean there is a small performance overhead when using foreign-lambda as opposed to just foreign-primitive? K. On Thu, Jun 6, 2013 at 11:59 AM, Thomas Chust ch...@web.de wrote: On 2013-06-06 11:46, Kristian Lein-Mathisen wrote: [...] From what I understand, this is exactly what foreign-primitive does: wraps C_return in a CPS, keeping the stack-allocation alive. [...] Hello, well, kind of. Since compiled CHICKEN code is fully CPS transformed you don't wrap something in a CPS context, you wrap anything that isn't natively in CPS with a function that calls it and passes the result to the values continuation. foreign-lambda and friends create such wrappers, foreign-primitive doesn't create a wrapper, it just expects the code to be in CPS style, which means that the code may never return at all. C_return is, in that case, just syntactic sugar for invoking the values continuation. Since the code in a foreign-primitive never returns, things allocated in the nursery (ie. on the stack) live on forever, or rather until the next minor garbage collection comes around, transfers anything that's still referenced into the second generation heap and throws away the nursery (ie. almost the entire stack). Therefore foreign-primitive can do allocation in the nursery, but foreign-lambda can't. However, foreign-lambda could still allocate directly in the second generation heap or transfer nursery-allocated values directly into the heap upon return before the stack context is destroyed. The question is whether such magic is present for foreign-safe-lambda, as the documentation may indicate, or whether that is not the case, as Felix has indicated with his earlier message :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
From: Thomas Chust ch...@web.de Subject: Re: [Chicken-users] Chicken C interface Date: Thu, 06 Jun 2013 11:34:40 +0200 On 2013-06-05 23:36, Felix wrote: From: Dan Leslie d...@ironoxide.ca [...] Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Note that this code is not correct: C_alloc allocates on the C stack and the data will be invalid once the function returns (Sorry). If this works, then it is just coincidental! [...] Hello, when I first saw that code I thought that this must be incorrect, too. Then I checked the CHICKEN documentation for foreign-safe-lambda and read: This is similar to foreign-lambda, but also allows the called function to call Scheme functions and allocate Scheme data-objects. The part about allocation is wrong, I'd say. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 12:13, Kristian Lein-Mathisen wrote: [...] I didn't know foreign-lambda were the one that had to do the CPS-conversion. Does that mean there is a small performance overhead when using foreign-lambda as opposed to just foreign-primitive? [...] Hello, the overhead is roughly one return instruction and one unconditional branch instruction. I would assume that is negligible on a modern CPU. At least, if you're worried about overhead in that order of magnitude, you should probably write your code in hand-optimized assembler with the CPU tuning manual on your lap, painstakingly tracking the state of your processor's pipeline through your code and arranging the instructions to never waste an idle cycle in any of the CPU subsystems, rather than relying on one of those pesky compilers that do the wrong thing all the time ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 12:19, Felix wrote: From: Thomas Chust ch...@web.de [...] when I first saw that code I thought that this must be incorrect, too. Then I checked the CHICKEN documentation for foreign-safe-lambda and read: This is similar to foreign-lambda, but also allows the called function to call Scheme functions and allocate Scheme data-objects. The part about allocation is wrong, I'd say. [...] Hello, thank you for the clarification :-) So what about allocating locally and not returning an object but passing it to a Scheme callback from inside a foreign-safe-lambda? Is that ok or can it happen that the callback stores this object away but never copies it into the second generation heap? Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
From: Thomas Chust ch...@web.de Subject: Re: [Chicken-users] Chicken C interface Date: Thu, 06 Jun 2013 12:29:01 +0200 On 2013-06-06 12:19, Felix wrote: From: Thomas Chust ch...@web.de [...] when I first saw that code I thought that this must be incorrect, too. Then I checked the CHICKEN documentation for foreign-safe-lambda and read: This is similar to foreign-lambda, but also allows the called function to call Scheme functions and allocate Scheme data-objects. The part about allocation is wrong, I'd say. [...] Hello, thank you for the clarification :-) So what about allocating locally and not returning an object but passing it to a Scheme callback from inside a foreign-safe-lambda? Is that ok or can it happen that the callback stores this object away but never copies it into the second generation heap? That can indeed happen. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 12:34, Felix wrote: From: Thomas Chust ch...@web.de [...] So what about allocating locally and not returning an object but passing it to a Scheme callback from inside a foreign-safe-lambda? Is that ok or can it happen that the callback stores this object away but never copies it into the second generation heap? That can indeed happen. [...] Hello, interesting! In that case the documentation for foreign-safe-lambda should really be changed, I think. But I wonder how that could happen. C_callback basically has to run a minor garbage collection to unwind the stack before returning to the context enclosing the callback. Hence the only way I can imagine a value escaping the garbage collection is if the context enclosing the callback does a C_alloc but forgets to do a C_callback_adjust_stack and passes some stack allocated object into the callback. Then the garbage collector might think that this object lives in permanent storage and ignore it. Is this reasoning correct? Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 6/6/2013 2:59 AM, Thomas Chust wrote: Therefore foreign-primitive can do allocation in the nursery, but foreign-lambda can't. However, foreign-lambda could still allocate directly in the second generation heap or transfer nursery-allocated values directly into the heap upon return before the stack context is destroyed. The question is whether such magic is present for foreign-safe-lambda, as the documentation may indicate, or whether that is not the case, as Felix has indicated with his earlier message :-) I think such magic may exist, or I'm extraordinarily lucky. Objects I was constructing inside of a foreign-safe-lambda call were sitting at top-level in application instances that were running for quite an extended time, and themselves were frequently referenced. (IE, a foreign-safe-lambda constructed Color would be referenced as the clear-color repeatedly). -Dan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
From: Dan Leslie d...@ironoxide.ca Subject: Re: [Chicken-users] Chicken C interface Date: Thu, 06 Jun 2013 09:54:41 -0700 On 6/6/2013 2:59 AM, Thomas Chust wrote: Therefore foreign-primitive can do allocation in the nursery, but foreign-lambda can't. However, foreign-lambda could still allocate directly in the second generation heap or transfer nursery-allocated values directly into the heap upon return before the stack context is destroyed. The question is whether such magic is present for foreign-safe-lambda, as the documentation may indicate, or whether that is not the case, as Felix has indicated with his earlier message :-) I think such magic may exist, or I'm extraordinarily lucky. Objects I was constructing inside of a foreign-safe-lambda call were sitting at top-level in application instances that were running for quite an extended time, and themselves were frequently referenced. (IE, a foreign-safe-lambda constructed Color would be referenced as the clear-color repeatedly). It just depends on whether a minor GC happens quickly enough. Once copied, the values are safe. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken C interface
Hello everybody,
I was planning to use Chicken Scheme in a fashion more similar to Guile and
Lua. i.e. passing Scheme Data Objects from Chicken to C and back using the
C interface.
I am a little confused though as how to have a C function return a Scheme
List that is seen by the garbage collector.
For example, is the code below correct, will the list be seen by the
garbage collector? And if not, is there correct way to do this.
#
C_word give_12()
{
C_word *mem = C_alloc(C_SIZEOF_LIST(2));
C_word list = C_list(mem, 2, C_fix(1), C_fix(2));
return list;
}
#
(print ((foreign-lambda scheme-object give_12)))
Also there doesn't seem to be a C_listp predicate. Is this a concious
omission?
thank you in advance,
Richard
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
I do this a fair bit in the Allegro egg.
Here's an example:
https://github.com/dleslie/allegro-egg/blob/985ca2ceef0f5b4028af3f97729f13cba2976fe5/color.scm
Basically, use C_alloc to allocate the memory required to host both the
List structure and the data it is to contain, then use the C_list macro
to patch it all together.
-Dan
On 6/5/2013 8:10 AM, pluijzer . wrote:
Hello everybody,
I was planning to use Chicken Scheme in a fashion more similar to
Guile and Lua. i.e. passing Scheme Data Objects from Chicken to C and
back using the C interface.
I am a little confused though as how to have a C function return a
Scheme List that is seen by the garbage collector.
For example, is the code below correct, will the list be seen by the
garbage collector? And if not, is there correct way to do this.
#
C_word give_12()
{
C_word *mem = C_alloc(C_SIZEOF_LIST(2));
C_word list = C_list(mem, 2, C_fix(1), C_fix(2));
return list;
}
#
(print ((foreign-lambda scheme-object give_12)))
Also there doesn't seem to be a C_listp predicate. Is this a concious
omission?
thank you in advance,
Richard
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On Wed, Jun 05, 2013 at 08:47:45AM -0700, Dan Leslie wrote: I do this a fair bit in the Allegro egg. Here's an example: https://github.com/dleslie/allegro-egg/blob/985ca2ceef0f5b4028af3f97729f13cba2976fe5/color.scm Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Also there doesn't seem to be a C_listp predicate. Is this a concious omission? There is no C_listp predicate because you can't directly check an object for being a list; you must check whether it's C_SCHEME_END_OF_LIST (then it is a list). Otherwise, if it's a pair you take its cdr and loop. If it's something else, it's not a list. Because this is a potentially heavy operation (and cyclic lists may even cause an endless loop), I guess it's been decided not to provide a predicate procedure for this, because it's too tricky to get right, and usually you want to avoid traversing the list twice anyway, so the operation itself is often embedded in the CDRing logic. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-05 19:50, Peter Bex wrote: [...] There is no C_listp predicate because you can't directly check an object for being a list; you must check whether it's C_SCHEME_END_OF_LIST (then it is a list). Otherwise, if it's a pair you take its cdr and loop. If it's something else, it's not a list. Because this is a potentially heavy operation (and cyclic lists may even cause an endless loop), I guess it's been decided not to provide a predicate procedure for this, [...] Hello, but it's trivial to detect cyclic lists during the traversal using either a set of seen elements or just two iteration pointers travelling at different speeds. The only problematic structures are truly infinite lists without periodicity, but those are impossible with eager data structures like the standard Scheme lists. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On Wed, Jun 05, 2013 at 07:57:49PM +0200, Thomas Chust wrote: Hello, but it's trivial to detect cyclic lists during the traversal using either a set of seen elements or just two iteration pointers travelling at different speeds. In C that's rather painful. Note that the OP was asking specifically for a C_listp macro. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-05 20:11, Peter Bex wrote: On Wed, Jun 05, 2013 at 07:57:49PM +0200, Thomas Chust wrote: but it's trivial to detect cyclic lists during the traversal using either a set of seen elements or just two iteration pointers travelling at different speeds. In C that's rather painful. Note that the OP was asking specifically for a C_listp macro. [...] Hello, well, I think that two iteration pointers are trivial even in C, but that may be a matter of taste :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
this should work for basic list test
(import foreign)
#
C_word C_listp(C_word p)
{
if (p == C_SCHEME_END_OF_LIST)
{
return C_SCHEME_TRUE;
}
// check for non-immidiate object and pair?
if (!C_immediatep(p) C_pairp(p) ==
C_SCHEME_TRUE)
{
return
C_listp(C_u_i_cdr(p));
}
return C_SCHEME_FALSE;
}
#
(define listp? (foreign-lambda scheme-object "C_listp" scheme-object))
(print (listp? 1))
(print (listp? (cons 1 2)))
(print (listp? (cons (cons 1 2) (cons 3 4
(print (listp? 1.0))
(print (listp? '(1)))
(print (listp? '(1 2)))
06/05/13 19:10:41, pluijzer . pluij...@gmail.com:
Hello
everybody,
I was planning to use Chicken Scheme in a fashion more similar to
Guile and Lua. i.e. passing Scheme Data Objects from Chicken to C and back
using the C interface.
I am a little confused though as how to have a C function return a
Scheme List that is seen by the garbage collector.
For example, is the code below correct, will the list be seen by the
garbage collector? And if not, is there correct way to do this.
#
C_word give_12()
{
C_word *mem = C_alloc(C_SIZEOF_LIST(2));
C_word list = C_list(mem, 2, C_fix(1), C_fix(2));
return list;
}
#
(print ((foreign-lambda scheme-object "give_12")))
Also there doesn't seem to be a C_listp
predicate. Is this a concious omission?
thank you in advance,
Richard
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On Wed, Jun 05, 2013 at 08:19:15PM +0200, Thomas Chust wrote: On 2013-06-05 20:11, Peter Bex wrote: On Wed, Jun 05, 2013 at 07:57:49PM +0200, Thomas Chust wrote: but it's trivial to detect cyclic lists during the traversal using either a set of seen elements or just two iteration pointers travelling at different speeds. In C that's rather painful. Note that the OP was asking specifically for a C_listp macro. [...] Hello, well, I think that two iteration pointers are trivial even in C, but that may be a matter of taste :-) Of course you're right. I was thinking of the set of seen elements. I need sleep. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
From: Dan Leslie d...@ironoxide.ca Subject: Re: [Chicken-users] Chicken C interface Date: Wed, 05 Jun 2013 08:47:45 -0700 I do this a fair bit in the Allegro egg. Here's an example: https://github.com/dleslie/allegro-egg/blob/985ca2ceef0f5b4028af3f97729f13cba2976fe5/color.scm Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Note that this code is not correct: C_alloc allocates on the C stack and the data will be invalid once the function returns (Sorry). If this works, then it is just coincidental! cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
From: pluijzer . pluij...@gmail.com
Subject: [Chicken-users] Chicken C interface
Date: Wed, 5 Jun 2013 17:10:41 +0200
Hello everybody,
I was planning to use Chicken Scheme in a fashion more similar to Guile and
Lua. i.e. passing Scheme Data Objects from Chicken to C and back using the
C interface.
I am a little confused though as how to have a C function return a Scheme
List that is seen by the garbage collector.
For example, is the code below correct, will the list be seen by the
garbage collector? And if not, is there correct way to do this.
#
C_word give_12()
{
C_word *mem = C_alloc(C_SIZEOF_LIST(2));
C_word list = C_list(mem, 2, C_fix(1), C_fix(2));
return list;
}
#
(print ((foreign-lambda scheme-object give_12)))
As written in the other message: C_alloc is just a wrapper around alloca(3),
so returning from the function invalidates or overwrites the data. A later
(minor) garbage collection may actually recover the data, but it is not
certain that it happens. See
http://api.call-cc.org/doc/foreign/access/foreign-primitive
for a variant that allows stack-allocation.
cheers,
felix
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
Oh dear! Well, it works and I haven't had problems. What's the correct way to go about this? -Dan On 6/5/2013 2:36 PM, Felix wrote: From: Dan Leslie d...@ironoxide.ca Subject: Re: [Chicken-users] Chicken C interface Date: Wed, 05 Jun 2013 08:47:45 -0700 I do this a fair bit in the Allegro egg. Here's an example: https://github.com/dleslie/allegro-egg/blob/985ca2ceef0f5b4028af3f97729f13cba2976fe5/color.scm Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Note that this code is not correct: C_alloc allocates on the C stack and the data will be invalid once the function returns (Sorry). If this works, then it is just coincidental! cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
Thanks, I'll get on updating my broken eggs soon.
obvious humpty dumpty joke notwithstanding
-Dan
On 6/5/2013 2:39 PM, Felix wrote:
From: pluijzer . pluij...@gmail.com
Subject: [Chicken-users] Chicken C interface
Date: Wed, 5 Jun 2013 17:10:41 +0200
Hello everybody,
I was planning to use Chicken Scheme in a fashion more similar to Guile and
Lua. i.e. passing Scheme Data Objects from Chicken to C and back using the
C interface.
I am a little confused though as how to have a C function return a Scheme
List that is seen by the garbage collector.
For example, is the code below correct, will the list be seen by the
garbage collector? And if not, is there correct way to do this.
#
C_word give_12()
{
C_word *mem = C_alloc(C_SIZEOF_LIST(2));
C_word list = C_list(mem, 2, C_fix(1), C_fix(2));
return list;
}
#
(print ((foreign-lambda scheme-object give_12)))
As written in the other message: C_alloc is just a wrapper around alloca(3),
so returning from the function invalidates or overwrites the data. A later
(minor) garbage collection may actually recover the data, but it is not
certain that it happens. See
http://api.call-cc.org/doc/foreign/access/foreign-primitive
for a variant that allows stack-allocation.
cheers,
felix
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
I just though I'd mention srfi-4 http://api.call-cc.org/doc/srfi-4 as
well, which are much easier to interface with from C. If all your elements
are integers, for example, you might want to check out u32vector. Srfi-4
vectors use plain C float/int arrays and are possible as argument-types
from foreign-lambda and friends.
K.
On Wed, Jun 5, 2013 at 5:10 PM, pluijzer . pluij...@gmail.com wrote:
Hello everybody,
I was planning to use Chicken Scheme in a fashion more similar to Guile
and Lua. i.e. passing Scheme Data Objects from Chicken to C and back using
the C interface.
I am a little confused though as how to have a C function return a Scheme
List that is seen by the garbage collector.
For example, is the code below correct, will the list be seen by the
garbage collector? And if not, is there correct way to do this.
#
C_word give_12()
{
C_word *mem = C_alloc(C_SIZEOF_LIST(2));
C_word list = C_list(mem, 2, C_fix(1), C_fix(2));
return list;
}
#
(print ((foreign-lambda scheme-object give_12)))
Also there doesn't seem to be a C_listp predicate. Is this a concious
omission?
thank you in advance,
Richard
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
The correct way is to not let C manage memory at all ;-P In the mpi egg, I used foreign-primitive and C_alloc as follows: ;; Returns the current MPI time as a floating-point number (define MPI:wtime (foreign-primitive scheme-object () #EOF C_word result; C_word *ptr; ptr = C_alloc (C_SIZEOF_FLONUM); result = C_number(ptr, MPI_Wtime()); C_return (result); EOF )) In various other C interface libraries, I use the following idiom: (define (func arg) ;; determine the size of the result vector (let* ((n (c_func_result_length arg)) ;; allocate memory for the result vector (v (make-f64vector n 0.0))) ;; obtain result (c_func arg v) v)) This of course assumes that the C library you are targeting is structured so as to allow you to determine the result size. This is often the case with various numerical libraries I have had to interface to, but that's a fairly specific use case. -Ivan On Thu, Jun 6, 2013 at 6:45 AM, Dan Leslie d...@ironoxide.ca wrote: Oh dear! Well, it works and I haven't had problems. What's the correct way to go about this? -Dan On 6/5/2013 2:36 PM, Felix wrote: From: Dan Leslie d...@ironoxide.ca Subject: Re: [Chicken-users] Chicken C interface Date: Wed, 05 Jun 2013 08:47:45 -0700 I do this a fair bit in the Allegro egg. Here's an example: https://github.com/dleslie/**allegro-egg/blob/** 985ca2ceef0f5b4028af3f97729f13**cba2976fe5/color.scmhttps://github.com/dleslie/allegro-egg/blob/985ca2ceef0f5b4028af3f97729f13cba2976fe5/color.scm Basically, use C_alloc to allocate the memory required to host both the List structure and the data it is to contain, then use the C_list macro to patch it all together. Note that this code is not correct: C_alloc allocates on the C stack and the data will be invalid once the function returns (Sorry). If this works, then it is just coincidental! cheers, felix __**_ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/**mailman/listinfo/chicken-usershttps://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
