Re: [Chicken-users] Re: Style Guide
Am Montag, den 05.11.2007, 17:42 +0100 schrieb Sunnan: Mark Fredrickson wrote: Here's a related question for more experienced Schemers: In Dybvig, he states that the define form: (define square (lambda (x) (* x x))) is to be preferred to (define (square x) (* x x)) After reading that, I started using the first form religiously. Now I'm not so sure. For no small part because the text editor I use (TextMate) doesn't highlight the first form as a function definition but does highlight the second form. The second form. Shorter is better. Always, always, always. For pure chicken code this maybe correct. But some Scheme implementations happen to treat the former form as a global variable, which can be set! later on, while the latter is beeing compiled into a static binding and set! on it will raise an error. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Static eggs query (was Re: [Chicken-users] ok my first egg is ready)
Hi all, This egg announcement inspired me to ask a couple of questions - On 06/11 07:09:28, felix winkelmann wrote: On 11/6/07, naruto canada [EMAIL PROTECTED] wrote: ok my first egg is ready. [ ... ] http://downloads.sourceforge.net/math-linux/predicate-calculus.egg Thanks, Naruto! I have added the egg to the repository, it should be available soon. I've recently been trying to work out how to build a Chicken app with statically-linked extensions. This was useful: http://galinha.ucpel.tche.br:8080/chicken-setup#linking-extensions-statically The instructions mostly worked correctly (see example below), though the only way I could think to make absolutely sure it was linking an extension statically was to make the contents of /usr/local/lib/chicken/3 temporarily unreadable. Using Naruto's predicate-calculus egg as a test (thanks, Naruto :)), I modified the predicate-calculus.setup as described in the above link (patch attached) and rebuilt/reinstalled it - then made a trivial test program: pct.scm (declare (uses predicate-calculus)) (begin (display This is a static-linking test.) (newline) (write (clausal-form '(all x (all y (= (P x y) (Q x y)) (newline) (display The above line should show \(((not (P ?x10 ?x11)) (Q ?x10 ?x11)))\.) (newline)) pct.scm I managed to build a standalone executable like so (using '$' to indicate a shell prompt): $ csc -c++ -static-extensions -c pct.scm $ csc -c++ -static-libs pct.o /usr/local/lib/chicken/3/predicate-calculus.o -o pct (though the -static-libs wasn't necessary just to link the extension statically, of course) Anyway, the upshot is that I have two questions. If anyone can suggest an answer (or two), that'd be good :-). First - is there a nicer way to build a Chicken app with statically-linked extensions? To clarify, I mean that I couldn't figure out a way to build a working pct without explicitly including /usr/local/lib/chicken/3/predicate-calculus.o in the link phase (see above). Is there a way to avoid this? The chicken-setup link above suggests that it could be done like the below, but this doesn't work: $ csc -static-extensions pct.scm -uses predicate-calculus pct.o: In function `f_26': pct.c:(.text+0x5cc): undefined reference to `C_predicate_calculus_toplevel' pct.o: In function `f_23': pct.c:(.text+0x643): undefined reference to `C_predicate_calculus_toplevel' collect2: ld returned 1 exit status *** Shell command terminated with exit status 1: gcc pct.o -o pct -L/usr/local/lib -Wl,-R/usr/local/lib -lm -ldl -lchicken $ This doesn't really matter a _great_ deal - I can explicitly link the extension .o files in the final link phase without too much effort - I just feel that it should be something the compiler can work out for me. Maybe. :) Second question (or perhaps a group of questions) - does anyone have any idea how many of the 348 or so Chicken eggs are set up for static linking? The link I mentioned above states: If you require a statically linkable version of an egg that has not been converted yet, contact the extension author or the CHICKEN mailing list. Is there a Grand Plan(tm) to convert existing eggs for static linking? It looks like the process should be pretty straightforward, but just hasn't been done yet for some (many? most? all?) eggs. Of course I appreciate that some (many? most?) Chicken users may not care very much about statically-linkable extensions, but... er... well, I think some of us do. :) If it's largely a matter of just doing the boring grunt work of patching the .setup files and testing... well, I'm happy to try doing that, at least for the eggs that I use most frequently (Naruto, see attached :)). Or are there some hideously tricky potential problems that I haven't noticed yet? If so, I bet it involves those bloody macros. Sigh. BTW, the current egg count is 348. Two more to go! I'm sure CPAN will have to admit defeat soon. :-) cheers, felix Thanks, Pete. -- Expressions including c (call-with-current-continuation) function calls tend to be hopelessly difficult to track down. This was, of course, the reason for including it in the language in the first place. -- Unlambda: Your Functional Programming Language Nightmares Come True --- predicate-calculus.setup 2007-11-06 21:23:34.0 +1100 +++ predicate-calculus-static.setup 2007-11-06 21:22:39.0 +1100 @@ -1,10 +1,12 @@ (compile -s -O2 -d1 predicate-calculus.scm) +(compile -c -O2 -d1 predicate-calculus -unit predicate-calculus) ; static (install-extension ; Name of your extension: `predicate-calculus ; Files to install for your extension: - `(predicate-calculus.so predicate-calculus.html) + `(predicate-calculus.so predicate-calculus.o predicate-calculus.html) ; Assoc list with properties for your extension: - `((version 0.9) + `((static predicate-calculus.o) +
Re: cross-compilation, part II - Re: [Chicken-users] cross compilation with 2.7
I notice in chicken-config.h #ifndef C_TARGET_CC # define C_TARGET_CC arm=linux-gcc #endif #ifndef C_TARGET_CXX # define C_TARGET_CXX arm=linux-g++ #endif I don't seem to be able to override these from the command line. My make was: make PLATFORM=linux TARGET_PREFIX=$HOME/moko/arm-chicken TARGET_CC=/home/john/moko/build/tmp/cross/bin/arm-angstrom-linux-gnueabi-gcc TARGET_CXX=/home/john/moko/build/tmp/cross/bin/arm-angstrom-linux-gnueabi-g++ PREFIX=$HOME/moko/arm-cross-chicken TARGET_RUN_PREFIX=/usr/local Btw, I am just building directly from the trunk which worked fine for building the ARM version of Chicken. The cross Chicken also built this way. I am not actually sure how to build a tarball from the trunk. I did not find a rule for 'make dist'. No doubt I am doing something daft as this is the first time I have tried the new build system since autoconf. Cheers, John. On 06/11/2007, felix winkelmann [EMAIL PROTECTED] wrote: On 11/6/07, john [EMAIL PROTECTED] wrote: Thanks Felix. I managed to build from the svn trunk for my Linux ARM setup. I am having problems getting the cross Chicken running. I was able to build it but I am not able to set the correct correct compilers. In a previous version I specified them for the build with: TARGET_CC=/home/john/moko/build/tmp/cross/bin/arm-angstrom-linux-gnueabi-gcc TARGET_CXX=/home/john/moko/build/tmp/cross/bin/arm-angstrom-linux-gnueabi-g++ Incidently, ./arm-csc -cc-name reports: arm=linux-gcc which I guess is a meant to be 'arm-linux-gcc'. Hm. Could this be a typo in your make invocation? Can you build the cross chicken once again, and send me a build log? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Style Guide
Jörg F. Wittenberger wrote: For pure chicken code this maybe correct. But some Scheme implementations happen to treat the former form as a global variable, which can be set! later on, while the latter is beeing compiled into a static binding and set! on it will raise an error. Thanks for this clarification, I didn't know that. However, since I only seldomly use set! on functions, I guess I'd prefer the latter form anyway. One notable exception is this (disgusting?) idiom I invented for making generators without call/cc yield: (define (fib) (let loop ((a 1) (b 1)) (set! fib (lambda () (loop b (+ a b a)) ;; maybe non-portable outside of current chicken semantics? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Style Guide
On Nov 6, 2007, at 6:30 AM, Sunnan wrote: Jörg F. Wittenberger wrote: For pure chicken code this maybe correct. But some Scheme implementations happen to treat the former form as a global variable, which can be set! later on, while the latter is beeing compiled into a static binding and set! on it will raise an error. Thanks for this clarification, I didn't know that. However, since I only seldomly use set! on functions, I guess I'd prefer the latter form anyway. One notable exception is this (disgusting?) idiom I invented for making generators without call/cc yield: (define (fib) (let loop ((a 1) (b 1)) (set! fib (lambda () (loop b (+ a b a)) ;; maybe non-portable outside of current chicken semantics? Except for the caveat about some compilers, no. However the above doesn't make a generator, in the sense that it can be reused. To restart the sequence 'fib' must be rebound. Certainly not disgusting, just of limited use. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Static eggs query (was Re: [Chicken-users] ok my first egg is ready)
On 11/6/07, Peter Wright [EMAIL PROTECTED] wrote: Hi all, This egg announcement inspired me to ask a couple of questions - On 06/11 07:09:28, felix winkelmann wrote: On 11/6/07, naruto canada [EMAIL PROTECTED] wrote: ok my first egg is ready. [ ... ] http://downloads.sourceforge.net/math-linux/predicate-calculus.egg Thanks, Naruto! I have added the egg to the repository, it should be available soon. I've recently been trying to work out how to build a Chicken app with statically-linked extensions. This was useful: http://galinha.ucpel.tche.br:8080/chicken-setup#linking-extensions-statically The instructions mostly worked correctly (see example below), though the only way I could think to make absolutely sure it was linking an extension statically was to make the contents of /usr/local/lib/chicken/3 temporarily unreadable. Using Naruto's predicate-calculus egg as a test (thanks, Naruto :)), I modified the predicate-calculus.setup as described in the above link (patch attached) and rebuilt/reinstalled it - then made a trivial test program: pct.scm (declare (uses predicate-calculus)) (begin (display This is a static-linking test.) (newline) (write (clausal-form '(all x (all y (= (P x y) (Q x y)) (newline) (display The above line should show \(((not (P ?x10 ?x11)) (Q ?x10 ?x11)))\.) (newline)) pct.scm I managed to build a standalone executable like so (using '$' to indicate a shell prompt): $ csc -c++ -static-extensions -c pct.scm $ csc -c++ -static-libs pct.o /usr/local/lib/chicken/3/predicate-calculus.o -o pct (though the -static-libs wasn't necessary just to link the extension statically, of course) Anyway, the upshot is that I have two questions. If anyone can suggest an answer (or two), that'd be good :-). First - is there a nicer way to build a Chicken app with statically-linked extensions? To clarify, I mean that I couldn't figure out a way to build a working pct without explicitly including /usr/local/lib/chicken/3/predicate-calculus.o in the link phase (see above). Is there a way to avoid this? The chicken-setup link above suggests that it could be done like the below, but this doesn't work: $ csc -static-extensions pct.scm -uses predicate-calculus pct.o: In function `f_26': pct.c:(.text+0x5cc): undefined reference to `C_predicate_calculus_toplevel' pct.o: In function `f_23': pct.c:(.text+0x643): undefined reference to `C_predicate_calculus_toplevel' collect2: ld returned 1 exit status *** Shell command terminated with exit status 1: gcc pct.o -o pct -L/usr/local/lib -Wl,-R/usr/local/lib -lm -ldl -lchicken $ This doesn't really matter a _great_ deal - I can explicitly link the extension .o files in the final link phase without too much effort - I just feel that it should be something the compiler can work out for me. Maybe. :) Second question (or perhaps a group of questions) - does anyone have any idea how many of the 348 or so Chicken eggs are set up for static linking? The link I mentioned above states: If you require a statically linkable version of an egg that has not been converted yet, contact the extension author or the CHICKEN mailing list. Is there a Grand Plan(tm) to convert existing eggs for static linking? It looks like the process should be pretty straightforward, but just hasn't been done yet for some (many? most? all?) eggs. There are three steps to solve your problem completely. First step is to simply recreate all the eggs' .setup file to simultaneously build both .so and .o. [EMAIL PROTECTED]: /root/t cat predicate-calculus.setup (compile -s -O2 -d1 predicate-calculus.scm) (compile -c -O2 -d1 predicate-calculus.scm -unit predicate-calculus) (install-extension ... `(predicate-calculus.o predicate-calculus.so predicate-calculus.html) ... Second step is simply left a choice for the person who wants static lib to do like this: ar rv liball.a /usr/lib/chicken/3/*.o csc -c++ -static-extensions -c pct.scm csc -c++ -static -static-libs pct.o -o pct -lall -L. Third step requires that egg tutorial be amended to instruct future egg writer to create both .so and .o in their .setup file. Thanks. Of course I appreciate that some (many? most?) Chicken users may not care very much about statically-linkable extensions, but... er... well, I think some of us do. :) If it's largely a matter of just doing the boring grunt work of patching the .setup files and testing... well, I'm happy to try doing that, at least for the eggs that I use most frequently (Naruto, see attached :)). Or are there some hideously tricky potential problems that I haven't noticed yet? If so, I bet it involves those bloody macros. Sigh. BTW, the current egg count is 348. Two more to go! I'm sure CPAN will have to admit defeat soon. :-) cheers, felix
Re: [Chicken-users] srfi-27 - producing pseudo and truly random numbers over a uniform distribution
On Oct 28, 2007, at 2:55 PM, Terrence Brannon wrote: In addition to the bug I filed on this egg - http://trac.callcc.org/ ticket/346 I have a question about common usage of this module. I would like to produce one function, roll-fixed, which produces pseudorandom numbers in the documented fashion of random-real and random in SRFI-27. Such that the sequence of randoms (over a uniform distribution) is predictable on each new startup of the intepreter: (define *fixed-seed* (expt 7 5)) (define roll-fixed (let ([side-effect (set-seed *fixed-seed*)]) (lambda (n) (if (zero? n) (random-real-based-on-fixed-seed) (random-integer-based-on-fixed-seed n) (use entropy-fixed) ; A fixed seed entropy struct (define fixed-seed (make-procedure-entropy-structure (let ([*fixed-seed* (expt 7 5)]) (lambda () *fixed-seed*)) fixed seed: (expt 7 5) ) ) ; This uses the 'current-random-source-structure' (define (roll-fixed n) (if (zero? n) (random-integer) (random-real) ) ) ; As default entropy: (current-entropy-source-structure fixed-seed) (random-source-randomize! default-random-source) ; Or: (random-source-randomize!/entropy default-random-source fixed-seed) Also, the random-state of a random-structure can be saved restored. So each run can load a file w/ a random-state before getting a random sequence. Note, until the new release is posted 'entropy-fixed' 'random- source-randomize!/entropy' are unavailable. 'entropy-fixed' is in the posted egg but is not in the .setup (I forgot it). Additionally, I would like a function, roll-truly-random, which again can produce reals or integer randoms, but whose sequence of randoms (over a uniform distribution) is different across each new startup of the interpreter. (define roll-truly-random (let ([side-effect (set-seed (truly-random-seed))]) (lambda (n) (if (zero? n) (random-real-based-on-truly-random-seed) (random-integer-based-on-truly-random-seed n) What is '(truly-random-seed)'? Currently the entropy structures 'dev-random-entropy', 'dev-urandom- entropy' are defined for unix 'crypt-random-entropy' for windows, and 'current-seconds-entropy' (for both platforms). Note that SRFI-27 does not define entropy sources - it just assumes there is one. I'm sorry to beg for such hand-holding, but it seems like the Issues section of the docs does admit that this library could use a few good examples. It also mentions that the API creates something of a hurdle for my desire to have two distinct random structures available in two distinct functions. You cannot have distinct random structures but you can have distinct random sources. (Well, you can, MWC is distinct from MOA but I doubt you want to define your own random number algorithm.) (use mwc mrg32k3a moa) (define my-mwc-source ((MWC 'make-random-source))) (define my-moa-source ((MOA 'make-random-source))) (define my-mrg-source ((MRG32k3a 'make-random-source))) (define my-mwc-random-integer (random-source-make-integers my-mwc- source)) (define my-mwc-random-real (random-source-make-reals my-mwc-source)) ... (random-source-randomize!/entropy my-mwc-source fixed-seed) (my-mwc-random-integer 23) ; [0 23) ... (use srfi-27-distributions) (define my-mwc-random-integers (make-uniform-random-integers 22 15 1 my-mwc-source)) (my-mwc-random-integers) ; [15 22] by 1 SRFI-27 was written assuming only one pseudo-random algorithm a simple module system. While I could have extracted the random source agnostic procedures it seemed better to just follow the spec. In any case a random structure is open upon load so these procedures are always available. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Static eggs query (was Re: [Chicken-users] ok my first egg is ready)
On 06/11 17:58:28, naruto canada wrote: There are three steps to solve your problem completely. [ ... ] Second step is simply left a choice for the person who wants static lib to do like this: ar rv liball.a /usr/lib/chicken/3/*.o csc -c++ -static-extensions -c pct.scm csc -c++ -static -static-libs pct.o -o pct -lall -L. Ah, of course. Blindingly obvious in hindsight, but it simply didn't occur to me. Thanks for that. There are probably a few other ways it can be done, but I like that one (I prefer to err in favour of simplicity, where possible). Third step requires that egg tutorial be amended to instruct future egg writer to create both .so and .o in their .setup file. That'd probably help, yeah. :) Pete. -- People who set up online petitions are wasting oxygen that would be better spent on farting. -- Eric the Fruitbat ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: cross-compilation, part II - Re: [Chicken-users] cross compilation with 2.7
On Nov 6, 2007 3:31 PM, john [EMAIL PROTECTED] wrote: I notice in chicken-config.h #ifndef C_TARGET_CC # define C_TARGET_CC arm=linux-gcc #endif #ifndef C_TARGET_CXX # define C_TARGET_CXX arm=linux-g++ #endif This must be a typo in the make invocation. I don't seem to be able to override these from the command line. My make was: make PLATFORM=linux TARGET_PREFIX=$HOME/moko/arm-chicken TARGET_CC=/home/john/moko/build/tmp/cross/bin/arm-angstrom-linux-gnueabi-gcc TARGET_CXX=/home/john/moko/build/tmp/cross/bin/arm-angstrom-linux-gnueabi-g++ PREFIX=$HOME/moko/arm-cross-chicken TARGET_RUN_PREFIX=/usr/local Replace TARGET_CC and TARGET_CXX with TARGET_C_COMPILER and TARGET_CXX_COMPILER, respectively. Alternatively, put .../cross/bin into your path and set TARGET=arm-angstrom-linux-gnueabi. Btw, I am just building directly from the trunk which worked fine for building the ARM version of Chicken. The cross Chicken also built this way. I am not actually sure how to build a tarball from the trunk. I did not find a rule for 'make dist'. There is no dist target, in the moment. Run csi -s misc/makedist.scm instead. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Static eggs query (was Re: [Chicken-users] ok my first egg is ready)
On Nov 6, 2007 6:58 PM, naruto canada [EMAIL PROTECTED] wrote: Third step requires that egg tutorial be amended to instruct future egg writer to create both .so and .o in their .setup file. Yes, someone should add a note in the tutorial - it's a wiki after all (HINT! HINT! ;-) cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Question about find-files
Thanks, Ivan. I have added this. cheers felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken bug?
On Nov 5, 2007 4:30 AM, naruto canada [EMAIL PROTECTED] wrote: Ok, I don't know what to make of this. One thing I noticed was that row-reduce should never have been called. This example don't use row-reduce. I assume you are calling a continuation with zero return values, probably in a non-values context. This is according to R5RS not defined, and in chicken works most of the times, but not always, depending on context. To see a longer backtrace, invoke csi with -:a256, for example. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
