Re: [Chicken-users] tcp-connect problem
On 8/10/05, Reed Sheridan <[EMAIL PROTECTED]> wrote: > > Chicken isn't doing this. I'm not much of a C coder, but I've written > a patch to correct this anyway (see attachment). It even works. > Thanks, patch is applied. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] udp.scm on cygwin
Here is another fix for udp.scm. I first added (uses scheduler), turned out it does not work. I don't know why. Is there any reason for it? The patch also includes a typo fix. 8<--8<--8<--8<--8<--8<--8<-- --- udp.scm.orig2005-08-10 15:41:22.0 +0900 +++ udp.scm 2005-08-10 16:47:43.0 +0900 @@ -53,7 +53,7 @@ (declare ; (unit udp) - (uses extras) + (uses extras srfi-18) (usual-integrations) (fixnum-arithmetic) (no-bound-checks) @@ -256,7 +256,7 @@ return(s); EOF )) -;;; ##net#inetaddr-port : sockaddr-in-pointer -> int +;;; ##net#inaddr-port : sockaddr-in-pointer -> int ;;; return the port number of a sockaddr_in structure. (define ##net#inaddr-port (foreign-lambda* int ((pointer saddr)) 8<--8<--8<--8<--8<--8<--8<-- I am not still able to run it on cygwin. Here is a screenshot. __ __ ____ | | |--.|__|..| |--.-.-. | ---| || || __||<| -__| | |__|__|__||__||||__|__|_|__|__| Version 2, Build 0 - windows-cygwin-x86 - [ dload ] (c)2000-2005 Felix L. Winkelmann #;1> (use udp) ; loading /usr/local/lib/chicken/udp.dll ... #;2> (define s (udp-open-socket)) #;3> (udp-bind! s #f 0) #;4> (udp-sendto s "127.0.0.1" 123 "\n") 1 #;5> (udp-recvfrom s 32) Error: Bad address: "recvfrom" #;5> Could anybody reproduce this? Thanks, Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Bug in the numbers egg?
Hello, consider the following example session: $ csi ___ _ __ / ___/ / (_)___/ /_ ___ / /__/ _ \/ / __/ '_/ -_) _ \ \___/_//_/_/\__/_/\_\\__/_//_/ Version 2, Build 104 - macosx-unix-gnu-ppc - [ dload ] (c)2000-2005 Felix L. Winkelmann #;1> (use numbers) ; loading /usr/local/lib/chicken/numbers.scm ... ; loading /usr/local/lib/chicken/numbers-base.so ... #;2> (expt 10 100) 10110891155767964156222877689497504522960006971153529700550125477736178357726682741211136 This result is apparently wrong. Nevertheless it has the correct magnitude. I wonder whether this is some kind of amplified rounding error or a more serious problem. Any idea or work around is appreciated. cu, Thomas Chust ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in the numbers egg?
John.Cowan wrote: [...] According to the GMP home page at http://swox.com/gmp/ , many versions of gcc miscompile GMP due to too-aggressive optimizations. We may need another library (or, Ghu forbid, a different C compiler). Try reinstalling libgmp from source. Hello, as a matter of fact, I had gmp 4.1.4 installed from source anyway, but I just rerun the test suite of the library and it worked flawlessly -- so the problem must lie somewhere else. I suppose the expt code should be the culprit because the following works: $ csi ___ _ __ / ___/ / (_)___/ /_ ___ / /__/ _ \/ / __/ '_/ -_) _ \ \___/_//_/_/\__/_/\_\\__/_//_/ Version 2, Build 104 - macosx-unix-gnu-ppc - [ dload ] (c)2000-2005 Felix L. Winkelmann #;1> (use numbers) ; loading /usr/local/lib/chicken/numbers.scm ... ; loading /usr/local/lib/chicken/numbers-base.so ... #;2> (do ((n 1 (* n 10)) (i 0 (add1 i))) ((>= i 100) n)) 1 cu, Thomas Chust ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in the numbers egg?
At Wed, 10 Aug 2005 23:05:06 +0200, Thomas Chust wrote: > > #;2> (expt 10 100) > 10110891155767964156222877689497504522960006971153529700550125477736178357726682741211136 The docs already note that expt gives incorrect results for exact numbers. In the meantime you can use something like this: (define (power base e) ; like expt but e must be an integer (define (square x) (* x x)) (if (negative? e) (/ 1 (power base (- e))) (let lp ((res 1) (e e)) (cond ((zero? e) res) ((even? e) (* res (square (lp 1 (quotient e 2) (else (lp (* res base) (- e 1))) #;5> (power 10 100) 100\00 -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in the numbers egg?
At Wed, 10 Aug 2005 20:37:21 -0500, Alex Shinn wrote: > > (define (power base e) ; like expt but e must be an integer Might as well go all the way. Attached is a patch to numbers-base.scm which modifies the above power function to work on any real numbers and defines the default expt case in terms of that. It's not the fastest implementation but it's probably better to be correct first then optimize later. -- Alex numbers-base.scm.diff Description: Binary data ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: first experiments with "simple-macros"
I too am quite interested in a decent module system, especially after kludging a few things in the sxml-tools egg to get around the lack of one. I have a couple general questions/observations though: - Startup time of either simple-macros or syntax-case is very long -- 1.7s as opposed to 0.1s without it, and this is on a 1.5GHz machine. So I am somewhat reluctant to use this very useful and fundamental concept except for big, non-time-critical apps. Is there room for much optimization, or is it near the limit? - Does it make sense to release official eggs using one or the other module system (assuming we pass the experimental phase)? The time and the memory penalty give me pause---same reason I don't use TinyCLOS in official stuff, seems silly to drag that much code in. - Does it make sense, given the time and space penalty, to use a module system at all for smaller projects? Obviously, we have gotten by without one, but the advantages are tempting. - I can't get define-macro to work with simple-macros (after importing chicken-macros), but I'm sure this is my fault. Don't get me wrong, it's highly interesting and I will experiment. I am just wondering if the intent is to really USE it all over the place, or if it will be relegated to occasional projects. On 8/4/05, Michele Simionato <[EMAIL PROTECTED]> wrote: > > Yes, this is why I waited some time before trying it, to have things > settled down for me ;) I read the first announcement on c.l.s. a while ago > and I thought it was too good to be true. What I like the most is the > module system, I have yet to test it seriously, but at least the > description in the SRFI document makes sense and it is more or less > what I had desired for a module system for my first day in Scheme > (I remember at that time I escaped from the Mzscheme module system > which I felt overcomplicated; I also hated the fact that it forced me > to write macro definitions and helper functions in separate modules, > for reasons that never convinced me). A thing I have always looked at > with suspicion in Chicken (suspicion of being more complicated than > needed) is eval-when: OTOH, van Tonder's system works in a pretty > obvious and reasonable way (by default things are evaluated both > at compile time and import time; if you want to evaluate things > at compile time only you say so and if you want to evaluate things > at import time only you say so: the quintessence of semplicity). > Still I do not understand why things should be more complicated > than that and which are the pittfalls of van Tonder's system (if any). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: first experiments with "simple-macros"
On 8/11/05, Zbigniew <[EMAIL PROTECTED]> wrote: > > - Startup time of either simple-macros or syntax-case is very long -- > 1.7s as opposed to 0.1s without it, and this is on a 1.5GHz machine. It's not much slower than loading the psyntax macros, though. > So I am somewhat reluctant to use this very useful and fundamental > concept except for big, non-time-critical apps. Is there room for > much optimization, or is it near the limit? I can't say, really. There should be room for improvement, but first we have to get it running properly. > - Does it make sense to release official eggs using one or the other > module system (assuming we pass the experimental phase)? The time and > the memory penalty give me pause---same reason I don't use TinyCLOS in > official stuff, seems silly to drag that much code in. Yes, that's something to keep in mind. It really depends on what you want: for application code it makes probably more sense to use psyntax/simple-macros modules. A counterexample is (say) utf8: here we shadow standard procedures. > - Does it make sense, given the time and space penalty, to use a > module system at all for smaller projects? Obviously, we have gotten > by without one, but the advantages are tempting. In small projects I find module systems more a nuisance than a real help. For medium-sized and large systems it is crucial (the chicken compiler, for example, should have been done using psyntax modules). > - I can't get define-macro to work with simple-macros (after importing > chicken-macros), but I'm sure this is my fault. Here is a patch: diff -c /home/fwinkel/stuff/work/kffd/chicken-macros-module.scm\~ /home/fwinkel/stuff/work/kffd/chicken-macros-module.scm --- /home/fwinkel/stuff/work/kffd/chicken-macros-module.scm~2005-08-06 00:23:28.0 +0200 +++ /home/fwinkel/stuff/work/kffd/chicken-macros-module.scm 2005-08-11 08:07:12.145400736 +0200 @@ -21,7 +21,7 @@ (import chicken-internals) (define-syntax include -(lambda form +(lambda (form) (if (= 2 (length form)) (let ((count ##sys#read-line-counter) (filename (cadr form)) ) @@ -38,12 +38,12 @@ (syntax-error "invalid `include' form") ) ) ) (define-syntax define-macro -(lambda form +(lambda (form) (cond ((and (= (length form) 3) (identifier? (cadr form))) (quasisyntax (define-syntax ,(cadr form) - (lambda exp + (lambda (exp) (datum->syntax (car exp) (apply ,(caddr form) (syntax->datum (cdr exp > > Don't get me wrong, it's highly interesting and I will experiment. I > am just wondering if the intent is to really USE it all over the > place, or if it will be relegated to occasional projects. I wouldn't use it all over the place. I'd use it for self-contained applications or large-scale library projects. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in the numbers egg?
Thomas Chust scripsit: > This result is apparently wrong. Nevertheless it has the correct > magnitude. I wonder whether this is some kind of amplified rounding > error or a more serious problem. On my system (Cygwin, gcc 3.4.4) the result is even worse: 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 which is again the right magnitude but has only 1 significant digit correct! > Any idea or work around is appreciated. According to the GMP home page at http://swox.com/gmp/ , many versions of gcc miscompile GMP due to too-aggressive optimizations. We may need another library (or, Ghu forbid, a different C compiler). Try reinstalling libgmp from source. -- John Cowan <[EMAIL PROTECTED]> http://www.ccil.org/~cowan http://www.reutershealth.com Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
