[tbnl-devel] TBNL/SBCL 0.9.16 problems

[Edi Weitz]

Hi!

On Mon, 4 Sep 2006 18:50:12 +0100, Xristos Kalkanis <ccalca at 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.