[Sbcl-devel] possible keyword bug?

[John K. <jk2...@ya...>]

[platform: OS X 10.3.2,  (lisp-implementation-version) => 0.8.6]

I have what I think is a SBCL bug, but then again, I'm often wrong.

In a file with package simbin, I have the following function:

(defun compute-chisqr-realizations (vel-error-vec n
				    &key (evolve nil) (rgb 30) (l-scale 0.8)
				    (binary-frac 1d0)
				    (m1 1d0))
  (loop for i below n
        collect (compute-one-chisqr-realization vel-error-vec
		 :evolve evolve :rgb rgb :l-scale l-scale
		 :binary-frac binary-frac :m1 m1))) 



Then I try:

=============
(describe #'simbin::compute-chisqr-realizations)
==>
 #<function simbin:compute-chisqr-realizations> is a function.
 Its associated name (as in function-lambda-expression) is
   simbin:compute-chisqr-realizations.
 The function's arguments are:  (vel-error-vec n
                                              &key
                                              (evolve nil)
                                              (rgb 30)
                                              (l-scale 0.8)
                                              (binary-frac 1.0d0)
                                              (m1 1.0d0))
 .....
Its defined argument types are:
   (t t &key (:evolve t) (:rgb t) (:l-scale t) (:binary-frac t) (:m1 t))
======================

But when I call:

(simbin::compute-one-chisqr-realization #(1 1 1) 10 :evolve t)

I get the error:
 debugger invoked on condition of type SB-INT:SIMPLE-PROGRAM-ERROR in 
 thread 4704:   odd number of &KEY arguments

But
 (simbin::compute-chisqr-realizations #(1 1 1) 10 :evolve nil)
or
 (simbin::compute-chisqr-realizations #(1 1 1) 10 :rgb 20)
or
 (simbin::compute-chisqr-realizations #(1 1 1) 10 :m1 10 :rgb 20)
all work fine.

I would like to provide a code snippet that causes this, but I
couldn't create a short file that recreates the problem.  It looks like
the current compilation state has something to do with it.  Placing this
function in a file by itself produces code that works fine.  The bug
survives recompilations and restarts of SBCL, so it isn't some temporary
confused state.   I've checked the latest release notes to
see whether a later version of SBCL would solve this, and I found
no sign that such a bug has been addressed, but sourceforge is down
so I can't rebuild SBCL.



Here's one weird detail: in the debugger frame that shows the
vars in simbin::compute-chisqr-realizations, I can try to list
variables with the 'L' command:

2]l
SIMBIN::VEL-ERROR-VEC  =  #(1 1 1)
#:|binary-frac-DEFAULTING-TEMP|  =  1.0d0
#:|evolve-DEFAULTING-TEMP|  =  T
#:|l-scale-DEFAULTING-TEMP|  =  0.8
#:|m1-DEFAULTING-TEMP|  =  10
#:|rgb-DEFAULTING-TEMP|  =  30

The variable N does not show up, when it should be 10.   In my 
failed attempt to recreate the misbehaving function in another file,
the variable N _did_ show up in the debugger.



As usual, apologies if this is in error.   If this is a real bug, I could
provide more backtraces, or a tarball of code, to try to recreate it.







__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html