Index: slime/ChangeLog diff -u slime/ChangeLog:1.137 slime/ChangeLog:1.142 --- slime/ChangeLog:1.137 Thu Dec 4 16:36:02 2003 +++ slime/ChangeLog Sat Dec 6 16:41:40 2003 @@ -1,3 +1,36 @@ +2003-12-06 Luke Gorrie luke@bluetail.com + + * slime.el (slime-easy-menu): Added menubar support, contributed + by Friedrich Dominicus. + +2003-12-06 Helmut Eller e9626484@stud3.tuwien.ac.at + + * swank-allegro.lisp: New file. + + * swank-loader.lisp (user-init-file): Translate logical + pathnames. Reported by Friedrich Dominicus. + + * swank-sbcl.lisp (handle-notification-condition): Don't ignore + warnings without context. + (compiler-note-location, brief-compiler-message-for-emacs, + compiler-note-location): Handle null context. + (compile-file-for-emacs): Bind *compile-filename* and load the + fasl file only if it exists. + (function-source-location): The name argument is now optional and + should be a symbol. + (find-function-locations): Return errors as a list of one error. + (call-with-debugging-environment): Set *print-level* to 4 and + *print-level* to 10. (Where both nil.) + (source-location-for-emacs): Fall back to the location of the + function, if there is no block-debug-info. + (safe-source-location-for-emacs): Don't catch all conditions; only + errors. + *compile-filename*: New variable + (open-listener): Don't make the socket non-blocking. + + * slime.el (slime-eval/compile-defun-dwim): New command. + Suggested by "jan" janmar@iprimus.com.au. + 2003-12-04 Helmut Eller e9626484@stud3.tuwien.ac.at
* slime.el (slime-debugging-state): Don't set sldb-level after
Luke Gorrie lgorrie@common-lisp.net writes:
+2003-12-06 Helmut Eller e9626484@stud3.tuwien.ac.at
- swank-allegro.lisp: New file.
Hey, cool! How far along is this port? I ask because (as some of you may know) I'm working on a Common Lisp book and one of my big problems is that I need to describe a proper Lisp programming environment but I don't want to be tied to any one implementation or IDE. Over the past few days I was thinking of using emacs + SLIME as one example and maybe the Allegro IDE as an example of a non-emacs environment.
The more implementations SLIME can be used with, the more plausable this becomes. And of course to the extent that SLIME is the best emacs intergation it gets even more plausable. I haven't actually had a chance to play with SLIME yet myself but I've read the backlog of messages on this list and looked at the code some--I'm impressed with the momentum you guys seem to have.
So I guess what I'm saying is, if you keep cranking out cool stuff the way you have over the past couple months I may be able to give you a big fat plug in my book. And that'll be even easier for me to do if you have good integration with Allegro. I'd volunteer to help out with some hacking but I'm already in up to my neck with writing the book.
I do have some contacts over at Franz--Steve Haflich is my technical reviewer--so if there's anything I can do from that perspective to facilitate the Allegro SLIME port, let me know. (Though Steve is also, as I understand it, the author of ELI so there may be limits to how much he or anyone at Franz will care about SLIME.)
-Peter
P.S. Are any of the SLIME hackers in the Bay Area? If so, I'd love to buy somebody dinner in return for getting a sit-down-at-a-computer tour of SLIME. I'm sure I can figure stuff out on my own but having someone who knows what they're doing show me the good bits will probably save me a bunch of time and decrease the chance I'll miss them altogether.
Peter Seibel peter@javamonkey.com writes:
Luke Gorrie lgorrie@common-lisp.net writes:
+2003-12-06 Helmut Eller e9626484@stud3.tuwien.ac.at
- swank-allegro.lisp: New file.
Hey, cool! How far along is this port?
Most of the basic (in Slime terms) functionality is there: evaluating, debugging, compiler condition trapping, definition finding, stream redirection, apropos, and xref lookup. Evaluating is implement in portable CL and works the same in all backends. Stream redirection uses the same gray stream based code as the other non-CMUCL ports. Allegro has a documented debugger interface and I used that where possible (the document is partly out of sync with the implementation). Only backtrace, listing of local variables, and "find frame source location" are implemented. More advanced stuff like stepping, "return from frame" etc are missing in Slime, but Allegro has very neat support for most things and it wouldn't be too hard to add them. Compiler condition trapping was mostly an exercise in reverse engineering; not sure if it works for non toy code. Compiling from buffers is implemented with temporary files. This works good enough for compiler warnings, but isn't much fun in the the debugger. Allegro's xref support is the best of all our backends.
Interrupting doesn't work very well, because Allegro asks which thread should be interrupted. That's quite annoying. In general the port is like the OpenMCL and LispWorks backends: works, but not as nice as for CMUCL.
I'm mostly interested in good CMUCL support and did the port to learn about Allegros xref stuff. (That's an area where CMUCL needs improvement.) I had the code lying around for some days and wasn't sure if I should commit it. More backends means rather boring porting work and fewer features for CMUCL. I committed in the hope that some Allegro user would take it up and maintain it. (Not very likely, given that ELI is the official Allegro interface; but one never knows.)
The more implementations SLIME can be used with, the more plausable this becomes. And of course to the extent that SLIME is the best emacs intergation it gets even more plausable. I haven't actually had a chance to play with SLIME yet myself but I've read the backlog of messages on this list and looked at the code some--I'm impressed with the momentum you guys seem to have.
The project snowballed; that's a good motivator. OTOH, Slime is still relatively young and, like any other piece of software, requires time to evolve. I don't know if Slime is ready for the Real World; probably not yet. We need more experience with non-toy projects and challenging problems, like multi-threading support and remote debugging, are note solved yet.
You will have to try Slime for yourself, to see if does what you need.
So I guess what I'm saying is, if you keep cranking out cool stuff the way you have over the past couple months I may be able to give you a big fat plug in my book. And that'll be even easier for me to do if you have good integration with Allegro. I'd volunteer to help out with some hacking but I'm already in up to my neck with writing the book.
Contributions, be it code, publicity, or feedback, are always welcome.
I do have some contacts over at Franz--Steve Haflich is my technical reviewer--so if there's anything I can do from that perspective to facilitate the Allegro SLIME port, let me know. (Though Steve is also, as I understand it, the author of ELI so there may be limits to how much he or anyone at Franz will care about SLIME.)
There is an almost endless list of things I'd like to know about Allegro internals. E.g., I really wonder how they implement the "compile modified definitions" commands; is it some heuristic or actually some sort of compilation with macro expansion and other complications? Also a way to tell the compiler where the source comes from would be very useful. E.g., we would like to say that a piece of code comes from a particular buffer so that the debugger knows where to find it. Is there some support for this?
P.S. Are any of the SLIME hackers in the Bay Area? If so, I'd love to buy somebody dinner in return for getting a sit-down-at-a-computer tour of SLIME. I'm sure I can figure stuff out on my own but having someone who knows what they're doing show me the good bits will probably save me a bunch of time and decrease the chance I'll miss them altogether.
Perhaps James Bielman? I think most others live in Europe.
Helmut.
-
Helmut Eller -
Luke Gorrie -
Peter Seibel