Maciej Katafiasz  <mathrick@gmail.com> wrote:
+---------------
| Rob Warnock:
| > 1. My first coding in CL[1] was for a database-backed web app,
| 
| Did something eat your footnotes, or am I misunderstanding the notation?
+---------------

*Yikes!* Yes, "something" (my absentmindedness) ate my footnotes.
Let me try that portion again:

1. My first coding in CL[1] was for a database-backed web app,
   and I initially used both CLISP & CMUCL, for quite a while,
   but then settled on CMUCL because the compiled code for my
   app was just *so* much faster, and also because the green
   threads in CMUCL[2] were a very good match to my app. All
   the initial development was done on FreeBSD 2.2.6, but was
   later moved to FreeBSD 4.3, 4.6, 4.10, and now 6.2 with no
   problems whatsoever.[3] Furthermore, the porting of the app
   to Linux 2.4.21-40.EL (RH) was nearly as seamless, as was moving
   to Linux 2.6.7 and then 2.6.20, and it's still running on all
   those platforms. [Well, except FBSD 2.2.26 -- that machine died.]
   So I clearly like CMUCL, on x86 platforms at least.
...


-Rob

[1] I had been doing serious coding in Scheme for ~10 years before
    that, including some CGI apps that did HTML generation in Scheme,
    so I hit the ground running with CL. [Yes, Kenny, I still owe
    you all an RTL page...]

[2] CMUCL confusingly calls the package "MULTIPROCESSING", but it's
    really multiprogramming, that is, "green" threads (co-routines)
    within a single Unix/Linux process. But since CMUCL's threads
    are very nicely integrated with its I/O so that by default *all*
    I/O uses "select()", starting a new thread per HTTP request works
    out extremely nicely. Some threads can block [waiting for a slow
    input or output file descriptor to become usable] without blocking
    others for which I/O is ready. The thread doesn't have to do
    anything special to make this work, just use normal CL stream I/O.

[3] A warning for CMUCL users thinking of switching to FreeBSD 7.0:
    Unlike FreeBSD 4.x, 5.x, and 6.x, which will happily run a CMUCL
    that has been compiled on some earlier version of FreeBSD, via
    the appropriate "compatN" libraries, the FreeBSD 7.0 beta changes
    the signal handling [specifically, SIGBUS vs. SIGSEGV] in a way
    that breaks CMUCL's GC. One of the CMUCL developers is currently
    communicating with FreeBSD developers to try to resolve this issue.

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607