Re: [Chicken-users] fixnum-specific math operators patch
On 9/1/06, Will M Farr [EMAIL PROTECTED] wrote: Hello all, In the spirit of my last post about flonum-specific math operators, attached is a patch which implements the following behavior for Chicken's fxXXX math operators: I would prefer to keep fixnum ops as they are, since safe code might give still results but will not crash the program (this definition of safe is used throughout the whole compiler and runtime-system). What do others say? cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] The predicate atom? considered bizarre
On 8/31/06, John Cowan [EMAIL PROTECTED] wrote: While messing around with some stuff in Paul Graham's paper The Roots of Lisp I was quite surprised to find that Chicken's atom? predicate returns #f on the empty list. This is the documented behavior. This is contrary to historic practice from Lisp 1.5 through Common Lisp. (Of course that is partly because () = NIL in that tradition, and NIL is a symbol.) R1RS was the last Scheme standard to specify ATOM, and it had the same semantics then. Why was this changed? Can it be fixed? I have changes this. Note that atom? is now equivalent to not-pair?. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum-specific math operators patch
On 9/1/06, Kon Lovett [EMAIL PROTECTED] wrote: The fp* routines must accept fixnums so checking is necessary for those, otherwise it should just assume an fp value. (Small side note: fp* didn't accept fixnums previously and do not with Wills patch) cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum-specific math operators patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 1, 2006, at 12:12 AM, felix winkelmann wrote: On 9/1/06, Kon Lovett [EMAIL PROTECTED] wrote: The fp* routines must accept fixnums so checking is necessary for those, otherwise it should just assume an fp value. (Small side note: fp* didn't accept fixnums previously and do not with Wills patch) Ok. Since these must be explicitly called. (I have used them and made sure any integer constants were like 1.0, so that explains why I didn't know this.) cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iEYEARECAAYFAkT33kgACgkQJJNoeGe+5O7bFwCcCB9EKT7JEGgM6MwsGqzUgCtR BJQAn0pc05cUMrwpsjvIGqc/oNFeGoSj =ooxn -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup quoting problem on CMake MinGW
On 8/31/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: I'm going to guess that because there are 4 quotes on this line, something is absorbing 2 of 'em or some nonsense like that, probably quoting the interior of the command and leaving E:\Program bare. I think the latter quotes are only due to escaping in the error message. I tried to simulate this situation by building a version on linux (ffrom repo) with a prefix containing whitespace. Not surprisingly the autotools build can't handle that (libtool bombs). CMake worked (modulo the problem I talked about with missing libchicken.so - entering make again works ok) and running chicken-setup opengl with paths and library-paths properly set runs to completion. So I guess this is a mingw issue. cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup quoting problem on CMake MinGW
felix winkelmann wrote: On 8/31/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: I'm going to guess that because there are 4 quotes on this line, something is absorbing 2 of 'em or some nonsense like that, probably quoting the interior of the command and leaving E:\Program bare. I think the latter quotes are only due to escaping in the error message. I tried to simulate this situation by building a version on linux (ffrom repo) with a prefix containing whitespace. Not surprisingly the autotools build can't handle that (libtool bombs). CMake worked (modulo the problem I talked about with missing libchicken.so - entering make again works ok) and running chicken-setup opengl with paths and library-paths properly set runs to completion. So I guess this is a mingw issue. No, probably a Windows Command Prompt issue. You did your stuff under a Bourne shell. I haven't tested under MSYS or Cygwin shells; maybe the problem will go away there. I'm in the middle of Autotools stuff right now, not gonna break focus... Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum-specific math operators patch
Hello all, On Sep 1, 2006, at 3:06 AM, Kon Lovett wrote: I think the fx* shouldn't check their arguments, ever. While the safe/unsafe rational makes sense (nicely symmetric), people shouldn't use these routines if not 100% sure of the types. The goes for the (fixnum arithmetic) declaration. This is what I thought until yesterday, too. But then I realized what people who want both safety against careless users and speed have to do to achieve these goals. Allow me to illustrate with one of my favorite macros :) : (define-syntax do-range (syntax-rules () ((_ (i aa bb) expr ...) (let ((a aa) (b bb)) (do ((i a (fx+ i 1))) ((fx= i b)) expr ...) As written this macro will go nuts if someone calls it with a float- producing expression for aa or bb: (let ((the-rev-indices '())) (do-range (i 0.0 (vector-length v)) (set! the-rev-indices (cons i the-rev-indices))) ... (use the-rev-indices) ...) This will generate an error in safe mode, but *not until the (use the- rev-indices) form is evaluated*. That can be well past the use of the do-range macro, and is therefore very hard to debug. I can see three possibilities for fixing this: 1. Tell the user to never pass a non-fixnum expression to do-range (and force them to require this of all library code they might use to determine the range arguments of the macro). If they fail to respect this requirement, their program will fail with a strange error message when they use the invalid value of i. This is clearly not The Right Thing (TM). 2. Re-define the macro to (define-syntax do-range (syntax-rules () ((_ (i aa bb) expr ...) (let ((a aa) (b bb)) (if (or (not (fixnum? a)) (not (fixnum? b))) (error 'do-range non-fixnum limits a b) (do ((i a (fx+ i 1))) ((fx= i b)) expr ...)) Now the user doesn't get a cryptic error when he/she calls do-range with strange arguments. The macro throws a sensible error before entering the loop---the error is associated with the point at which the mistake was made. BUT, if the user declares (unsafe)---that is, explicitly requests blazing speed because safety has been pre- checked---the macro still has the extra overhead of the now- unnecessary checks. I don't think this is The Right Thing (TM), either. 3. My opinion is that The Right Thing (TM) is to code the macro as follows: (define-syntax do-range (syntax-rules () ((_ (i aa bb) expr ...) (let ((a aa) (b bb)) (cond-expand ((not unsafe) (if (or (not (fixnum? a)) (not (fixnum? b))) (error 'do-range non-fixnum limits a b (do ((i a (fx+ i 1))) ((fx= i b)) expr ...) This works, but it's pretty yucky. It is the simplest way, given the present behavior of the fxXXX operators, to achieve safety in safe mode (with useful, and immediate, error reporting) and speed in unsafe mode. I submitted the fixnum patch because it would implement the same behavior, but without requiring people using the fxXXX operators to think so much about these issues (and type (cond- expand ...) every time). Perhaps this situation is familiar to other Chicken users, but I didn't realize that something like #3 was needed to be both safe and fast until yesterday. This is just food for thought---I understand if felix and others want to keep the present behavior of the fxXXX operators. Will ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum-specific math operators patch
On 9/1/06, Will M Farr [EMAIL PROTECTED] wrote: 3. My opinion is that The Right Thing (TM) is to code the macro as follows: (define-syntax do-range (syntax-rules () ((_ (i aa bb) expr ...) (let ((a aa) (b bb)) (cond-expand ((not unsafe) (if (or (not (fixnum? a)) (not (fixnum? b))) (error 'do-range non-fixnum limits a b (do ((i a (fx+ i 1))) ((fx= i b)) expr ...) This works, but it's pretty yucky. It is the simplest way, given the present behavior of the fxXXX operators, to achieve safety in safe mode (with useful, and immediate, error reporting) and speed in unsafe mode. I submitted the fixnum patch because it would implement the same behavior, but without requiring people using the fxXXX operators to think so much about these issues (and type (cond- expand ...) every time). Using something like ensure can help here: % cat x.scm (define x 33) (print (ensure fixnum? x)) % csc x.scm -debug 2 ./x [canonicalized] (set! c2 'argument has incorrect type) (##core#callunit library) (##core#callunit eval) (##core#callunit extras) (##core#undefined) (##core#undefined) (set! x '33) (print (let ((g01 x)) (if (fixnum? g01) g01 (##sys#signal-hook type-error: c2 g01 'fixnum? ((##sys#implicit-exit-handler)) (##core#undefined) 33 % csc x.scm -debug 2 -unsafe ./x [canonicalized] (set! c2 'argument has incorrect type) (##core#callunit library) (##core#callunit eval) (##core#callunit extras) (##core#undefined) (##core#undefined) (set! x '33) (print (let ((g01 x)) (if '#t g01 (##sys#signal-hook type-error: c2 g01 'fixnum? ((##sys#implicit-exit-handler)) (##core#undefined) 33 (Note that the if expression will be folded to g01) cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum-specific math operators patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 1, 2006, at 7:15 AM, Will M Farr wrote: Hello all, On Sep 1, 2006, at 3:06 AM, Kon Lovett wrote: snip 3. My opinion is that The Right Thing (TM) is to code the macro as follows: (define-syntax do-range (syntax-rules () ((_ (i aa bb) expr ...) (let ((a aa) (b bb)) (cond-expand ((not unsafe) (if (or (not (fixnum? a)) (not (fixnum? b))) (error 'do-range non-fixnum limits a b (do ((i a (fx+ i 1))) ((fx= i b)) expr ...) This works, but it's pretty yucky. It is the simplest way, given the present behavior of the fxXXX operators, to achieve safety in safe mode (with useful, and immediate, error reporting) and speed in unsafe mode. I submitted the fixnum patch because it would implement the same behavior, but without requiring people using the fxXXX operators to think so much about these issues (and type (cond- expand ...) every time). Perhaps this situation is familiar to other Chicken users, but I didn't realize that something like #3 was needed to be both safe and fast until yesterday. This is just food for thought---I understand if felix and others want to keep the present behavior of the fxXXX operators. Good food. (Made me think to re-visit some older code that had some ASSumptions about the public interface arguments.) But Felix's point about 'ensure' should help w/ syntax forms that have domain range restrictions. Best wishes, Kon Will -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iEYEARECAAYFAkT4StUACgkQJJNoeGe+5O4PPQCfXr70oMy9Ib+evIMf1H0Sj3UV 99AAnjye5hn+dHxo5RAIBtSuqX83EGtT =jTMq -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] fixnum-specific math operators patch
Kon (and others), On Sep 1, 2006, at 10:59 AM, Kon Lovett wrote: But Felix's point about 'ensure' should help w/ syntax forms that have domain range restrictions. Yeah---that would be The Right Way (TM). (And it allows for more situation-adapted tests.) By the way (maybe felix can answer this), if I define a structure with (define-record foo bar baz) does it define the accessors and setters as (define (foo-bar f) (ensure foo? f) (block-ref f 0)) ... I'm curious because I've read in other places (one of Manuel Serrano's papers on type inference) that type checks can take up a large fraction of the runtime, and it would be nice to eliminate as many as possible in (unsafe) code. Will ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] type-and-range-check optimizations in unsafe mode
Hello all, I've noticed with a bit more poking around the chicken runtime that there are at least two places where chicken performs safety checks even if you specify -unsafe (felix or others please correct me if I'm reading the code incorrectly): - structure getters and setters - vector-refs There may be more places. I don't really know how much time these type checks take up---Serrano and Feeley claim in _Storage Use Analysis and its Applications_ (http://www-sop.inria.fr/mimosa/fp/ Bigloo/bigloo-5.html#Papers--Reports ), Section 4, that they don't take up much time *if* a compiler uses copy propogation and inlining effectively, but cite benchmarks that say 25% if the compiler doesn't. Would people be interested me going through the runtime and breaking the type-and-range checks out of procedures like vector-ref and vector-set! such that they are only performed in safe mode? The general principles I propose are: 1. C_xxx in runtime.c check as few argument types and ranges as possible consistent with genericity of operation. 2. Type and range checks are inserted in library.scm before calling C_ procedures so that they are absent in the unsafe library code and in any unsafe code which inlines the library procedures (using (declare (unsafe) (usual-integrations) (inline)), would inline these I assume). This shouldn't be too much work, and it's pretty straightforward work at that. I would be happy to implement it and submit patches if felix and others think it's OK to include. We could then check for improvement on, say, the shootout benchmarks. Will ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Patch for unsafe structure getters and setters
Hello all, So, I was wrong about the unsafe vector-ref in Chicken---it doesn't check indices or types. But, structure getters and setters do check types even in unsafe mode. The attached patch against the current darcs repository (i.e. darcs patch, not diff patch) implements type- checks for struct getters and setters using (ensure ...), so they will compile into nothing in unsafe mode. Kon tells me that the misc- extn egg already has such a define-record-type macro, so maybe there's a reason this isn't already in the main distribution---if so, just ignore it :). Sorry for all the confusion. Will unsafe-structures.patch Description: Binary data ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Patch for unsafe structure getters and setters
Oops---unclosed list in the patch. The attached corrects that problem and also comments out the duplicate definition of flonum? in support.scm (since it's now defined in library.scm). By the way, in a benchmark which compares the time to add two double- precision floating-point numbers together one billion times, chicken with the new non-checking fpXXX operators comes in only seven times slower than straight C. I imagine that this is the most-biased way to compare the two---i.e. any expression involving math library operators like sqrt, log, exp, expt, etc, would show chicken in a more favorable light, as would any expression which did more work before looping (since every loop frame takes up stack/heap space, and therefore requires more invocations of the GC). I think that's good news! Sorry, Will unsafe-structures.patch Description: Binary data On Sep 1, 2006, at 4:40 PM, Will M Farr wrote: Hello all, So, I was wrong about the unsafe vector-ref in Chicken---it doesn't check indices or types. But, structure getters and setters do check types even in unsafe mode. The attached patch against the current darcs repository (i.e. darcs patch, not diff patch) implements type-checks for struct getters and setters using (ensure ...), so they will compile into nothing in unsafe mode. Kon tells me that the misc-extn egg already has such a define- record-type macro, so maybe there's a reason this isn't already in the main distribution---if so, just ignore it :). Sorry for all the confusion. Will unsafe-structures.patch ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Lazy ssax/sxpath?
Hello, I'm interested in using lazy-ssax to do some xml parsing. I think it's a beautiful API, and I want to try it for some largish xml files I have. http://modis.ispras.ru/Lizorkin/Apidoc/lazy-ssax.html The ssax egg doesn't currently have this, and neither does the sxml-tools egg. Before I go about starting to get this working, I would like if somebody else has gotten this stuff running on chicken. If not, I'll try to tackle it this weekend. Thanks, Ben ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] lazy-ssax egg
I pulled out the lazy-ssax stuff out into its own egg. It requires the ssax egg and you can use the sxml-tools-extra extension to load a bunch of other lazy tools (I knew they would come in handy eventually :) http://3e8.org/zb/eggs/lazy-ssax.egg If this looks good I can write an eggdoc and upload it to the egg repository. It could also be integrated directly into the ssax egg. Actually, ssax, sxml-tools and sxml-transforms are all out of date and should be updated at some point, though they do work well right now. I think the license is Public Domain but am not sure. Here's the output of test.scm, which is included in the egg bundle: [EMAIL PROTECTED] ~/scheme/lazy-ssax$ csi -R lazy-ssax ; loading /usr/local/lib/chicken/1/lazy-ssax.so ... ; loading /usr/local/lib/chicken/1/ssax-core.so ... ; loading /usr/local/lib/chicken/1/ssax-utils.so ... #;1 (load test.scm) ; loading ./test.scm ... ; loading /usr/local/lib/chicken/1/sxml-tools-extra.so ... ; loading /usr/local/lib/chicken/1/sxml-tools.so ... --- Lazy XML-to-SXML conversion (*TOP* (*PI* xml version='1.0') (poem (@ (title The Lovesong of J. Alfred Prufrock) (poet T. S. Eliot)) (stanza (line Let us go then, you and I,) #promise) #promise)) --- Forced promise ((stanza (line In the room the women come and go) #promise) #promise) --- Querying a lazy SXML document, lazily ((line Let us go then, you and I,) #promise) --- Obtain the next portion of the result ((line In the room the women come and go) #promise) --- Converting the lazy result to a conventional SXML nodeset ((line Let us go then, you and I,) (line In the room the women come and go)) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
