Re: [Chicken-users] string-translate and utf-8
Well; here's a transcript: CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 3.2.7 - linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables applyhook hostpcre ] compiled 2008-08-21 on debian (Linux) #;1> (string-translate " i " "ö " "o_") Error: (string-translate) invalid translation destination 0 "o_" Call history: (string-translate " i " "ö " "o_") (string-translate " i " "ö " "o_") <-- #;1> (require-extension utf8) ; loading /var/lib/chicken/3/utf8.scm ... ; loading /var/lib/chicken/3/utf8-support.so ... ; loading /var/lib/chicken/3/utf8-lolevel.so ... ; loading /var/lib/chicken/3/byte-string.so ... #;2> (string-translate " i " "ö " "o_") Error: (vector-ref) out of range #(#\o #\_) 2 Call history: (string-translate " i " "ö " "o_") (string-translate " i " "ö " "o_") <-- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] string-translate and utf-8
I'm updating old code that used to work: (require-extension syntax-case utf8 srfi-1 utf8-srfi-13 miscmacros) ;(import utf8) ;(import utf8-srfi-13) ;(commented out since they're not needed anymore?) (use utf8-srfi-13) ;(I've tried with and without this line) (string-translate " i " "ö " "o_") ;; this should eval to "_i_" but i get Error: (vector-ref) out of range, I guess because it reads the multi-byte characters (i.e. #\ö) as multiple entries in the vector. My chicken is from debian, see: Version 3.2.7 - linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables applyhook hostpcre ] compiled 2008-08-21 on debian (Linux) Any ideas on how to fix this? Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Style Guide
Ivan Shmakov wrote: >>>>>> Sunnan <[EMAIL PROTECTED]> writes: > > (define (fib) > > (let loop ((a 1) (b 1)) > > (set! fib (lambda () (loop b (+ a b > > a)) > > This `set!' isn't necessary, compare: > > (define fib > (let ((a 1) (b 1)) > (lambda () > (let ((saved a)) > (set! a b) > (set! b (+ saved b)) > saved Yes, this is the longer, classic style. As a fib generator with only two counters, it works fine, but you have to save the entire state "by hand" with a set! for each original variable, and you also introduce an extra variable for the "swap". Your version is probably faster, and probably more familiar to many programmers. I was just fascinated by the two perverse ideas of 1. freezing a delayed call to a named let 2. resetting/redefining the very function we're in (similar to some call/cc tricks) > Both variants should be quite portable. (Especially on > non-compilers.) > Thanks. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Style Guide
Kon Lovett wrote: (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. I've used the idiom for more complex generators with multiple yield points but it quickly becomes tangled. I don't like the programming style that too many generators afford, so I don't do this so much. I usually use generator for generating ids where http://okmij.org/ftp/Scheme/monad-in-Scheme.html would use either a global variable or a state monad. Sunnan ___ 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
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. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Eggology
felix winkelmann wrote: I agree with Benedikt that dependencies should be kept at a minimum. It starts with simple sharing of code but quickly everything ends up in a tangle of dependencies that no one can comprehend. What's the alternative? Should "tool" implement its own args documentation? Should array-lib implement its own miscmacros? "tool" is a good example: tool -> srfi-37, args-doc args-doc -> srfi-37, srfi-95 srfi-95 -> array-lib array-lib -> srfi-42, miscmacros, misc-extn srfi-42 -> syntax-case This is insane. That example is a tree of non-circular dependencies. Syntax-case is low-level, srfi-42 and miscmacros are control structures... This is part of what lisp is to me; layers upon layers of code. Of course, I'm not saying that dependencies are an end in itself; I'm just wondering if you or Benedikt have an alternative suggestion. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Eggology
Ivan Raikov wrote: Another solution would be to modify salmonella to construct a dependency graph for all eggs and issue a warning for each dependency cycle detected. That would detect the problems, but wouldn't really solve them. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Eggology
Benedikt Rosenau wrote: Anyway, I propose the following: please keep dependencies between eggs small. I disagree; sometimes, it seems better to split common code to libraries than to have duplication. Dependencies can be hell, but so can duplication. Further, no mutual dependencies (A needs B, and B needs A) should be created. I guess I can agree with that. If that should happen, here are two solutions to that: Either: 1) create a third package, C, with the stuff from A that B depends on, so that A depends on B and C, and B depends on C, or: 2) join the two packages. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] libffi and cmake on gnu/linux again
felix winkelmann wrote: It should be possible to modify the compiler- and linker flags in ccmake to use libffi. Thanks. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] libffi and cmake on gnu/linux again
felix winkelmann wrote: BTW, in ccmake you can simply press "e" and continue. It should still be able to generate a makefile. OK. I was concerned that that would build a version of chicken without libffi support. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] libffi and cmake on gnu/linux again
I haven't compiled chicken for a while, but now I'm trying to compile darcs head. The first step is to run ccmake . , right? Well, it says that it can't compile the libffi test. I don't know where to go from there or troubleshoot this further; I've got these files: /. /usr /usr/share /usr/share/doc /usr/include /usr/include/ffi.h /usr/include/ffitarget.h /usr/lib /usr/lib/libffi.a /usr/lib/libffi.la /usr/lib/libffi_pic.a /usr/lib64 /usr/lib64/libffi.a /usr/lib64/libffi.la /usr/lib64/libffi_pic.a /usr/share/doc/libffi4-dev /usr/lib/libffi.so /usr/lib64/libffi.so Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Syntactic sugar for regular expressions and URIs
Arto Bendiken wrote: Now, I know that marring the purity of Scheme with arguably gratuitous [surface] syntax won't appeal to everyone, I agree with this. I even have a problem reading the [] as an alternative to () that some people use. I even kind of long for scsh-style SRE's because I dislike non-sexp-syntaxes so much. (quote and quasiquote are grandfathered in because it's so useful to toggle between data and code.) Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS Rant
Kon Lovett wrote: If I may be so bold, it seems the greatest issue is the "library" arena. Drop it. Define a core only. There is so many similar extensions of R5RS in std use that an agreeable R6RS would not be a rewrite of R5RS. (BTW, I think the full numeric tower & extended characters/strings should be core. Doesn't mean a compiler can't be told to not use them.) What I miss most from R5RS is the user-visible way to include and/or define libraries. Today I use chicken and write (require-extension extension-names ...) but I'd love for this to be the same across most Schemes. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
felix winkelmann wrote: A stalin-compat library? No problem. It wasn't so much a request as an example of what people can do. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
bryan rasmussen wrote: Hi, I was wondering about integration between Chicken and Stalin, has anyone ever done anything to use the two together in any way? 1. Stalin reads sexps, chicken writes sexps (or vice versa) 2. Develop with a subset of chicken, deploy with stalin 3. Separate processes with fork/exec or client/server ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Choosing chicken
Shawn W. wrote: For more specific tasks, some schemes are better suited than others -- if you want good java integration instead of C, you'll want kawa. Is kawa still being actively developed? I'm looking for a good java scheme and I haven't settled yet. (Sisc may be faster, and it may be the one I end up with, but it seems underdocumented to me.) If you want a small extension language for an existing program written in something besides scheme, tinyscheme or guile come to mind. If that something-beside-scheme is C, I'd probably go with Chicken. To get screaming fast numeric code stalin. Stalin doesn't currently support the numeric tower. (That said, I'm very impressed by what it can do.) Chicken also has a few ways to more-or-less easily optimize your code, for example the crunch egg. As for choosing chicken... This thread might degenerate into AOL hell as everybody me-too:s, but for me it's ease of use, good continuation performance, many extensions, great community (+ felix!) and good integration with C and Unix. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
(could be slightly OT) Re: [Chicken-users] Chicken manual in Texinfo format
Joerg F. Wittenberger wrote: c) Therefore I'd always recomment to *store* some strictly checked format, while serializing to the fashion-of-the-day, human readably syntax in the very moment of delivery for edit/display. I agree. The hard part there is the conversion from edit-mode to strict. I run a medium-size counter-culture wiki (+ 1 nodes) that grew out of a UseMod-fork and I want to change the syntax drastically (perhaps offering a choice between some future homegrown superset of Textile, and a souped-up Xinha). I need to (this is on my someday-maybe-list) figure out a way to *strictly* parse it. Not easy considering the amount of abuses of syntax people have put in over the years. (Using our h2-syntax to center images is one of the worst examples, but there are others, less extreme.) I do agree, though. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS
On 5/18/07, Michael McDermott <[EMAIL PROTECTED]> wrote: Ubiquitous Unicode support I tend to look at requiring Unicode support as analogous to requiring the full numeric tower -- really important for some applications, and I have no beef with Chicken's solutions to both of these problems. Library/module system If and only if that standard library/module system takes off, I'll finally try to write portable Scheme. In the past I've resigned to just always writing implementation specific code (that could, with some effort, be ported). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] import, the utf8 egg, syntax-case and tinyclos
On Fri, 2006-03-24 at 11:52 +0100, felix winkelmann wrote: > Can you show us some example code that generates the error? > > > cheers, > felix > > Huh, I just wrote a message about this (with a new topic) but it doesn't appear to have hit the list. My email chain is crazily bad atm, so here's the text again: Ok, I've pulled the most recent darcs (my last one was a couple of months old) and downloaded the most recent syntax-case. It's possible/probable that I've misconfigured it somehow. Here's a failing program: ;; file starts (require-extension syntax-case tinyclos) (define-method (clean (c )) (list->string (list c))) ;; file ends Just compiling this with csc and running it spits out: Error: unbound variable: clean Call history: make-method add-method Removing syntax-case from require-extension makes the program run fine (but I need syntax-case for some things; notably import and, if the program grows, I'm sure I'll use srfi-42 somewhere). Since I'm sure many of you already use syntax-case together with tinyclos, I'm asking for some trouble-shooting tips. What am I doing wrong? AML, Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] syntax-case tinyclos redux
Ok, I've pulled the most recent darcs (my last one was a couple of months old) and downloaded the most recent syntax-case. It's possible/probable that I've misconfigured it somehow. Here's a failing program: ;; file starts (require-extension syntax-case tinyclos) (define-method (clean (c )) (list->string (list c))) ;; file ends Just compiling this with csc and running it spits out: Error: unbound variable: clean Call history: make-method add-method Removing syntax-case from require-extension makes the program run fine (but I need syntax-case for some things; notably import and, if the program grows, I'm sure I'll use srfi-42 somewhere). Since I'm sure many of you already use syntax-case together with tinyclos, I'm asking for some trouble-shooting tips. What am I doing wrong? AML, Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] import, the utf8 egg, syntax-case and tinyclos
On Sat, 2006-03-25 at 17:03 +0100, felix winkelmann wrote: > installed under this name, i.e. you have to do it manually, like this: > > (define-generic clean) > > Just put it before your first method definition. Thank you very much! (And my apologies to Alex!) Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] string-split-fields
The following expressions: (string-split-fields "foo" "foobarfooquuxfoo foo baz foo" #:infix) (string-split-fields "foo" "foobarfooquuxfoo foo baz foo" #:suffix) (string-split-fields "foo" "foobarfooquuxfoo foo baz " #:infix) all return the same, while (string-split-fields "foo" "foobarfooquuxfoo foo baz " #:suffix) dies with an error, which I guess makes sense. Would you please consider updating the #!:infix variant so that (string-split-fields "foo" "foobarfooquuxfoo foo baz foo" #:infix) returns an extra "" at the end of the list, to distinguish it from (string-split-fields "foo" "foobarfooquuxfoo foo baz " #:infix) Sunnan PS My tinyclos/syntax-case problem that I reported earlier remains unsolved. I'll download darcs chicken and see if it' still there. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] import, the utf8 egg, syntax-case and tinyclos
At Thu, 23 Mar 2006 02:12:47 -0600, Alex Shinn wrote: > I'm not exactly sure what (uses) does, but I don't think you want this > line. If you want these features you should just use That's how we always did it when we were kids! I wasn't sure how chicken had changed. But I changed it as per your suggestion. (Same problem, though - I don't think the problem is with the utf-8 egg.) > (require-extension srfi-1 srfi-13 regex) > > Note that utf8 already provides Unicode-aware regex functions. Thanks! > Also, srfi-13 won't do the right thing with utf8 strings, it'll treat > them as byte strings. If you're using utf8, you probably want I only use the srfi-13 operations on strings which have had their non-ascii characters stripped; but I might change it as per your suggetion to make it less confusing for any possible future maintainers of my code. > (require-extension syntax-case tinyclos utf8 utf8-srfi-13) > (import utf8) > (import utf8-srfi-13) > > which works fine for me. I still get: Error: unbound variable: clean Call history: ##sys#require ##sys#require make-method add-method <-- clean is a method I have defined differentlly for numbers, characters and strings. Works fine when I'm not requiring syntax-case. AML, Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] import, the utf8 egg, syntax-case and tinyclos
I want to use the ut8 egg, but when I do it complains that it doesn't know what import is. Adding (require-extension syntax-case) gets rid of that complaint but then instead it complains about my tinyclos methods: This is my preamble: (require-extension syntax-case) (require-extension tinyclos) (require-extension utf8) (declare (uses srfi-1 srfi-13 regex extras)) (import utf8) and this is the error message: Error: unbound variable: clean Call history: ##sys#require make-method add-method What should I do? (Note that removing the inclusion of import and syntax-case makes the program work fine for ascii clean data.) Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] stripping accents
Just to make sure, to prevent duplication of effort: is there an easy way to strip accents from unicode characters with Chicken? For example, ï should become i, å should become a. Failing that, is there an easy way to translate characterns similar to unix tr or sed's y/// expression? Thanks, Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Question
On Sun, 2005-12-25 at 23:49 +0100, Benedikt Rosenau wrote: > What made you try or choose Chicken in the first place? > I liked that it was relatively easy to use C libraries. I prefer chicken over bigloo -- iirc, call-with-current-continuation is cheaper in chicken, too. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
the point of REC , was (Re: [Chicken-users] Re: crazy behaviour in csi!)
On Mon, 2005-12-05 at 23:54 +0100, Jens Axel Søgaard wrote: > Sunnan wrote: > > ;; instead of: > > (let f ((n (...))) > > (if (zero? n) 1 > > (* n (f (- n 1) > > ;; it's the exact same number of characters! > > Almost - note that REC returns the recursive > function, so you need to return the function > in the let: > >((let f ((n (...))) > (if (zero? n) 1 > (* n (f (- n 1 > f) > (...)) But that does the same thing; the whole expression as such returns the result of the recursive function in both cases. The recursive function returned by REC is use-once-and-destroy. And in chicken, ((rec (F N) (if (zero? N) 1 (* N (F (- N 1) (...)) macroexpands to almost the same as (let f ((n (...))) (if (zero? n) 1 (* n (f (- n 1) if I recall correctly. BTW, your example evaluates (...) twice. AML, Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] crazy behaviour in csi!
On Mon, 2005-12-05 at 23:49 +, Thomas Chust wrote: > On Mon, 5 Dec 2005, Sunnan wrote: > > > [...] > > I hadn't looked at srfi-31 before. I thought I knew most of the srfis. > > This one was pretty disappointing. > > [...] > > Hmm, most of the time I don't need this type of thing, but if I want to > pass an anonymous callback that is recursive, the rec form comes in quite > handy. I find writing >(letrec ((loop > (lambda (p) > (if (pred? p) (foo p) (loop (bar p)) > loop) > much more awkward than >(rec (loop p) (if (pred? p) (foo p) (loop (bar p))) How about (lambda (p) (let loop ((p p)) (if (pred? p) (foo p) (loop (bar p) Yeah, I know, it's slightly more awkward (three more symbols) and if you use it all the time, using rec might be a win, but if you do something all the time there's usually an even more winning way. Thanks for the example (anon callbacks), though. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] crazy behaviour in csi!
Thanks, I guess I was stressed, and forgot that unknown macros can already be defined. The error message just looked so weird. I was pretty sleep-deprived at the time. I hadn't looked at srfi-31 before. I thought I knew most of the srfis. This one was pretty disappointing. (define (...) 10) ; They want to write: ((rec (F N) (if (zero? N) 1 (* N (F (- N 1) (...)) ;; instead of: (let f ((n (...))) (if (zero? n) 1 (* n (f (- n 1) ;; it's the exact same number of characters! ;;; you could argue that want to do: (let ((foo (rec (F N) (if (zero? N) 1 (* N (F (- N 1)) (bar (...))) ;and more (...) ;and more (+ (foo bar) (foo 3))) ;; but this doesn't save much compared to: (let ((foo (lambda (n) (let f ((n n)) (if (zero? n) 1 (* n (f (- n 1))) (bar (...))) ; and more (...) ; and more (+ (foo bar) (foo 3))) ;; well... as always with scheme, we've got ;; a lambda-n construct that some people want to ;; shave away. shaving away is always a good thing, ;; but in this case the gain was so small ;; for such a high price. ;;; this is nothing but a named let and a lambda ;;; rolled into one. ;; gah! knowing myself, I'll maybe end up using ;; this some day. but I still don't like it. ;; for factorials, I prefer (product-ec (: n 1 (+ (...) 1)) n) ;srfi-42 ;; or even the APL-inspired: (apply * (iota (...) 1)) ;srfi-1 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] crazy behaviour in csi!
#;31> (define rec itrec) #;32> ((rec zero? 1 * sub1) 6) Error: during expansion of (letrec ...) - (letrec) unexpected object: ((zero? 1 * sub1)) #;32> (eq? rec itrec) #t #;33> ((rec zero? 1 * sub1) 6) Error: during expansion of (letrec ...) - (letrec) unexpected object: ((zero? 1 * sub1)) #;33> ((itrec zero? 1 * sub1) 6) 720 #;34> itrec and rec are the same, but one makes error and the other doesn't. csi -version Version 2, Build 214 - linux-unix-gnu-unknown - [ dload ptables ] Chicken and csi is from darcs repo a couple of days ago. ; This is the definition of itrec (define (itrec break start do inc) (lambda (x) (let loop ((x x) (total start)) (if (break x) total (loop (inc x) (do x total)) ;; and this is the definition of rec that I originally wanted to have, ;; but the behaviour is as crazy regardless of what rec does. ;; even with (define rec itrec) it becomes crazy! ;; or with (define rec list) or define rec anything, anything! (define (rec break fin do inc) (lambda (x) (let loop ((x x)) (if (break x) fin (do x (loop (inc x))) I wanted to make an implementation of the idea in near the bottom of http://www.paulgraham.com/power.html help! years truely, sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Packaging practices
> On 11/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > One example of using the autotools is here: > > http://chicken.humankraft.com/wiki.ssp?page=Using%20the%20GNU%20Autotools%20with%20compiled%20code > > It's rather minimalistic, but should show the general procedure. Thank you very much. > Apart from Chicken itself, I try to avoid autoconf/automake as much > as possible, but it certainly is a standard way of handling the build > of source packages. The standard is using ./configure (preferably accepting --prefix), make and make install -- whether or not the configure script and makefile was generated by the autotools doesn't seem to be important. Thanks again. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Packaging practices
Hi, What are, in this list's opinion, the recommended best practices for distributing free software written in Chicken? I'm thinking proper GNU-style source tar balls, since that's currently the basis for most further (distro specific and other binary) packaging. * Do you use autoconf, if so, what do you check for? * What about automake? * Do you make one distribution containing the full .scm-files and one with just the .c-files, or do you only make the .scm-distribution? * How do you deal with third-party eggs from the call-with-current-continuation repo that your program uses? I'd love to see example chicken projects, I'm especially interested in autoconf and automake usage but other solutions are also of interest. Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] an ode to Spiffy
Magnus Therning <[EMAIL PROTECTED]> writes: > I'm sure you've read what Paul Graham has to say after using Lisp > (almost as nice as Scheme :-) for web applications in ViaWeb? He used CPS because full continuations weren't available; maybe Scheme could do it nicer. -- .i mi'e snan .i mi rodo roda fraxu ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] darcs patch: fixed a small typo in README
Wed Apr 27 00:33:28 CEST 2005 [EMAIL PROTECTED]
* fixed a small typo in README
New patches:
[fixed a small typo in README
[EMAIL PROTECTED] {
hunk ./README 210
-hen.el an emacs mode for exiting Scheme programs, by Linh Dang
+hen.el an emacs mode for editing Scheme programs, by Linh Dang
}
Context:
[- the reader can read now |.| [Thanks to Nicolas Pelletier]
[EMAIL PROTECTED]
[- removed last traced of libstuffed-chicken/libsrfi-chicken
[EMAIL PROTECTED]
[- `define-extension' allows optional `export' clause
[EMAIL PROTECTED]
- fixed a stupid bug in `string->number' (caused by previous "fix")
- `set-finalizer!' was broken
]
[- several patches and hooks for numbers
[EMAIL PROTECTED]
[- `string->number' didn't handle inexact numbers starting with #\#
[EMAIL PROTECTED]
- `set-finalizer!' forces finaloizers if live count exceed max
]
[- Removed DJGPP support
[EMAIL PROTECTED]
- libstuffed-chicken and libsrfi-chicken have been folded into libchicken
]
[pp handles other pointer types
[EMAIL PROTECTED]
[- SWIG-pointers are accepted by `##sys#foreign-pointer-argument'
[EMAIL PROTECTED]
[- `CHICKEN_delete_gc_root()' didn't free memory of root object
[EMAIL PROTECTED]
- chicken-entry-points.scm: added void-ptr cast
- removed wrong entry in help text given by `,?' in csi [Thanks to Dale Jordan]
- library: added `##sys#' aliases to `string->number' and `number->string' (and some other primitives)
for later hooking
- added `define-extension'
]
[- deletion of GC roots is O(1)
[EMAIL PROTECTED]
[- internal char-type predicates didn't use libc alias macros
[EMAIL PROTECTED]
[resolved stupid conflict
[EMAIL PROTECTED]
[- fixed `define-method' to specialize all arguments
[EMAIL PROTECTED]
[- John Lenz fixed a few problems with handling methods with argument lists of unequal length
[EMAIL PROTECTED]
[- backtrace indicates current frame
[EMAIL PROTECTED]
- `printf' accepts `~n' as an alias for `~%'
- wwchicken: fixed broken links to SRFI47/57 docs [Thanks to Reed Sheridan]
]
[- Makefile.am: banner.scm was installed for unknown reasons
[EMAIL PROTECTED]
- #\U... char syntax and \U... escape sequence
- pretty-print didn't handle extended character syntax
- changed macro-definition of `define-method' to handle non-specialized args correctly [Thanks to John Lenz]
- utils: `decompose-pathname' should return #f, #f, #f for the empty string [Thanks to Peter Bex]
]
[- csc.scm and chicken-config pass -DHAVE_CHICKEN_CONFIG_H to C compiler [Thanks to Alex Shinn]
[EMAIL PROTECTED]
[- manual: added documentation for `\u'
[EMAIL PROTECTED]
[- utils: `make-pathname' didn't check type of filename-argument [Thanks to Peter Bex]
[EMAIL PROTECTED]
- wwchicken: added new eggs
- syntax-case: `declare' is now always available, even with `-r5rs'
]
[- changed version-numbering to use 3-digit release number
[EMAIL PROTECTED]
- manual: moved `___pointer' description
]
[- Arithmetic comparison operators didn't work properly on 64-bit machines [Thanks to Alex Shinn]
[EMAIL PROTECTED]
[- Makefile.in: uses different escapes to allow commas [Thanks to Göran Krampe]
[EMAIL PROTECTED]
- compiler: keywords are not optimized to literal accesses in strict mode; assignment to keyword triggers warning
[Thanks to Damian Gryski]
- '\u' escape sequence in strings
]
[- library.scm: file-open functions and deletion/renaming use strerror(3) for better error messages [suggested by
[EMAIL PROTECTED]
Alejandro Forero Cuervo]
]
[- chicken.h: added macro for `___pointer'
[EMAIL PROTECTED]
- easyffi: added `opaque' pseudo-declaration; `___byte_vector' pseudo type
]
[- easyffi: added `___pointer' marker
[EMAIL PROTECTED]
[- easyffi: default-renaming is now triggered on any uppercase or underscore character
[EMAIL PROTECTED]
[- easyffi: default-renaming is also triggered on underscores
[EMAIL PROTECTED]
- library: ##sys#find-symbol-table is exported
]
[- runtime.c: the removal of finalizer-list entries was broken [Thanks to John Lenz]
[EMAIL PROTECTED]
[- wwchicken: added requirements for stream-ldif
[EMAIL PROTECTED]
- srfi-4: fixed problem for `u32vector-ref' on 64-bit machines [Thanks to Alex Shinn]
- extras: fixed stupid buf in rassoc
- easyffi: `___length()' argument marker
]
[...
[EMAIL PROTECTED]
[huh?
[EMAIL PROTECTED]
[resolved RCS conflicts; new eggs in wwchicken
[EMAIL PROTECTED]
[- added internal error class #:process-error
[EMAIL PROTECTED]
- posix: uses strerror(3)
- lolevel: `object-unevict' optionally copies byteblock objects
- compiler: gives warnings for undefined exported globals
- `define-inline' and `define-constant' are now usable with psyntax' module system (but expand to simple defines)
- added inlining, no noticable performance improvements, though (customizable procedures and gcc inlining may probably
do the job here...)
]
[- added `u' debugging mode
[EMAIL PROTECTED]
[- csi: ,ln prints an arrow before the result
[E
