Re: [Chicken-users] Problem with chicken-install -p
From: Jeronimo Pellegrini j...@aleph0.info Subject: [Chicken-users] Problem with chicken-install -p Date: Wed, 21 Apr 2010 20:49:32 -0300 Hello, After this changeset: 098a8b9a626ce58f0f8f5d8c7c85889df04604fb added destination-prefix to make installation-prefix compatible again I can no longer use chicken-install -p ~/chicken/ from the directory in which where an egg's source is. I'm not sure if there's some detail missing from the changeset or if I'm missing something. Any hints? Do make confclean clean and rebuild. This should work. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-install from behind a proxy
From: Paul Romanchenko paula...@gmail.com Subject: Re: [Chicken-users] chicken-install from behind a proxy Date: Fri, 16 Apr 2010 18:28:18 +0400 Ok, again this bug hit me. Captured conversation attached. On Wed, Apr 7, 2010 at 1:52 PM, Paul Romanchenko paula...@gmail.com wrote: Hmm, when trying to repeat the problem gone. Either it was fixed on server side or proxy. I don't understand this. The response looks ok. Can you send me the response data only? Perhaps gzipped, so that I can look at the exact bytes getting retrieved? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-install from behind a proxy
I think I'm close to nail the bug. This is setup-download.scm, the part when the size and body of file are read. After reading size, you read an line like this (_ (read-line in)); When using proxy this actually EATS the line from body, so when next you read string of body, you eats the description of next file. I have no sources under my hand now. Tomorrow I'm going to spend some time to this. On Thu, Apr 22, 2010 at 6:47 PM, Felix fe...@call-with-current-continuation.org wrote: From: Paul Romanchenko paula...@gmail.com Subject: Re: [Chicken-users] chicken-install from behind a proxy Date: Fri, 16 Apr 2010 18:28:18 +0400 Ok, again this bug hit me. Captured conversation attached. On Wed, Apr 7, 2010 at 1:52 PM, Paul Romanchenko paula...@gmail.com wrote: Hmm, when trying to repeat the problem gone. Either it was fixed on server side or proxy. I don't understand this. The response looks ok. Can you send me the response data only? Perhaps gzipped, so that I can look at the exact bytes getting retrieved? cheers, felix -- rmrfchik. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problem with chicken-install -p
Hi, On Thu, Apr 22, 2010 at 04:41:57PM +0200, Felix wrote: Do make confclean clean and rebuild. This should work. I did: make confclean clean . scripts/build-boot-chicken.sh chicken linux bunzip chicken-boot-.gz2 make PLATFORM=linux CHICKEN=./chicken-boot- make uninstall make install But chicken-install -p /some/dir still fails with unbound variable: destination-prefix... J. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Weird macro behaviour
Hi all, I'm experimenting a bit, trying to understand how the renaming and comparing of er-macros work, and I found this really strange thing; if I copy the definition of er-macro-transformer and the definitions it depends on to my own file and execute it, I get a different behaviour than with the built-in one. When I run csi -qb test2.scm, I get three lines of foo using my copy of the Chicken code. When I change the my-er-macro-transformer in the file to er-macro-transformer, I get two lines of foo. Can anyone explain this black voodoo magic? Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth (define-syntax dd (syntax-rules () ((dd . foo) (void (define (lookup id se) (cond ((assq id se) = cdr) ((get id '##core#macro-alias)) (else #f))) (define (macro-alias var se) (if (or (##sys#qualified-symbol? var) (let* ((str (##sys#slot var 1)) (len (##sys#size str))) (and (fx len 0) (char=? #\# (string-ref str 0) var (let* ((alias (gensym var)) (ua (or (lookup var se) var))) (put! alias '##core#macro-alias ua) (put! alias '##core#real-name var) (dd aliasing alias (real: var ) to (if (pair? ua) 'macro ua)) alias) ) ) (define ((my-er-macro-transformer handler) form se dse) (let ((renv '())) ; keep rename-environment for this expansion (define (rename sym) (cond ((pair? sym) (cons (rename (car sym)) (rename (cdr sym ((vector? sym) (list-vector (rename (vector-list sym ((not (symbol? sym)) sym) ((assq sym renv) = (lambda (a) (dd `(RENAME/RENV: ,sym -- ,(cdr a))) (cdr a))) ((lookup sym se) = (lambda (a) (cond ((symbol? a) (dd `(RENAME/LOOKUP: ,sym -- ,a)) a) (else (let ((a2 (macro-alias sym se))) (dd `(RENAME/LOOKUP/MACRO: ,sym -- ,a2)) (set! renv (cons (cons sym a2) renv)) a2) (else (let ((a (macro-alias sym se))) (dd `(RENAME: ,sym -- ,a)) (set! renv (cons (cons sym a) renv)) a (define (compare s1 s2) (let ((result (cond ((pair? s1) (and (pair? s2) (compare (car s1) (car s2)) (compare (cdr s1) (cdr s2 ((vector? s1) (and (vector? s2) (let ((len (vector-length s1))) (and (fx= len (vector-length s2)) (do ((i 0 (fx+ i 1)) (f #t (compare (vector-ref s1 i) (vector-ref s2 i ((or (fx= i len) (not f)) f)) ((and (symbol? s1) (symbol? s2)) (let ((ss1 (or (get s1 '##core#macro-alias) (lookup2 1 s1 dse) s1) ) (ss2 (or (get s2 '##core#macro-alias) (lookup2 2 s2 dse) s2) ) ) (cond ((symbol? ss1) (cond ((symbol? ss2) (eq? (or (get ss1 '##core#primitive) ss1) (or (get ss2 '##core#primitive) ss2))) ((assq ss1 (##sys#macro-environment)) = (lambda (a) (eq? (cdr a) ss2))) (else #f) ) ) ((symbol? ss2) (cond ((assq ss2 (##sys#macro-environment)) = (lambda (a) (eq? ss1 (cdr a (else #f))) (else (eq? ss1 ss2) (else (eq? s1 s2))) ) ) (dd `(COMPARE: ,s1 ,s2 -- ,result)) result)) (define (lookup2 n sym dse) (let ((r (lookup sym dse))) (dd (lookup/DSE (list n) : sym -- (if (and r (pair? r)) 'macro r) )) r)) (handler form rename compare) ) ) (define-syntax my-cond (my-er-macro-transformer ;; Change this to er-macro-transformer and it works (lambda (exp rename compare) (let ((clauses (cdr exp))) (if
Re: [Chicken-users] Is there interest in a new egg (fast-io)?
On Apr 6, 2010, at 9:34 AM, Jeronimo Pellegrini wrote: BTW, I've benchmarked complex reading ad writing too. I suppose the difference is huge for reading complexes because the read procedure doesn't know that it's a complex number. Hi there. Your numbers looked odd to me so I downloaded and ran your benchmarks. I believe you got such poor performance on reads due to (use numbers). Here are your numbers again: schemefast-io speedup --- write fixnum14.602 5.3032.7535 read fixnum58.208 11.7064.9725 write flonum37.003 21.6471.7094 read flonum 100.367 15.6266.4231 write complex 89.361 56.0201.5952 read complex 3076.952 59.47651.734 --- Here are my numbers: scheme fast-io line numbers 1.8 2.1 -- write fixnum26 2126 26 read fixnum61 2022 211 193 write flonum48 2548 50 read flonum86 2425 276 246 where scheme is your code without numbers loaded, fast-io is your fast-io code, numbers is your code with numbers version 1.8 or 2.1 loaded, line is my fast scheme implementation. CPU performance disparity aside, I don't get nearly the slowdown that you do with plain scheme (read), so my guess is that either you loaded the numbers egg or that fast-io is inexplicably slow on my machine. I presume you loaded numbers because your complex test did not work without it. Furthermore the line implementation is basically on par with fast-io, as long as numbers is not loaded. To get the line implementation for readers all you need to do is replace (read port) with (string-number (read-line port)). Furthermore when you generate the files, use a newline delimiter instead of a space. line is faster than scheme by 3-4x because read is more general and more importantly, because (read) is character based and char-based I/O from stream ports is really slow on Chicken. On the other hand, line and string based I/O is fast. Based on this admittedly quick test, there's not much advantage to using fast-io as long as your data is newline-delimited. What might be useful is a read-delimited-string (or whatever) which would read until a specified set of delimiters. This wouldn't replace read-line--as newlines are handled specially due to \r--nor would it handle escaped chars, but it would handle the basic case of reading strings until NUL or SPACE. Or you could preprocess your space-delimited files with tr ' ' '\012' :) Jim ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Is there interest in a new egg (fast-io)?
Hello! On Thu, Apr 22, 2010 at 02:25:00PM -0500, Jim Ursetto wrote: Here are my numbers: scheme fast-io line numbers 1.8 2.1 -- write fixnum26 2126 26 read fixnum61 2022 211 193 write flonum48 2548 50 read flonum86 2425 276 246 where scheme is your code without numbers loaded, fast-io is your fast-io code, numbers is your code with numbers version 1.8 or 2.1 loaded, line is my fast scheme implementation. CPU performance disparity aside, I don't get nearly the slowdown that you do with plain scheme (read), so my guess is that either you loaded the numbers egg or that fast-io is inexplicably slow on my machine. I presume you loaded numbers because your complex test did not work without it. Yes, I used the numbers egg, that's right. I wasn't expecting that it would slow down reading and writing of flonums and fixnums that much. Furthermore the line implementation is basically on par with fast-io, as long as numbers is not loaded. To get the line implementation for readers all you need to do is replace (read port) with (string-number (read-line port)). Furthermore when you generate the files, use a newline delimiter instead of a space. line is faster than scheme by 3-4x because read is more general and more importantly, because (read) is character based and char-based I/O from stream ports is really slow on Chicken. On the other hand, line and string based I/O is fast. That makes sense -- by reading a sequence of characters and then using string-number you used a somewhat similar idea that I used myself (if you *know* it's a number, don't try to parse a string or S-expression or anything else). Based on this admittedly quick test, there's not much advantage to using fast-io as long as your data is newline-delimited. Yes, it looks like that. What might be useful is a read-delimited-string (or whatever) which would read until a specified set of delimiters. It's on the latest version of the egg! (read-string-until CHAR PORT) (read-string-between LEFTCHAR RIGHTCHAR PORT) I didn't yet include read-string-n because it's an identifier used in R6RS, and may (who knows) end up in the next standard (R7RS or whatever it will be called -- as far as I know there is no name for it yet) when it comes out. This wouldn't replace read-line--as newlines are handled specially due to \r--nor would it handle escaped chars, but it would handle the basic case of reading strings until NUL or SPACE. Or you could preprocess your space-delimited files with tr ' ' '\012' :) Thanks for pointing this out! I'll still use specialized-io myself (my files have several numbers per line, with some strings there too). For human-unreadable fast I/O maybe converting numbers into binary and writing blobs would be faster. J. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
