[Chicken-users] chicken-setup -test
Hello! I've added (well, changed, but the old one was not documented and did something not particularly useful).a "-test" option to chicken-setup that will run a Scheme script named "run.scm" in a "tests" directory in the unpacked egg directory, if it exists (after installation). I suggest that authors of new eggs, or maintainers of existing ones put any test cases in there, since this allows automated testing (for example via salmonella). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup -tests
On 5/23/07, Kon Lovett <[EMAIL PROTECTED]> wrote: Hi Felix, I will modify my eggs so that they do not automatically run the tests but use the -tests option & "tests/run.scm" protocol. Very good. I was just about announcing this. Note that many users run chicken-setup as root (which should be avoided) in a default installation. I will still install the test suites though. The idea behind this was to run regression against required units/extensions when a dependency is updated. Unfortunately a unimplemented idea. But at least the info & tests are available when I have the time. Yes, that makes sense. Perhaps in $PREFIX/share/chicken ? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Trivial suggestion
On 5/23/07, Kon Lovett <[EMAIL PROTECTED]> wrote: Hi Felix, Suggest 'blob-length' => 'blob-size'. Size conveys a sense of overall magnitude, while Length suggests a gradient, and 'blobs' have no structure ;-) Yes, but "vector-length", "string-length", etc. suggest a uniform naming scheme. But if your prefer "-size", make it so. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] JSON and unicode escapes
On May 23, 2007, at 11:05 AM, Dan Muresan wrote: Hi, (json-read) doesn't support Unicode escapes: csi> (json-read ) csi> "\u201c" "u201c" I'd like to fix that. Parsing the escapes should be easy since Chicken's (read) actually seems to understand the escapes (even without the utf8 egg). Yes it does, but just the escapes. I see from Trac that a number of people have worked on this egg, and that there's an official Tony G repository somewhere. Where is that repository? Does anyone know how to fix interpret-string- escape (i.e. can it return multiple chars, how to obtain the next token)? He has a homepage < http://homepages.kcbbs.gen.nz/~tonyg >, but I didn't see a JSON. You can of course checkout a copy of the svn repo: svn checkout https://anonymous:@galinha.ucpel.tche.br/svn/chicken- eggs/json Checking in though probably requires a user identity. Cheers, Dan ___ 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
Re: [Chicken-users] records in evicted objects
On May 23, 2007, at 10:44 AM, Dan Muresan wrote: The zeroth "slot" of the record contains the symbol representing its type. When you evict the record, you also evict the symbol. The interned and uninterned symbols are not equal, hence the type-check failure when it is inspected. (equal? :pare (object-evict :pare)) => #f You could set the slot-value back to the non-evicted, interned symbol: Well, the Chicken manual warns against setting slots in evicted objects to non-evicted data, so I'm not gonna do it. I think the right thing to do would be to change the SRFI-9 implementation so that, for evicted objects, it skips the record type test. The misc-extn egg provides SRFI-9 workalikes that "... skips the record type test." Best, Dan ___ 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] JSON and unicode escapes
Hi, (json-read) doesn't support Unicode escapes: csi> (json-read ) csi> "\u201c" "u201c" I'd like to fix that. Parsing the escapes should be easy since Chicken's (read) actually seems to understand the escapes (even without the utf8 egg). I see from Trac that a number of people have worked on this egg, and that there's an official Tony G repository somewhere. Where is that repository? Does anyone know how to fix interpret-string-escape (i.e. can it return multiple chars, how to obtain the next token)? Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] openssl egg
On May 23, 2007, at 6:38 AM, Thomas Christian Chust wrote: your patch looks correct so far. The reason why I didn't include a procedure like that in the egg in the first place is that its existence suggests the possibility to wrap an SSL transport layer around any given pair of input and output ports. That is unfortunately not the case, though. Currently it is only possible to create an SSL wrapper for a file descriptor. You CAN make SSL wrappers for sockets, files, strings/memory, in C, using the bio API. Can they be wrapped up in scheme ports? So you could so something like (define fp (bio-file-new :output-file "encrypted.out")) (bio-push fp an-encryption-filter-bio) (define out-stream (bio->output-stream fp)) (fprintf out-stream "blah blah blah) -- Shawn W. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] records in evicted objects
The zeroth "slot" of the record contains the symbol representing its type. When you evict the record, you also evict the symbol. The interned and uninterned symbols are not equal, hence the type-check failure when it is inspected. (equal? :pare (object-evict :pare)) => #f You could set the slot-value back to the non-evicted, interned symbol: Well, the Chicken manual warns against setting slots in evicted objects to non-evicted data, so I'm not gonna do it. I think the right thing to do would be to change the SRFI-9 implementation so that, for evicted objects, it skips the record type test. Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] records in evicted objects
On 5/23/07, Dan Muresan <[EMAIL PROTECTED]> wrote: Well, the Chicken manual warns against setting slots in evicted objects to non-evicted data, so I'm not gonna do it. I think the right thing to do would be to change the SRFI-9 implementation so that, for evicted objects, it skips the record type test. Wise choice. :-) G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] records in evicted objects
On 5/23/07, Dan Muresan <[EMAIL PROTECTED]> wrote: Evicted objects do not work with srfi-9 records for some reason: (define-record-type :pare (kons x y) pare? (x kar set-kar!) (y kdr)) (kar (object-evict (kons 1 2))) Error: bad argument type - not a structure of the required type The zeroth "slot" of the record contains the symbol representing its type. When you evict the record, you also evict the symbol. The interned and uninterned symbols are not equal, hence the type-check failure when it is inspected. (equal? :pare (object-evict :pare)) => #f You could set the slot-value back to the non-evicted, interned symbol: (let ((p (object-evict (kons 1 2 (##sys#setslot p 0 :pare) (kar p)) => 1 or a more general way: (define (reintern-record-symbol! rec) (##sys#setslot rec 0 (string->symbol (->string (##sys#slot rec 0) (let ((p (object-evict (kons 1 2 (reintern-record-symbol! p) (kar p)) I'm not sure what the implications of this are, though. Maybe your process will blow up after GC. :-) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
On May 23, 2007, at 9:43 AM, Dan Muresan wrote: Not sure what you mean. As opposed to text streams? Binary streams as in binary data, as opposed to text. Calling read-char repeatedly is probably not efficient; besides, read-char may not be the same as read-byte (if utf8 is loaded). Actually 'read-byte' uses the builtin 'read-char' when the utf8 egg is loaded. I was wrong about ##sys#custom-*-port not working w/ UTF8, at least in the broader sense. Excellent. 1. I can't find the documentation for read-byte. I didn't even realize that read-byte existed. What i meant was that read-char might read multiple bytes, when the programmer wanted to read a single byte of binary data. Ha ha. An undocumented part of the utf8 egg. You have a good point. We should probably make 'read-byte' part of the library unit. 2. You did not address the other point -- calling read-char repeatedly is probably not efficient. I think being able to read binary data efficiently is mandatory for a language that's supposed to be practical, no? Yes. Chicken currently doesn't distinguish binary/text, or uni/bi- directional in its' port concept. I will create a TRAC ticket for this. However, you can use 'read/write-string' for binary i/o. The string type in core Chicken is treated as a byte-vector. Again, these will be replaced by the utf8 egg so a 'read/write-bytes' routine in the library unit would be nice. But you can always capture the core definition before such replacement. (Chicken internals do this trick for just the above reason.) Unfortunately not all port classes efficiently support the "string" read/write operation, ##sys#custom & stream ports for example, but string & socket ports do. -- byte-io.scm (declare (uses extras) (export read-byte write-byte read-bytes write-bytes) ) (define read-byte read-char) (define write-byte write-char) (define read-bytes read-string) (define write-bytes write-string) -- It is a work in progress, Kon Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] records in evicted objects
Evicted objects do not work with srfi-9 records for some reason: (define-record-type :pare (kons x y) pare? (x kar set-kar!) (y kdr)) (kar (object-evict (kons 1 2))) Error: bad argument type - not a structure of the required type Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken-setup -tests
Hi Felix, I will modify my eggs so that they do not automatically run the tests but use the -tests option & "tests/run.scm" protocol. I will still install the test suites though. The idea behind this was to run regression against required units/extensions when a dependency is updated. Unfortunately a unimplemented idea. But at least the info & tests are available when I have the time. Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
Not sure what you mean. As opposed to text streams? Binary streams as in binary data, as opposed to text. Calling read-char repeatedly is probably not efficient; besides, read-char may not be the same as read-byte (if utf8 is loaded). Actually 'read-byte' uses the builtin 'read-char' when the utf8 egg is loaded. I was wrong about ##sys#custom-*-port not working w/ UTF8, at least in the broader sense. Excellent. 1. I can't find the documentation for read-byte. I didn't even realize that read-byte existed. What i meant was that read-char might read multiple bytes, when the programmer wanted to read a single byte of binary data. 2. You did not address the other point -- calling read-char repeatedly is probably not efficient. I think being able to read binary data efficiently is mandatory for a language that's supposed to be practical, no? Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] openssl egg
On May 23, 2007, at 6:38 AM, Thomas Christian Chust wrote: Goetz Isenmann wrote: [...] I try to create a https connection tunneling through a proxy. Therefore I have to (1) create an unencrypted tcp connection to the proxy, (2) tell the proxy to create a tunnel to the servers https port (CONNECT host.domain:port HTTP/1.0), (3) wait for a positive response (HTTP/1.0 200 Connection established), and (4) initiate a SSL handshake over this already estabilshed connection. Looks like the current openssl egg does not support this (step 4). May I suggest a change? [...] Beware: I have never done anything in scheme, I can only guess, what that values, cut, and wrap business might do. Hello Goetz, your patch looks correct so far. The reason why I didn't include a procedure like that in the egg in the first place is that its existence suggests the possibility to wrap an SSL transport layer around any given pair of input and output ports. That is unfortunately not the case, though. Currently it is only possible to create an SSL wrapper for a file descriptor. How do others think about this: Should an ssl-start procedure be included in the OpenSSL egg and if yes, should it try to extract a file descriptor from given ports, should it be given a file descriptor directly or should it maybe really create a wrapper around the given ports and pass that to OpenSSL? Extracting an fd from a port is problematic. The posix unit 'port- >fileno' will throw an exception when the port isn't socket or stream (really if it has an associated FILE* but custom & string ports don't). The Windows version only recognizes ports w/ an associated FILE*. I guess if the parameter is called 'port' it should probably accept a port ;-) BTW: Does this #!optional port make sense? Isn't it a required argument? The port argument doesn't have to be passed if you include the port specification in the hostname argument (eg. "ftp:localhost"). See the documentation of tcp-connect for more information. cu, Thomas ___ 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
Re: [Chicken-users] 32 bit integers?
On May 23, 2007, at 6:33 AM, Dan Muresan wrote: The SRFI-60 egg, per the SRFI document, exports bitwise-* & and arithmetic-shift, which override the definitions in the library unit. It probably should at least rename them before the override. I will do this & release an update SRFI-60. (Personally I don't think the aliases are a good idea but that is the SRFI.) The strictest interpretation of the aliasing requirement that I can concieve of is that (eq? bitwise-ior logior) returns true. I don't think the SRFI mandates the reference implementation to be used. Therefore, you could simply alias logior to mean bitwise-ior etc. This would solve the bug, right? Yes. What I did was a Q&D placeholder. W/O a real review of the semantics of SRFI-60 I didn't feel comfortable w/ the above. W/ the numbers egg the reference implementation will work w/ bignums. (Interesting given that GMP uses sign-magnitude & not 2s-complement.) While the document speaks of fixnums, it uses the term interchangeably with integer. Maybe the log* operations could have a broader definition of 'integer' than the bitwise-* operations. But, it might be best to be true to the spirit of the SRFI. In any case, the bit fiddling/logic operations on bignums should be done by GMP so a SRFI-60 extension for the numbers egg is a good idea. Best Wishes, Kon -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
On May 23, 2007, at 8:37 AM, Dan Muresan wrote: See make-output/input-port, in the extras unit. Very nice, I missed it. So I guess if READ and PEEK yield instead of blocking, then that stream plays nicely with threads, just like tcp streams? I think so. The ##sys#custom-*-port routines do yield. Take a look at the source in "posixunix.scm" Unfortunately it uses sys & core namespace routines, but you can get the idea. Any thoughts on binary streams? Not sure what you mean. As opposed to text streams? Or are you talking about bi-directional streams? If so then it would be nice to have but since I have no requirements as yet I really shouldn't speak to it. Calling read-char repeatedly is probably not efficient; besides, read-char may not be the same as read-byte (if utf8 is loaded). Actually 'read-byte' uses the builtin 'read-char' when the utf8 egg is loaded. I was wrong about ##sys#custom-*-port not working w/ UTF8, at least in the broader sense. Excellent. -- Dan Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
See make-output/input-port, in the extras unit. Very nice, I missed it. So I guess if READ and PEEK yield instead of blocking, then that stream plays nicely with threads, just like tcp streams? Any thoughts on binary streams? Calling read-char repeatedly is probably not efficient; besides, read-char may not be the same as read-byte (if utf8 is loaded). -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Trivial suggestion
Hi Felix, Suggest 'blob-length' => 'blob-size'. Size conveys a sense of overall magnitude, while Length suggests a gradient, and 'blobs' have no structure ;-) Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
On May 23, 2007, at 4:15 AM, Dan Muresan wrote: LOCATIONcalling procedure/context id NAMEname for the port (usually the process command pathname) FILENOopen file descriptor BUFFER-INFOeither a fixnum size or a string ON-CLOSEfileno was closed notification procedure MORE-PREDICATE boolean procedure indicating whether more input is available, usually not needed but the programmer may know something that the C 'read' procedure doesn't Interesting... Let me put forward the following proposal: 1. Binary streams, maybe wrapping fread / fwrite. 2. Two stream APIs (one for binary and one for char ports) The ideea would be that I'd be able to write, for example, my own application-level reliable transport protocol over UDP, and wrap it into Chicken Streams. The char output stream API could look like (##sys#make-output-stream write-char close) and the input one (##sys#make-input stream peek-char read-char close) See make-output/input-port, in the extras unit. This, of course, doesn't yet take into account threads and UTF8. What do you guys think? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] openssl egg
Goetz Isenmann wrote: > [...] > I try to create a https connection tunneling through a proxy. > > Therefore I have to (1) create an unencrypted tcp connection to the > proxy, (2) tell the proxy to create a tunnel to the servers https > port (CONNECT host.domain:port HTTP/1.0), (3) wait for a positive > response (HTTP/1.0 200 Connection established), and (4) initiate a > SSL handshake over this already estabilshed connection. > > Looks like the current openssl egg does not support this (step 4). > > May I suggest a change? > [...] > Beware: I have never done anything in scheme, I can only guess, what > that values, cut, and wrap business might do. Hello Goetz, your patch looks correct so far. The reason why I didn't include a procedure like that in the egg in the first place is that its existence suggests the possibility to wrap an SSL transport layer around any given pair of input and output ports. That is unfortunately not the case, though. Currently it is only possible to create an SSL wrapper for a file descriptor. How do others think about this: Should an ssl-start procedure be included in the OpenSSL egg and if yes, should it try to extract a file descriptor from given ports, should it be given a file descriptor directly or should it maybe really create a wrapper around the given ports and pass that to OpenSSL? > BTW: Does this #!optional port make sense? Isn't it a required argument? The port argument doesn't have to be passed if you include the port specification in the hostname argument (eg. "ftp:localhost"). See the documentation of tcp-connect for more information. cu, Thomas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Disappearing functions from DLL
Hallo, On 5/23/07, felix winkelmann <[EMAIL PROTECTED]> wrote: Sorry, but I need more information or some test code to help here. Do you compile in unsafe mode? Does "disappear" mean they are not there, or do references trigger the above error? After loading, does "(apropos )" list the functions exported from the dll? I guess the code will be useless unless you install IUP. :-( - I compile with just "-s" (not unsafe, not optimizing) - (apropos) is not defined here - "Disappear" means undefined variable when I call the function One funny thing: When I put (display iup:main-loop) at the beginning of file, "#" is shown and the function is available from now on. Previously it wasn't. Cheers, -- -alex http://www.ventonegro.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] openssl egg
Hi! I try to create a https connection tunneling through a proxy. Therefore I have to (1) create an unencrypted tcp connection to the proxy, (2) tell the proxy to create a tunnel to the servers https port (CONNECT host.domain:port HTTP/1.0), (3) wait for a positive response (HTTP/1.0 200 Connection established), and (4) initiate a SSL handshake over this already estabilshed connection. Looks like the current openssl egg does not support this (step 4). May I suggest a change? Something like: --- openssl.scm 2006-10-18 07:48:10.0 +0200 +++ openssl2.scm2007-05-23 14:20:39.614720373 +0200 @@ -4,6 +4,7 @@ (define-extension openssl (export ssl-connect + ssl-start ssl-make-client-context ssl-client-context? ssl-listen @@ -401,9 +402,12 @@ ;; connect to SSL server (define (ssl-connect hostname #!optional port (ctx 'sslv2-or-v3)) + (let-values (((i o) (tcp-connect hostname port))) + (ssl-start i o ctx))) + +(define (ssl-start i o #!optional (ctx 'sslv2-or-v3)) (let* ((fd - (call-with-values (cut tcp-connect hostname port) - ##net#unwrap-tcp-ports)) + (##net#unwrap-tcp-ports i o)) (ctx (if (ssl-client-context? ctx) (##ssl#unwrap-client-context ctx) Beware: I have never done anything in scheme, I can only guess, what that values, cut, and wrap business might do. BTW: Does this #!optional port make sense? Isn't it a required argument? -- Goetz Isenmann -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] stream API (was busy-wait in tcp-connect)
LOCATIONcalling procedure/context id NAMEname for the port (usually the process command pathname) FILENOopen file descriptor BUFFER-INFOeither a fixnum size or a string ON-CLOSEfileno was closed notification procedure MORE-PREDICATE boolean procedure indicating whether more input is available, usually not needed but the programmer may know something that the C 'read' procedure doesn't Interesting... Let me put forward the following proposal: 1. Binary streams, maybe wrapping fread / fwrite. 2. Two stream APIs (one for binary and one for char ports) The ideea would be that I'd be able to write, for example, my own application-level reliable transport protocol over UDP, and wrap it into Chicken Streams. The char output stream API could look like (##sys#make-output-stream write-char close) and the input one (##sys#make-input stream peek-char read-char close) This, of course, doesn't yet take into account threads and UTF8. What do you guys think? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
