Hi!
On Mon, 4 Sep 2006 18:50:12 +0100, Xristos Kalkanis ccalca@essex.ac.uk wrote:
I encountered the following problems with latest TBNL (0.10.1) under sbcl 0.9.16:
; file: /Users/xristos/.sbcl/site/tbnl-0.10.1/easy-handlers.lisp ; in: DEFUN COMPUTE-ARRAY-PARAMETER ; (CL-PPCRE:REGISTER-GROUPS-BIND ; (TBNL::NAME TBNL::INDEX-STRING) ; ("^(.*)\[(\d+)\]$" TBNL::FULL-NAME) ; (WHEN ; (STRING= TBNL::NAME TBNL::PARAMETER-NAME) ; (PARSE-INTEGER TBNL::INDEX-STRING))) ; --> LET MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION WHEN COND IF ; --> PROGN LET* LET IF ; ==> ; NIL ; ; caught WARNING: ; This is not a STRING: ; NIL
This stops compilation and throws me in the debugger where the only option i have in order to continue compilation is to accept the operation as completed. Result: easy-handler test example does not work properly (blank page). This happens under both linux and osx.
Hmm, SBCL's error message is not very helpful, I'm afraid. My /guess/ is that it looks at the macro-expansion of REGISTER-GROUPS-BIND and infers that NAME or INDEX-STRING could in theory be NIL and thus aren't valid arguments for STRING= or PARSE-INTEGER. However, in this particular case it is perfectly clear that his won't happen - the body of the macro will only be executed if there's a match; and if there's a match, then all registers will match as well.
I'd propose that you ask the SBCL experts if my guess is right and if so how one can convince the compiler to be a bit less overzealous.
decoding error on stream #<SB-SYS:FD-STREAM for "file /Users/xristos/.sbcl/site/tbnl-0.10.1/test/test.lisp" {13F903C9}> (:EXTERNAL-FORMAT :UTF-8): the octet sequence (233 34 10) cannot be decoded. [Condition of type SB-INT:STREAM-DECODING-ERROR]
This happens only on osx. #lisp regulars informed me that default locale on osx is utf-8 and since test.lisp contains invalid character according to utf-8, it cant be read properly. Compiles ok on linux with posix locale.
Ah, Pelé... :)
Well, before SBCL came up with Unicode support, it was perfectly fine to use ISO-8859-1 files. Now, everybody has to change their code in order to appease their compiler - sigh. I'll change that in the next release.
TBNL/Kmrcl still hangs approx 50% of the time when serving requests (both linux & osx). The solution is to use (close socket) instead of (sb-bsd-sockets:socket-close socket) in function close-active-socket in latest kmrcl (sockets.lisp line 118). I'd really like to see this fixed.
Then you should probably contact KMRCL's author. I think that's the most likely way to get it changed.
Thanks for the report.
Cheers, Edi.