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] [ANN] usb egg v0.1.0 is released
Hello Aaron, We're just started looking at your chicken-usb egg. The API is much more intuitive than Python'shttp://pyusb.sourceforge.net/docs/1.0/tutorial.html! Might it be a good idea to define a record printer for #usb-device records to include the vendor and product ids, and perhaps serial-number? That way, we could quickly test like this: $ csi -R usb -p '(usb-devices (usb-make-context))' (#usb-device #usb-device #usb-device #usb-device) ;; I'd love to get (#usb-device idVendor: 0x1234 idProduct: 0x3214 ...) Cheers, K. On Wed, May 8, 2013 at 11:36 PM, Kristian Lein-Mathisen kristianl...@gmail.com wrote: Hello Aaron, I can't believe nobody has commented on this yet - this is really cool! I have no experience with libusb, but it seems this is how you'd start if you're trying to make your own USB driver or investigating someone else's. I hope I run into a problem where I need lolevel USB access like this :) a usbrepl like this must be really handy. Thanks for your contribution! K. On Apr 22, 2013 7:18 PM, Aaron Patterson tenderl...@ruby-lang.org wrote: Hi everyone! I laid my first egg, and I'm emailing here to inform you of its existence. This egg wraps libusb and gives you a scheme API. Here is the repository: https://github.com/tenderlove/chicken-usb My scheme is not fully hatched, and this code is not 100% complete (as noted in the README). Thanks everyone! -- Aaron Patterson http://tenderlovemaking.com/ ___ 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
[Chicken-users] A Scheme based make - soliciting you comments
Hi all, these days I ran (again as every once in a while) a case which made me longing for a make(1) in Scheme. Gave the make egg a try and… decided I'd need something else. Something powerful enough to make it easier to maintain Chickens build and similar complex things. So far I ended up with something working. I'm not yet sure that it's worth the effort to document/release it, so please tell me if you like it. Furthermore, and even more important: there's a bit of syntax defined. In attempt to avoid the worst pitfalls (as in The Three Laws of Programming Language Design http://lambda-the-ultimate.org/node/4754 ) I'd love to read your bitching on the following. Best Regards /Jörg The rest is the scheme makefile for the scheme make itself. Insofar it's working. (Just the windows part is fake; only used unix so far. The conditional stuff however works.) ;; The following line retrieves the tharget to make from the environment ;; variable make using ssx as default value. #(make: make ssx) ;; The syntax of the following is really subject to discussion. ;; ;; It is essentially equivalent to ;; ;; (define FEAT_ORIG v1 ;; ;; A different syntax seems to be in order because in constrast to the ;; semantics of a normal `define`, the *first* definition seen is ;; used; no overwrites. Additionally there is an environment lookup ;; to FEAT_ORIG; if the environment variable is set, it determines ;; the value. The value v1 just a default. #(param: FEAT_ORIG v1) ;; expose -feature arg to call site #(param: PLATFORM unix or windows, see below) ;; Expose tracing to potential overwrite by invocation. #(param: CSCTRACE '(-no-trace -no-lambda-info)) ;; `define-dir` and `define-file` declare binding to some directory or ;; file. This is mostly useful to avoid the system's directory ;; separator showing up in the source code. (define-dir PMPTH ..) ; path to pre-made stuff (define CSCINCLUDE `(-I ,PMPTH)) (define CSC csc) (define cscflags.opt `(-O3 ,CSCTRACE)) ;; conditional ex-/inclusion ;; ;; Comments on the syntax to be used again very much solicited. ;; ;; * Conditionals are ONLY available at top-level and must find their ;; corresponding #(end) token in the same file. For rationale see ;; SRFI-0. ;; * This syntax is NOT in s-expressions. Rationale: Be friendly ;; diff(1) and maintainers. Those are often late additions or even ;; temporary measurements. Good practise is to adhere indentiation ;; rules (often done by automatic means). If this would introduce ;; additional nesting, too much un-changed source ends up in the ;; diff. ;; * By now there is no else clause. Convince me that it's good to ;; have. So far I feel it's clearer to enforce all cases to be ;; stated explicit. Users who really need an else can always do ;; via variables beeing defined in the individual branches. #(if: (equal? PLATFORM unix) ) (define ext.obj o) #(end) #(if: (equal? PLATFORM windows) ) (define ext.obj obj) #(end) (define (csc x . o) ;; `result-file` and `source-file` are not mandatory to be used. ;; Those are convinience-and-saftey related: they return their ;; argument; as side effect the file is registered as source or ;; result. An exception is raised upo attempt to overwrite a file ;; declared with the source property. (let ((o (result-file (if (pair? o) (car o) (filename #f x ext.obj) (run CSC cscflags.opt CSCINCLUDE '-J -c x '-emit-type-file (result-file (filename #f x types)) -o o))) ;; Same as above, but with -compile-syntax . (define (csc/syntax module into) (run `(,CSC -feature ,FEAT_ORIG -O3 -c ,module -compile-syntax ,CSCINCLUDE -J -emit-type-file ,(result-file (filename #f module types)) -o ,(result-file into ;; Comments may use Scheme syntax, even though this loks weird here. #; #(Imported objects not (yet) build here.) (define SSX_PM_OBJECTS (map ;; `filename` is some crazy syntax using decompose-pathname, ;; make-pathname and friends behind the scene. It accepts symbols ;; instead of strings for components and flattens nested lists in ;; the path for convenience. (You don't want them here and doing ;; the right thing in plain Scheme is just an error prone, tedious ;; task whose only outcome is source clutter in this context.) (lambda (o) (filename PMPTH o o)) '(srfi-34 srfi-35 matchable))) (define SSX_OBJECTS (map (lambda (o) (filename #f o 'o)) '(alexpander synclo ssx-divert make))) ;; The `make(1)` alike part. Declares a target, it's dependencies and ;; a list of commands (here only one) to build it. Nested lists are ;; in the depenciencies flattened secretly. ;; ;; `make-rule` is syntax. It will only register the rule. No ;; immediate actions (except for some validation). Actions are run ;; once all input files are evaluated. ((This leads to the question ;; whether or not we should allow redefinition of
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
