Well, I foolishly upgraded slime. So like everyone else, stuff broke
that I have no idea about.
The basic problem is getting SLIME to intern new code in the selected
package. I've executed an in-package form in the slime repl and used
the SLIME menu pulldown to set the package but neither work. In a
source buffer, typing C-x-C-e or C-c-C-c after a defun form seems to
work OK.
But try to run that function hits ye-olde "does not exist" problem,
checking in CL-USER shows the function present there. That seems
rather USELESS. What have the slime devs turned off this time?
The only way to get slime to pay attention is to load a source file
(well at least that used to work too). Lots of files contain source
code and other stuff not suitable for loading, so merrily C-c-C-c'ing
used to be fun.
a sample (untested)
(in-package #:cl-user) (unless (packagep (find-package :pfetcher)) (make-package :pfetcher))
(in-package :pfetcher)
(defun are-we-there-yet?()
(format t "~A~%" "Found it"))
that will show up in CL-USER unless a file is actually loaded. I want
to just be able to load into that package from a source buffer.
CMUCL 19e and SLIME Nov 7 2008
--
When Lisp was 8, it took PEDs. (Timothy Hart)
Gl> The basic problem is getting SLIME to intern new code in the selected
Gl> package.
selected where? there is current package for REPL, and current package
for each buffer, and they are different things. this actually makes
sense, because typically you edit files from different packages, and
switching it all the way would be too much hassle.
SLIME automatically guesses package from the first in-package form in file
(as i understand), and it most cases it works fine. you can see current
package for a buffer in a buffer information, e.g. it says "Lisp
Slime:cl-user".
you can manually set buffer's package via (guess what?) slime-set-package
command.
Gl> Lots of files contain source code and other stuff not suitable for
loading,
this is a core of your problem -- your source code is messy. write
code in a clean way, and SLIME will do what you mean automatically.
Gl> (in-package #:cl-user) (unless (packagep (find-package :pfetcher))
Gl> (make-package :pfetcher)) (in-package :pfetcher)
this is messy, it won't work if you compile file, for example.
is it that hard to organize your code in a normal way? create a package.lisp
file that defines all packages you need, and then just do (in-package
:pfetcher)
in your source file, and it will just work autmatically.
* "Alex Mizrahi" <·························@news.sunsite.dk> :
Wrote on Sat, 14 Feb 2009 13:04:23 +0200:
| Gl> The basic problem is getting SLIME to intern new code in the selected
| Gl> package.
|
| selected where? there is current package for REPL, and current package
| for each buffer, and they are different things. this actually makes
| sense, because typically you edit files from different packages, and
| switching it all the way would be too much hassle.
|
| SLIME automatically guesses package from the first in-package form in
| file (as i understand),
No This is incorrect . In the SLIME I have (And I decided to quit
updating a few weeks ago), SLIME searches LAST in-package form From the
point where you executed the slime command. I don't believe this has
changed
Make sure the (IN-PACKAGE XXX) form you want starts at column 0. and is
the last in-package form when you scan backwards from the point. I
think the regexp searches for this.
| and it most cases it works fine. you can see current package for a
| buffer in a buffer information, e.g. it says "Lisp Slime:cl-user".
| you can manually set buffer's package via (guess what?)
| slime-set-package command.
| Gl> Lots of files contain source code and other stuff not suitable for
| loading,
|
| this is a core of your problem -- your source code is messy. write
| code in a clean way, and SLIME will do what you mean automatically.
This is non-advice. In fact this is nonsense, and if this is given it
shows a limitation of the tool being used. The tool is limiting your
productivity because of its limitations/
I fail to see how you could possibly know how best I can organize my
code/work for maximising my productivity
|
| Gl> (in-package #:cl-user) (unless (packagep (find-package :pfetcher))
| Gl> (make-package :pfetcher)) (in-package :pfetcher)
|
| this is messy, it won't work if you compile file,
It will work.
| for example. is it that hard to organize your code in a normal way?
| create a package.lisp file that defines all packages you need, and
| then just do (in-package :pfetcher) in your source file, and it will
| just work autmatically.
No it only works for a few limited cases. Your'e just lucky your case
was covered by the developers.
SLIME can't handle a say (For example)
(in-package #+Pcl "PCL" #-pcl "CLOS")
--
Madhu
M> Make sure the (IN-PACKAGE XXX) form you want starts at column 0. and is
M> the last in-package form when you scan backwards from the point. I
M> think the regexp searches for this.
yep, looks like that.
M> | this is a core of your problem -- your source code is messy. write
M> | code in a clean way, and SLIME will do what you mean automatically.
M> This is non-advice.
it is bad thing to write code in a clean way??
M> In fact this is nonsense, and if this is given it shows a limitation of
M> the tool being used.
do you have a real need in writing messy code?
M> The tool is limiting your productivity because of its limitations/
code that cannot be loaded is bad for productivity anyway
M> | this is messy, it won't work if you compile file,
M> It will work.
compile-file will not work:
; compiling file "/home/alex/check.lisp" (written 14 FEB 2009 02:13:57 PM):
; compiling (IN-PACKAGE #:CL-USER)
; compiling (UNLESS (PACKAGEP #) ...)
; compiling (IN-PACKAGE :PFETCHER)
debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<THREAD
"initial thread" {A7125F1}>:
The name "PFETCHER" does not designate any package.
because UNLESS is not executed at compile time, you need EVAL-WHEN to do
this.
M> No it only works for a few limited cases. Your'e just lucky your case
M> was covered by the developers.
it is quite a frequent case when you just want your code in a specific
package,
i'd say it's such in 99.9% of cases, so you cannot attribute it to luck.
M> SLIME can't handle a say (For example)
M> (in-package #+Pcl "PCL" #-pcl "CLOS")
this is extremely rare case, don't you think so?
* "Alex Mizrahi" <·························@news.sunsite.dk> :
Wrote on Sat, 14 Feb 2009 14:19:09 +0200:
| it is bad thing to write code in a clean way??
|
| M> In fact this is nonsense, and if this is given it shows a limitation of
| M> the tool being used.
|
| do you have a real need in writing messy code?
As lispers we are familiar with the style of code develpment where we
can use undefined functions in code AT DEVELOPMENT time. (or use stubs
and still have a working program). This is in contrast to say C or some
language which enforces type checking, which will not produce a
(development) program unless all functions are defined, or all types are
declared etc. There have been several posts in this newsgroups
describing why this is generally considered a win for lisp over the
other development environments --- where the others enforce cleanliness,
compilation. AT ALL TIMES.
The point I wanted to make is similar. You can be more productive and
produce clean in the end code by being messy during intermediate steps,
In many cases deciding package naming and structure, decomposing the
symbols to their correct packages, etc. is something that changes during
development before taking a final ideal form.
You can be positively worse off if your tool limits your ability to use
all the facilities and leeway that common lisp as a languag provides.
| compile-file will not work:
[snip]
| because UNLESS is not executed at compile time, you need EVAL-WHEN to do
| this.
[I assumed you'd fix that part..]
| M> (in-package #+Pcl "PCL" #-pcl "CLOS")
|
| this is extremely rare case, don't you think so?
To quote an old (but much missed) wag:
"The only thing I know for sure about most programs is that I haven't
seen them"
--
Madhu
M> As lispers we are familiar with the style of code develpment where we
M> can use undefined functions in code AT DEVELOPMENT time.
undefined functions do not make code non-loadable.
M> The point I wanted to make is similar. You can be more productive and
M> produce clean in the end code by being messy during intermediate steps,
M> In many cases deciding package naming and structure, decomposing the
M> symbols to their correct packages, etc. is something that changes during
M> development before taking a final ideal form.
that is different thing, code might not work, but it is nice if it at least
loads.
if you cannot load whole file, then you'll need to spend your time loading
functions/files one by one, and that is extremely unpleasant, as it wastes
time.
so it is hard for me to see why one might deliberately choose to waste his
time
loading stuff manually.
M> | because UNLESS is not executed at compile time, you need EVAL-WHEN to
M> do | this.
M> [I assumed you'd fix that part..]
isn't that easier to do it in package.lisp rather than writing all these
eval-when/unless
shit?
if that's just one file, it does not need a package.
if project consists of more than one file, than i assume one loads it in
automatic way via asdf or whatever, and it would be easy to move package
definiton into a separate file.
M> | this is extremely rare case, don't you think so?
M> To quote an old (but much missed) wag:
M> "The only thing I know for sure about most programs is that I haven't
M> seen them"
i think i've seen representative subset of programs so i know the
statistics.
M> Either you are setting up a strawman argument or I think You've missed
M> my point completely.
you've missed my point as well.
M> Have you never used #+nil reader macros to comment out code in a file
M> (say alternate behaviour of a certain function) which you later evaluate
M> from the editor after loading the file?
yep. note that it does not influence loadability of file.
M> Have you never kept code in a *slime scratch* file that you persist?
never. if you're speaking about forms that are frequently used in REPL,
SLIME keeps them it its history and it is very easy to recall them -- just
write first few chars and hit M-p.
if some construct gets complex enough so you start to worry about losing
it, it is better to write it in source code along with other functions.
files with code snippets is waste of time IMHO.
M> I think you can't see past the batch file paradigm in interacting with a
M> long lived lisp runtime.
no, i use REPL a lot actually, i just do not have a file with pieces of REPL
in it.
REPL is REPL, code is code, scratch is scratch. i see no place for a
"persistent scratch" in this scheme.
M> OTOH there may be a shapir-worf type effect here ---- most people who
M> are limited by the tools can never understand what they are missing.
i don't think that "persistent scratch" is such a different tool, apparently
REPL with searchable history and editing abilities can replace it, it
is even more general, as you can recall previous version of your forms
from history, but you can't do this in your scratch buffer.
From: Tobias C. Rittweiler
Subject: Re: Getting SLIME and Packages to play nicely
Date:
Message-ID: <87hc2xovph.fsf@freebits.de>
Madhu <...> writes:
> SLIME can't handle a say (For example)
>
> (in-package #+Pcl "PCL" #-pcl "CLOS")
Actually, it can.
-T.
* "Tobias C. Rittweiler" <··············@freebits.de> :
Wrote on Sat, 14 Feb 2009 16:59:54 +0100:
| Madhu <...> writes:
|
|> SLIME can't handle a say (For example)
|>
|> (in-package #+Pcl "PCL" #-pcl "CLOS")
|
| Actually, it can.
No it can't. Did you check before posting?
Unless you fixed it in the last few weeks. Put this form in a file and
try evaluating some form after that.
(in-package #-ANSI-CL "USER" #+ANSI-CL "CL-USER")
Here is the backtrace for your edification:
Debugger entered--Lisp error: (invalid-read-syntax "#")
read("#-ANSI-CL \"USER\" #+ANSI-CL \"CL-USER\"")
(format "%s" (read name))
(let ((name ...)) (format "%s" (read name)))
slime-pretty-package-name("#-ANSI-CL \"USER\" #+ANSI-CL \"CL-USER\"")
(progn (slime-pretty-package-name package))
(if package (progn (slime-pretty-package-name package)))
(when package (slime-pretty-package-name package))
(let ((package ...)) (when package (slime-pretty-package-name package)))
(progn (let (...) (when package ...)))
(if (memq major-mode slime-lisp-modes) (progn (let ... ...)))
(when (memq major-mode slime-lisp-modes) (let (...) (when package ...)))
slime-compute-modeline-package()
(let ((old-pkg slime-modeline-package) (old-conn slime-modeline-connection-name) (old-state slime-modeline-connection-state) (new-pkg ...) (new-conn ...) (new-state ...)) (when (or ... ... ...) (setq slime-modeline-package new-pkg) (setq slime-modeline-connection-name new-conn) (setq slime-modeline-connection-state new-state) (setq slime-modeline-string ...)))
slime-update-modeline-string()
(progn (slime-update-modeline-string) (force-mode-line-update))
(if (slime-shall-we-update-modeline-p) (progn (slime-update-modeline-string) (force-mode-line-update)))
(when (slime-shall-we-update-modeline-p) (slime-update-modeline-string) (force-mode-line-update))
(save-current-buffer (set-buffer (window-buffer window)) (when (slime-shall-we-update-modeline-p) (slime-update-modeline-string) (force-mode-line-update)))
(with-current-buffer (window-buffer window) (when (slime-shall-we-update-modeline-p) (slime-update-modeline-string) (force-mode-line-update)))
(while --cl-dolist-temp-- (setq window (car --cl-dolist-temp--)) (with-current-buffer (window-buffer window) (when ... ... ...)) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--)))
(let ((--cl-dolist-temp-- ...) window) (while --cl-dolist-temp-- (setq window ...) (with-current-buffer ... ...) (setq --cl-dolist-temp-- ...)) nil)
(catch (quote --cl-block-nil--) (let (... window) (while --cl-dolist-temp-- ... ... ...) nil))
(cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
(block nil (let (... window) (while --cl-dolist-temp-- ... ... ...) nil))
(dolist (window (window-list)) (with-current-buffer (window-buffer window) (when ... ... ...)))
slime-update-all-modelines()
(cond (delay (slime-restart-or-init-modeline-update-timer)) (t (slime-update-all-modelines)))
slime-recompute-modelines(nil)
slime-dispatch-event((:return (:abort) 81) #<process SLIME Lisp>)
slime-process-available-input(#<process SLIME Lisp>)
slime-net-filter(#<process SLIME Lisp> "000015(:return (:abort) 82)000017(:debug-return 1 1 nil)000015(:return (:abort) 81)")
From: Tobias C. Rittweiler
Subject: Re: Getting SLIME and Packages to play nicely
Date:
Message-ID: <87d4dlotxp.fsf@freebits.de>
Madhu <·······@meer.net> writes:
> * "Tobias C. Rittweiler" <··············@freebits.de> :
> Wrote on Sat, 14 Feb 2009 16:59:54 +0100:
>
> | Madhu <...> writes:
> |
> |> SLIME can't handle a say (For example)
> |>
> |> (in-package #+Pcl "PCL" #-pcl "CLOS")
> |
> | Actually, it can.
>
> No it can't. Did you check before posting?
Yes, I did. That's a bug in the modeline display.
Aside from that, it _does_ do the right thing, i.e. evaluate an
expression in the correct package.
-T.
* "Tobias C. Rittweiler" <··············@freebits.de> :
Wrote on Sat, 14 Feb 2009 17:38:10 +0100:
|> |> SLIME can't handle a say (For example)
|> | Actually, it can.
|> No it can't. Did you check before posting?
| Yes, I did. That's a bug in the modeline display.
|
| Aside from that, it _does_ do the right thing, i.e. evaluate an
| expression in the correct package.
I find your value of "it handles it" leans on "dishonest", given that
slime updates the modeline display and throws that error after every
keypress inside a form --- it is only with great difficulty that you can
edit anything let alone evaluate it.
--
Madhu
From: Tobias C. Rittweiler
Subject: Re: Getting SLIME and Packages to play nicely
Date:
Message-ID: <874oyxoskn.fsf@freebits.de>
Madhu <...> writes:
> * "Tobias C. Rittweiler" <··············@freebits.de> :
> Wrote on Sat, 14 Feb 2009 17:38:10 +0100:
>
> |> |> SLIME can't handle a say (For example)
> |> | Actually, it can.
> |> No it can't. Did you check before posting?
> | Yes, I did. That's a bug in the modeline display.
> |
> | Aside from that, it _does_ do the right thing, i.e. evaluate an
> | expression in the correct package.
>
> I find your value of "it handles it" leans on "dishonest", given that
> slime updates the modeline display and throws that error after every
> keypress inside a form --- it is only with great difficulty that you can
> edit anything let alone evaluate it.
Asserting that something can't handle something sounds like a stronger
incapability than a small, mostly unrelated bug.
Anyway, the display bug is fixed in CVS. Thanks for raising the issue!
-T.
On Sat, 14 Feb 2009 16:05:23 +0530, <·······@meer.net> wrote:
>
> * "Alex Mizrahi" <·························@news.sunsite.dk> :
> Wrote on Sat, 14 Feb 2009 13:04:23 +0200:
>
>| Gl> The basic problem is getting SLIME to intern new code in the selected
>| Gl> package.
>|
>| selected where? there is current package for REPL, and current package
Well, lets see. I have an active slime buffer with a selected package
active. I try to add some code from a regular emacs buffer into the
running image. So of course, I expect that code in the active slime
buffer package.
>| for each buffer, and they are different things. this actually makes
>| sense, because typically you edit files from different packages, and
>| switching it all the way would be too much hassle.
well, I'm puzzled why slime would guess about an ordinary emacs buffer
that may or may not be in lisp mode. But I've never messed around
with a multiple package setup.
>| SLIME automatically guesses package from the first in-package form in
>| file (as i understand),
>
> No This is incorrect . In the SLIME I have (And I decided to quit
> updating a few weeks ago), SLIME searches LAST in-package form From the
> point where you executed the slime command. I don't believe this has
> changed
>
> Make sure the (IN-PACKAGE XXX) form you want starts at column 0. and is
> the last in-package form when you scan backwards from the point. I
> think the regexp searches for this.
Yup. That's it.
I had moved on and thought about that (in-package :cl-user)
(..make package) stuff and decided it was silly to need to be in
CL-USER to create a package. I removed the switch into cl-user, and
everything was fine once again. Apparently slime gets baffled on
multiple in-package forms, probably for reasons Alex mentions.
When I used that setup ( ->cl-user, make-package, in new package)
before, I had all of the in-package forms starting in column 0, but it
had become such a common setup in my code that I compressed linespace
and ran afoul of slime.
From: Tobias C. Rittweiler
Subject: Re: Getting SLIME and Packages to play nicely
Date:
Message-ID: <87fxidsc3i.fsf@freebits.de>
GP lisper <········@CloudDancer.com> writes:
> well, I'm puzzled why slime would guess about an ordinary emacs buffer
> that may or may not be in lisp mode. But I've never messed around
> with a multiple package setup.
It needs a value of *PACKAGE* the request should be performed in. Now,
if no explicit buffer package can be determined, Slime's REPL package
will be used.
> When I used that setup ( ->cl-user, make-package, in new package)
> before, I had all of the in-package forms starting in column 0, but it
> had become such a common setup in my code that I compressed linespace
> and ran afoul of slime.
Alternatively, iirc, it also looks at a file mode line, so you can put
-*- mode: common-lisp-mode; package: foo -*-
at the beginning of your files. (Intervened IN-PACKAGE forms will
take precedence, though.)
-T.