On Wed, 6 Apr 2005 15:43:52 -0700, Keith Irwin keith.irwin@gmail.com wrote:
en_US.UTF-8
If you currently don't need full Unicode support then maybe (where are the SBCL experts?) it suffices to change this to "en_US.ISO-8859-1" (or whatever it's called) before starting SBCL.
Yeah. Okay.
I changed stuff in rfc2238 and araneida to use unsigned-byte 8 in a few with-open-files and that solves the compilation problem. Serving images is a different story, and I imagine if I use unicode chars in my content I'd get a similar prob.
My current option is to serve the images using apache (an Alias in the config), but I tend to like to have apps that require a minimum of os-level config (until they're big enough to warrant that sort of thing).
I might play with it tomorrow a bit more.
I basically agree with you that it's nice to have everything served by the Lisp image. However, this is almost impossible unless you have bivalent streams. (It is my understanding that SBCL will have them sooner or later because the need is obvious.) Also, note that Apache is pretty good at serving static content.
As far as serving full Unicode content is concerned you'll actually want more than bivalent streams - you want to have (socket) streams that can change their character encoding on the fly. AFAIK only CLISP (not supported by TBNL) and AllegroCL can do that at the moment. But look at the Unicode example in test.lisp for an example on how this can be done in LW with implementation-specific features.
Cheers, Edi.
I basically agree with you that it's nice to have everything served by the Lisp image. However, this is almost impossible unless you have bivalent streams. (It is my understanding that SBCL will have them sooner or later because the need is obvious.) Also, note that Apache is pretty good at serving static content.
Okay, I'll give up on it then. The way I've worked this out before in my own proto http servers was to convert everything to a byte buffer and write it all to the socket stream with element type (unsigned-byte 8) and the web browser seemed to pick it up just fine. Not sure about images as I never got that far. Probably naive, but it seemed to work. My assumption was that whatever was reading what I was writing was also reading the raw socket as bytes, then encoding after the fact.
Looking at modlisp.lisp, this seemed a bit more work than just a couple of well-placed #+sbcls. ;)
But apache works for now.
Thanks for the info.
Keith
As far as serving full Unicode content is concerned you'll actually want more than bivalent streams - you want to have (socket) streams that can change their character encoding on the fly. AFAIK only CLISP (not supported by TBNL) and AllegroCL can do that at the moment. But look at the Unicode example in test.lisp for an example on how this can be done in LW with implementation-specific features.
Cheers, Edi.