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: syntax(string-translate i ö o_) eval (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: syntax(string-translate i ö o_) eval (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
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
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] 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] 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
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
[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] 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] 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
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] 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
(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
[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
[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
[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
