[slime-devel] Slime bug in macro handling

[Brian Downing]

On Fri, Apr 29, 2005 at 01:43:04PM -0400, Will M. Farr wrote:
> I have just encountered a bug while using SBCL 0.9.0.1 or OpenMCL 
> 0.14.3 and the latest CVS slime (as of 10 minutes ago) on my PowerBook 
> G4 with Mac OS 10.3.9.  Evaluating the following commands using C-M-x 
> (except for the in-package, which I have to type at the REPL) works 
> fine:
> 
> (defpackage :fast-math
>    (:use :cl))
> 
> (in-package :fast-math)
> 
[....]
> 
> However, if I then type
> 
> (f* 10.d0 30.d0)
> 
> at the REPL, I get an error involving the "undefined function f*".  
> Even after this, if I then evaluate (f* 10.d0 30.d0) using C-M-x it 
> works fine!  I notice that typing (f* ...) in the REPL doesn't bring up 
> the autocomplete information from SLIME, while typing it in a different 
> slime buffer does bring up the note (f* &rest xs).  The problem doesn't 
> occur if the macros are defined in the cl-user package.

It sounds like you've got package problems.

The way this works is that each buffer has a separate package (or
packages), and the REPL has a current package.

Buffer packages are determined automatically by the last IN-PACKAGE form
before point.  You can see the buffer package in the modeline:

--:**  scratch.lisp   All (3,0)        (Lisp Slime:common-lisp-user)---------

The REPL package is shown on the prompt:

CL-USER> 

It sounds like you defined the functions in a different package from
where your REPL is.

You don't have to evaluate IN-PACKAGE forms in buffers at all - they get
automatically picked up.  You can experiment with this by typing a new
one and watching the buffer package change on the modeline on the fly,
and by having more than one and watching it change as you move between
them.

The REPL package is changed by either running "(in-package :foo)", or
by using the change-package REPL command (type ",change-package" or
",!p" at an empty REPL prompt).

In your case, make sure the REPL prompt shows "FAST-MATH> " since that's
where your buffer is designated to go.

If this still doesn't work you can, from the repl, type (apropos "F*"),
which will print all symbols containing F*.  If your macro shows up in
the output it will be fully qualified such that typing the name as it
shows up will get at it.  If you're in the correct package, it should
show up simply as "F*", and if it has a package qualifier it will at
least tell you where it wound up and you can try to figure it out from
there.

-bcd
-- 
*** Brian Downing <bdowning at lavos dot net>