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 wrote: > On Sat, Dec 13, 2008 at 12:05 PM, Basile STARYNKEVITCH > wrote: >> >> % csc hartex.scm -o hartex Error: during expansion of (hart ...) - unbound >> variable: hart-parse >> >> Call history: >> >> (begin (hart (html (head (title "People")) (body (h1 (fmt: >> "A list of ~a people" (length people))) (if... >> (hart (html (head (title "People")) (body (h1 (fmt: "A >> list of ~a people" (length people))) (if: (nu.. >> (##sys#list (quote noop) (apply hart-parse forms)) >> (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
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] 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
[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 # ___ 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 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] 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] 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] thread-sleep! using milliseconds->time is broken
On Mon, Apr 7, 2008 at 10:17 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > Graham, > > There is a thread entitled "thread-sleep! for less than a second" from 12 Jan > 2007 which discusses this issue. Basically it was an either/or thing and the > current way won. I just was not aware of the proper usage. I used Daishi's > shorter solution and just made a local procedure in the egg. I'm glad it worked out, Jim. I was just a bit put off by all the arithmetic you had to go through, to effect a simple thread-sleep. I still think I might suggest a microsecond-sleep routine be added to srfi-18 (our srfi-18 already has extensions from the spec, one more couldn't hurt!). Best wishes, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] thread-sleep! using milliseconds->time is broken
On Mon, Apr 7, 2008 at 4:00 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > > On 4/7/08, Graham Fawcett <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 7, 2008 at 1:47 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > > > So I need to do this? > > > > > > (thread-sleep! > > > (milliseconds->time (+ 500 (time->milliseconds (current-time) > > > > Just this: > > (thread-sleep! 0.5) > > That would be the easy solution, yeah. But it can not be accomplished from > within an egg using (declare fixnum-arithmetic) unless you call into another > compilation unit. As far as I know. And I don't want to introduce a > dependency on a single-function egg. Ah, sorry, I misunderstood. Yes, defining (thread-sleep/microseconds!) in a separate unit seems an expedient way around the problem. (Or we could extend our SRFI-18 and add this procedure there -- just my two cents, but that seems like a reasonable extension, given the commonality of compiling with fixnum-arithmetic.) Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] thread-sleep! using milliseconds->time is broken
On Mon, Apr 7, 2008 at 1:47 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > So I need to do this? > > (thread-sleep! > (milliseconds->time (+ 500 (time->milliseconds (current-time) Just this: (thread-sleep! 0.5) 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] macro systems and chicken (long)
On Mon, Apr 7, 2008 at 6:11 AM, felix winkelmann <[EMAIL PROTECTED]> wrote: > I'm currently working on a hygienic version of chicken (explicit-renaming + > syntax-rules) which is a first requirement for a full, macro-aware > module system (which is also being implemented). This will be fully > integrated and compatible with all special features (non-contiguous > local definitions, curried and empty "define" and DSSSL lambda-lists), > provide compiled macros (with support for the runtime-macros > option/declaration) > and proper handling of syntactic environments. This will also obsolete > all external macro expanders and provide a more uniform handling of > extensions that provide syntax. Excellent! > The downside is that define-record and in particular define-macro have to go. define-record has to go? That's scary. I can live without define-macro (now that Alex has shown me how to do low-level macrology without it) but define-record is fundamental, no? 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] 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 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] 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 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
[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=threadring&lang=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 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
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 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 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: [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: 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: Spiffy relies on content-length (was Re: [Chicken-users] Spiffy relies on removed proc.)
On Sun, Mar 16, 2008 at 4:06 PM, Robin Lee Powell
<[EMAIL PROTECTED]> wrote:
> On Sun, Mar 16, 2008 at 03:20:11PM +0100, Peter Bex wrote:
> >
> > Thanks for the error report! I've fixed the bug and added a
> > testcase for it so it will not happen again. I've also pushed a
> > new release which should be available shortly (3.8).
>
> It seems to work now, but this leads to a more general Spiffy
> problem.
>
> Run spiffy with:
>
> (define-http-resource ("/test") "test html, sort of")
>
> and then access /test in any browser. You will find (I hope) that
> the browser hangs until timeout or until you kill Spiffy; I
> certainly do.
>
> Sending a Content-Length header, which define-http-resource doesn't,
> solves the problem.
Well, you've got three options that I can think of:
1) use a Content-Length header,
2) use a Connection: close header to prevent keep-alive,
3) use chunked encoding to send responses of arbitrary length, but
retaining keepalive.
The latter requires a "Transport-Encoding: chunked" header, and an
encoding of your response into chunked format. It's not hard, and a
(define-http-resource/chunked) could be written to handle the encoding
and header for you. See
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 for the
details.
But still, there are at least three options, and none is "correct" as
a default. The lack of a correct default is probably why Spiffy punts
on the issue and leaves it up to you to do the right thing for your
app.
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 8:14 PM, Kon Lovett <[EMAIL PROTECTED]> wrote: > In release/3 is hart 1.3.0 which supports syntax-case. Nicely done, Kon. For those who haven't seen Kon's modification yet, it uses cond-expand to see if syntax-case is installed when hart is loaded: if so, it provides high-level versions of the macros instead of low-level ones. Thanks very much for this. 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] 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] 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 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] (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] Bug report: low-level macros vs. variables in csi
On Thu, Mar 13, 2008 at 12:05 PM, John Cowan <[EMAIL PROTECTED]> wrote: > Proposed course of action: have the interpreter check whether an > identifier is the name of a macro and signal an error rather than using > any existing definition. You mean, upon every expression evaluation, or just when (set! macro-name ...) is evaluated? For symmetry, should it also raise an error if you try to define a macro with the same name as an existing identifier? "First system to claim the name wins"? 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
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
[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 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] 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] 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] 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] 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 "hello"))) 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 "") (apply hart-print (map hart-html-escape (list my-h1-text))) (hart-print ""))) 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 & dime, Jimmy Dean..."))) (hart (p "Come back to the five " (raw: "&") " dime, Jimmy Dean...")) (hart (p "Come back to the five " (scheme: (print "&")) " 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] google summer of code
On Wed, Mar 5, 2008 at 12:34 PM, Peter Bex <[EMAIL PROTECTED]> wrote: > On Thu, Mar 06, 2008 at 02:07:43AM +0900, Alex Shinn wrote: > > > "Felix" == felix winkelmann <[EMAIL PROTECTED]> writes: > > > > Felix> If you'd like to help or suggest something, > > Felix> please provide input in the next days. I will be > > Felix> gone over the weekend, but am back at the start > > Felix> of next week. > > > > Well, the one feature I most want is a proper hygienic > > module system that can support compiled macro modules > > without distributing source code. Ideally one that could > > inter-operate smoothly with Chicken eggs that were not > > compiled to use the module system. I think I could hack > > that out in a summer. > > This is a killer feature, and the top one on my wishlist for sure :) +1 from me too. I like the native-threading idea, but it would take one hell of a SoC candidate to pull that off. Alex's "I think I could hack that out" metric is a good one. 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: argument against using '() for null values? ([Chicken-users] DBI)
On Sun, Mar 2, 2008 at 10:21 PM, Elf <[EMAIL PROTECTED]> wrote: > > heh, thats the longest response ive ever gotten to a random selection from > the tao of programming. cool :) Yes. Beautiful work there, John. Graham Nice, nice, very nice, Nice, nice, very nice, Nice, nice, very nice, So many different hackers in the same device. -- "The Book of Bokonon" for Unix (work in progress ;-) ___ 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 Sun, Mar 2, 2008 at 9:56 PM, Elf <[EMAIL PROTECTED]> wrote: > > out of curiousity, how can sql be returning symbols, ever? enums are > integers, > yes? Hi Elf, My reasoning was that I don't want to needlessly restrict what a database driver returns. In Postgresql's case, for example, the database can define custom datatypes. It may be possible that a custom type is best represented by a symbol. When your db has builtin datatypes for arrays, circles, polygons and MAC addresses, and has an open system for defining anything else, it broadens one's horizons somewhat. :-) In Postgres, Enums are string values in a restricted set. (I gave that as a *possible* case where symbols might make sense, since they are interned strings.) Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Syntax of case expressions
On Sat, Mar 1, 2008 at 7:40 PM, Elf <[EMAIL PROTECTED]> wrote:
>
> id consider it a bug with the reader fighting with the macroexpander for
> unpredictable dominance of the universe.
Just to be clear, elf -- what specifically is the bug that you see
here? Do you really see unpredictability, or just an unexpected
result? What should be the correct behaviour?
FWIW, Gambit's result in this case is identical to Chicken's:
[EMAIL PROTECTED]:~$ gsi
Gambit Version 4.0 beta 20
> (define foo 'quote)
> (case foo ('a 1) (else 2))
1
So is Guile's:
[EMAIL PROTECTED]:~$ guile
guile> (define foo 'quote)
guile> (case foo ('a 1) (else 2))
1
Graham
___
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] How can one get the latest html-dump of the doc?
Hi Adhi, On Fri, Feb 29, 2008 at 8:29 PM, Adhi Hargo <[EMAIL PROTECTED]> wrote: > How can one get the latest html-dump of the doc? There isn't an official one, AFAIK. The wiki content is stored in the svn repo, and you can always get the latest version there, but it's in wiki markup, not HTML. I've set up a quick hack to snapshot the wiki from svn, and generate a tarball. It's available at http://cleo.uwindsor.ca/static/chickendoc.tgz Next week I'll set up a cron job to refresh this nightly; at the moment it is a snapshot of the wiki as of about an hour ago. Warning, there are probably some wiki elements that did not convert properly; I'm using a modified version of a script called wiki2html, described here: http://www.mail-archive.com/chicken-users@nongnu.org/msg07776.html It is not "perfect" but it is pretty good. Please let me know if this helps; if not, I'll probably not bother with the cron job. ;-) 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: [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 # 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 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] 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 Thu, Feb 28, 2008 at 10:30 AM, Peter Bex <[EMAIL PROTECTED]> wrote: > On Thu, Feb 28, 2008 at 10:05:58AM -0500, Graham Fawcett wrote: > > > 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). > > You can make a 'smart' custom port that only really opens the blob when > you first read from it (it has to be a custom port anyway, so this is > not too much extra work). This makes for a more convenient API, IMHO. That's true. I was going to argue that it doesn't have to be a custom port (some interfaces may return a TCP port to consume the blob, for example) and that I'd rather not add an extra layer. But using a custom port would also ensure that the right cleanup code was called, and that's a big win. The custom-port is a good solution. G ___ 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] 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 4:11 AM, Peter Bex <[EMAIL PROTECTED]> wrote: > On Wed, Feb 27, 2008 at 02:27:36PM -0800, Vincent Manis wrote: > > On 2008 Feb 27, at 13:27, Graham Fawcett wrote: > > > 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. > > +1. -- vincent > I assume with "input stream" you mean "input port"? (With "stream", I > think of SRFI-40/41) > > In that case, +1. 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. 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] 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
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: 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 #. 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] Unfair question: best Lisp for web development?
Hi Jim, On Wed, Feb 27, 2008 at 5:01 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > On 2/27/08, Graham Fawcett <[EMAIL PROTECTED]> wrote: > > Personally, I don't use Spiffy; I wrote a custom framework instead. > > Would you mind expanding a little on your custom framework and > whether it resides behind another webserver via mod_proxy, scgi, > fastcgi, cgi, or is itself the main webserver? 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). > Also, do you handle requests with one request per process > or with SRFI-18 threads? SRFI-18 threads, using one thread per connection; so, possibly handling several requests on a keep-alive connection. I find this works really well. I was going to move to a preforking approach eventually, and had once started on a single-threaded, asynchronous design. But in production, I've yet to find a fault with the threaded model, so those projects are on the backburner. One day I'll finish the preforking one though, I have an app in mind that will need that. I'm currently "extracting" the framework from an application I'm working on, and modularizing it. If you're interested, I will share the code. Best, 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 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 #, 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 6:29 PM, Ozzi <[EMAIL PROTECTED]> wrote: > > I suggest that a row be an a-list, and that null columns be represented > > by being non-existent in the a-list. If you end up preferring a plain > > list or a vector, then use (void) instead -- I am trying to get this > > standardized as the Chicken representation of SQL's NULL. > > Is there an argument against using '() instead of (void) SQL NULL values? 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")) 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. Personally, I'm okay with (void), though Vincent's comment about displaying results is a good one. I think the only logical alternative to (void) is a # value, similar in implementation to #: a disjoint type plus a predicate. (Currently that's how the postgresql egg handles it.) 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: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". (void) returns the unspecified value, in Chicken, # -- as does (values). But the unspecified value is a value, and can be tested for identity with eq?. > (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. It's an implementation detail of Chicken, but it is highly unlikely that it will change. Void is nebulous as a concept, but its Chicken implementation is concrete. 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: [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] Unfair question: best Lisp for web development?
Hi Robin, On Wed, Feb 27, 2008 at 12:29 PM, Robin Lee Powell <[EMAIL PROTECTED]> wrote: > > I'm thinking of starting a .com; probably not an especially Web 2.0 > sort of one, but maybe with some Ajax involved. I seem to be more > comfortable with Lisps than anything else. > > Are there any compelling reasons to choose a Lisp other than Chicken > (my current best-known) for that sort of thing? Not that I can think of. :-) Here's my pitch; let me find a soapbox to stand on... I've used Common Lisp to run a few small sites, but I quickly moved over to Chicken for that sort of work. My apps run from plain-vanilla HTML to sexy AJAX stuff, and Chicken has been a great platform for developing across the gamut. PLT Scheme seems to have a good community around its Web app framework. They also have a larger community I think, and some interesting tools. But with respect to the Web framework, I don't think there's anything there that isn't reproducible in Chicken (including the continuation-based logic, see the suspension egg). Their Unicode support might be better; I don't remember. For the Chicken Web apps I maintain, I get about 100,000 hits per day in total, about 50MB bandwidth per day, so it's not dot-com sized; but on the other hand, they are all running on a crappy old Linux box, and the load-average hovers around 0.2, so I have room for growth. Overall I'm very happy with performance. I also appreciate that the Chicken interpreter is quite fast, so most of my app code can stay intrepreted (it's a little easier to manage), but I can compile the hotspots for more efficient code. Web apps don't tend to run too hot, but it's nice to know you can squeeze out more performance when you need it. Chicken is a very Unix-friendly Scheme, and I find my Chicken apps are easy to maintain from a sysadmin perspective. The few Common Lisp apps I had (they were in SBCL, which is beautiful in its way, but weighs 800 pounds) were troublesome to manage as processes, ate huge swaths of memory, and were not particularly efficient. Personally, I don't use Spiffy; I wrote a custom framework instead. But Spiffy seems to be an great tool, and many people here use it, so you'd get good support for your efforts. I'm biased, but I think you might enjoy the Hart HTML-generation library too. Database-wise, we've got good library support, though each db interface is different: there is not a common DB-API as is found in some languages (JDBC, Python dbapi, etc.). So if you're going RDBMS, I'd pick one database and stick with it, or help write a common dbapi framework. Best, Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macroexpand-1 not expanding a macro(?)
On Wed, Feb 27, 2008 at 8:42 AM, Peter Wright <[EMAIL PROTECTED]> wrote: > #;1> (use syntax-case) > ; loading /usr/local/lib/chicken/3/syntax-case.so ... > ; loading /usr/local/lib/chicken/3/syntax-case-chicken-macros.scm ... > #;2> (define-macro (alpha x y) `(beta ,y ,x)) > #;3> (macroexpand '(alpha 1 2)) > (beta (quote 2) (quote 1)) > #;4> (macroexpand-1 '(alpha 1 2)) > (alpha 1 2) > #f > #;5> I suspect that syntax-case is messing with things. You don't need it for lowlevel macros. This is what I get, without syntax-case: CHICKEN Version 3.0.0rc1 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook ] (c)2000-2008 Felix L. Winkelmanncompiled 2008-01-22 on cleo (Linux) ; loading /home/graham/.csirc ... #;1> (define-macro (alpha x y) `(beta ,y ,x)) #;2> (macroexpand '(alpha 1 2)) (beta 2 1) #;3> (macroexpand-1 '(alpha 1 2)) (beta 2 1) #t when I include syntax case, and define a new version of the macro: #;4> (use syntax-case) ; loading /usr/local/lib/chicken/3/syntax-case.so ... ; loading /usr/local/lib/chicken/3/syntax-case-chicken-macros.scm ... ... #;9> (define-macro (al x y) `(be ,y ,x)) #;10> (macroexpand-1 '(al 1 2)) (al 1 2) #f Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] postgresql: support for query parameters
On Wed, Feb 27, 2008 at 12:24 AM, Matthew Welland <[EMAIL PROTECTED]> wrote: > On Tuesday 26 February 2008 07:47:27 pm Graham Fawcett wrote: > > ;; new interface > > (pg:query-tuples > > (list "select foo, bar from baz where foo > $1 and baz < $2" > >foo-low baz-high) > > the-conn) > > I don't know if it is a standard of sorts but all the db api's (perl, ruby, > sqlite3 egg) I have used use a ? for the placeholder. [snip] > It would be nice to be consistent IMHO, perhaps even going to the extent of > a DBI like approach. The dollar-sign syntax is the native Postgres parameter syntax. Oracle uses (:1, :2, ...) and as you've noted, many others use a question mark. If we ever have a common db-api, this conversion should probably be addressed at that level, but I think the Postgres egg should be true to its roots. On the other hand, if you're really interested in that feature, I think the right way to implement it would be as a module-level parameter, e.g. (pg:use-?-for-parameters #t). We could rewrite the queries to replace the question marks with dollar-numbers when the parameter is true. A good compromise? Thanks for offering to test it! 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 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
[Chicken-users] postgresql: support for query parameters
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. In all of the querying procedures, the new interface lets you replace the query-string argument with a list, (query-string . args). Given a list, the new code uses the PQsendQueryParams call, so escaping of parameters is handled automatically. Examples: ;; old interface (still works) (pg:query-tuples "select foo, bar from baz" the-conn) ;; new interface (pg:query-tuples (list "select foo, bar from baz where foo > $1 and baz < $2" foo-low baz-high) the-conn) Felix, I believe that Johannes is no longer maintaining the postgresql egg. I would be happy to maintain it if no one objects. Thanks, 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
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] 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] 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- 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 Thu, Feb 21, 2008 at 4:40 PM, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > I hereby humbly propose the removal of key-on from the combinators egg > on the basis that it is entirely redundant with cmp-key in the orders > egg, except for the fact that the documentation for the orders egg > needs a bit of love and care. If redundancy were a reason for deleting egg functionality, we have about seven object systems to get rid of. ;-) I don't mind, Alejo. I've started documenting the orders egg as an act of good faith. Graham ___ 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] MSVC makefile and patches
On Fri, Feb 22, 2008 at 4:19 AM, Vincent Manis <[EMAIL PROTECTED]> wrote: > Would it be possible to put together a package of GnuWin32 programs so > as to make Chicken building and egg installation reliable on Windows? > I guess that would include make, gzip, tar, maybe cp, rm, mv, and I > don't know what else. That would make it easy for a naive Windows user > to set up and use Chicken. IIRC, this is a good packaging of those tools for win32: http://unxutils.sourceforge.net/ MSYS, though heavier, would include these too. 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
[Chicken-users] two procedures looking for a good home
Hi folks, 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? If such an egg exists and I'm not aware of it, please let me know. Graham (define (group-by keyproc lst #!optional (is-equal equal?)) ;; group a list of elements by some key attribute. ;; the list must be in sorted order with respect to the key. ;; examples: ;; (group-by identity '(1 2 3 3 4 4 4)) --> ((1) (2) (3 3) (4 4 4)) ;; (group-by car '((a 1) (a 2) (b 1))) --> '(((a 1) (a 2)) ((b 1))) (let loop ((lst lst) (acc '())) (if (null? lst) (reverse acc) ;; possibly remove the reversal? (let ((key (keyproc (car lst (receive (grouped rest) (span (lambda (item) (is-equal key (keyproc item))) lst) (loop rest (cons grouped acc))) (define (key-on proc #!optional (comparator <)) ;; Define a comparator function for a sort. E.g. to sort a list of ;; lists by their first items, using string-case-insensitive ;; comparison: (sort lst (key-on first string-cihttp://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On Thu, Feb 21, 2008 at 2:35 PM, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > > Is that possible, given that reading the Scheme file may require > > custom syntax? > > It may not be possible to do it reliably, but if we get just 50% of > the cases right, that's an improvement. I suspect with some lovin' we > should be able to get 90% or so. :-) I agree, love is the answer. ;-) 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. 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 2:22 PM, Kon Lovett <[EMAIL PROTECTED]> wrote: > > 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? > > I would use something similar to the process in the "source-xref" egg > (un-released) to find the defined symbols. It provides a Chicken > compiler 'user-post-analysis-pass'. Mirabile dictu! I didn't know that existed. Best of luck. 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] Topics and a main index (was: egg documentation)
On Feb 19, 2008 2:10 PM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > Your topic idea is interesting. My opinion, for what it's worth, is that it > imposes too much on the user when required for every definition. Instead, if > any topic indexing is to be done in the future, I think the topics could be > drawn from the egg tags themselves. Well, it could be handled in a cascading fashion. A tag on the egg would suffice, but a tag on the procedure could enhance or override it. Take an egg like miscmacros, which itself is hard to classify, but whose procedures could be tagged with 'list-manipulation', 'conditionals', etc. > I think using the egg tags (categories) would be sufficient for any future > index. Any more granular and there is a high barrier to entry. Users would > avoid changing entries for fear of putting something in the wrong category; > old hands would get fatigued at choosing topics for every definition. Perhaps, but it would make a nice hackathon job: if the mechanism is there, someone could zip through an egg's doc and tag a few dozen specialized procedures. I agree that in general an egg-level tag is enough; but there are lots of corner cases. Procedure level tags should be optional, but could be useful. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Snippets wiki (Re: [Chicken-users] My language trajectory)
On Feb 19, 2008 12:57 AM, Matthew Welland <[EMAIL PROTECTED]> wrote: > For us learners the best thing the gurus can do in my opinion is to put a > hierarchy of snippets doing lots of things from simple (even obvious) to > complex on the Wiki. > > I suggest breaking the snippets into four sections: > > beginner > intermediate > advance > refugees >[ section has idioms from other languages and an equivalent in scheme ] That is a great idea. There is the Scheme Cookbook site, but it's heavily weighted toward PLT Scheme. Doing a good job on a cookbook like that can take some effort, but I'm sure it would be a useful resource. How to start? > I'll happily contribute to the beginner and maybe intermediate > sections. BTW, I'd love it if an expert couple put a handful of > examples that illustrate what cut and cute do. I still don't get it > and the frustrating part is I suspect it will be obvious when I do > :) Since we are not set up yet, I can give an example or two here, and anyone can refine it or paste it into the Wiki later on. Cut and cute are useful for writing short, single-argument procedures. For example, to double the values in a list, you could write: (map (lambda (x) (* x 2)) the-list) But you could shorten it using cut: (map (cut * 2 <>) the-list) where <> is the placeholder for the argument. Cute and cut differ in the way they deal with the *other* arguments in the expression. (cut * foo <>) (cute * foo <>) In the cut form, foo gets re-evaluated every time the procedure is called. In the cute form, foo is evaluated once, and the value is reused upon every call. In other words, cute forms a closure, and the value of foo is captured in the closure when the cute form is initially evaluated. In the interpreter, you can macro-expand the two forms to help remind yourself of which does which: #;1> ,x (cut * foo <>) (lambda (g4) ((begin *) foo g4)) #;1> ,x (cute * foo <>) (let ((g6 foo) (g5 *)) (lambda (g7) (g5 g6 g7))) Note the (let ...) around the (lambda ...) in the cute example: a typical pattern of code that creates a closure. One pattern that sometimes crops up with cut (or with lambdas in general) is a nested-map. Say you have a list of lists, and you want to perform some operation on the sublists: #;1> (define the-list '((1 2) (3 4))) #;2> (map (cut map (cut * 2 <>) <>) the-list) ((2 4) (6 8)) See also left-section and right-section, which have a similar purpose. Note that although 'cut' and 'cute' are plays upon the word 'curry' (as in 'curry upon this'), they are not currying forms, but partial-evaluation forms (sometimes called operator sections). Curry takes a binary procedure and returns a unary procedure that itself returns a unary procedure, e.g. (curry +) => (lambda (a) (lambda (b) (+ a b))) 'curry' is not defined in Chicken, though it would be easy to write. Graham ___ 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] 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] 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] 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
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
[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 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
