If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
Which Emacs versions?
How well does SLIME work for you?
What bugs (reproducible or otherwise) or missing features annoy you?
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
If you said anything negative above then please say something nice here to make us feel good:
Luke Gorrie luke@bluetail.com writes:
Questions:
Which Lisp versions do you use SLIME with?
Mostly CVS SBCL.
Which Emacs versions?
GNU Emacs 21.3.1
How well does SLIME work for you?
Works great!
What bugs (reproducible or otherwise) or missing features annoy you?
I'm a little annoyed from time to time with buffer splitting for notes, but not so annoyed that I've tried seriously to fix it.
I also wish the REPL would re-send old input if you hit RET while on that input.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
No.
If you said anything negative above then please say something nice here to make us feel good:
SLIME is awesome! I didn't know what I was missing until I started using it. Now I wish all other languages had such a cool Emacs environment for development.
Zach
On Fri, 18 Jun 2004 10:16:39 -0400, Zach Beane xach@xach.com wrote:
I also wish the REPL would re-send old input if you hit RET while on that input.
<AOL> Me too. </AOL>
On Fri, Jun 18, 2004 at 05:08:18PM +0200, Edi Weitz wrote:
I also wish the REPL would re-send old input if you hit RET while on that input.
<AOL> Me too. </AOL>
I would vote for the first RET just pulling the old input onto the last prompt (probably placing point in the same location in the new copy as where you hit RET in the old one) to give the user a chance to make changes. If you didn't want changes, you just hit RET RET.
The LispWorks Listener behaves this way.
-bcd
Brian Downing bdowning@lavos.net writes:
On Fri, Jun 18, 2004 at 05:08:18PM +0200, Edi Weitz wrote:
I also wish the REPL would re-send old input if you hit RET while on that input.
<AOL> Me too. </AOL>
I would vote for the first RET just pulling the old input onto the last prompt (probably placing point in the same location in the new copy as where you hit RET in the old one) to give the user a chance to make changes. If you didn't want changes, you just hit RET RET.
The LispWorks Listener behaves this way.
In CVS now.
Enough already :-)
-Luke
Brian Downing writes:
On Fri, Jun 18, 2004 at 05:08:18PM +0200, Edi Weitz wrote:
I also wish the REPL would re-send old input if you hit RET while on that input.
<AOL> Me too. </AOL>
I would vote for the first RET just pulling the old input onto the last prompt (probably placing point in the same location in the new copy as where you hit RET in the old one) to give the user a chance to make changes. If you didn't want changes, you just hit RET RET.
The LispWorks Listener behaves this way.
(with-parroting (:aol) me too!)
As does FRED. I've been meaning to go back to using MCL for a bit, to see what features hit me as something I miss in SLIME. Alas, getting work done with SBCL keeps getting in the way.
On Fri, 2004-06-18 at 15:58, Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
SBCL w/ multithreading, v 0.8.10.48
Which Emacs versions?
GNU Emacs 21.3.1
How well does SLIME work for you?
Actually, pretty nice!
What bugs (reproducible or otherwise) or missing features annoy you?
I cant get some interfaces to work (DISASSEMBLE-FRAME LIST-CALLEES LIST-CALLERS PROFILE-PACKAGE RESTART-FRAME WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES)
Also, when using multithreaded applications, the communication obviously is a little particular .. I had to set the comm style to fd-handler to get it to work.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this? If you said anything negative above then please say something nice here to make us feel good:
Well, I's harder to find something bad to say about it then something nice! I discovered CL a few months ago as well as slime, and so started to understand better lots of things: how to get emacs to work, how to hack the sawfish window manager and, concerning slime, how to turn Emacs into the best, most productive, and most extensible IDE I've ever seen. Slime is great, and gets greater every single day. No doubt it will very soon become a mush-have for all CL developpers. No less no more. I mean it.
:)
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Regards,
Arnaud
On Fri, 18 Jun 2004 15:58:45 +0200, Luke Gorrie luke@bluetail.com wrote:
Which Lisp versions do you use SLIME with?
CMUCL 18e, AllegroCL 6.2 and 7.0beta. I have licenses for LW 4.3 pro and I'm planning to use it with SLIME, too.
Which Emacs versions?
GNU Emacs 21.3.
How well does SLIME work for you?
Works great (no problems I can remember) with CMUCL, several problems with AllegroCL which I'll try to report later.
What bugs (reproducible or otherwise) or missing features annoy you?
Other than the AllegroCL stuff nothing comes to mind.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Debian would be nice. I think Kevin Rosenberg would be the first person to ask although he probably has too much stuff to maintain already.
If you said anything negative above then please say something nice here to make us feel good:
I don't want to learn a new IDE for each Lisp I'm working with and I also can't see me using one single implementation in the near future, so I'm looking for a cross-implementation IDE. ILISP came close but somehow never felt like the real thing. SLIME seems to be on its way to be the perfect CL IDE. Kudos to the SLIME hackers!
Cheers, Edi.
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
CLISP 2.33.1 on Cygwin
Which Emacs versions?
XEmacs 21.4.13
How well does SLIME work for you?
Almost perfectly. It seems that some of the nice xref features are not implemented for CLISP at present, but it still works well enough to forestall seeking anything better.
What bugs (reproducible or otherwise) or missing features annoy you?
The only bug I experience frequently is probably not SLIME's fault. XEmacs hangs when left for a long while (usually overnight) with an open SLIME connection. I have to break the connection for XEmacs to awaken from its blocking wait. Provided that I run a CLISP instance as a separate process from XEmacs, it's not too hard to interrupt the swank server and restart it. I expect that this bug is related to XEmacs and/or Cygwin, and SLIME just happens to manifest the problem most frequently.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
No, packaging isn't important to me. I run a copy updated from CVS, and installation is simple.
If you said anything negative above then please say something nice here to make us feel good:
SLIME's presentation of restarts and debugger interaction is fantastic. It enables me to explore the CL condition/restart system faster and with much less typing than with ILISP.
Luke Gorrie luke@bluetail.com writes:
Questions:
Which Lisp versions do you use SLIME with?
CMUCL 18e, SBCL CVS
Which Emacs versions?
GNU Emacs 20.7.2
How well does SLIME work for you?
It rocks. It Just works(tm).
What bugs (reproducible or otherwise) or missing features annoy you?
Most bugs are fixed before I can see them, no kidding. The few I caught were fixed in a matter of hours, and didn't stop any important work.
I second what others have said about RETURN being able to reissue old expressions in the repl. Also, you may have missed an interesting question for this survey: which operating system? In my case, Debian Woody.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Not particularly interested: I use SLIME CVS (head; FAIRLY-STABLE is for old ladies).
If you said anything negative above then please say something nice here to make us feel good:
Your karma looks great. And your aura is lovely.
Paolo
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
OpenMCL 0.14p2 darwin (90%)
SBCL darwin (10%)
Which Emacs versions?
CVS
How well does SLIME work for you?
better 95% of everything i've ever worked with.
What bugs (reproducible or otherwise) or missing features annoy you?
Random minor bits and pieces related to OpenMCL. While some of them are annoying none of them stop me from getting real work done.
the only place where slime could use some work is the remote/multi-thread debugging stuff, but i don't yet have any suggestions to make so i'll just let it sit for now.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
emacs.
If you said anything negative above then please say something nice here to make us feel good:
if you're ever in torino drinks are on me, the first round at least :).
Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
SBCL cvs and CMUCL 18e
Which Emacs versions?
GNU Emacs 21.3.50 (cvs, multi-tty branch).
How well does SLIME work for you?
Almost without fault, the occaisional small bugs I find seem to be problems with either Emacs (e.g. a change in rename-buffer), or the lisps (e.g. some backtrace frames being unavailable in SBCL).
What bugs (reproducible or otherwise) or missing features annoy you?
I also think hitting RET on old REPL input should resend it. Other than that, I can't think of much.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I'm not a big fan of the Debian Emacs packaging, but, otoh, it does deal relatively easily with multiple installed versions. It's quite easy to do though, I can probably have a look at it when I've unpacked boxes if people like.
If you said anything negative above then please say something nice here to make us feel good:
SLIME Just Works, which is nice.
On Fri, 18 Jun 2004, Luke Gorrie wrote:
Questions:
Which Lisp versions do you use SLIME with?
cmucl, abcl
Which Emacs versions?
GNU Emacs 21.2.1
How well does SLIME work for you?
Very well!
What bugs (reproducible or otherwise) or missing features annoy you?
Only minor things like unwarranted window config changes; e.g. when compiling/loading files, the emacs window splits and I get the REPL which I didn't ask for. Also, when completing symbols, the *completions* buffer sometimes doesn't go away, or it does, but the window remains split. A test case showing the former (and also a bug in the completion algorithm): try to complete 'list-'; the point will back up to the hyphen, so you have to move it forward, and this will confuse slime-complete-symbol enough that even after a successful completion, the *completions* window doesn't disappear.
On the features side: I think that RET should do newline and indent in a source buffer (who would want to write lisp code without indentation?). I use
(defun slime-mode-newline () "Indent, insert a newline and indent again." (interactive) (save-excursion (lisp-indent-line)) (newline 1) (lisp-indent-line))
(taken from eli), but there are probably easier/better ways to achieve this.
Also, multiple REPLs to the same lisp image (like in eli) would be nice. (I'd probably switch from eli to slime with acl.)
An easy way to toggle (with no questions asked) between source files and the REPL (or REPLs) with the same (simple) key chord. Ideally, with a prefix argument, it would offer the recently visited source files or REPLs, depending on whether we're in a REPL or a source file.
And I second Zach:
I also wish the REPL would re-send old input if you hit RET while on that input.
It'd also be nice if in this situation, C-RET or M-RET or something similar would copy the old input to the last prompt and jump there, so that one could modify and evaluate it without 'changing history'.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
No.
If you said anything negative above then please say something nice here to make us feel good:
Good bye, ILISP!
Andras
Andras Simon andras@renyi.hu writes:
Only minor things like unwarranted window config changes; e.g. when compiling/loading files, the emacs window splits and I get the REPL which I didn't ask for.
IIRC we started popping up the REPL because otherwise you don't get a sense of progress during compiles. There may be a better way though.
Also, when completing symbols, the *completions* buffer sometimes doesn't go away, or it does, but the window remains split.
I've hacked the window configuration stuff for completion a bit. See if you like it better now.
-Luke
On Mon, 21 Jun 2004, Luke Gorrie wrote:
Andras Simon andras@renyi.hu writes:
Only minor things like unwarranted window config changes; e.g. when compiling/loading files, the emacs window splits and I get the REPL which I didn't ask for.
IIRC we started popping up the REPL because otherwise you don't get a sense of progress during compiles. There may be a better way though.
Switching to the REPL (instead of splitting the window) would be an option that I think I'd like better - but I'm sure it'd drive some people crazy. But it's not a big issue, and now that I know the reason, it doesn't annoy me anymore.
Also, when completing symbols, the *completions* buffer sometimes doesn't go away, or it does, but the window remains split.
I've hacked the window configuration stuff for completion a bit. See if you like it better now.
It's perfect now. Thanks!
Andras
Luke Gorrie writes:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
SBCL (0.8.8 and 0.8.10) on Mac OS X.
Which Emacs versions?
Carbon Emacs from CVS, and corresponding X11 builds. Currently this means GNU Emacs 21.3.50 (or .51, I forget)
How well does SLIME work for you?
Better and better; well enough that it hardly ever gets in the way of the work I'm trying to do.
What bugs (reproducible or otherwise) or missing features annoy you?
When using Hemlock, I used to keep a window open with a Garnet tree widget that kept track of compilation notes. I tried to setup the a frame just for the compilation notes buffer, but it didn't work out too well. Generally, support for keeping a seperate frame for certain SLIME buffers (notes, inspector, etc) would be nice.
The compilation notes buffer always pops up when there is exactly one STYLE-WARNING (usually a redefinition warning, ug), but not when there are some notes, which I might actually want to see.
The debugger doesn't let me easily inspect the current condition (although I found the variable where it's kept). The inspector doesn't do anything useful when given condition objects.
I haven't tried using a local Emacs to attach to a remote Lisp. I gather though, that M-. won't work, if I do; it would be nice to integrate use Tramp to do this.
Finally, there's no ASDF system editor.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Nope.
If you said anything negative above then please say something nice here to make us feel good:
SLIME has developed so quickly that I've gotten very high expectations for it; it doesn't feel like using some crummy free software environment where one has lowered expectations, it feels like the prerelease of a commercial-quality environment. Great job y'all!
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
The debugger doesn't let me easily inspect the current condition (although I found the variable where it's kept). The inspector doesn't do anything useful when given condition objects.
There's a M-x sldb-inspect-condition command. The inspector shows the same slots as SBCL's tty inspector.
I haven't tried using a local Emacs to attach to a remote Lisp. I gather though, that M-. won't work, if I do; it would be nice to integrate use Tramp to do this.
You have to configure the slime-{from,to}-lisp-filename functions. The idea is that those functions create Tramp style filenames. I never tried it, but the infrastructure is there.
Helmut.
Helmut Eller writes:
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
The debugger doesn't let me easily inspect the current condition (although I found the variable where it's kept). The inspector doesn't do anything useful when given condition objects.
There's a M-x sldb-inspect-condition command. The inspector shows the same slots as SBCL's tty inspector.
Hmm, not here it doesn't. It looks like I'm using a SLIME from about June 8, so if it's been fixed since then, that'd explain it.
Assuming a more useful sldb-inspect-condition command than I seem to have here, this patch would give the behavior I intuitively expected from the debugger:
--- slime.el.~1.309.~ Tue Jun 8 17:18:38 2004 +++ slime.el Tue Jun 22 17:12:55 2004 @@ -4831,10 +4831,11 @@
(defun sldb-insert-condition (condition) (destructuring-bind (message type references) condition - (insert (in-sldb-face topline message) - "\n" - (in-sldb-face condition type) - "\n\n") + (slime-insert-propertized '(sldb-default-action sldb-inspect-condition) + (in-sldb-face topline message) + "\n" + (in-sldb-face condition type) + "\n\n") (when references (insert "See also:\n") (slime-with-rigid-indentation 2
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
Hmm, not here it doesn't. It looks like I'm using a SLIME from about June 8, so if it's been fixed since then, that'd explain it.
I think there was no relevant change. Could you give an example of what you see?
Assuming a more useful sldb-inspect-condition command than I seem to have here, this patch would give the behavior I intuitively expected from the debugger:
That's a good idea. It's all to easy to overlook such simple but effective little goodies. Thanks! In CVS now.
Helmut.
Helmut Eller writes:
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
Hmm, not here it doesn't. It looks like I'm using a SLIME from about June 8, so if it's been fixed since then, that'd explain it.
I think there was no relevant change. Could you give an example of what you see?
I was seeing
Slots:
^- no slots actually shown
but then I tried a more recent sbcl than 0.8.8, and it works again. That's what I get for bouncing between so many versions, I guess. Shoot, I guess I'll have to find the last slime that worked with 0.8.8, or update the sbcl on that server :-)
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
SBCL 0.8.10, Darwin
Which Emacs versions?
CVS
How well does SLIME work for you?
Very.
What bugs (reproducible or otherwise) or missing features annoy you?
This is really more of an SBCL problem, but since SLIME reports compilation errors and warnings afterwards, it would be nice to be able to have it suppress SBCL's extreme chattiness in the REPL buffer when doing a compile from a lisp buffer. It would probably speed things up as well, since Emacs would no longer have to fontify all those notes.
For some features, SLIME reinvents wheels that come standard with newer Emacs (i.e. "slime-autodoc" is a reimplementation of Eldoc with its local hook; the notes tree vs. David Ponce's excellent tree-widget package). It would reduce duplication of both development and ~/.emacs configuration to use these existing facilities.
Other than that, (1) it works amazingly well, (2) SLIME development is quite active, and (3) it's Lisp and I've got the source, so obviously these problems aren't serious enough to motivate me to fix them.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Nope. It's not the GNU Emacs way...
/s
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
CMUCL, SBCL
Which Emacs versions?
GNU Emacs 21.3.50.1
How well does SLIME work for you?
*perfectly* :))) ...for now ;>
What bugs (reproducible or otherwise) or missing features annoy you?
My wish is edebug like ability.
Regards.
SLIME is really, really great!
Today, Luke Gorrie luke@bluetail.com wrote:
Questions:
Which Lisp versions do you use SLIME with?
SBCL, more-or-less recent CVS versions and CMUCL 18e
Which Emacs versions?
not-quite-current CVS (21.3.50.4)
How well does SLIME work for you?
It started out working great (I switched from ILISP after the non-mt SBCL interface was done), and it got better and better. For me, it works better and more consistently good than most packages that are shipped with emacs.
What bugs (reproducible or otherwise) or missing features annoy you?
Just a brain dump:
As Thomas F. Burdick said, it's not very useful to have a buffer pop up containing only one STYLE-WARNING (redefining FOO) but leaving out the compiler notes. I know that sometimes it's good to be informed that you're just redefining stuff, But when I'm using compile-defun, I know that I'm redefining the function. C-c C-k is a different story, though (-:
A condition inspector would be very good to have.
The window that pops up when you C-c C-k (compile-and-load-file) should structure the conditions into conditions raised at compile-time and at load-time.
And this one's here because I've grown to like this feature in eclipse (lets me take a break from coding from time to time (-;): A simple way of running RT tests and looking at the results - preferably with a green bar. (-:
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I guess the answer to that one is "as many as possible". Spread the Viru^WSLIME!
If you said anything negative above then please say something nice here to make us feel good:
SLIME is a really great development environment for reading, writing and debugging programs interactively. It's fun to use it, and it makes for a very nice demo of how programming lisp feels like (-:
Thanks for the great work,
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
SBCL bleeding edge. Usually I get myself into a complete mess with multiple fasls of old(er) versions lying around, and wondering what it is I've done this time to cause binary incompatibility.
Which Emacs versions?
GNU Emacs 21.3.1. (Or, more generally, whatever's in Debian unstable today).
How well does SLIME work for you?
Pretty well. It was already quite good for the limited application programming that I do; with its improved ability to understand SBCL syntax, all I have to do is train myself out of the habit of using X cut'n'paste for incremental development...
What bugs (reproducible or otherwise) or missing features annoy you?
I would like to see a little more work on coordination between slime and implementations (not just SBCL, though obviously that's where my focus is). There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
One thing: emacs seems relatively bad at fontifying large buffers. It's quite possible that this is my fault, but doing a full compilation of CLX, McCLIM and Gsharp, say, is probably slower than it could be because of scrolling and fontifying interaction buffers. I'm sure SLIME isn't designed for this kind of abuse... but maybe it could be. :-)
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I can help with Debian integration, though not with the actual distribution (though if pushed I have Debian Developers who owe me favours :) -- I would like to encourage stable versions of SLIME to be distributed via the package management system, because then you get the benefits of reciprocal advocacy: sbcl's Debian package can "Recommend: slime", for instance.
If you said anything negative above then please say something nice here to make us feel good:
I'm very impressed at the way you've alleviated the need for a cl-emacs. It's probably not ZWEI or Zmacs (or similar mythological Nirvana), but it seems pretty good to me. Will buy drinks (in addition to the ones I owe Luke!) just as soon as my paychecks start coming through :-)
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
I've given this some more thought. I think it's highly likely that SLIME 1.0 will be broken pretty quickly due to changes to Lisp internals that it pokes around in, either SBCL or some other Lisp.
Let's accept that. When you upgrade your Lisp there'll be a chance that you have to upgrade SLIME too (and vice versa), and we'll need to stay on top of this so that we have a SLIME update ready and e.g. SBCL release notes can say "this doesn't work with SLIME before version foo."
These invariants are probably pretty realistic:
The latest SLIME works with the latest of each Lisp. Each Lisp release is compatible with some released version of SLIME.
Naturally we try to minimize breakages and make an honest mode of ourself by using supported interfaces in the future. Meanwhile if you want to update SLIME or Lisp then you may have to do both, just like when you do 'cvs update' today :-)
This would suggest we be careful of which packaging systems we try to bundle 1.0 with. In e.g. Debian which handles dependencies and includes Lisp implementations is probably fine. Bundling with e.g. XEmacs is possibly not so fine, since most people don't want to upgrade Emacs as often as their Lisp. (Though perhaps their packaging system can handle this anyway.)
This should be okay for Peter's book. "Lisp in a Box" can include mutually compatible SLIME/Lisp releases and anyone who wants to download stuff themself can just grab the latest SLIME and Lisp off the 'net and plug them together.
That's my 2c for today anyway.
-Luke
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
Originally OpenMCL from Darwin Ports, then SBCL from CVS on OS X, and I expect to bounce back and forth between those two depending on what I am working on.
Which Emacs versions?
Carbon build of Emacs from CVS (5-15-2004) on OS X
How well does SLIME work for you?
Mostly pretty well. I don't hammer it that hard though.
What bugs (reproducible or otherwise) or missing features annoy you?
Sometimes, and this seems totally random, the SBCL debugger only shows up in the REPL rather than giving me the SLIME debugger.
I don't like the point being moved into the macroexpand1 window when I do C-c C-m.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I expect I will continue to use SLIME from CVS and take advantage of ASDF.
If you said anything negative above then please say something nice here to make us feel good:
I think SLIME made it easier for me to explore Lisp programming. I particularly like being able to compile functions from inside the lisp buffer so that I don't have to jump to the repl a lot. I tend to also put test code in the lisp buffer where I do C-x C-e to evaluate it. This is much nicer than pasting into the repl.
On Fri, Jun 18, 2004 at 03:19:30PM -0400, David Steuber wrote:
Sometimes, and this seems totally random, the SBCL debugger only shows up in the REPL rather than giving me the SLIME debugger.
If the condition says something along the lines of "-819843 is not of type (MOD 0 536870911)", this is an SBCL bug (on some non-x86 platorms), and not Slime.
I have a hacky workaround (not a fix, and it's possible it breaks other things) for this. If you're interested, let me know.
-bcd
David Steuber david@david-steuber.com writes:
I think SLIME made it easier for me to explore Lisp programming. I particularly like being able to compile functions from inside the lisp buffer so that I don't have to jump to the repl a lot. I tend
By the way, since I use the repl often, I do this under Linux. I keep an Emacs frame with the SLIME repl, and another frame with the Lisp code buffer on which I am working. Each Emacs frame goes into its own KDE virtual desktop. Switching from the Lisp buffer to the repl is a simple matter of Ctrl-Fn.
Paolo
Paolo Amoroso amoroso@mclink.it writes:
By the way, since I use the repl often, I do this under Linux. I keep an Emacs frame with the SLIME repl, and another frame with the Lisp code buffer on which I am working. Each Emacs frame goes into its own KDE virtual desktop. Switching from the Lisp buffer to the repl is a simple matter of Ctrl-Fn.
I forgot to mention that I maximize each frame into its own desktop.
Paolo
Paolo Amoroso amoroso@mclink.it writes:
By the way, since I use the repl often, I do this under Linux. I keep an Emacs frame with the SLIME repl, and another frame with the Lisp code buffer on which I am working. Each Emacs frame goes into its own KDE virtual desktop. Switching from the Lisp buffer to the repl is a simple matter of Ctrl-Fn.
I use the `slime-selector' command. This is not bound anywhere by default because it really needs a global binding to be useful.
If you put it on e.g. `C-c s' then you can jump into the repl with `C-c s r' and back to the most recently visited Lisp source by pressing `C-c s l'. It supports more buffers too, and is extensible.
-Luke
Luke Gorrie luke@bluetail.com writes:
Paolo Amoroso amoroso@mclink.it writes:
By the way, since I use the repl often, I do this under Linux. I keep an Emacs frame with the SLIME repl, and another frame with the Lisp code buffer on which I am working. Each Emacs frame goes into its own KDE virtual desktop.
Imho "ratpoison" wm is best solution with Emacs with multiple frames (no KDE&stuff, Emacs look&feel) [ http://ratpoison.sourceforge.net/ ].
Switching from the Lisp buffer to the repl is a simple matter of Ctrl-Fn.
I post my (temporary) solution on alt.pl.comp.os.linux.newbie few weeks ago, I think it's better solution than yours. First message [1] (below) is my .emacs file. See fragment with `ssb-make-select-key' macro:
.....
(macrolet ((CREATE-SELECT-KEYS (&rest lst) `(progn ,@(mapcar (lambda (x) `(ssb-make-select-key ,@x)) lst))))
(CREATE-SELECT-KEYS
;; --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ;; key ssb-x-cdll prefix(es) command hook-name mode-name ;; --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
("s-i" "info" Info info ) ("s-s" "eshell" eshell eshell ) ("s-w" "w3m" w3m w3m ) ("s-t" "text" text ) ("s-;" "slime/ielm" (slime-repl ielm) nil nil (slime-repl-mode inferior-emacs-lisp-mode)) ("s-l" "LISP/elisp" (lisp emacs-lisp) )
;; --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- )) ; hook-name and mode-name are optional. They are created from `prefix(es)'.
.....
[1] Message-ID: 87y8mzuf9u.fsf_-_@darkstar.example.net
my dot-emacs.
[2] Message-ID: 87r7sruf4q.fsf@darkstar.example.net
`ssb-make-selct-key' macro - it do the job.
[3] Message-ID: 87n03fuf38.fsf@darkstar.example.net
funny "library" (stupid and hairy (stupidness and hairness was intended) dll) required by `ssb-make-select-key' macro.
I use the `slime-selector' command. This is not bound anywhere by default because it really needs a global binding to be useful.
If you put it on e.g. `C-c s' then you can jump into the repl with `C-c s r' and back to the most recently visited Lisp source by pressing `C-c s l'. It supports more buffers too, and is extensible.
Iteresting. I must try it.
Regards.
On Fri, Jun 18, 2004 at 03:58:45PM +0200, Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
cmucl
Which Emacs versions?
emacs 21.2.1, rh rpm
How well does SLIME work for you?
much more useful than ilisp. especially the remote connections and multiple connections.
What bugs (reproducible or otherwise) or missing features annoy you?
no problems aside from the swank-backend (patched) and the "bad file descriptor" (fixed),
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
rpm. i packaged the cvs myself. you can have the spec file if you want it.
If you said anything negative above then please say something nice here to make us feel good:
very useful. nice tight UI.
On Jun 18, 2004, at 8:58 AM, Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
SBCL CVS, OpenMCL 0.14.2
Which Emacs versions?
GNU emacs CVS from November, 21.3.1
How well does SLIME work for you?
SLIME is a great tool. It works to my satisfaction most of the time, and much of what annoys me when using it is the fault of Emacs itself.
What bugs (reproducible or otherwise) or missing features annoy you?
The behavior of the completions window is constantly annoying - it doesn't go away, and when I do close it, Emacs sometimes inscrutably decides to give the frame to a buffer that wasn't there before the completions window pops up. In general, Emacs' behavior with buffers is annoying, but the completion window is more annoying than most.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Nope
If you said anything negative above then please say something nice here to make us feel good:
Sorry, my quota of nice things is expired for today :-)
(Seriously, SLIME is the best thing out there right now in CL development.) -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
On Fri, 18 Jun 2004 15:58:45 +0200, Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
Mostly SBCL & CMUCL, a little bit of CLISP.
Which Emacs versions?
Emacs 21.3.1. I was recently a hardcore XEmacs user, but I've moved back to Emacs.
How well does SLIME work for you?
I think it's great. It has *significantly* enhanced my usage and enjoyment of Common Lisp over the past year.
What bugs (reproducible or otherwise) or missing features annoy you?
Bugs: none that I can think of. Daily CVS seems to work pretty well.
Missing features:
Inspector navigation seems a little off, could be a little better, one of the wish items mentioned in Helmut's wish list.
I'd like to see viewing source from a stack frame try and go to the actual line of source code, instead of just the function.
I think a stepper like the Emacs Lisp debugger or like gdb-mode would be pretty cool. I realize there's a lot of challenges to doing nice stepping in Lisp. I think this would help newbies get a better feel for the language, especially since it's a common feature in the IDEs they come from.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I think getting it apt-gettable via Debian and Fedora (yum) would be really useful. Maybe for the 1.0 release. Ultimately, I just download it from the daily CVS whenever I use it. That's pretty easy to do.
If you said anything negative above then please say something nice here to make us feel good:
I didn't say anything negative, but I can't emphasize how important I think SLIME is to the community as a whole and to it's future growth. I think it is an incredible tool and I can't imagine not using it. It is light years ahead of ILISP, for example.
Kilo-kudos to all of you! (ok, mega-kudos!)
Luke Gorrie writes:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
SBCL
Which Emacs versions?
XEmacs 21.4.12 (FreeBSD), Emacs 21.3.50 (MacOSX)
How well does SLIME work for you?
It works great for me, but I haven't really got started with any of the advanced features.
What bugs (reproducible or otherwise) or missing features annoy you?
None.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
If you said anything negative above then please say something nice here to make us feel good:
I don't think any of the above could be counted as negative, but I'll say this anyway: SLIME is an extremely smooth way of working with Lisp code :-)
Here is a batch-mode reply to some survey comments:
Bill_Clementson@peoplesoft.com writes:
Which Lisp versions do you use SLIME with?
Allegro 6.2 and 7.0beta, LispWorks 4.3, CLISP 2.33, and ABCL (cvs) - all on Win2000
[...]
bug: the "v"iew source option in sldb doesn't work for any implementation I'm using
Not even in LispWorks? It should work there, with defun-granularity. Likewise ACL in CVS now.
Andras Simon andras@renyi.hu writes:
On the features side: I think that RET should do newline and indent in a source buffer (who would want to write lisp code without indentation?). I use
That is most reasonable, though the usual Emacs Way is to have C-j do this instead of RET. You can rebind RET to `newline-and-indent'.
An easy way to toggle (with no questions asked) between source files and the REPL (or REPLs) with the same (simple) key chord. Ideally, with a prefix argument, it would offer the recently visited source files or REPLs, depending on whether we're in a REPL or a source file.
Try the `slime-selector' command. Not exactly what you're asking for, but perhaps pretty close.
Also, multiple REPLs to the same lisp image (like in eli) would be nice. (I'd probably switch from eli to slime with acl.)
The internals actually support this. You could do:
(swank:create-server :dont-close t)
To start a server that stays open after the first connection, then open multiple connections to it using `M-x slime-connect'.
[I would quite like to delete the internals that make this possible, but I don't think I'll get away with that :-)]
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
The compilation notes buffer always pops up when there is exactly one STYLE-WARNING (usually a redefinition warning, ug), but not when there are some notes, which I might actually want to see.
Yes, that shits me too. The reason it pops up is that those "redefining:" style warnings are signalled without any source-path information, so we don't know where to annotate them and fall back to popping up the buffer.
I've hacked those warnings out of my local SBCL and started a nagging campaign on Christophe.
Finally, there's no ASDF system editor.
What would such a beast look like?
Christophe Rhodes csr21@cam.ac.uk writes:
I would like to see a little more work on coordination between slime and implementations (not just SBCL, though obviously that's where my focus is). There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
Christophe and I have talked about this off-list. We've suggested that for whatever internal SBCL functions we're still calling towards the release, we'll call them indirectly via an "sb-slime"-or-such package which will be part of SBCL. This level of indirection means that the SBCL guys can change the internals that we're accessing and still be SLIME-1.0 compatible so long as they update sb-slime in terms of the new internals.
We could also do this with for any other Lisps that're interested. Of course as much as possible we'd prefer to switch to using public interfaces instead of digging into internals.
Glenn Ehrlich glenn.ehrlich.lists@cox.net writes:
I'd like to see viewing source from a stack frame try and go to the actual line of source code, instead of just the function.
This is a per-backend thing. In CMUCL you should get the exact source form within the definition. It would be very nice to figure out how to do this for other implementations.
-Luke
Luke Gorrie luke@bluetail.com writes:
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
The compilation notes buffer always pops up when there is exactly one STYLE-WARNING (usually a redefinition warning, ug), but not when there are some notes, which I might actually want to see.
Yes, that shits me too. The reason it pops up is that those "redefining:" style warnings are signalled without any source-path information, so we don't know where to annotate them and fall back to popping up the buffer.
I've hacked those warnings out of my local SBCL and started a nagging campaign on Christophe.
This is hard. David Lichteblau looked at doing something similar, but the problem in essence is (I think -- I'm certainly no expert in this, and probably won't become one in the next two months) that the SBCL fasl file format first contains new definitions, etc, and then backpatches the new definitions with source file information. So at the time of function (re)definition, all that neat debugging information simply isn't associated with the function.
So, fixing this right probably involves messing around with the fasl format, which is annoying and non-trivial.
Christophe Rhodes csr21@cam.ac.uk writes:
I would like to see a little more work on coordination between slime and implementations (not just SBCL, though obviously that's where my focus is). There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
Christophe and I have talked about this off-list. We've suggested that for whatever internal SBCL functions we're still calling towards the release, we'll call them indirectly via an "sb-slime"-or-such package which will be part of SBCL. This level of indirection means that the SBCL guys can change the internals that we're accessing and still be SLIME-1.0 compatible so long as they update sb-slime in terms of the new internals.
I should say that this won't happen automagically. (Welcome to Free software...) The more users who can distill unsupported functionality used by slime into entry points _with tests_, so that SBCL developers stand a chance of knowing when they've broken something, the more successful this attempt at providing a certain amount of stability will be. In particular, if you feel that you would appreciate not having to upgrade slime and sbcl whenever either team decides to change something, then now is the time to make your efforts felt.
Cheers,
Christophe
Luke Gorrie writes:
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
Finally, there's no ASDF system editor.
What would such a beast look like?
I had started working on a CLX one, but I really only got as far as writing a DAG widget. I was thinking of writing an Emacs one, making heavy use of widget.el, with the information about the system itself (name, license, etc) at the top of the buffer, and the rest of the buffer being a clicky graph with up/down, back/foreward, and expand/collapse navigation commands.
This is pretty much what I've done when I've written these in the past for my own ad-hoc system definition utilities, except not in Emacs Lisp.
Which Lisp versions do you use SLIME with?
CMUCL-18e, CMUCL-CVS, CMUCL-19A-PRE2-X86-LINUX, Allegro-6.0
Which Emacs versions?
Emacs 21.1.95.1, Emacs 21.2.1
How well does SLIME work for you?
Good, much better than ILISP.
What bugs (reproducible or otherwise) or missing features annoy you?
. I wish EDIT-DEFINITION would work better when the source file has changed. I suggest associating a non-trivial hash code (like a secure hash function) with the s-expression for each definition to be used in finding the definition in a modified source file.
. It would be nice if s-expressions for reader-macro conditionals that evaluate to NIL in the running Lisp were displayed in a different Emacs face. SLIME aleady has slime-eval-feature-conditional with evaluates the reader conditional wrt. *features* of running Lisp.
. I wish that the inspector part of the debugger would allow the args and locals of the current frame to be inspected. I realize that there are no Lisp objects for either, but an a-list or some sort of object could be "consed up" to hold the information.
. SLIME needs more control over how arrays are printed. This is partially a gripe about the CL Spec: *print-array* needs counterpart information like *print-length* for lists to control how much is printed about arrays. In particular, *print-array-length* = n might mean either print at most the first n elements of arrays. Alternatively, *print-array-length* = n might mean to print the array with *print-array* = (<= (array-total-length array) n).
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
No.
If you said anything negative above then please say something nice here to make us feel good:
My previous suggestions should be not be considered as criticisms of SLIME, but as ways to improve it.
I have been grumbling for many years about the problems with the ILISP communication model. There always seemed to be something wrong with the regular-expressions used to detect the REPL prompt. SLIME appears to have avoided those problems by having a distinct stream for the REPL buffer (and other things) vs control and asynchronous communication.
Good work, SLIMIES (or is it SLIMERS?).
Lynn Quam quam@ai.sri.com writes:
. I wish EDIT-DEFINITION would work better when the source file has changed. I suggest associating a non-trivial hash code (like a secure hash function) with the s-expression for each definition to be used in finding the definition in a modified source file.
In what cases does it cause you problems under CMUCL? I thought that the source-file-cache hack pretty much took care of this.
In the current scheme our "hash" is just the first 256 characters of the definition, for which we find the longest match. I don't see what interesting cases a real hash function would handle that this doesn't, and it would seem less robust wrt modifications to the definition that's being looked up. Am I missing something?
One issue with the source cache is that it doesn't always get at the source file soon enough. I think I can fix this. Meanwhile if you find M-. going to the wrong place then doing `C-c C-k' on the buffer should hopefully make it work well for the rest of your session.
. It would be nice if s-expressions for reader-macro conditionals that evaluate to NIL in the running Lisp were displayed in a different Emacs face. SLIME aleady has slime-eval-feature-conditional with evaluates the reader conditional wrt. *features* of running Lisp.
This would be good. Right now I don't know of the right mechanism by which to do it. Anyone have ideas?
-Luke
Luke Gorrie replied:
In what cases does it cause you problems under CMUCL? I thought that the source-file-cache hack pretty much took care of this.
I have noticed that in files with reader-macro conditionals that have undergone insertions and/or deletions of code that EDIT-DEFINITION sometimes gets me to the wrong place. Recently, I have seen that I have been getting to the next definition after the correct one. EDIT-DEFINITION should really also consider reader-macro conditionals.
In the current scheme our "hash" is just the first 256 characters of the definition, for which we find the longest match. I don't see what interesting cases a real hash function would handle that this doesn't, and it would seem less robust wrt modifications to the definition that's being looked up. Am I missing something?
Perhaps I am nitpicking, but it is possible for there to be 2 definitions in a file with the same first 256 characters.
A long hash code like that of the NIST Secure Hash Standard ("Applied Cryptography", Bruce Schnier) is extremely robust wrt modifications to the input string.
. It would be nice if s-expressions for reader-macro conditionals that evaluate to NIL in the running Lisp were displayed in a different Emacs face. SLIME aleady has slime-eval-feature-conditional with evaluates the reader conditional wrt. *features* of running Lisp.
This would be good. Right now I don't know of the right mechanism by which to do it. Anyone have ideas?
There is the Emacs hide-ifdef-mode that might provide some ideas for this.
Lynn Quam quam@ai.sri.com writes:
Luke Gorrie replied:
In what cases does it cause you problems under CMUCL? I thought that the source-file-cache hack pretty much took care of this.
I have noticed that in files with reader-macro conditionals that have undergone insertions and/or deletions of code that EDIT-DEFINITION sometimes gets me to the wrong place. Recently, I have seen that I have been getting to the next definition after the correct one. EDIT-DEFINITION should really also consider reader-macro conditionals.
If you can send me reproducible examples I'll try to fix them. No rush though, in playing around I've just found one case that should work but doesn't, so I've got some fixing to do.
Perhaps I am nitpicking, but it is possible for there to be 2 definitions in a file with the same first 256 characters.
A long hash code like that of the NIST Secure Hash Standard ("Applied Cryptography", Bruce Schnier) is extremely robust wrt modifications to the input string.
I'm thinking of robustness in the opposite sense: if I'm looking up the definition of FOO, but FOO has been modified, then a hash won't find it but a best-prefix-match search quite possibly will. Looking for definitions that have been modified since compilation is fairly common for me I think.
It's possible to make the snippet longer than 256 characters, but I figured that was probably more than enough in practice. Also, the search starts from the expected character-position and if there're multiple best-matches then it will choose the nearest one.
If you want to be extreme you could e.g.
(setq swank-backend::*source-snippet-size* most-positive-fixnum)
That way the "snippet" would be the complete source code from the beginning of the definition until the end of the file.
More ideas would be welcome. But hashing seems more sensitive to changes in the sought-after definition than I'd like.
For now I'm suspecting that any problems you're seeing are due to bugs rather than limitations of the snippet-based algorithm.
-Luke
Luke Gorrie replied:
I'm thinking of robustness in the opposite sense: if I'm looking up the definition of FOO, but FOO has been modified, then a hash won't find it but a best-prefix-match search quite possibly will. Looking for definitions that have been modified since compilation is fairly common for me I think.
Yes, If the definition has been recompiled, and the preceeding part of the buffer has been modified, we have the wrong buffer position. This is where the ZMACS (ZWEI) buffer sectionization was a winner. The question is how to limit the best-prefix-match search so that alternative versions can be distinguished, but modifications can be made to a definition and still be found.
Does the existing best-prefix-match search distinguish between versions of the definition that are prefixed by reader conditionals that fail for the current Lisp? This is probably the situation that annoys me the most: finding a definition that is impossible for the current Lisp.
More ideas would be welcome. But hashing seems more sensitive to changes in the sought-after definition than I'd like.
I agree, unless there is a way to "mark" the buffer position of a recompiled definition in some manner that is insensitive to insertions and/or deletions in the preceeding part of the buffer.
Luke Gorrie luke@bluetail.com writes:
This would be good. Right now I don't know of the right mechanism by which to do it. Anyone have ideas?
The code below works in Emacs but I was unable to get it to work in XEmacs. Evaluating reader conditionals doesn't work so well if the file isn't written for the connected Lisp, e.g. the wrong expressions will be highlighted in CMUCL sources files, if you are connected to ACL.
(defvar slime-highlight-suppressed-forms t "*If true then highlight reader conditionalized forms where the test evaluates to false.")
(defun slime-search-suppressed-forms (limit) "Find reader conditionalized forms where the test is false." (when (and slime-highlight-suppressed-forms (slime-connected-p) (re-search-forward "#[-+]" limit t)) (ignore-errors (let* ((char (char-before)) (e (read (current-buffer))) (val (slime-eval-feature-conditional e))) (when (<= (point) limit) (if (or (and (eq char ?+) (not val)) (and (eq char ?-) val)) (let ((start (point))) (forward-sexp) (assert (<= (point) limit)) (let ((md (match-data))) (fill md nil) (setf (first md) start) (setf (second md) (point)) (set-match-data md) t)) (slime-search-suppressed-forms limit)))))))
(defun slime-activate-font-lock-magic () (font-lock-add-keywords 'lisp-mode '((slime-search-suppressed-forms 0 font-lock-comment-face t))))
Helmut Eller writes:
Luke Gorrie luke@bluetail.com writes:
This would be good. Right now I don't know of the right mechanism by which to do it. Anyone have ideas?
The code below works in Emacs but I was unable to get it to work in XEmacs. Evaluating reader conditionals doesn't work so well if the file isn't written for the connected Lisp, e.g. the wrong expressions will be highlighted in CMUCL sources files, if you are connected to ACL.
(defvar slime-highlight-suppressed-forms t "*If true then highlight reader conditionalized forms where the test evaluates to false.")
(defun slime-search-suppressed-forms (limit) "Find reader conditionalized forms where the test is false." (when (and slime-highlight-suppressed-forms (slime-connected-p) (re-search-forward "#[-+]" limit t))
Actually, # is a non-terminating macro character, and as for all non-terminating macro characters, if the character before # is a constituent character then the # is too.
CL-USER> 'toto#-titi TOTO#-TITI
http://www.lispworks.com/reference/HyperSpec/Body/02_ad.html
Perhaps: - swank get the read-table, - swank tries to extract information from it, (it's not COMMON-LISP), - swank sends some regexps to slime, - slime uses these regexp.
In the mean-time: (re-search-forward "<#[-+]" limit t)
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
Until very recently weeks ago, my main Lisp was cmucl 18e, but I recently spent the $$$ to buy Lispworks for Windows Pro (v4.3.7).
Which Emacs versions?
GNU Emacs 21.2.1 (on OpenBSD v3.2)
How well does SLIME work for you?
Well, it worked flawlessly for me on cmucl, but I have never been able to get it work properly with Lispworks. See below.
What bugs (reproducible or otherwise) or missing features annoy you?
I run Lispworks on WinXP and Emacs on my OpenBSD box. SLIME occassionally provokes an error: The Lispworks debugger says 'Error in thread "control-thread"', "PROCESS-WAIT called when scheduling not allowed".
Note that I run Lispworks on Windows XP and Emacs on my OpenBSD box. I strongly suspect that the problem is related to Lispworks multiprocessing. To start SLIME I defined
(defun init-slime () (setf swank::*loopback-interface* "192.168.2.16") ; Windows XP IP addr (setf swank::*use-dedicated-output-stream* nil) (swank:create-swank-server 4005 swank::*communication-style* #'swank::simple-announce-function t))
which I call to setup the swank server. After that, M-x slime-connect. This will work for a while, but eventually it dies.
I have not researched this extensively, and suspect I'm overlooking something fundamental somewhere, but since you ask, I thought I'd report the problem (hoping for a resolution, of course - my fingers strongly prefer Emacs to the Lispworks IDE for program editing!).
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Not really - I have had no problems with the CVS access.
If you said anything negative above then please say something nice here to make us feel good:
I have found SLIME to be very impressive indeed. Thanks guys!
-Klaus.
On Sun, 20 Jun 2004 18:08:04 +0200, Klaus Harbo klaus@harbo.net said:
Klaus> I run Lispworks on WinXP and Emacs on my OpenBSD box. SLIME Klaus> occassionally provokes an error: The Lispworks debugger says 'Error in Klaus> thread "control-thread"', "PROCESS-WAIT called when scheduling not Klaus> allowed".
Klaus> Note that I run Lispworks on Windows XP and Emacs on my OpenBSD box. Klaus> I strongly suspect that the problem is related to Lispworks Klaus> multiprocessing.
The error means that something is mis-using PROCESS-WAIT, but we need to know more. Next time it happens, please try to get a bug report including a backtrace by using the :bug-form command.
How is Windows XP running on OpenBSD (some kind of emulator or VM)?
__Martin
Martin Simmons martin@xanalys.com writes:
On Sun, 20 Jun 2004 18:08:04 +0200, Klaus Harbo klaus@harbo.net said:
Klaus> I run Lispworks on WinXP and Emacs on my OpenBSD box. SLIME Klaus> occassionally provokes an error: The Lispworks debugger says 'Error in Klaus> thread "control-thread"', "PROCESS-WAIT called when scheduling not Klaus> allowed".
Klaus> Note that I run Lispworks on Windows XP and Emacs on my OpenBSD box. Klaus> I strongly suspect that the problem is related to Lispworks Klaus> multiprocessing.
The error means that something is mis-using PROCESS-WAIT, but we need to know more. Next time it happens, please try to get a bug report including a backtrace by using the :bug-form command.
I will do that - any help would be most welcome.
How is Windows XP running on OpenBSD (some kind of emulator or VM)?
No, they are separate machines - I use M-slime-connect to connect from the OpenBSD box to the XP machine, which is why use
(defun init-slime () (mp:initialize-multiprocessing) (sleep 2) (setf swank::*loopback-interface* "192.168.2.16") (setf swank::*use-dedicated-output-stream* nil) (swank:create-swank-server 4005 swank::*communication-style* #'swank::simple-announce-function t))
to change the address swank listens at from "127.0.0.1" to "192.168.2.16", to enable remote connections. I am not sure this is really the best way to do it, though.
best,
-K.
Klaus Harbo wrote:
Martin Simmons martin@xanalys.com writes:
>On Sun, 20 Jun 2004 18:08:04 +0200, Klaus Harbo klaus@harbo.net said: > >
Klaus> I run Lispworks on WinXP and Emacs on my OpenBSD box. SLIME Klaus> occassionally provokes an error: The Lispworks debugger says 'Error in Klaus> thread "control-thread"', "PROCESS-WAIT called when scheduling not Klaus> allowed".
Klaus> Note that I run Lispworks on Windows XP and Emacs on my OpenBSD box. Klaus> I strongly suspect that the problem is related to Lispworks Klaus> multiprocessing.
The error means that something is mis-using PROCESS-WAIT, but we need to know more. Next time it happens, please try to get a bug report including a backtrace by using the :bug-form command.
I will do that - any help would be most welcome.
I have been seing the same error maybe once a day when using LispWorks Personal 4.3.[67] and various slime versions from cvs over the last month or two. I have not been remote controlling other lisps using slime.
I have mostly been doing CAPI work when this has happened, but since I have done little else than CAPI work with LispWorks in this period this might not be a clue.
Kristian
On Tue, 22 Jun 2004 10:14:31 +0200, =?ISO-8859-1?Q?Kristian_Elof_S=F8rensen?= elof@image.dk said:
Kristian> Klaus Harbo wrote:
Martin Simmons martin@xanalys.com writes:
>> On Sun, 20 Jun 2004 18:08:04 +0200, Klaus Harbo klaus@harbo.net said: >> >>
Klaus> I run Lispworks on WinXP and Emacs on my OpenBSD box. SLIME Klaus> occassionally provokes an error: The Lispworks debugger says 'Error in Klaus> thread "control-thread"', "PROCESS-WAIT called when scheduling not Klaus> allowed".
Klaus> Note that I run Lispworks on Windows XP and Emacs on my OpenBSD box. Klaus> I strongly suspect that the problem is related to Lispworks Klaus> multiprocessing.
The error means that something is mis-using PROCESS-WAIT, but we need to know more. Next time it happens, please try to get a bug report including a backtrace by using the :bug-form command.
I will do that - any help would be most welcome.
Kristian> I have been seing the same error maybe once a day when using LispWorks Kristian> Personal 4.3.[67] and various slime versions from cvs over the last Kristian> month or two. I have not been remote controlling other lisps using slime.
Kristian> I have mostly been doing CAPI work when this has happened, but since I Kristian> have done little else than CAPI work with LispWorks in this period this Kristian> might not be a clue.
The problem might be in SWANK::ENCODE-MESSAGE. I assume that emacs is on the other end of the stream, but if it fails to read fast enough then one of the CL stream functions in SWANK::ENCODE-MESSAGE might block, which will cause the error because this happens inside the WITHOUT-INTERRUPTS.
__Martin
Martin Simmons martin@xanalys.com writes:
The problem might be in SWANK::ENCODE-MESSAGE. I assume that emacs is on the other end of the stream, but if it fails to read fast enough then one of the CL stream functions in SWANK::ENCODE-MESSAGE might block, which will cause the error because this happens inside the WITHOUT-INTERRUPTS.
The intention of WITHOUT-INTERRUPTS is that we don't get a signal half way through send a message to Emacs and then enter the debugger and start a new message. That way we'd garble up the on-the-wire protocol.
However, this is mostly an issue for select()/SERVE-EVENT based communications. In multithreaded (the :SPAWN communication style) it's always the dedicated "control thread" that sends the messages, and if that thread gets a signal and hits the debugger I think you're cactus anyway. So WITHOUT-INTERRUPTS is probably not buying us anything.
The original poster could try hacking swank-lispworks.lisp so that (call-without-interrupts fn) just does (funcall fn) and see if that clears it up. Likewise with the OpenMCL backend.
-Luke
On Tue, 22 Jun 2004 09:01:29 +0200, Klaus Harbo klaus@harbo.net said:
Klaus> Martin Simmons martin@xanalys.com writes:
How is Windows XP running on OpenBSD (some kind of emulator or VM)?
Klaus> No, they are separate machines - I use M-slime-connect to connect from Klaus> the OpenBSD box to the XP machine, which is why use
Klaus> (defun init-slime () Klaus> (mp:initialize-multiprocessing) Klaus> (sleep 2) Klaus> (setf swank::*loopback-interface* "192.168.2.16") Klaus> (setf swank::*use-dedicated-output-stream* nil) Klaus> (swank:create-swank-server 4005 Klaus> swank::*communication-style* Klaus> #'swank::simple-announce-function Klaus> t))
Klaus> to change the address swank listens at from "127.0.0.1" to Klaus> "192.168.2.16", to enable remote connections. I am not sure this is Klaus> really the best way to do it, though.
Oh, I see now. This shouldn't affect the PROCESS-WAIT issue.
__Martin
Luke Gorrie writes:
Which Lisp versions do you use SLIME with?
Lispworks Professional edition, Both Linux and (a colleague) windows. He has considerable less success with it than I do.
Which Emacs versions?
GNU emacs-version's value is "21.3.1", off debian testing.
How well does SLIME work for you?
Very nicely; I'd say it's 90% there. Of course, the last 10% of the features always take 90% of the time.
What bugs (reproducible or otherwise) or missing features annoy you?
Not many left; I think this is better left to bug-specific messages on the list than to a survey.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I'm pretty doing CVS update every couple of days, at the moment. In the long run, yes, # apt-get install slime would be nice. Kevin Rosenberg knows how to coordinate this.
If you said anything negative above then please say something nice here to make us feel good:
Slime is the absolute best and coolest project, run the the most helpful and clueful developers I have ever had the fortune to meet.
It sure wipes the floor with ILISP, at any rate. :-)
Luke Gorrie luke@bluetail.com writes:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
cmu out of cvs, sbcl out of cvs
Which Emacs versions?
emacs out of cvs
How well does SLIME work for you?
I had problems with foreign functions and the :SIGIO and :SPAWN interface on cmucl. Most of the other stuff works well enough for me.
What bugs (reproducible or otherwise) or missing features annoy you?
Window configuration is not always restored in the correct way.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
not especially.
If you said anything negative above then please say something nice here to make us feel good:
Cool software! Immanuel
Questions:
Which Lisp versions do you use SLIME with?
SLIME CVS
Which Emacs versions?
Emacs CVS
How well does SLIME work for you?
Very, very good.
What bugs (reproducible or otherwise) or missing features annoy you?
When some error occurs, SLIME don't enter the debugger mode, it directly shows the Lisp buffer. Strange.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Well. I don't have any trouble with updating my CVS copy myself and I don't use any packaged version of Emacs. But, since almost every Emacs software is available through Debian packages, it will be a good idea to have SLIME packaged.
If you said anything negative above then please say something nice here to make us feel good:
Actually, SLIME is the most advanced Lisp editor I've seen so far. It's so integrated and so intelligent that I can't find anything wrong about it. Even the way it's implemented is great (in both Emacs and Common Lisp sides).
Luke Gorrie wrote:
Questions:
Which Lisp versions do you use SLIME with?
CMUCL 18e+
Which Emacs versions?
GNU Emacs 21.3.1
How well does SLIME work for you?
Very well, all-in-all.
What bugs (reproducible or otherwise) or missing features annoy you?
I've had some occasions when the slime session suddenly ended, usually in the middle of debugging. I don't have enough info to characterize this yet (and I've been off on a Python based firefight for the last 3 weeks so I'm a bit out of date with SLIME in our environment). There are multiple threads in use when this happens -- that may not be relevant.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
RPM, if anything (we use RedHat/Fedora here). But it's not important.
If you said anything negative above then please say something nice here to make us feel good:
I'm a new guy (but an old Lisp hacker) in a much larger group with a large, mature Lisp product. A couple of others have now been SLIMEd and there seems to be wider interest. It's a lot easier to get working than ILISP and seems more stable to me. I expect the number of users here to grow.
Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
LispWorks for Linux.
Which Emacs versions?
Emacs 21.2.
How well does SLIME work for you?
Very well.
What bugs (reproducible or otherwise) or missing features annoy you?
It's not a bug, but I find it a bit annoying that default directory that the REPL buffer uses doesn't work more, er, "the way I want". That is, if I'm working on a directory on some files (perhaps evaling functions in a different buffer), and I then say (load "whatever") in the REPL buffer, it doesn't find that file, because the directory hasn't been updated...
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I use Debian, so Slime packaged for Debian would be nice. :-)
If you said anything negative above then please say something nice here to make us feel good:
I program faster with Slime than without.
Lars Magne Ingebrigtsen larsi@gnus.org writes:
It's not a bug, but I find it a bit annoying that default directory that the REPL buffer uses doesn't work more, er, "the way I want". That is, if I'm working on a directory on some files (perhaps evaling functions in a different buffer), and I then say (load "whatever") in the REPL buffer, it doesn't find that file, because the directory hasn't been updated...
Don't want to `C-c C-l' (slime-load-file) from a lisp buffer instead?
-Luke
Luke Gorrie luke@bluetail.com writes:
Don't want to `C-c C-l' (slime-load-file) from a lisp buffer instead?
Hm. Good point. That does exactly what I want. Never mind. :-)
Lars Magne Ingebrigtsen larsi@gnus.org writes:
Never mind. :-)
But I was actually reminded of one kinda annoying thing with Slime. It happens so rarely that I haven't really looked into whether Slime has a way to deal with it, but anyway: Once in a blue moon while doing something multithreaded and with lots of CAPI windows and stuff, and I accidentally write something that infloops the Lisp process, `C-c C-g' isn't able to do anything useful. This probably isn't Slime's fault, but in these rare instances I'd just like to be able to kill the Lisp process.
So I'd like a command for doing that.
(What I've done when this happens until now is just going to a shell and "kill -9" a likely Lisp process.)
Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
LispWorks Personal 4.3.[67] on Windows XP/Pro and on Linux/x86 cmu18e on Linux/x86 occasionally SBCL 0.8.11 on Linux/x86
Which Emacs versions?
XEmacs 21.4 on Linux/x86 and Windows XP/Pro
How well does SLIME work for you?
I am very happy with the productivity gain and it is a joy to use compared to ilisp and the LispWorks GUI.
What bugs (reproducible or otherwise) or missing features annoy you?
See my recent reply regarding remote controlling LispWorks.
I have had to kill -9 XEmacs a few times after it ceased to respond to mouse or keyboard input. I haven't seen it for the last week or two though. I recall that it usually (always?) happened immediately after hitting tab in the repl while running cmucl18e locally.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
Personally I am happy with cvs access for now. For 1.0 and later versions OpenBSD packages and RPM would be fine.
If you said anything negative above then please say something nice here to make us feel good:
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
[reposting from the *right* account, this time] Luke Gorrie luke@bluetail.com writes:
Which Lisp versions do you use SLIME with?
SBCL cvs
Which Emacs versions?
Emacs 21.3.1
How well does SLIME work for you?
It works very well for me, either with a detached sbcl (most of the time) or with an 'inferior' one.
What bugs (reproducible or otherwise) or missing features annoy you?
I think this is not a bug, but when i was playing with threads, i was periodically confused with slime "polling" messages.
It just seemed to hang with these messages, and from then on, i couldn't use slime, as if it was waiting for something from me that it wouldn't get, cueing all further slime request i did.
I guess this is trivial : i just didn't bother looking further into this at the time because i had (and still have) a lot to learn, i couldn't decide weither i should have RTFM more or not, and restarting slime was not a great inconvenience (not doing anything useful, yet). Maybe there's some slime functions to control this ?
I feel a little more confortable with CL in general now, so i think i'll try to reproduce this and see if it is a bug in slime... or in myself :)
Apart from that, i can't remember having been annoyed by slime in any way. It just works :)
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I'm happy with the cvs head.
If you said anything negative above then please say something nice here to make us feel good:
Well, i lied. It doesn't *just* works : it works *and* it is one of the most helpful tools i used so far.
I started learning cl a few months ago, and i must admit that slime's documentation and code exploration facilities were very helpful.
Great job, really !
Oh, and i like those welcome messages very much :)
Den 18/6-2004, kl. 15.58, skrev Luke Gorrie:
Which Lisp versions do you use SLIME with?
The latest packaged version of OpenMCL: OpenMCL Version (Beta: Darwin) 0.14.2-p1
Which Emacs versions?
A CVS snapshot from a couple of months ago: GNU Emacs 21.3.50.2 (powerpc-apple-darwin7.2.0) of 2004-01-25 on dandytiger.local
How well does SLIME work for you?
I have only begun to scratch the surface of it yet, but it works very well for me. I can see that some of the functionality isn't available in the OpenMCL backend, which might be a problem when/if I get to write anything bigger; especially the WHO-* functions.
What bugs (reproducible or otherwise) or missing features annoy you?
As above, nothing at the moment, but I can see that the missing functions in the OpenMCL backend might be useful in bigger projects.
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
I'm using Darwin Ports as my package manager but CVS is working fine for me, really.
If you said anything negative above then please say something nice here to make us feel good:
Lisp is by far the most efficient and fun programming language I have used and SLIME somehow makes it even more fun. It gives some of the explorability found in Smalltalk environments to command line Lisp implementations.
Regards Jens
On 8779 day of my life Luke Gorrie wrote:
If the ALU can do it then so can we :-). It would be nice to get some feedback to understand which backends are getting the most/least usage and which ones are flaky.
So if you are an active SLIME user and you have a moment then please reply to this mail (send the reply to the list).
Questions:
Which Lisp versions do you use SLIME with?
CMU Common Lisp CVS snapshot 2003-12
Which Emacs versions?
GNU Emacs 21.3.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
How well does SLIME work for you?
Excellent!!!
What bugs (reproducible or otherwise) or missing features annoy you?
If I'll meet bug, I will try to fix it! :)
Is there some packaging system (e.g. Debian) that you would like to see SLIME 1.0 bundled with? If so, do you know how to coordinate this?
If you said anything negative above then please say something nice here to make us feel good:
:))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Which Lisp versions do you use SLIME with?
OpenMCL 0.14.x Allegro 6.2
Which Emacs versions?
GNU Emacs 21.3.50.2 (powerpc-apple-darwin7.0.0)
How well does SLIME work for you?
I'm a fairly casual user at the moment, but I've not had any problems with it on this platform so far (I had some issues on Linux, but I think they were mainly to do with a screwy Emacs installation).
Keep up the good work! Cheers, Ian.
-
Alain.Picard＠memetrics.com -
Alan Ruttenberg -
Andras Simon -
Andreas Fuchs -
Arnaud Diederen -
Brian Downing -
Brian Mastenbrook -
Christophe Rhodes -
Dan Pierson -
David Steuber -
Edi Weitz -
Frederic Brunel -
Glenn Ehrlich -
Helmut Eller -
Ian Phillips -
Immanuel Litzroth -
Ivan Boldyrev -
Jens Bjerrehuus -
Klaus Harbo -
Kristian Elof Sørensen -
Lars Magne Ingebrigtsen -
lawrence mitchell -
Luke Gorrie -
Lynn Quam -
Marco Baringer -
Martin Simmons -
Paolo Amoroso -
Pascal J.Bourguignon -
Pierre-François Gomez -
Raymond Wiker -
Robert Lehr -
Sean O'Rourke -
Steven E. Harris -
szymon -
Thomas F. Burdick -
Zach Beane