[CM] cm,clm and sbcl

[Christophe Rhodes]

On Tue, May 14, 2002 at 04:24:17AM -0700, Bill Schottstaedt wrote:
> > sbcl is derived from cmucl, with a few changes in focus.
> > so, porting from cmucl to sbcl shouldnt be to difficult (famous last words)
> 
> CMN works in sbcl (with a minor change to cmn-init.lisp),
> but CLM doesn't;  I made a few hundred changes for sbcl, but
> finally stopped when I hit (in ffi.lisp):

[ do you mean clm-snd.lisp? I've just got this, and that's where it BUGs
  for me... ]

> debugger invoked on condition of type SB-INT:BUG:
>     full call to SB-KERNEL:%INSTANCE-REF
>   This is probably a bug in SBCL itself. (Alternatively, SBCL might have been
>   corrupted by bad user code, e.g. by an undefined Lisp operation like
>   (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe
>   Lisp code; or there might be a bug in the OS or hardware that SBCL is running
>   on.) If it seems to be a bug in SBCL itself, the maintainers would like to
>   know about it. Bug reports are welcome on the SBCL mailing lists, which you
>   can find at <http://sbcl.sourceforge.net/>.

If my BUG is the same as your BUG, this message arises due to compiling
the following macro definition:

  #-just-lisp
  (defmacro <send-snd> (result &optional fstr &rest args)
    (let ((lst (gethash (second result) vars)))
      (if (or lst (varinfo-refd lst))
          (format *c-file* "  ~A = FALSE;~%" (lc (second result))))
      (format *c-file* "  {char *buf; buf = (char *)calloc(512,sizeof(char));~%   sprintf(buf,~A);~% clm_send_snd(buf); free(buf);}~%"
              (apply #'lisp-to-C-format nil fstr args)))
    nil)
				
And the problem lies in the (or lst (varinfo-refd lst)) -- the second
clause only gets executed if lst is NIL, at which point doing structure
accesses on it isn't going to be great. Admittedly, the compiler giving
up at this point isn't ideal, and is in fact BUG 168 in our
(overflowing) bug file, but changing it to (and lst (varinfo-refd lst))
should make this problem go away.

If you're seeing a different BUG, could you let me know how to reproduce
it, please?

>Other things I noticed; sbcl stumbles on:
> 
> (defconstant a-name "a string")
> 
> claiming that I'm trying to set the value twice. 

This is actually ANSI compliant behaviour, somewhat surprisingly; under
Macro DEFCONSTANT, ANSI specifies that constant values are compared with
EQL for compatibility, and under SBCL (eql "a string" "a string") is not
T in general. Workarounds are either to use defparameter or a symbol
macro instead, or else if you need either compile-time or execute-time
value only to wrap it in a (eval-when (:compile-toplevel) ...) or
(eval-when (:execute) ...) respectively.

> And in ffi.lisp, it complains:
> 
> ;   caught 1 fatal ERROR condition
> compilation aborted because of input error:
>   READ failure in COMPILE-FILE:
>     READER-ERROR at 57154 on #<SB-SYS:FD-STREAM
>                                for "file \"/home/bil/test/clm/ffi.lisp\""
>                                {9346E89}>:
> too many colons in "SB-ALIEN"

This one's odd -- how did it happen? If you can send me instructions for
reproducing it, I'll look into it.

Thanks for the report,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)