Re: [Chicken-users] newbie: using hart- unbound variable: hart-parse
Hi folks, Thanks, Felix, for answering this one. Is there a directive we could add to hart itself, to automate the require-for-syntax? Basile, I hope you enjoy using Hart! Best, Graham On Mon, Dec 15, 2008 at 2:29 AM, felix winkelmann bunny...@gmail.com wrote: On Sat, Dec 13, 2008 at 12:05 PM, Basile STARYNKEVITCH bas...@starynkevitch.net wrote: % csc hartex.scm -o hartex Error: during expansion of (hart ...) - unbound variable: hart-parse Call history: syntax(begin (hart (html (head (title People)) (body (h1 (fmt: A list of ~a people (length people))) (if... syntax(hart (html (head (title People)) (body (h1 (fmt: A list of ~a people (length people))) (if: (nu.. eval(##sys#list (quote noop) (apply hart-parse forms)) eval(apply hart-parse forms)-- *** Shell command terminated with exit status 1: /usr/bin/chicken hartex.scm -output-file hartex.c -quiet I am obviously missing something obvious, but what? I thought that the use directive is enhancing the enviroment, including macro syntax extension, at compile time! This is a big in hart.scm: the macro uses a function from hart-support.scm, but this is only available at run-time, not compile-time. For the time being, add this before the first use if the hart macro: (require-for-syntax 'hart-support) cheers, felix ___ 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] current base64 on chicken 3 incorrect?
Hi folks, The current base64 egg for Chicken 3 builds, but gives me incorrect results. The non-working version is by Bailey, ported by Felix. (I found an older version in Scheme by Felix that works correctly.) Sorry for not debugging the problem, but attached is a test program that runs (base64:encode) across a fixed input and compares with a known output. (If you have the base64 tool from coreutils, you can verify my test files with base64 -w 0 base64-in | diff base64-out -.) This succeeds with the old Felix code but fails with the current Bailey code. Best, Graham base64-test.tar Description: Unix tar archive ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] base64 import problem with chicken-hygienic
Hi folks, it looks like base64 under chicken-hygienic doesn't import properly -- I get the import.so but not the real one. I used the new chicken-install to fetch base64, though I don't think that's relevant. Best, Graham CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.0.0x - linux-unix-gnu-x86 [ manyargs dload ptables applyhook ] SVN rev. 11777 compiled 2008-08-27 on fawcett-lap (Linux) ; loading /home/graham/.csirc ... #;1 ,s chicken-status4 | grep base base64 .. version: 2.0 0 #;2 (import base64) ; loading /home/graham/tmp/chicken4/lib/chicken/4/base64.import.so ... ; loading /home/graham/tmp/chicken4/lib/chicken/4/chicken.import.so ... ; loading /home/graham/tmp/chicken4/lib/chicken/4/scheme.import.so ... #;3 encode Error: unbound variable: base64#encode #;3 (load /home/graham/tmp/chicken4/lib/chicken/4/base64.so) ; loading /home/graham/tmp/chicken4/lib/chicken/4/base64.so ... #;4 encode #procedure (base64#encode str11) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] base64 import problem with chicken-hygienic
On Wed, Aug 27, 2008 at 1:33 PM, Peter Bex [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 12:11:02PM -0400, Graham Fawcett wrote: Hi folks, it looks like base64 under chicken-hygienic doesn't import properly -- I get the import.so but not the real one. (import) is a statement that imports the module into the current module. For that to work, you must have loaded the extension first. The correct incantations are: #;1 (require-library base64) OR: #;1 (require-extension base64) D'oh, of course, that was silly of me. Thanks for the correction. The latter example is the same as you'd do it in Chicken 3. It loads and imports the extension in one go, without allowing you to do any operations on the imported symbols anymore. It's more convenient, but less powerful. I think Felix reinstated the (use ) command also, so you could also just do (use base64), just like you'd do with chicken 3. Yes, I can confirm that (use base64) does the right thing. Cheers, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] pretty-print
On Wed, Aug 27, 2008 at 5:52 PM, Daishi Kato [EMAIL PROTECTED] wrote: Hi, This is more like a general scheme or lisp question, but does anybody know how I can get a formal rule for pretty print? I want to implement pretty print in non-scheme programming language. Not Scheme at all, but you might enjoy these: Philip Wadler, A prettier printer. http://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettier.pdf The Design of a Pretty-printing Library in Advanced Functional Programming, Johan Jeuring and Erik Meijer (eds), LNCS 925 http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken on linux64
On Thu, Aug 21, 2008 at 3:39 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 10:15 PM, Graham Fawcett [EMAIL PROTECTED] wrote: I know I'll need to recompile Chicken and any shared libraries. Are there other things I should be concerned about, e.g. surprising differences in Chicken behaviour on 64-bit systems? The most obvious difference will be that fixnums don't overflow so quickly into flonums. Naturally, more storage will be used, as cells use twice as much space. Apart from that (and provided you don't use too much foreign code), there isn't much of a difference, from the chicken point of view. Thanks, Felix and Sven, for the responses. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken on linux64
Hi folks, I have some Chicken 2.x and 3.x Web applications in production on a 32-bit Intel Linux server. We may be upgrading to a new 64-bit Intel machine, and I'm wondering what kind of Chicken-specific road-bumps I might encounter when I try to migrate the apps. I know I'll need to recompile Chicken and any shared libraries. Are there other things I should be concerned about, e.g. surprising differences in Chicken behaviour on 64-bit systems? Having never maintained a 64-bit box, I'm embarrassingly short on 64-bit knowledge, so anything you might be willing to share would be a great help. Links to general 64-bit migration challenges documents would also be very welcome (perhaps send those to me directly, so as not to spam the list). Thanks in advance, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg announcement: remote-repl
On Tue, Aug 19, 2008 at 9:36 AM, Tobia Conforto [EMAIL PROTECTED] wrote: Jörg F. Wittenberger wrote: are dynamic-wind pre/post-thunks by chicken executed upon each thread switch? Why would they? It's not a bad question. When threads are implemented using continuations, it is reasonable to expect dynamic-wind to be triggered in a context switch. I don't have references at hand, but I've read an academic paper or two on this issue. In fact they don't: And thankfully so! Graham (use srfi-18) (thread-start! (make-thread (lambda () (dynamic-wind (lambda () (print Entering thread 1)) (lambda () (print In thread 1) (thread-yield!) (print In thread 1)) (lambda () (print Exiting thread 1)) (dynamic-wind (lambda () (print Entering thread 0)) (lambda () (print In thread 0) (thread-yield!) (print In thread 0)) (lambda () (print Exiting thread 0))) (thread-sleep! 1) Entering thread 0 In thread 0 Entering thread 1 In thread 1 In thread 0 Exiting thread 0 In thread 1 Exiting thread 1 Tobia ___ 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] egg announcement: remote-repl
On Tue, Aug 19, 2008 at 10:02 AM, Graham Fawcett [EMAIL PROTECTED] wrote: On Tue, Aug 19, 2008 at 9:36 AM, Tobia Conforto [EMAIL PROTECTED] wrote: Jörg F. Wittenberger wrote: are dynamic-wind pre/post-thunks by chicken executed upon each thread switch? Why would they? It's not a bad question. When threads are implemented using continuations, it is reasonable to expect dynamic-wind to be triggered in a context switch. I don't have references at hand, but I've read an academic paper or two on this issue. Ah, I found the paper I was thinking of: Martin Gasbichler, Eric Knauel, Michael Sperber Richard A. Kelsey: How to Add Threads to a Sequential Language Without Getting Tangled Up, In The 2003 Scheme Workshop, Boston, Ma., October 2003 Abstract: It is possible to integrate Scheme-style first-class continuations and threads in a systematic way. We expose the design choices, discuss their consequences, and present semantical frameworks that specify the behavior of Scheme programs in the presence of threads. While the issues concerning the addition of threads to Schemelike languages are not new, many questions have remained open. Among the pertinent issues are the exact relationship between continuations and the call-with-current-continuation primitive, the interaction between threads, first-class continuations, and dynamic-wind, the semantics of dynamic binding in the presence of threads, and the semantics of thread-local store. Clarifying these issues is important because the design decisions related to them have have profound effects on the programmer's ability to write modular abstractions. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] An alternative thread system?
On Sun, Aug 10, 2008 at 9:42 PM, Vincent Manis [EMAIL PROTECTED] wrote: CPython uses a Global Interpreter Lock (GIL) to implement critical sections in the interpreter, thus rendering native threads in that system impossible. Some version of the Python interpreter (I think it was 1.6) was rewritten without the GIL, so as to provide for native threads. That's close, but not quite right. CPython threads are indeed system threads, but the GIL guarantees that only one of them is running Python code at any time. Best, G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Anyone up for porting Termite to Chicken?
On Wed, May 21, 2008 at 9:39 AM, Mark Fredrickson [EMAIL PROTECTED] wrote: I do believe that one can start a new Erlang VM and add it to the cloud at any time, but I get the impression this is actually rare. With n cores, why not just start a VM on each core to begin with? A year or two ago, the Erlang VM gained SMP support, so while it runs green threads, they can be executed in parallel. I believe this is called M:N threading (running M green threads on N native ones). Prior to this, I suspect one-vm-per-core was an Erlang idiom. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Cyclic lists and the Interpreter
On Mon, Apr 7, 2008 at 3:24 PM, Alex Rozenshteyn [EMAIL PROTECTED] wrote: (define a (list 'a)) (set-cdr! a a) ;a is now a cyclic list (pair? a) ; - #t (list? a) ; - #f (length a) and now the interpreter gets stuck. control-c does not break (this is because I have the readline egg installed). I have two questions: 1) How do I get C-c to break? 2) Is the interpreter supposed to freeze if length is passed a cyclic list? Yes, it's correct. See length and length+ in SRFI-1: http://srfi.schemers.org/srfi-1/srfi-1.html#Miscellaneous length+ will give you sane behaviour with cyclic lists. Other scheme implementations generate an error. Yes, but that's implementation-specifc. (length) may diverge or signal an error according to SRFI-1, and in Chicken's case it diverges. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Sun, Apr 6, 2008 at 1:46 PM, Matthew Welland [EMAIL PROTECTED] wrote: What is the status of this effort? I have written a *very* simplistic DBI which supports lowest common demoninator access to sqlite3 and postgresql. It is only 90 or so lines of code but so far seems enough to let me write for sqlite and switch to postgresql etc. Matthew, you just reminded me that I never made a release for the Postgres change I made, that allows for (optional) query parameters. I'll find a minute today to release it. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Mon, Apr 7, 2008 at 9:51 AM, Graham Fawcett [EMAIL PROTECTED] wrote: Matthew, you just reminded me that I never made a release for the Postgres change I made, that allows for (optional) query parameters. I'll find a minute today to release it. Ah, it looks like Kon moved postgresql to the tags/trunk structure (r9971, March 20), which included my query-parameters in the 2.0.13 release. Thanks Kon! Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http cookie order
On Mon, Mar 31, 2008 at 1:40 PM, Tony Sidaway [EMAIL PROTECTED] wrote: Thanks for a very informative analysis. Of course this whole problem only cropped up because we Schemers like to build up lists by consing new elements to the front. I would probably have included a reverse in the result of the let loop without thinking, I think I'm wired the same way. Typing (if (null? lst) (reverse acc) ...) is the path of least resistance! but unless you have reason to suspect that attribute order will matter somewhere down the line, that's just wasted CPU cycles and wasted consing. I don't think I'd worry much about the consing: there are rarely many attributes in a request, and minor GC would deal with the garbage quickly and efficiently. It's worth the cost in order to make the attribute-list more correct, and Drake has dug up proof that ordering is significant in the spec. Of course, then somebody comes along and writes a hack to update the cookie attribute.. :) Let's hope they do it with (set-cdr!) and all is well! Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http cookie order
On Thu, Mar 27, 2008 at 9:07 PM, Tony Sidaway [EMAIL PROTECTED] wrote: Using http.egg to write a bot that has to login to a ubb forum, I discovered that the cookie processing order of that egg resulted in login failure. When I tweaked http:read-request-attributes to reverse the order of the attributes it returned, all was well. This is because in reply to a successful login the ubb server sends a sequence of set-cookie headers, one of which is something like ubbt_myid=deleted (presumably to end any previous session) while a later header contains a cookie that looks something like ubbt_myid=26 signifying the id corresponding to the username. Processing the cookies in the wrong order results in the Cookie attribute of the http-request object being set to contain ubbt_myid=deleted, destroying the session login data on the client side and effectively ending the session. It's a bit risky of the UBB server to send two Set-Cookies with the same cookie name, without giving one precedence by specifying a more specific path. RFC2109 allows for multiple Set-Cookies, but it also warns that an intervening gateway could fold multiple such headers into a single header. Since folding is undefined, there's no way the origin server can guarantee the sequence of the cookies in the received header. If the two cookies have different path precedence, that's a different matter: effectively they are two different cookies. I suppose it makes sense to retain the headers in the order they were received from the server, but gateway meddling could lead to unpredictable results in this particular case. Just my two cents, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Win32 Threading Issue
On Thu, Mar 27, 2008 at 6:12 PM, Raymond Medeiros [EMAIL PROTECTED] wrote: can someone give me a reasonable explanation as to why this would not work on Win32 but works properly on Linux? what am i missing here? Just curious, in what way doesn't it work? Graham (use tcp-server) (thread-start! (make-thread (lambda () ((make-tcp-server (tcp-listen 9000) (lambda () (write-line (conc response: (read) #t)) )) (thread-yield!) (define send-data (lambda (ip port msg) (define-values (i o) (tcp-connect (-string ip) port)) (write msg o) (let ((result (read-line i))) (close-input-port i) (close-output-port o) result))) (letrec ((loop (lambda () (pp (send-data 127.0.0.1 9000 hi)) (loop (loop)) ___ 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] http cookie order
On Fri, Mar 28, 2008 at 8:31 PM, Drake Wilson [EMAIL PROTECTED] wrote: [RFC excerpts snipped] My interpretation of this is: - Forwarders are not permitted to rearrange multiple Set-Cookie headers. HTTP client and server libraries have the same constraint. - Origin servers should not generate multiple Set-Cookie headers in the same response for the same (name, domain, path) tuple, since it is not clear what one should do with them. - Clients should interpret Set-Cookie headers in the order they are received, partly because it's a more constrained interpretation of the term pre-existing in the spec, and partly due to rude-ish websites that will return ambiguous responses and expect that interpretation. (I do not know of any site that expects a different interpretation of multiple cookies overwriting each other in the same response.) Excellent analysis, Drake. I think your interpretation is on the money. (RFC 2109 is also supposedly obsoleted by RFC 2965, but that describes the behavior of Set-Cookie2 headers, not Set-Cookie headers, and it doesn't seem any clearer.) Yes, I find that odd as well. :-) Thanks, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
On Tue, Mar 18, 2008 at 7:05 AM, Alex Shinn [EMAIL PROTECTED] wrote: Tobia == Tobia Conforto [EMAIL PROTECTED] writes: Tobia Graham Fawcett wrote: Here's another thought. It seems to me that if we were to represent strings as composite values, e.g. a two-slot record whose first slot is an encoding (the symbol 'utf8, or #f for 'byte' encoding), and whose second slot contains the string data, then the various string functions could dispatch on the type, and there would be no need to monkey-patch core string functions to get the desired semantics. Tobia This is more or less how other languages, such as Tobia Python, solved the issue. Two kinds of strings, Tobia byte and unicode, and overloading a few string Tobia operations to have a slightly different meaning Tobia when called on either, computing byte length Tobia vs. character length. I keep trying to say, this is *not* the issue! :) And eventually I'll listen, I promise Alex. :-) The entire problem revolves around adding Unicode support as an option, without modifying the core. *If* we allow ourselves to modify the core, then there is no problem at all, and we can just copy the utf8 egg code over the existing string procedures, and add in some procedures for byte-level access. While I'm leery of hastily choosing utf8 as our core string representation (I feel that this issue *does* involve internal representation for that very reason, though admittedly not in the same sense) I agree 100% that Unicode support should be core. And on that note I'll stop muddying the waters and give my +1 to copying utf8 into the core and adding a suite of byte- functions. For what it's worth, I also think that GMP should be in the core, and that no one, nowhere should be allowed to publish an egg with a toplevel procedure named (format) in it. Mysterious toplevel interactions between indirect dependents are the bane of good software. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
On Tue, Mar 18, 2008 at 10:01 AM, John Cowan [EMAIL PROTECTED] wrote:
Graham Fawcett scripsit:
So, a byte string would simply be a string with a null auxilliary vector.
That doesn't work. A byte-string is not a sequence of characters from
the ASCII repertoire, it's a sequence of characters from the repertoire
{ASCII set, characters numbered 129 through 255 with uncertain semantics}.
Well, except on EBCDIC machines, where the repertoire is that of some
unspecified EBCDIC code page.
Right. But I had taken byte string to mean, string of one-byte
characters of unspecified encoding; possibly a vector of octets that
don't represent characters at all. Under this model, a null auxiliary
vector would indicate the lack of wide characters, nothing more.
Graham
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
On Tue, Mar 18, 2008 at 12:22 PM, John Cowan [EMAIL PROTECTED] wrote: It wouldn't solve the data-punning problem. As long as the same object can be seen one way by one module and another way by another, problems will continue to be endemic. To fix that, we need two run-time types, which I hereby dub restricted and unrestricted strings. Just curious, whence the 'restricted' terminology? I would have thought 'utf8 and raw/byte strings' since that's the practical implication. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] shootout benchmark: ring
Hi folks, Last night I worked on a submission for the 'ring' benchmark in the Shootout: http://shootout.alioth.debian.org/sandbox/benchmark.php?test=threadringlang=all After a couple different approaches, the one that worked best by far was to use the 'mailbox' egg, which we cannot do in the Shootout, since it's not part of the core. So, I stripped down the mailbox to its essentials (w.r.t. this program), and included it. It adds an extra 80 lines to the program size, but it's a better representation of what Chicken can do, IMO. On my laptop, I can run N=1e7 in about 33 seconds, compared to about 47 seconds for the Python version (though I am possibly running an older Python?). I can't speak for the Shootout machines, but this might put Chicken roughly in the category of the GNU gcc program. Code is attached; comments are welcome. Graham ring.tgz Description: GNU Zip compressed data ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
On Mon, Mar 17, 2008 at 11:22 AM, Kon Lovett [EMAIL PROTECTED] wrote: Summary: I want a byte-string API. I want string integrations. I want global UTF8 strings. The Factor language borrowed from Larceny a clever mechanism for representing Unicode strings efficiently. Perhaps such a system is feasible for Chicken, and might eliminate some of these issues (at the cost of distancing our string type a bit more from C char arrays): http://factor-language.blogspot.com/2008_01_01_archive.html The new representation is quite clever, and comes from Larceny Scheme. The idea is that strings are ASCII strings, but have an extra slot pointing to an 'auxiliary vector'. If no auxiliary vector is set, the nth character of the string is just the nth byte. If an auxiliary vector is set, then the nth character has the nth byte as the least significant 8 bits, and the most significant 13 bits come from the nth double-byte in the auxiliary vector. Storing a non-ASCII character into the string creates an auxiliary vector if necessary. This reduces space usage for ASCII strings, it can represent every Unicode code point, and for strings with high code points in them, it still uses less space than the other alternative, UTF-32. So, a byte string would simply be a string with a null auxilliary vector. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
On Mon, Mar 17, 2008 at 10:29 PM, Alex Shinn [EMAIL PROTECTED] wrote: Graham == Graham Fawcett [EMAIL PROTECTED] writes: Graham On Mon, Mar 17, 2008 at 11:22 AM, Kon Lovett [EMAIL PROTECTED] wrote: Graham The Factor language borrowed from Larceny a Graham clever mechanism for representing Unicode Graham strings efficiently. Perhaps such a system is Graham feasible for Chicken, and might eliminate some Graham of these issues (at the cost of distancing our Graham string type a bit more from C char arrays): [snip] This only adds news issues, and solves none of the old ones. The representation itself is interesting, though it may in fact be a pessimisation in many cases (utf8 is about the fastest approach for parsing and regex matching, which are the string operations where speed is the biggest issue to begin with). Fair enough. Here's another thought. It seems to me that if we were to represent strings as composite values, e.g. a two-slot record whose first slot is an encoding (the symbol 'utf8, or #f for 'byte' encoding), and whose second slot contains the string data, then the various string functions could dispatch on the type, and there would be no need to monkey-patch core string functions to get the desired semantics. A proper protocol for handling string encodings could be designed, utf8 being one of those encodings. I don't imagine the dispatch overhead would be significant in any but the tightest inner loops, in which case one could resort to fully-specified functions (e.g. byte-string-length or utf8-string-length). Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 6:06 PM, Peter Bex [EMAIL PROTECTED] wrote: On Sun, Mar 16, 2008 at 02:56:11PM -0700, Robin Lee Powell wrote: With define-http-resource, *Spiffy* defines the headers, and it never asks the body. In fact, the headers are sent before the body is run. That's not entirely correct. Spiffy parameterizes the headers. You can override them in the body. I'm glad I wasn't totally wrong, since I didn't look into Spiffy's docs first. :-) But yes, this should work: (current-reponse-headers (cons (cons Content-Length (-string clen)) (current-response-headers))) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hart and syntax-case won't play nice. :(
On Sat, Mar 15, 2008 at 1:26 PM, Kon Lovett [EMAIL PROTECTED] wrote: hart uses low-level macros only. Is there a way I can alter hart so that it will play better with code that uses higher-level macro systems? I'd rather not rewrite it in syntax-case (though it's really not very much macro code; perhaps a syntax-case version wouldn't be that hard). I confess to being an unhygienic, low-level macro user, and have to scratch my head whenever I encounter syntax-case code. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] web-scheme hart
On Sat, Mar 15, 2008 at 2:42 AM, Robin Lee Powell [EMAIL PROTECTED] wrote: On Thu, Mar 06, 2008 at 09:37:42AM -0500, Graham Fawcett wrote: Hope this helps. Comments and suggestions are always welcome. I'd really like a way to call my i18n code with a minimum of fuss. This led me to looking at the hart code and discovering: ;; Hart keyword syntax ;; Fixme -- I really want to make this user-extensible. Yes, I would like you to too! :) I would offer suggestions, but I've never used match-let. Sure Robin, let's talk about this if/when the hi-level/low-level macro stuff gets sorted out to your satisfaction. FwIW, though, all I really want is something like: (text: (foo ...)) aliased as something nice and short: (f: ...) Until I get custom tag support, you could try adding an (f:) clause to hart-support.scm, e.g.: ((t: text:) (hart-emit `(apply hart-print (map hart-html-escape (list ,@body) +((f:) (hart-parse-keyword-form `(text: (foo ,@body Untested but should work. Here, (f: ...) is simply translated to (text: (foo ...)) and then resubmitted for processing. Note too that (t: ...) is an abbreviation for (text: ...). You can tell from the snippet above how abbreviations can be specified. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hart and syntax-case won't play nice. :(
On Sat, Mar 15, 2008 at 2:49 PM, Robin Lee Powell [EMAIL PROTECTED] wrote: On Sat, Mar 15, 2008 at 02:48:01PM -0400, Graham Fawcett wrote: On Sat, Mar 15, 2008 at 1:26 PM, Kon Lovett [EMAIL PROTECTED] wrote: hart uses low-level macros only. Is there a way I can alter hart so that it will play better with code that uses higher-level macro systems? I'd rather not rewrite it in syntax-case (though it's really not very much macro code; perhaps a syntax-case version wouldn't be that hard). I confess to being an unhygienic, low-level macro user, and have to scratch my head whenever I encounter syntax-case code. What about define-syntax, rather than syntax-case? That's the only thing I'm importing syntax-case for anyways. (Yes, I'm friends with John Cowan :) Lucky you! :-) I guessed, from the Lojban .sigs. The main macro in Hart is ridiculously small. Hart-support (the non-macro code) does all the work: (define-macro (hart . forms) `(noop ,(apply hart-parse forms))) That should be trivial to translate into any macro system. The trickiest macro is hart-for, which provides some polymorphism (iteration over both lists and vectors) and destructuring for the (for: ...) construct. (define-macro (hart-for args . body) (let ((real-iter (gensym 'iter)) (foreach (gensym 'foreach)) (lst (gensym 'list))) (match-let (((iter the-lst) args)) `(let* ((,lst ,the-lst) (,foreach (if (list? ,lst) for-each hart-vector-for-each*))) (,foreach (lambda (,real-iter) (match-let ((,iter ,real-iter)) ,@body)) ,lst) That too could be simplified. There's no real need to choose for-each vs. hart-vector-for-each* at the macro-level, since really the decision between the two is made at runtime. So we could add a generic hart-for-each* support procedure that takes either: (define (hart-for-each* proc lst) (cond ((list? lst) (for-each proc lst)) ((vector? lst) (hart-vector-for-each* proc lst)) (#t (error not a list or vector and simplify the macro down to this (totally untested): (define-macro (hart-for args . body) (let ((real-iter (gensym 'iter)) (foreach (gensym 'foreach)) (lst (gensym 'list))) (match-let (((iter the-lst) args)) `(hart-for-each* (lambda (,real-iter) (match-let ((,iter ,real-iter)) ,@body)) ,lst which *might* be easier to write in higher-level macro systems. It might be hard to do the variable capture though. Ignoring (for: ...) for the moment, just (use hart) and then use (define-syntax) to define your own high-level version of: (define-macro (hart . forms) `(noop ,(apply hart-parse forms))) and you should be good to go. Sorry, I don't have more time for a tested solution today... Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hart and syntax-case won't play nice. :(
On Sat, Mar 15, 2008 at 3:24 PM, Graham Fawcett [EMAIL PROTECTED] wrote: The main macro in Hart is ridiculously small. Hart-support (the non-macro code) does all the work: (define-macro (hart . forms) `(noop ,(apply hart-parse forms))) That should be trivial to translate into any macro system. Hm, on second thought, I probably shouldn't assume that just because a macro is short, it would be trivial to translate into another system. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [chicken-users] (declare (uses ...)) causing grief
(declare (uses ...)) doesn't do what you think it does. :-) It's for specifying relationships between compilation units, not modules (eggs). I usually do csc -X module1 -R module2 myfile.scm (where module1 is needed at compilation, and module2 is needed at runtime). Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hang problem with the http egg.
On Wed, Mar 12, 2008 at 11:22 AM, Robin Lee Powell [EMAIL PROTECTED] wrote: Could it be that the body is the string OK,585562 with no terminating newline, and read-line hangs on it? Possible. If that's really the issue, you could try using read-lines or read-all. But if so, it's still an http egg bug, because http:GET hangs on it too. The blocking makes sense: if you ask a port to read an indeterminately long string, it will eventually block until the connection is closed. Perhaps get the Content-Length header from the response, and (read-string n) where n is the Content-Length? Not saying it isn't an http-egg bug, just that the symptom of the problem seems logical from a network-socket perspective. Graham Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hang problem with the http egg.
On Wed, Mar 12, 2008 at 3:47 PM, Hans Bulfone [EMAIL PROTECTED] wrote: hi, What's happening is that eof never returns true, even though the port is closed. ready returns #f, and the next operation (either peek-char or read-char, I've tried both) hangs. eof-object? is imho not meant to be called with a port. $ grep imho hans-message | wc -l 5 $ grep -v imho hans-message | wc -l 21 Humility on 5 of 26 lines. Hans, you have qualified as the most humble person on chicken-users. ;-) Your humble servant, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] salmonella reports broken?
Hi Mario, It looks like the salmonella scheduled task is choking on something. Recently the eggs are failing to build, showing this error text: Error: unbound variable: -script Not the end of the world, but I wasn't sure if you were aware of the problem. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Chicken MPI
On Sat, Mar 8, 2008 at 9:02 AM, Ivan Raikov [EMAIL PROTECTED] wrote: Well, the mailbox protocol is rather limited; I think you are much better off learning at least some of the group communication semantics of MPI, because they make a lot of sense to a practitioner of functional programming languages. [snip] Thank you for the excellent writeup, Ivan! I'll play with some basic examples, and might bug you for help later. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] google summer of code
On Thu, Mar 6, 2008 at 6:27 AM, Alaric Snell-Pym [EMAIL PROTECTED] wrote: I wrote an efficient shared-memory lock-free queue system for a client once. They own the copyright, but I would happily mentor a student to build a somewhat more general and portable (this was specific to a few platforms) version of it in C and wrap it in chicken for lightweight interprocess goodness :-) On reflection, I'd much rather see a really efficient IPC system like this, rather than having a native-threaded Chicken. The overhead of a trivial Chicken process is quite small, and multiple communicating processes is much safer than a shared-everything threaded design. Having a shared-memory version of remote-mailbox would be very useful: if mailbox, remote-mailbox and sm-mailbox could share an API, we would have a very powerful IPC abstraction. Other than for concurrent designs, I think there is a case for native threads when I/O is involved. I believe that GHC Haskell uses a separate native thread for handling I/O, but (unless you use forkIO) runs everything else in lightweight threads. Perhaps we could play a similar game, and spawn native threads as I/O custodians, managed under a very strict protocol that avoids GC contention and other concurrency issues. Perhaps one I/O thread and select/epoll is enough. I'm also keen on a proper library/module system, though. I'd like to be able to use multiple macro systems in the same source file, for a start. As long as I don't have to give up lowlevel macros, I'm happy. :-) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macrolet
On Fri, Mar 7, 2008 at 1:11 PM, Lui Fungsin [EMAIL PROTECTED] wrote: Hi, Is there a macrolet (CL style old school lexically scoped macro) for chicken? No macrolet, but you can use CL-style macros in Chicken. They just have to be defined at the toplevel, not in a macrolet. You can do variable capture as usual in CL. (define-macro (foo n) `(+ ,n local-name)) (let ((local-name 100)) (print (foo 25))) should print 125. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macrolet
On Fri, Mar 7, 2008 at 3:56 PM, Lui Fungsin [EMAIL PROTECTED] wrote: Hi Graham, Thanks for the reply. But it wouldn't do it for me because I'm trying to capture a binding at macro expansion time, not run runtime. Use case : (to support CL like (return-from) clause with call/cc) (define-macro (defun name args . body) (with-gensyms (return) `(define ,name (lambda ,args (call/cc (lambda (,return) (macrolet ((return-from (proc value) ;; ignore proc name (,return value))) ,@body))) I've only looked at this for a second, but couldn't you just use (lambda (return-from) ...) instead of (lambda (,return) ...)? If you're nesting these environments, I could see that would be problem -- naming the return-from context would be important -- but in a single defun with a single call/cc, it's not such an issue. I know it doesn't answer your question, it's just my two-cents observation while I'm packing up to go home. :-) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] google summer of code
On Fri, Mar 7, 2008 at 6:48 PM, Ivan Raikov [EMAIL PROTECTED] wrote: Graham Fawcett [EMAIL PROTECTED] writes: On reflection, I'd much rather see a really efficient IPC system like this, rather than having a native-threaded Chicken. Try the MPI egg! (Yet another shameless plug, I know). Not a shameless plug, IMO -- I had never really looked at MPI. Thanks! For newbies like me, I'd love to see an MPI-for-dummies egg that overlayed it with a simpler, familiar protocol (like mailbox). Other than for concurrent designs, I think there is a case for native threads when I/O is involved. I believe that GHC Haskell uses a separate native thread for handling I/O, but (unless you use forkIO) runs everything else in lightweight threads. Perhaps we could play a similar game, and spawn native threads as I/O custodians, managed under a very strict protocol that avoids GC contention and other concurrency issues. Perhaps one I/O thread and select/epoll is enough. No, forkIO is normally for lightweight threads. forkOS explicitly associates Haskell threads with native threads. See here for details: D'oh, you're right, I got them backwards. Concurrent Haskell is based on monadic processes: if you want to have Haskell-like threads, first you need to provide support for monads in the core of Chicken. Well, my idea was slightly less grandiose. :-) I imagine that native threads might be useable within a Chicken process, as long as code running in those threads followed *very* restrictive guidelines. Most notably they would not share data with the main (Chicken) thread except through a proper message-passing interface. That would mean that the native threads would *never* have access to any value in Chicken's heap and stack -- data could only be copied across a synchronized boundary. In this way, a native thread could perform blocking I/O in isolation, passing 'packets' across the MPI boundary to the Chicken process. It's just a sketchy idea, Ivan, and not worth anyone's time unless it would simplify certain blocking I/O and native-library scenarios. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] web-scheme hart
On 05 Mar 2008 23:29:19 -0300, Mario Domenech Goulart [EMAIL PROTECTED] wrote: On Wed, 5 Mar 2008 17:45:42 -0800 Robin Lee Powell [EMAIL PROTECTED] wrote: It seems to me that web-scheme and hart do more-or-less the same thing. 2. What's the difference between web-scheme and hart? Do people have preferences between the two? I don't know much about hart. I think Graham can write about it. Briefly, Hart is a syntax extension that tries to turn as much of your html expression into simple print statements at macro-expansion time. The base-case, where nothing in your expression requires variable-substitution, turns into a single print statement: #;2 ,x (hart (h1 (@ (id main)) hello)) (noop (begin (hart-print h1 id=\main\hello/h1))) Adding variables makes it a bit more verbose at expansion time. #;2 ,x (hart (h1 (@ (id my-h1-id)) (t: my-h1-text))) (noop (begin (hart-print h1) (let ((g3 my-h1-id)) (when g3 (hart-print id=\ (hart-html-escape g3) \))) (hart-print ) (apply hart-print (map hart-html-escape (list my-h1-text))) (hart-print /h1))) My goal was to develop a nice syntax, but also to reduce runtime overhead as much as possible. I've never properly benchmarked it against other options (I haven't used Mario's egg; I used to use the shtml-html option in the htmlprag egg). Also, I haven't really tried to optimize it, beyond compiling with an -On flag, and using a fast-if-primitive html-escape routine. I guess I found that it was efficient enough for my needs. One thing I'd like to add is better support for HTML entities, probably following SXML syntax: (hart (p Come back to the five ( amp) dime, Jimmy Dean...)) right now you need to use a (raw: ...) or (scheme: ...) block to do that: (hart (p (raw: Come back to the five amp; dime, Jimmy Dean...))) (hart (p Come back to the five (raw: amp;) dime, Jimmy Dean...)) (hart (p Come back to the five (scheme: (print amp;)) dime, Jimmy Dean...)) Hope this helps. Comments and suggestions are always welcome. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] readline blocks threads
On Tue, Mar 4, 2008 at 5:50 PM, Shawn Rutledge [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 3:47 PM, Elf [EMAIL PROTECTED] wrote: there is a way to do this. its just very painful. im working on a readline-ng egg with the changes, as the existing readline wont work. OK. I hope I'm not causing too much pain. Just curious, does the nbstdin egg help at all? I know it helps when I'm running a REPL inside a Web app. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: chicken literary spoofs (was: Re: argument against using '() for null values? ([Chicken-users] DBI))
On Mon, Mar 3, 2008 at 4:00 PM, Shawn Rutledge [EMAIL PROTECTED] wrote: Chicken Literary is all in a panic that the stacks are falling. lol! Fortunately, Chicken Literary and his friends visited the fox, Henry Baker, who reminded them that their stacks are GC'd frequently. All was well again in Chicken Literary Land! But when he added that function-calls never return, Chicken Literary and friends lapsed into an existential stupor. And Henry the Fox ate them. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values
On Fri, Feb 29, 2008 at 4:02 PM, Ozzi Lee [EMAIL PROTECTED] wrote: I don't see that anyone's mentioned the existing sql-null egg yet. Is there anything wrong with it? http://chicken.wiki.br/sql-null I didn't know that existed. Thanks Ozzi. There are just too many damn eggs these days... ;-) I like the egg. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 7:57 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 1:41 PM, Tobia Conforto [EMAIL PROTECTED] wrote: felix winkelmann wrote: Would a db interface include symbols as output? Would it? I honestly don't know. I haven't seen it in practice, and can't think of a deal-breaking use-case. Enum types come to mind, but that could be handled (perhaps less naturally) with strings. Could it? I'm looking at Postgres, and wondering how to come up with a consistent approach for handling user-defined datatypes. There's no right solution, and the best compromise is to let the user register in/out translation functions. An out-function could translate a value in a custom type into anything, including a symbol (unless we *specify* that this should be illegal). Should it? If we are approaching a common dbi, we should decide now. But it feels premature to rule out an entire datatype for lack of a good null type. For representing sql-null, the special immediate-type solution is best because it's unambiguous. If that were ruled out, simply using the symbol 'null -- and forbidding database layers from returning symbols as output-values other than 'null -- would be my second choice, but it's an inferior solution, and I have a feeling I'd regret it later. But please not '(), for the same reason not #f, 0, or an empty string. cheers, felix (who would like to keep the number of immediate types small) I don't want to see a circus of immediate types either, but one more isn't horrible. I thought (void) was perfect for this, but I respect the concerns that have been raised. So, (void) needs a brother who has no semantic baggage. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Fri, Feb 29, 2008 at 10:41 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Thu, Feb 28, 2008 at 4:02 PM, Graham Fawcett [EMAIL PROTECTED] wrote: It would be a smart idea to change the implementation, then, so that the unspecified value could not be tested with (eq?). That would prevent it from being 'misused'. The unspecified value is unspecified. It has both no identity and no efforts are made to make it identity-less. Right, but (eq? (void) (void)) = #t is a property that shouldn't exist for two unspecified values: by definition it gives identity to unspecified. (eq? (void) (void)) = #f is better, raising an exception is better still. To preserve the 'undefined' meaning, any functions that can test #unspecified should really be internal, e.g. in the ##sys# namespace. But as you say, it's unspecified, so this is a divergent discussion. :-) There does seem to be a good case for an immediate value that *can* be tested this way, though. John et. al. wouldn't have used (void) in eggs if there weren't. Record instances aren't really a great answer (though I suggested them myself) since different records of the same type will fail an identity test. Unless you use a single unique instance. That would be problematic in compiled code, would it not? Where is the instance stored? Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Fri, Feb 29, 2008 at 2:57 PM, Tobia Conforto [EMAIL PROTECTED] wrote: So, to recap: Perfect recap! :-) (define-record-type sql-null (sql-null) sql-null?) Not too bad. Any piece of code could create null values with (sql- null), even in different compilation units. People would just have to remember to use (sql-null? x) instead of eq?. The API could state that eq? on two sql-null values is undefined. True. I suspect there will be slightly more overhead here than with using an immediate, perhaps noticeably on large queries. Ideally (sql-null) would be a closure that constantly returned the same instance, while (sql-null?) was just a record predicate, as in your example. I *believe* that if multiple modules include (define-record sql-null ...), that the predicates will work across definitions. E.g. if your module defines a sql-null record, and mine does too, then instances of your type will satisfy my predicate, as long as the type-names match. This is *ugly*, but it would be better than forcing each db egg to dynamically link to some sql-null egg. This is not a terrible answer for the sql API, though perhaps more terrible for other APIs, and I don't think it would be bad to solve both problems at once (the sql-null, and the well-intentioned 'abuse' of (void) in current eggs). A new immediate value IMHO the best option, and it could be useful for other APIs too, but if Felix says no he's probably right. My preference by far, too. Thanks for this summary, Tobia, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: argument against using '() for null values? ([Chicken-users] DBI)
On Wed, Feb 27, 2008 at 10:53 PM, Ozzi [EMAIL PROTECTED] wrote: How is (sql-null?) harder or less intuitive? It's not harder, but not being able to use null? to test for NULL is counterintuitive in my eyes. I know what you're saying. I guess I just like to keep my different types of nulls in different baskets. Count me as on the fence I guess, between null void and sql-null. Sitting on the fence between null and void sounds like a scary place to be. :-) Graham The Tao that can be tested for equality with the Tao is not the true Tao. -- Chuang Tzu (paraphrased) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unfair question: best Lisp for web development?
Hi Daishi, On Thu, Feb 28, 2008 at 1:28 AM, Daishi Kato [EMAIL PROTECTED] wrote: Graham Fawcett wrote: Sure. My first version was an SCGI server, but later I switched to HTTP. I usually host behind Apache, and moving from mod_scgi to mod_proxy was pretty straightforward, and in return it's much easier to test when Apache isn't running. I also like that using HTTP as the only protocol means that you can deploy apps in small-scale, standalone situations (e.g. localhost workstation apps). I'm also curious on this for I'm now running a HTTP server and thinking to change it to an SCGI server (using web-unity). Is the performance technically the same in these cases? SCGI performs very well. It is hard to find performance differences between mod_scgi and mod_proxy performance. (I also used a custom SCGI handler, so I can't speak for or against the current scgi egg.) Also, do mod_scgi and mod_proxy handle long-lived connections (a.k.a. COMET connections) very well? Hm, good question. My guess is that they would both work, but I haven't tried that. SCGI responses are closely based on the CGI model: you print a 'Status: 200 OK' followed by your headers, and then write out the response body. I believe that Apache / lighttpd will just proxy your response stream back to the client. Note that the SCGI protocol uses connections only once: SCGI is not keepalive. But Apache can maintain keepalive connections with your clients and simply use multiple SCGI connections to complete the work. Some testing would be a good idea. You might also want to confirm that your front-end Web server is not configured to time-out on long-running connections. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: postgresql: support for query parameters
On Thu, Feb 28, 2008 at 2:43 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Wed, Feb 27, 2008 at 3:47 AM, Graham Fawcett [EMAIL PROTECTED] wrote: Felix, I believe that Johannes is no longer maintaining the postgresql egg. I would be happy to maintain it if no one objects. Cool, that would be very helpful. I suggest you note that in the postgreql docs and take the opportunity to convert the html into wiki syntax... :-) Great! Yes, I'll do that. If anyone is using the postgresql egg and wants to offer ideas, feature requests, etc., please let me know. Perhaps we could add a 'feature requests' section to the wiki page as well: I'm not sure if the wiki has a page-watching feature, but I'll set up a way to monitor it if we don't. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Thu, Feb 28, 2008 at 2:40 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Wed, Feb 27, 2008 at 10:31 PM, Peter Bex [EMAIL PROTECTED] wrote: On Wed, Feb 27, 2008 at 04:23:37PM -0500, Graham Fawcett wrote: Can you even check for void? Afaik there's no VOID? procedure. You can; just compare with another (void) value: (define void? (cute eq? (void) )) That sounds rather brittle. Afaik void is defined as no value. One possible and plausible implementation of VOID is this: (define (void) (values)) (eq? (values) (values)) is #t, but I'm not sure how safe it is to depend on that. Especially since VOID is some kind of undefined value, nobody says this representation can't change. I don't think you should depend on this implementation detail. Absolutely. Tha values definition of void above is btw not equivalent and would break in many places. I stand corrected. :-) It would be a smart idea to change the implementation, then, so that the unspecified value could not be tested with (eq?). That would prevent it from being 'misused'. There does seem to be a good case for an immediate value that *can* be tested this way, though. John et. al. wouldn't have used (void) in eggs if there weren't. Record instances aren't really a great answer (though I suggested them myself) since different records of the same type will fail an identity test. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Thu, Feb 28, 2008 at 9:54 AM, Peter Bex [EMAIL PROTECTED] wrote: On Thu, Feb 28, 2008 at 09:47:08AM -0500, Graham Fawcett wrote: Yes, input port was what I was thinking. Thanks. The input port would return the body of the LOB and return #!eof when it's consumed. The Chicken blob or string options are redundant, so the revised proposal is to represent a LOB with a thunk that evaluates to an input port. Why the thunk? (why not directly the port?) Laziness: it avoids the overhead of setting up the input port if it's not required. You might want to iterate over a set of (id, name, blob) records and only open the blob if the name meets some criteria that are local to the app (i.e. can't be expressed in a WHERE clause). Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New immediate values (was: DBI)
On Thu, Feb 28, 2008 at 7:31 PM, Tobia Conforto [EMAIL PROTECTED] wrote: Graham Fawcett wrote: There does seem to be a good case for an immediate value that *can* be tested this way, though. John et. al. wouldn't have used (void) in eggs if there weren't. What about providing a utility to create new immediate values, disjoint from anything else? The immediate value space is far from cramped, if I'm not mistaken. Such a new-immediate-value function (which could benefit from a better name) would return a new value every time it's called, using for example an internal counter. One could write: (define sql-null (new-immediate-value)) (define (sql-null? x) (eq? x sql-null)) I think that, to work well, we'd have to define it statically, so that all libraries using (sql-null) would have the same immediate value. E.g. #! static C_word sql_null = ((C_word) ((C_word)(C_SPECIAL_BITS | 0x0040))); # I am not a core hacker, and can't forsee the consequences of doing this, though... Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Wed, Feb 27, 2008 at 4:04 PM, Peter Bex [EMAIL PROTECTED] wrote: I've tended to let null be '(), but that partly comes from liking the look of (null? (alist-ref 'field result)) I'm not entirely comfortable with leaving the value entirely absent simply because the mapping I mention to value lists and vectors becomes more problematic. That said, my usage of value lists and vectors is limited enough that I'm not that tied to it either. Can you even check for void? Afaik there's no VOID? procedure. You can; just compare with another (void) value: (define void? (cute eq? (void) )) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On Wed, Feb 27, 2008 at 4:04 PM, Peter Bex [EMAIL PROTECTED] wrote: On Wed, Feb 27, 2008 at 02:47:14PM -0600, Jeremy Sydik wrote: dbi:query-fold, dbi:query-map, query-for-each. I thought about implementing these, but I haven't been able to think of the use case that makes them necessary in the presence Scheme's fold, map, and for-each, other than as shorthand (which could be define'd in place in a heartbeat for anyone who wants it) No. If you want to look at a result set that consists of several hundred binary blobs of megabytes each, you most certainly don't want to implement this as a fetch all into one list operation. You would want to load in one row, handle it, then take the next, etc. At the driver level, LOBs are often handled with a stream-based interface. For an LOB, I'd suggest representing it with a a thunk which, when evaluated, returns an input stream, Chicken blob or a string. That would allow you to inspect the other column values before deciding whether to evaluate the LOB. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: argument against using '() for null values? ([Chicken-users] DBI)
On Wed, Feb 27, 2008 at 6:33 PM, Jeremy Sydik [EMAIL PROTECTED] wrote: Thinking more about it, I'm leaning MORE toward '() than before. I also like relying on a representation that's standard scheme rather than one that's specifically part of Chicken if we have the choice (and we do) There's nothing particularly non-standard about (void). (void) returns a value #undefined, whose type is disjoint from all other types, e.g. ((disjoin list? number? string? symbol? boolean?) (void)) constantly returns #f. It ain't nothing but void, and that's an important quality for a value that is supposed to represent the absence of a value. This is also why '() is a bad idea. R5RS doesn't guarantee or forbid the creation of disjoint types, but every practical Scheme depends upon it. For example, for a Scheme to be able to support SRFI-9, the record-types SRFI, it must be able to define disjoint types. The point is that any Scheme that can define records can define (void), so there's nothing non-standard about it. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: argument against using '() for null values? ([Chicken-users] DBI)
On Wed, Feb 27, 2008 at 8:29 PM, Ozzi [EMAIL PROTECTED] wrote: Three that I can think of: 1) It would make alist representations ugly: (query select foo, NULL as bar, baz from stuff) = ((foo . 1) (bar) (baz . a string)) This doesn't bother me. 2) It is not a disjoint type. (list? '()) = #t. That's bad. 3) As a special case of (2), some databases have array-type columns. An empty list may be a valid column value. All right, there's the big problem. How about keeping '() for sql NULL, and using vectors to represent array-type columns? Vectors are currently used in the Postgres egg to represent date-time values. Not saying it's good, but there it is. (BTW, a dbapi needs consistent date/time support too...) In Common Lisp, NIL is the same as '(), and both mean false. In Scheme we have an explicit #f. For the same reasons we should have an explicit #sql-null. It is important that (sql-null? (sql-null)) is #t, and (sql-null? anything-else) is #f. Since SQL NULL values are common, I really like the simple null? test. It's intuitive. How is (sql-null?) harder or less intuitive? On the other hand, I didn't even know array-type columns existed until tonight. I'd prefer to go with something slightly less intuitive for representing them if it will let us use '() for NULL. ...and perhaps we should use '() for #f as well? ;-) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] What's the current version of eggs?
On Tue, Feb 26, 2008 at 9:29 AM, felix winkelmann [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 3:19 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: No. Look, I didn't change anything. It has grown that way and I know it's fscking broken. Ahh, alright, I guess I was wrong. I thought it used to show the version numbers. Sorry. No problem. It really is like this, and IIRC several people have complained about it already. Hysterical raisins, again, are to be blamed. Those damn raisins are at it again! I'll volunteer to help here. For tagged eggs, the version number is the name of the most recently-added tag (correct)? For untagged eggs, the setup file will include a version number; if it does not, we can assume a version of 0.0.0. I'll keep a local, updated copy of the release/3 repository, analyze the eggs for their version numbers, and put a CGI script somewhere that will return a sexpr of the eggs and their version numbers. We can add release/X support later if this works for release/3. Would this help? Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] What's the current version of eggs?
On Tue, Feb 26, 2008 at 10:18 AM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: For tagged eggs, the version number is the name of the most recently-added tag (correct)? No. The version number is the greatest string sorting them as a human would compare version numbers... [snip] Ah, okay. Now that I think about it, perhaps this can be optimized using the orders egg! ;-) Oh, that reminds me, there's this procedure I'm thinking of adding to the orders egg... Naw, just kidding. Thanks! :-) Just to be clear, is that thanks, yes please set up the CGI or thanks, I've just realized how do it myself? :-) G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: postgresql: support for query parameters
On Tue, Feb 26, 2008 at 9:47 PM, Graham Fawcett [EMAIL PROTECTED] wrote: Hi folks, I've just checked in a patch to the trunk of the release/3/postgresql egg, providing support for query parameters. If anyone else is using this egg, I'd appreciate your checking out this version and testing it. Minor correction: the postgresql egg does not have a trunk/tags layout. I have not modified the version number in the .setup file, so I believe this will not trigger a new egg release. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
On Sun, Feb 24, 2008 at 1:16 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: If redundancy were a reason for deleting egg functionality, we have about seven object systems to get rid of. ;-) Ah, but if you pick any two of those, they will have their differences! In this case, however, *absolutely* all usages of the new code are supported by the old one and it is *impossible* for a user to find any difference between them (other than the fact that orders' function is called cmp-key and the combinator's make-/key) no matter how hard they try. No worries, I was just joking. :-) I agree, the redundancy is pointless. It's pointless, I say. I'd like to add a (sort/decorated lst cmp key) proc to your orders egg, that calculates the key values only once; this can be more efficient than (sort ... (cmp-key ...)) for cases where key generation is expensive. I think it fits in your egg; are you OK with that? (The name 'decorated' is an allusion to the 'decorate-sort-undecorate' idiom in Python, which this replicates; we can rename to something more clear.) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
On Sun, Feb 24, 2008 at 1:55 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: I'd like to add a (sort/decorated lst cmp key) proc to your orders egg, that calculates the key values only once; this can be more efficient than (sort ... (cmp-key ...)) for cases where key generation is expensive. I think it fits in your egg; are you OK with that? You are still joking here, right? (See the sort-key-cache function in said egg.) ;-) D'oh, no I wasn't joking that time, I just hadn't read the whole egg properly. Funny. :-) Alejo, feeling very redundant with Graham today. :-) Heh. I am fighting a cold today; I didn't think it was impairing my judgment, but I think I was wrong... Best wishes, Graham http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken For Ruby Programmers
On Sat, Feb 23, 2008 at 4:52 PM, Peter Bex [EMAIL PROTECTED] wrote: Today during the hackathon I've created an initial document at http://chicken.wiki.br/chicken-for-ruby-programmers I'm not a Ruby user, but this looks pretty good. I just committed an edit (r8734) to your discussion of tail-call optimization. I hope you don't mind; feel free to revert the edit if you don't like it. :-) Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On Thu, Feb 21, 2008 at 1:55 PM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote: Given the following SQL table: CREATE TABLE symbols ( symbol varchar, file varchar, line integer ); could someone create a function that receives (1) a base path containing a checkout of the chicken-eggs svn repository, (2) a path to some file inside the repository and (3) a sqlite3 database with said table and, if the file is a Scheme file outside of the wiki, adds one entry to the table for each symbol defined? Is that possible, given that reading the Scheme file may require custom syntax? As a subcase, if a record type is defined, do you list all the record getter and setter procs (e.g. post-macro-expansion) or just the define-record (pre-expansion)? At least define-record is standard syntax; if an egg uses custom syntax, it may be impossible to tell whether there are any definitions at all; or worse, it may contain numerous internal definitions that should not be exposed in an index. Just a thought, G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two procedures looking for a good home
On Thu, Feb 21, 2008 at 3:26 PM, Kon Lovett [EMAIL PROTECTED] wrote: I find that I use these two procedures frequently, and I'd love to see them in an egg so I don't need to keep including them locally. Perhaps is someone interested in working on a shared misc-combinators egg, to store handy little things like this? Done. See release/3/combinators. Ignore the License stuff, much of this is automatically generated boiler-plate. Damn, Kon, you are fast! This is the clinching evidence supporting my theory that you are actually a bot. Thanks, konbot, G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On Thu, Feb 21, 2008 at 3:09 PM, Kon Lovett [EMAIL PROTECTED] wrote: Some day, we might want to offer an alternate way of marking which procs should be indexed, or providing a formal exports list, like the (declare ) form but for interpreted files as well. That would cover the cases where automated indexing is intractable. But yes, 50% is a good target for a first attempt. It should get 100% of the global symbols. What I can't do reliably is get the define syntax forms. The expanded syntax that defines global symbols though is caught. Might it not turn up global symbols that weren't intended for public visibility, though? Perhaps well-designed eggs shouldn't do that, but it could happen in the wild. (/me jumps to the egg repo to see how well-designed his eggs are...) Perhaps this isn't a problem, if the use-case is to provide a search facility. But I think that preparing a good index might take more care (as good indexes always do). Graham 'Flattering to the author, insulting to the reader, she said. In a hyphenated word, she said with the shrewd amiability of an expert, self-indulgent. I'm always embarrassed when I see an index an author has made of his own work. It's a revealing thing... a shameless exhibition' -- Claire Minton, in Vonnegut's 'Cat's Cradle', on why one should never index one's own book. ;-) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new egg, Stacktor
On Feb 19, 2008 9:21 AM, Graham Fawcett [EMAIL PROTECTED] wrote: What I was trying to work out, personally, was a nice way of transforming a postfix, fixed-arity language into decent lexically-scoped expressions, e.g.: 20 dup print + 30 * might translate into (lambda (b) (let ((a 20)) (print a) (* 30 (+ 10 b Oops, I meant (lambda (b) (let ((a 20)) (print a) (* 30 (+ a b You can tell I don't have a Quacktor REPL open right now.. ;-) G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new egg, Stacktor
Neat! Mark, you may not believe this, but a few months ago I started writing a stack-based language in Chicken, and the first name I chose for it was 'Quacktor'. Great minds think alike, and fools seldom differ... Also, John Cowan has worked on a Joy egg, if I'm not mistaken; you might find that interesting. What I was trying to work out, personally, was a nice way of transforming a postfix, fixed-arity language into decent lexically-scoped expressions, e.g.: 20 dup print + 30 * might translate into (lambda (b) (let ((a 20)) (print a) (* 30 (+ 10 b ...so that I did not have to maintain an explicit stack, and could get Chicken to compile it to something efficient. It worked out pretty well, IIRC, though my examples were pretty short. I also had a nice SCHEME: form, so you could do stuff like REQUIRE: http-client SCHEME: http-get ( url -- body ) (http:GET url) ; : main http://callcc.org/; dup print http-get print ; If you're interested, I'll dig up my notes. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: YADT: yet another documentation thread
On Feb 18, 2008 1:45 PM, Peter Bex [EMAIL PROTECTED] wrote: On Sat, Feb 16, 2008 at 05:03:47PM -0500, Graham Fawcett wrote: The CL community has a My Road to Lisp meme, where CL users write up a quick story on how they arrived. I'd *love* to hear people's My Road to Chicken stories. A little painful to admit, but I started out with BASIC on the C64, There's nothing embarrassing about that! Unless you mean that it's a sign of your advanced age! ;-) I started with BASIC on a Commodore PET when I was about 14. The first computer I owned was a Commodore 64 -- I detasseled corn for a summer to earn the cash. It was a *wonderful* machine, and I learned a lot of languages on it: BASIC, COMAL, Forth, Logo and 6502 assembler. Forth and Logo were revelations. Whatever strange things they did to my brain have never really been undone. I remembered the 'head' and 'tail' concepts from my adolescent Logo experiences; when I saw them much later in Lisp and Scheme, I had a very strange feeling of deja vu. The 6502 was the only CPU I ever really programmed assembly for. I had read about cellular automata (probably Conway's Game of Life, and probably in a Martin Gardner book) and managed to get a CA engine written in assembly that was fast enough to run a game at a decent speed. It even had an opcode system for describing the rules of the CA games. Not bad for a naive, pre-Internet teenager! I wish I still had that code, but the audio-cassette tape it was stored on has long since vanished. Thanks for the trip down memory lane, Peter. ;-) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] My language trajectory
On Feb 16, 2008 9:05 PM, Kon Lovett [EMAIL PROTECTED] wrote: @ University: (Algol W Snobol 4 360 BAL Fortran 4 - course work, not too serious) [snip] No Work: Python (minor, just to learn) Io (minor, just to learn) Chicken Scheme C Strange road it has been, Kon Impressive trajectory! From Algol to Chicken in a few short hops... Thanks for sharing this. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] domain query
On Feb 16, 2008 3:53 PM, Toby Butzon [EMAIL PROTECTED] wrote: +1 chickenscheme.org for me too. +1 from me too. I like cleverness of call-with-current-continuation.org. But it seems as if Chicken is growing up, and a boring-but-descriptive domain name is a good idea to welcome and retain new visitors. Perhaps we should also add a more inviting home-page. Maybe some photos of managers and developers smiling at a table, shaking hands. With everyone wearing nice suits. (OK, maybe not suits. Or managers. Shaking hands may also be overkill.) BTW, how are we paying for this suff? It's nice to have a volunteer to pick up the tab, but many of us probably would be happy to support the effort. Felix and Toby have done us all a great service (also the Galinha folks, but I assume there are public funds supporting the wiki site?), we should nurture a little fund to cover some of their costs. For a .org, I might be able to get some hosting at our university. If anyone's interested, I'll ask and find out. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: YADT: yet another documentation thread
On Feb 16, 2008 8:11 AM, Hans Nowak [EMAIL PROTECTED] wrote: Mark Fredrickson wrote: I suggest we draft Hans (http://4.flowsnake.org/) for the Python doc. :-) I was actually going to write such a document last year... the Python programmer's guide to Chicken, or something. As it turns out, I am much better at pointless blathering than at writing solid documentation. :-/ So for now, my Python vs Scheme posts will have to fill that void. Just curious, how many of us on the list are (or were) Python users? I still write and support a lot of Python code, and there was a time when I thought of myself as a Pythonista. :-) For the record, my language trajectory (where I've actually written serious code) is C, Java, Python, Lisp, Scheme. The CL community has a My Road to Lisp meme, where CL users write up a quick story on how they arrived. I'd *love* to hear people's My Road to Chicken stories. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] new egg etiquette
Hi folks, I just started a new egg in the svn repo. It's nothing worth looking at yet, I just want to make sure I didn't do something stupid that would break anything. Here's what I did: cd release/3/ svn mkdir locality svn mkdir locality/trunk cp files locality/trunk svn commit locality This won't release an egg, or mess with any of the server-side tasks, will it? Apologies in advance if it does; I'll ask before I act next time... Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
On Thu, Feb 14, 2008 at 6:07 PM, Daishi Kato [EMAIL PROTECTED] wrote: Is it true that if you have svn write access, you can just edit the wiki/* files and commit them, which reflects to the web pages? My understanding is that this is a nice feature of svnwiki. Yes, you're correct on this. And yes, it is a great feature. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] proposed change to http-client
On Feb 13, 2008 10:41 AM, Elf [EMAIL PROTECTED] wrote: It would be nice if the handling of Connection: close is consistent with http:POST and http:GET. how is it inconsistent? http posts should close connect afterwards, its not a continuable operation, from my understandings. That's incorrect. Persistent connections are the default in HTTP/1.1, and POSTs are not excepted. Unless connection closure is explicitly negotiated, a HTTP/1.1 server may assume that the connection will continue to be used after a POST (or any other operation). See RFC 2616, section 8.1 for the whole story. For HTTP 1.0, *all* connections are closed after a single transaction, altough the Keep-Alive header may be used to request a persistent connection. The 1.1 spec warns that this approach has its problems. See RFC 2608 and 2616. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] proposed change to http-client
On Feb 13, 2008 12:17 PM, Elf [EMAIL PROTECTED] wrote: Right. It takes a lot more work to write a correct HTTP 1.1 client; there are many new issues that are considered MUSTs in RFC-speak: 307 redirects, transfer encoding, etc. hm, this is offtopic of course, but methinks it would be easier to do many of the requirements in scheme than in other languages transfer encodings are just procedure dispatch + composition, for exmaple. I agree, if we were writing a comprehensive library from scratch. If that's the case (e.g. if libcurl license or API sucks, or if it isn't supported on some key platform), then sure, I'd write my 1.1 library in Scheme too. Don't misunderstand, I think there's a perfect case for a quick and dirty HTTP client, as an 80% solution. I just wouldn't reinvent the tricky 20% when a 99% solution already exists. i have to be honest, though, i have no clue what a 307 is, ive never encountered one and dont remember it from the rfcs at all (and it should be abundantly clear from earlier conversation today that my memory of them is flaky at best). When you've forgotten more than you remember, you know you have arrived. ;-) The take-home point, I think, is that implementing a protocol client properly can be a lot of work, and it's wise to let someone else sweat and enjoy their API. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] proposed change to http-client
On Feb 13, 2008 12:45 PM, Elf [EMAIL PROTECTED] wrote: aye, i wasnt trying to say or imply that we should be concerned with a full-fledged 1.1 client, i just wanted to know if there are problems with the changes i made this morning :) Nope, personally I don't mind the change. G (Where the heck is my ice cream?) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
On Feb 13, 2008 8:46 PM, Leonardo Valeri Manera [EMAIL PROTECTED] wrote: We don't have license limitations on gentoo, but I still have to specify what license each package is under... since we're on the subject, exactly what version of the LGPL are 'awk' and 'make' under? They are under the GPL, not the LGPL. The versions on my machine are under GPL Version 2, but newer versions may be under Version 3. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
On Feb 13, 2008 9:01 PM, Elf [EMAIL PROTECTED] wrote: On Wed, 13 Feb 2008, Graham Fawcett wrote: On Feb 13, 2008 8:46 PM, Leonardo Valeri Manera [EMAIL PROTECTED] wrote: We don't have license limitations on gentoo, but I still have to specify what license each package is under... since we're on the subject, exactly what version of the LGPL are 'awk' and 'make' under? They are under the GPL, not the LGPL. The versions on my machine are under GPL Version 2, but newer versions may be under Version 3.' erm, graham, the eggs unlimited page says lgpl for both and plt itself is lgpl (or was) Hah! I thought Leonardo meant the GNU tools, 'awk' and 'make'! Thanks, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] on the note of documentation...
On Feb 12, 2008 2:12 PM, Elf [EMAIL PROTECTED] wrote: and given that there will be an influx of people working on lots of stuff... what do people think about setting some style/indent rules/suggestions for code? For me, it's Emacs' (indent-sexp), with scheme-mode's adjustments for Scheme code. You could probably suggest a max-line-length, but beyond use conventional Scheme indentation I'm not sure what else you could do. Does anyone have a reference to a Scheme style guide? I know I've seen one, but I can't think where. This lazy Emacs user is spoiled by built-in functionality. On the naming of things, it would be very hard at this point in the game to enforce a prefix: naming convention across all egg procedures (as in http:GET, contrasted with the gazillion 'format' definitions). It would be helpful, iff there were also syntactic support for not requiring the prefixes when a module is imported, as mzscheme and Common Lisp do. I've worked on a module system that addresses that, as I'm sure many others have, but we have no comprehensive solution. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
On 12 Feb 2008 15:54:32 -0200, Mario Domenech Goulart [EMAIL PROTECTED] wrote: Hi Tobia, On Tue, 12 Feb 2008 18:37:36 +0100 Tobia Conforto [EMAIL PROTECTED] wrote: Mario Domenech Goulart wrote: Would it be integrated to the wiki system? How much and what kind of integration do we need? It would be nice if a regular user could edit the documentation like he/she would do with the current wiki system. In our audience, a regular user might not be averse to editing a sexpr. I really like the wiki philosophy, but I confess I'd much rather do semantic markup with sexprs than somewhat arbitrary wiki tags. I have good tools for navigating sexprs. ;-) Most developers are already working in the svn repo. I would be more inclined to edit my egg's wiki page in the repo, rather than through the Web interface. Given that, the wiki really becomes more of a place for comments and typographic corrections, which might be better suited to a formal comments section at the bottom of the egg's documentation page. Personally, I've never modified the documentation of someone else's egg; perhaps if I saw a typo, but even then I would contact the author, in case they kept the documentation in a secondary form. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
On Feb 12, 2008 1:28 PM, Mark Fredrickson [EMAIL PROTECTED] wrote: Perhaps before we decide where data should live, what format, etc, we should come up with a list of requirements that we want to meet? Here's my attempt at cataloging what I've heard so far: 4. Users should be able to update data via wiki system [2] I have the utmost respect for the wiki developers and maintainers. But having said that, I don't think we should include it as a formal requirement. If it fits, great; if it doesn't, let's find something that solves the problem. Your other points look solid, Mark. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hackathon!
It turns out that (doc-from-wiki #t) is also a valid form, so there are a few false matches in my list. I leave the grep fix as an exercise for the reader; I'm going to get caffeinated now. G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hackathon!
On Feb 12, 2008 9:43 AM, Graham Fawcett [EMAIL PROTECTED] wrote: Looking at the trunk for each egg, that gives us the following eggs which do not have Wiki docs. Not all of these eggs have actually been published though. Argh, ignore that last script. I really need coffee. $ find . -name *.meta | xargs grep -L (doc-from-wiki) | sed -n s|./\(.*\)/trunk.*|\1|p | sort | xargs echo alexpander apr array-lib atlas-lapack blas bloom-filter cgi-util curl digraph dyn-vector endian-port etxtproc extended-cond format-graph format-textdiff gdb glfw graph-bfs graph-cycles graph-dfs graph-scc grobner-basis gtk2 gtk2-glade gtk2-gobject hashes html-plots input-parse interp1d irnc-base iup lalr libsvm lookup-table mat5-lib matrix-utils mayo mime misc-extn mpd-client mpi mysql nordsieck-vector npdiff ode ode-lmm orders patch plist-utils predicate-calculus probdist pyffi random-mtzig random-swb random-test rb-tree s11n sendfile sfht sigma slang sql sqlite3 sqlite3-tinyclos srfi-27 srfi-38 srfi-4-utils SSAX-Project stream-flash stream-flash-tree-map stream-flash-tree-map/stream-flash-tree-map stream-htpasswd stream-httplog svn-post-commit-hooks tinyclos treap unitconv uri xml-rpc Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hackathon!
On Feb 12, 2008 3:19 AM, Peter Bex [EMAIL PROTECTED] wrote: On Mon, Feb 11, 2008 at 08:50:02PM -0500, Raymond Medeiros wrote: is it possible to get a list of all eggs which do not currently have their documentation in the wiki? then we could start migrating the doc to the wiki. Yeah, it's easy. Just look through the Eggs Unlimited page and see what links point to call/cc.org Or, when you have subversion checkout, see what eggs DON'T have (doc-from-wiki) in their .meta file. Looking at the trunk for each egg, that gives us the following eggs which do not have Wiki docs. Not all of these eggs have actually been published though. Graham ~/chicken-eggs/release/3$ find . -name *.meta | xargs grep -lv (doc-from-wiki) | sed -n s|./\(.*\)/trunk.*|\1|p | sort 9p alexpander apr array-lib atlas-lapack blas bloom-filter cgi-util content-type contexts curl daemon-tools date-literals defun-cond dict digraph dyn-vector endian-port estraier etxtproc extended-cond format-graph format-modular format-textdiff fp fspath gdb geoip gettext glc glfw graph-bfs graph-cycles graph-dfs graph-scc grobner-basis gsl-srfi-27 gtk2 gtk2-glade gtk2-gobject hart hashes html-plots html-stream http http-session iconv input-parse interp1d irnc-base iup kvlists lalr libsvm lookup-table mat5-lib matpak matrix-utils mayo memcached message-digest metaweb mime misc-extn modules mpd-client mpeg3 mpi mysql nest-tool nordsieck-vector npdiff ode ode-lmm orders pairing-heap pairing-heap/branches/unsafe patch php-s11n plist-utils predicate-calculus probdist procedure-decoration pyffi random-mtzig random-swb random-test rb-tree rdf-ntriples regex-extras regex-literals s11n salmonella scheme-dissect sendfile sfht sigma slang slib slib SO31 spiffy sql sqlite3 sqlite3-tinyclos srfi-27 srfi-34 srfi-38 srfi-41 srfi-4-utils SSAX-Project stream-cgi stream-ext stream-flash stream-flash-tree-map stream-flash-tree-map/stream-flash-tree-map stream-htpasswd stream-httplog stream-parser stream-sections stream-wiki svn-client svn-post-commit-hooks tinyclos treap unitconv uri uri-literals uri-namespaces web-scheme web-unity wings xml-rpc ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] egg documentation
Ivan raised a good point on the Hackathon1 page (where he asks that people don't move his egg documentation out of the egg and into the wiki, because it's a pain to deal with eggs that don't have a copy of their docs in the egg directory itself). It's good to have the wiki docs, and especially so with Toby's excellent callcc.org site as a search interface. But it doesn't address local documentation very well. We've done some work on wiki-texi conversion, which is good, but it's not integrated with chicken-setup in any way, and that's a drawback. One can imagine pushing local docs into the wiki upon releasing a new egg version; or adding an include mechanism to the wiki to pull in external docs (though that would make search-indexing harder if not done properly). Since the wiki is stored in the svn repository, there are opportunities for svn-commit hooks to do some of the work, as well as opportunities for a decent inclusion mechanism. Before we venture too far into 'wikifying' all of the egg documentation, if that's a hackathon goal, we should probably ensure that we have a consistent documentation plan that ensures a local copy of the docs is preserved in some form. Personally, I'd love to have texi documentation, and (optionally) have chicken-setup do the necessary work to pull egg docs into the 'info' system. I'd never have to leave Emacs to look something up, and that would (for me) be more efficient than keeping a callcc.org browser open. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] i7on
On Feb 11, 2008 8:26 AM, Alejandro Forero Cuervo [EMAIL PROTECTED] wrote:
I just wanted to show you a simple project I made using Chicken, i7on:
http://i7on.com/
Neat!
I can't help myself...
$ egrep -i ^i.{7}on$ /usr/share/dict/words | xargs echo
imposition impression incubation indecision indication inhibition
initiation injunction innovation inspection insulation intimation
intonation intubation invitation invocation irrigation irritation
I hope it stands for 'innovation' and not 'intubation'... ;-)
G
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] passing on of chicken maintainership
On Feb 11, 2008 5:45 AM, felix winkelmann [EMAIL PROTECTED] wrote: Dear chicken users and hackers, I have decided to quit being chief maintainer of this project. Various developments have lead to this step which I don't take lightheartedly. Bravo, Felix, for making a good but difficult choice. Life is more than Chicken. All the best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hackathon!
On Feb 11, 2008 5:37 PM, Peter Bex [EMAIL PROTECTED] wrote: Hello everyone, In light of the recent announcement by Felix and some people's concerns that the project may get into a bit of a slump with a lack of a single Benevolent Dictator, I decided that it would be a good idea to organize a Hackathon. This will be an excellent opportunity for the community to get involved and pick up on anything that we've all come to take for granted Felix (and other core committers) would take care of. Peter, this is a great idea. I'm not certain I can participate on that weekend, but I'll watch the Hackathon1 page, and try to jump in if I can. Long live the Chicken, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] egg update: hart 1.1.2
Hi folks, I've just committed a new release (1.1.2) of the 'hart' HTML-generation egg on the release/3 branch. The egg itself should be available the next time the egg-post-commit job runs. This is a bugfix release to correct an error in the evaluation of attribute expressions. For example, in the expression: (hart (a (@ (href (some-proc))) ...)) ...the expression (some-proc) was being evaluated twice. This has now been corrected. The reason for evaluating twice in the first place was to allow for optional attributes: if (some-proc) evaluated to #f, then the 'href' attribute would be omitted from the output. E.g.: (let ((maybe-link (lambda () #f))) (hart-string (a (@ (href (maybe-link))) foo))) = afoo/a (The optional-attribute behaviour was an undocumented feature. Ahem, I'll berate my documentation writer for the omission.) In this new version, you can use the following technique to generate elements with alternating attributes, e.g.: (define (make-toggler a b) (let ((curr #f)) (lambda () (set! curr (not curr)) (if curr a b (hart-string (let: ((tog (make-toggler odd even))) (for: (n '(1 2 3)) (li (@ (class (tog))) (text: n) = li class=\odd\1/lili class=\even\2/lili class=\odd\3/li I'll put these examples into the wiki documentation shortly. This version also includes a much faster html-escaping routine (written in C). (In common usage, it makes less of an performance impact than I thought it would, so it's a bit of a premature optimization.) Enjoy! Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hash-table-ref Error: (apply) bad argument type: #procedure (f_10741)
On Feb 6, 2008 4:42 PM, Andre Kuehne [EMAIL PROTECTED] wrote: CHICKEN Version 3.0.1 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook ] (c)2000-2008 Felix L. Winkelmanncompiled 2008-02-05 on disko (Linux) SVN rev. 8157 #;1 (define x (make-hash-table)) #;2 (hash-table-set! x 1 2) 2 #;3 (hash-table-ref x 1) Error: (apply) bad argument type: #procedure (f_10741) For what it's worth, I had the same problem with the current svn trunk. The 3.0.0 release works, though: http://chicken.wiki.br/dev-snapshots/2008/02/06/chicken-3.0.0.tar.gz G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] critical-section not in Chicken 3?
Hi folks, I'm porting some old code that had a (critical-section) in it, to ensure that a set of instructions was completed atomically with respect to the rest of the program. But it looks like critical-section is no longer supported in Chicken 3. I could move to mutexes, but it will be a bit of a pain. Is there any way to emulate (critical-section) in Chicken 3, or has the runtime changed so that it's no longer possible? Thanks, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] critical-section not in Chicken 3?
On Feb 5, 2008 12:30 PM, Elf [EMAIL PROTECTED] wrote: im pretty sure you need mutexes. its pretty easy though... Are you saying this because you know (critical-section) behaviour is no longer available in the Chicken runtime? Note that (critical-section) is not a mutex-synchronizing form: it suspends timer interrupts until the body is evaluated (i.e. you are guaranteed that no other threads are executing during the evaluation of the body). (define-macro (protect-section ml . body) [snip] I'd recommend using the excellent (synch) egg rather than writing a custom mutex-handler. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] critical-section not in Chicken 3?
On Feb 5, 2008 1:11 PM, Kon Lovett [EMAIL PROTECTED] wrote: Hi Graham, I don't know why Felix deprecated 'critical-section'. I to had a couple of uses for it. ...You might want to ask the reason. Thanks, Kon. Felix, please consider it asked! Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] multiple values in chicken
On Feb 4, 2008 12:13 PM, John Cowan [EMAIL PROTECTED] wrote: felix winkelmann scripsit: This is why I'm proposing a simple extension to lambda-lists: a fixnum in a lambda-list declares that the procedure returns exactly that many values. Sorry, too ugly. :-) What about (declare (arity foo in-arity out-arity) ..)? It's a compiler optimization, after all... Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] can not coerce inexact literal - coerced inexact literal - benchmarks game
On Jan 31, 2008 11:41 AM, Elf [EMAIL PROTECTED] wrote: i've been working on some revised shootout progs for a while, but never bothered submitting. should i? Why not? G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: A few questions
On Jan 31, 2008 8:51 PM, Elf [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2008, John Cowan wrote: Elf scripsit: (define (foo . rest) (if (= 1 (random 1)) (car rest) #f) in this case, 0. this entire expression should have been removed by the compiler and replaced by #f, though. Okay, make it (random 2) then, smartass. sure, min 0, max 1. I may have lost track of the point of this thread, but I think it's still about providing a reflection mechanism in Chicken to describe the arity of a procedure. If not, then please steer me out of the woods and back on to the main road, because I've lost my way in the dark... John's halting-problem analogy is precisely correct. You cannot write an algorithm to determine the arity of an arbitrary Scheme procedure. The (random N) is an intentionally simplistic example, but it clearly proves that in some cases a procedure's arity is dependent upon runtime evaluation: its arity is not statically determinable, period. however, youre forgetting to check that the element exists before car'ing. i may be under a mistaken impression, but when working with rest lists, i thought that one should always check size before trying to grab elements. such restrictions are part of why i say its easy... if one omits this, its a bit harder, but will also crash in other ways from incorrect code. I think you're trying to base a general solution upon a prescription: if only we all did proper bounds checks, we might be able to determine arity. Scheme semantics don't require the bounds check, so how could a sane Scheme reflection mechanism depend upon one? If the whole point of this thread is that some people would like better documentation of procedure signatures then let's build a proper documentation mechanism. Pretending that our language is some language Foo, for some Foo where we can write a proper arity-checking algorithm, is a waste of time. Regards, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] static lib of chicken for windows?
On Jan 30, 2008 8:14 AM, Heinrich Taube [EMAIL PROTECTED] wrote: does anyone have a win32 static lib of chicken 3.0 that they would be willing to email me? I only have limited access to a windows machine that doesnt have mingw or cygwin compilers installed, just the microsoft one. There's a 3.0 release of Chicken for Windows, at http://chicken.wiki.br/releases/ It appears to contain both static and dynamic libraries. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] can not coerce inexact literal - coerced inexact literal - benchmarks game
Hi folks, Here's a revised nbody program (based on the current Shootout version) that actually compiles and runs. (Did the current version *ever* compile in Chicken?) With Kon's compiler flags, it does N=2e7 in 270 seconds on my crusty old laptop. $ ./nbody 1000 -0.169075164 -0.169087605 $ time ./nbody 2000 -0.169075164 -0.169031665 real4m29.065s user4m19.208s sys0m0.328s Isaac, I don't know the shootout rules, but you're welcome to use this if you want it. Graham ;; csc -O3 -no-trace -no-lambda-info -optimize-level 3 -disable-interrupts -block -lambda-lift chicken-nbody.scm -o nbody ;; -- ;; define planetary masses, initial positions velocity (define +pi+ 3.141592653589793) (define +days-per-year+ 365.24) (define +solar-mass+ (* 4 +pi+ +pi+)) (define-record body x y z vx vy vz mass) (define *sun* (make-body 0.0 0.0 0.0 0.0 0.0 0.0 +solar-mass+)) (define *jupiter* (make-body 4.84143144246472090 -1.16032004402742839 -1.03622044471123109e-1 (* 1.66007664274403694e-3 +days-per-year+) (* 7.69901118419740425e-3 +days-per-year+) (* -6.90460016972063023e-5 +days-per-year+) (* 9.54791938424326609e-4 +solar-mass+))) (define *saturn* (make-body 8.34336671824457987 4.12479856412430479 -4.03523417114321381e-1 (* -2.76742510726862411e-3 +days-per-year+) (* 4.99852801234917238e-3 +days-per-year+) (* 2.30417297573763929e-5 +days-per-year+) (* 2.85885980666130812e-4 +solar-mass+))) (define *uranus* (make-body 1.28943695621391310e1 -1.5514016986312e1 -2.23307578892655734e-1 (* 2.96460137564761618e-03 +days-per-year+) (* 2.37847173959480950e-03 +days-per-year+) (* -2.96589568540237556e-05 +days-per-year+) (* 4.36624404335156298e-05 +solar-mass+))) (define *neptune* (make-body 1.53796971148509165e+01 -2.59193146099879641e+01 1.79258772950371181e-01 (* 2.68067772490389322e-03 +days-per-year+) (* 1.62824170038242295e-03 +days-per-year+) (* -9.51592254519715870e-05 +days-per-year+) (* 5.15138902046611451e-05 +solar-mass+))) ;; --- (define (offset-momentum system) (let loop-i ((i system) (px 0.0) (py 0.0) (pz 0.0)) (if (null? i) (begin (body-vx-set! (car system) (/ (- px) +solar-mass+)) (body-vy-set! (car system) (/ (- py) +solar-mass+)) (body-vz-set! (car system) (/ (- pz) +solar-mass+))) (loop-i (cdr i) (+ px (* (body-vx (car i)) (body-mass (car i (+ py (* (body-vy (car i)) (body-mass (car i (+ pz (* (body-vz (car i)) (body-mass (car i ;; --- (define (energy system) (let loop-o ((o system) (e 0.0)) (if (null? o) e (let ([e (+ e (* 0.5 (body-mass (car o)) (+ (* (body-vx (car o)) (body-vx (car o))) (* (body-vy (car o)) (body-vy (car o))) (* (body-vz (car o)) (body-vz (car o))]) (let loop-i ((i (cdr o)) (e e)) (if (null? i) (loop-o (cdr o) e) (let* ((dx (- (body-x (car o)) (body-x (car i (dy (- (body-y (car o)) (body-y (car i (dz (- (body-z (car o)) (body-z (car i (distance (sqrt (+ (* dx dx) (* dy dy) (* dz dz) (let ([e (- e (/ (* (body-mass (car o)) (body-mass (car i))) distance))]) (loop-i (cdr i) e) ;; --- (define (advance system dt) (let loop-o ((o system)) (unless (null? o) (let loop-i ((i (cdr o))) (unless (null? i) (let* ((o1 (car o)) (i1 (car i)) (dx (- (body-x o1) (body-x i1))) (dy (- (body-y o1) (body-y i1))) (dz (- (body-z o1) (body-z i1))) (distance (sqrt (+ (* dx dx) (* dy dy) (* dz dz (mag (/ dt (* distance distance distance))) (dxmag (* dx mag)) (dymag (* dy mag)) (dzmag (* dz mag)) (om (body-mass o1)) (im (body-mass i1))) (body-vx-set! o1 (- (body-vx o1) (* dxmag im))) (body-vy-set! o1 (- (body-vy o1) (* dymag im))) (body-vz-set! o1 (- (body-vz o1) (* dzmag im))) (body-vx-set! i1 (+ (body-vx i1) (* dxmag om))) (body-vy-set! i1 (+ (body-vy i1) (* dymag om))) (body-vz-set! i1 (+ (body-vz i1) (* dzmag om))) (loop-i (cdr i) (loop-o (cdr o (let loop-o ((o system)) (unless (null? o) (let ([o1 (car o)]) (body-x-set! o1 (+ (body-x o1) (* dt (body-vx o1 (body-y-set! o1 (+ (body-y o1) (* dt (body-vy o1 (body-z-set! o1 (+ (body-z o1) (* dt (body-vz o1 (loop-o (cdr o)) ;;
Re: [Chicken-users] can not coerce inexact literal - coerced inexact literal - benchmarks game
On Jan 30, 2008 11:00 PM, Isaac Gouy [EMAIL PROTECTED] wrote: --- Graham Fawcett [EMAIL PROTECTED] wrote: Here's a revised nbody program (based on the current Shootout version) that actually compiles and runs. Thanks. However we only accept source code files attached to a tracker item, see: http://shootout.alioth.debian.org/gp4/faq.php#contribute Sure. I've submitted it there. By the way, folks, the existing program was easy to fix; it had PLT Scheme-isms in it that just needed translating. If you have 10-15 minutes to spare, you could probably fix one of the other broken ones. If I can do it, you certainly could. ;-) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] choosing right timezone for future date
On Jan 28, 2008 5:27 PM, John Cowan [EMAIL PROTECTED] wrote:
Graham Fawcett scripsit:
Here's a demo program that does work: [snip]
However, this doesn't really solve your problem, because it sets
the offset and tzname to the current values, not to the values in
effect at the time.
I think I've got it. It's localtime(3) that sets the tz, so converting
to time_t and back invokes the TZ lookup:
#include string.h
#include stdio.h
#include time.h
void get_tz(int y, int m, int d, int hh, int mm, char *buf) {
struct tm tm;
time_t t;
if (hh == -1) { // if no hour, assume noon.
hh = 12; mm = 0;
}
memset(tm, 0, sizeof(tm)); // just to be safe
tm.tm_year = y - 1900; tm.tm_mon = m; tm.tm_mday = d;
tm.tm_hour = hh; tm.tm_min = mm;
t = mktime(tm);
localtime_r(t, tm); // localtime sets the tz.
strftime(buf, sizeof(buf), %Z, tm);
}
int main() {
char buf[200];
get_tz(2008, 1, 1, 0, 0, buf); // January 1
printf(%s\n, buf);
get_tz(2008, 8, 1, 0, 0, buf); // August 1
printf(%s\n, buf);
}
$ ./a.out
EST
EDT
$ TZ=Europe/London ./a.out
GMT
BST
Thanks John Kon for your help, you set me on the right path.
Graham
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Runtime arity?
On Jan 29, 2008 11:28 AM, Mark Fredrickson [EMAIL PROTECTED] wrote: Is it possible to determine at run time the arity of function? I'm thinking something like (arity (lambda (x y z) (* x y z))) = 3 You can use 'procedure-information': (procedure-information (lambda (x y z) (* x y z))) = (? x y z) where (? x y z) is an s-expression that you can parse. It's of less use when the procedure takes variable arguments, though, and of course it doesn't tell you whether the procedure returns multiple values. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
