slime-devel June 2004

slime-devel@common-lisp.net

57 participants
102 discussions

[slime-devel] Patch for startup animation
by Frederic Brunel 16 Jun '04

16 Jun '04

Hi, Here is a tiny patch concerning the startup animation. I've just added a customizable variable instead of having a «simple» variable to be setted. Actually, I tend to use only customizable variables, I think it's a great system. -- Frederic Brunel

2 1

[slime-devel] Patch for recent changes in CVS emacs.
by Lawrence Mitchell 16 Jun '04

16 Jun '04

I wondered today why doing C-u M-x slime wasn't prompting me to create a new inferior-lisp buffer. It turns out that a recentish change to generate-new-buffer-name in CVS emacs meant that rename-buffer wasn't actually renaming the inferior-lisp buffer. This patch fixes things (we generate the buffer-name semi-manually). 2004-06-11 Lawrence Mitchell <wence(a)gmx.li> * slime.el (slime-maybe-rearrange-inferior-lisp): Call `generate-new-buffer-name' manually, rather than relying on the UNIQUE argument to `rename-buffer' to do so. Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.312 diff -u -r1.312 slime.el --- slime.el 10 Jun 2004 17:34:07 -0000 1.312 +++ slime.el 11 Jun 2004 22:16:08 -0000 @@ -1122,7 +1122,7 @@ "Offer to rename *inferior-lisp* so that another can be started." (when (y-or-n-p "Create an additional *inferior-lisp*? ") (with-current-buffer "*inferior-lisp*" - (rename-buffer (buffer-name) t) + (rename-buffer (generate-new-buffer-name (buffer-name))) t))) (defun slime-maybe-start-lisp () -- Lawrence Mitchell <wence(a)gmx.li>

2 1

[slime-devel] Fix for slime-reindent-defun when in repl
by Brian Downing 16 Jun '04

16 Jun '04

Here is a quick fix for slime-reindent-defun when used in the repl input area. As it was, (beginning-of-defun) tended to find the beginning of the repl buffer, which was suboptimal (especially for 20000 line repl buffers! :). There may be a more kosher way of finding out if you're in a repl buffer, but checking for the input mark seems to work. -bcd

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 16 Jun '04

16 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.393 slime/ChangeLog:1.395 --- slime/ChangeLog:1.393 Sat Jun 12 05:30:28 2004 +++ slime/ChangeLog Tue Jun 15 17:13:48 2004 @@ -1,3 +1,14 @@ +2004-06-16 Robert Lehr <bozzio(a)the-lehrs.com> + + * slime.el (slime-backend): This variable can now be set to an + absolute filename. + +2004-06-15 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-compile-file): Just prompt for saving the + current file instead of calling `save-some-buffers'. Based on a + patch from Brian Downing. + 2004-06-12 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * wank-allegro.lisp (format-sldb-condition, condition-references):

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 13 Jun '04

13 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.391 slime/ChangeLog:1.393 --- slime/ChangeLog:1.391 Thu Jun 10 11:08:23 2004 +++ slime/ChangeLog Sat Jun 12 05:30:28 2004 @@ -1,3 +1,13 @@ +2004-06-12 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * wank-allegro.lisp (format-sldb-condition, condition-references): + Add workarounds for buggy no-applicable-method. + + * swank.lisp (parse-symbol, parse-package): Handle reader errors. + + * swank-openmcl.lisp (send, receive): Ensure that messages are + never nil. + 2004-06-10 Christophe Rhodes <csr21(a)cam.ac.uk> * swank-sbcl.lisp (call-with-syntax-hooks): Add hooks to fix

1 0

[slime-devel] Re: [Openmcl-devel] Problems with the SLIME debugger
by Alan Ruttenberg 12 Jun '04

12 Jun '04

I'm having a few problems as well and have been really wanting to sit down and document and try to untangle them. I think a couple of messages to slime-devel got lost in the down time. 1) I get this periodically in the inferior lisp, when running slime in openmcl. > Error in process control-thread(3): Undefined function :DEBUG called with arguments (#<PROCESS control-thread(3) [Active] #x6C76166> 1 ("destructure-case failed: NIL" " [Condition of type SIMPLE-ERROR]") (("ABORT" "Restart dispatch loop.") ("ABORT-BREAK" "#<RESTART ABORT-BREAK #x7FEE06>") ("ABORT" "#<RESTART ABORT #x7FEE2E>")) ((0 "(SWANK::DISPATCH-EVENT #<TCP-STREAM (SOCKET/19) #x6C76EBE>)") (1 "(SWANK::DISPATCH-LOOP #<TCP-STREAM (SOCKET/19) #x6C76EBE> #S(SWANK::CONNECTION :SOCKET-IO #<TCP-STREAM (SOCKET/19) #x6C76EBE> :DEDICATED-OUTPUT #<TCP-STREAM (SOCKET/20) #x6C76756> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM #x6C76366> :USER-OUTPUT #<TCP-STREAM (SOCKET/20) #x6C76756> :USER-IO #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x6C76366>, output #<TCP-STREAM (SOCKET/20) #x6C76756> #x6C76326> :CONTROL-THREAD #<PROCESS control-thread(3) [Active] #x6C76166> :READER-THREAD #<PROCESS reader-thread(4) [Active] #x6C75F66> :REPL-THREAD #<PROCESS repl-thread(5) [Active] #x6C75D6E> :READ #<Compiled-function SWANK::READ-FROM-CONTROL-THREAD #x6C2DCC6> :SEND #<Compiled-function SWANK::SEND-TO-CONTROL-THREAD #x6C2B1BE> :SERVE-REQUESTS #<Compiled-function SWANK::SPAWN-THREADS-FOR-CONNECTION #x6C1FE16> :CLEANUP NIL :INDENTATION-CACHE #<HASH-TABLE :TEST EQ size 60/60 #x6C768E6> :INDENTATION-CACHE-PACKAGES (#<Package \"ASDF1017\"> #<Package \"ASDF945\"> #<Package \"ASDF-INSTALL-CUSTOMIZE\"> #<Package \"ASDF-INSTALL\"> #<Package \"ASDF-INSTALL-SYSTEM\"> #<Package \"ASDF942\"> #<Package \"SWANK-COMPLETION-TEST\"> #<Package \"SWANK-IO-PACKAGE\"> #<Package \"SWANK\"> #<Package \"NREGEX\"> #<Package \"SWANK-BACKEND\"> #<Package \"SWANK-LOADER\"> #<Package \"ASDF\"> #<Package \"CROSS-REFERENCE\"> #<Package \"PPC64\"> #<Package \"PPC\"> #<Package \"PPC32\"> #<Package \"ILISP\"> #<Package \"OPENMCL-MOP\"> #<Package \"GRAY\"> #<Package \"CLOS-BOOT\"> #<Package \"OPENMCL-SOCKET\"> #<Package \"INSPECTOR\"> #<Package \"OS\"> #<Package \"ARCH\"> #<Package \"ANSI-LOOP\"> #<Package \"COMMON-LISP-USER\"> #<Package \"SETF\"> #<Package \"CCL\"> #<Package \"COMMON-LISP\"> #<Package \"KEYWORD\">)))") (2 "(RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE (:LAMBDA 1 :IN %PROCESS-RUN-FUNCTION) #x6C7612E>))") (3 "((:LAMBDA 1 :IN %PROCESS-PRESET-INTERNAL) '(#<COMPILED-LEXICAL-CLOSURE (:LAMBDA 1 :IN %PROCESS-RUN-FUNCTION) #x6C7612E>))") (4 "((:LAMBDA 1 :IN THREAD-MAKE-STARTUP-FUNCTION))"))) . > While executing: FUNCALL It's usually impossible to recover once this starts happening. It's as if the :emacs-rex if being left off the car of all the messages. 2) In openmcl. Traced send and receive. These receives don't seem to be initiated by a send... They happen now and then when loading a system that takes a while to load (probably other times too). Ignoring them prevents my lisp from being hosed. If you already know what the problem is, send me a note, otherwise I will continue looking when I have a chance. Calling (SWANK-BACKEND:RECEIVE) SWANK-BACKEND:RECEIVE returned NIL DISPATCHING: NIL IGNORING UNKNOWN EVENT: NIL Calling (SWANK-BACKEND:RECEIVE) SWANK-BACKEND:RECEIVE returned NIL DISPATCHING: NIL IGNORING UNKNOWN EVENT: NIL Calling (SWANK-BACKEND:RECEIVE) SWANK-BACKEND:RECEIVE returned NIL DISPATCHING: NIL IGNORING UNKNOWN EVENT: NIL 3) CCL::%%FRAME-BACKLINK periodically hard crashes the lisp. I'll send the kernel debugger backtrace next time it happens 4) Typically after a very large amount of output to the repl, slime space starts infinite looping in emacs and I have to interrupt it with control-g (after I type each space). Needless to say, I restart as soon as I can. So things are a bit of a mess and I would spend some time looking into it but have been flat out recently. But maybe this will give someone a hint about what is going on. And I should start having some more time in a couple of weeks. -Alan On Jun 11, 2004, at 4:25 PM, Gary Byers wrote: > > > On Fri, 11 Jun 2004, Christian Hofer wrote: > >> Hi, >> >> when I'm working with OpenMCL on Darwin, and SLIME, I just cannot >> figure out, how to use the debugger correctly. I just downloaded the >> newest OpenMCL release and the newest SLIME tarball, and the behaviour >> is getting even worse. >> >> E.g. when I try to evaluate the variable test in the listener, I get - >> as expected - the following error: >> >> Unbound variable: TEST >> [Condition of type UNBOUND-VARIABLE] >> >> Restarts: >> 0: [CONTINUE] Retry getting the value of TEST. >> 1: [USE-VALUE] Specify a value of TEST to use this time. >> 2: [STORE-VALUE] Specify a value of TEST to store and use. >> 3: [ABORT] Abort handling SLIME request. >> 4: [ABORT-BREAK] #<RESTART ABORT-BREAK #x1692E06> >> 5: [ABORT] #<RESTART ABORT #x1692E2E> >> >> Now, none of the aborts seem to work properly. When I chose 3, I get >> the following error: >> >> Undefined function CCL::SIMPLE-RESTART called with arguments () . >> [Condition of type CCL::UNDEFINED-FUNCTION-CALL] >> >> When I try, on the other hand option 4 or 5, the listener seems to >> loose contact to OpenMCL. >> >> SBCL on FreeBSD behaves completely different and I did not encounter >> any similiar problems. >> >> Thus I wanted to know, if the lost connection is expected behaviour. >> And on the other hand, if I did s.th. wrong during installation or if >> simple-restart does not work at the moment? > > CCL::SIMPLE-RESTART isn't a function (it -is- the name of a type of > restart), so if something's calling it as a function it's not too > surprising that it's undefined. If something's trying to call it as a > function, there would probably have been undefined-function warnings > during compilation; you might want to look at the *INFERIOR-LISP* > buffer to see if it shows any evidence of this. > > I tried to reproduce this with the current SLIME from CVS; I found that > restarts 0-2 worked as expected in this case; 3-5 seemed to all lose > the connection, with messages in the *INFERIOR-LISP* buffer to the > effect that some socket used to communicate between Emacs and the lisp > had received an unexpected EOF. The thread that's running the SLIME > REPL seems to be in: > > (defimplementation receive () > (let* ((mbox (mailbox ccl:*current-process*)) > (mutex (mailbox.mutex mbox))) > (ccl:wait-on-semaphore (mailbox.semaphore mbox)) > (ccl:with-lock-grabbed (mutex) > (pop (mailbox.queue mbox))))) > > waiting on a semaphore that'll probably never be signalled (I don't > know much about the protocol SLIME/SWANK use, but I'd guess that > the unexpected EOF has something to do with this ... > > Sorry that's not more helpful. > >> >> Thanks, >> Chris >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel(a)clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel(a)clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 11 Jun '04

11 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.390 slime/ChangeLog:1.391 --- slime/ChangeLog:1.390 Wed Jun 9 21:40:28 2004 +++ slime/ChangeLog Thu Jun 10 11:08:23 2004 @@ -1,3 +1,48 @@ +2004-06-10 Christophe Rhodes <csr21(a)cam.ac.uk> + + * swank-sbcl.lisp (call-with-syntax-hooks): Add hooks to fix + "SB!"-style package names. + (shebang-readtable): Return a readtable with readermacros needed + to parse SBCL sources. + + * swank.lisp (with-buffer-syntax): New macro. This should be used + for code which needs to READ code from Emacs buffers. *package* + and *readtable* are bound suitable values. + (to-string, format-values-for-echo-area, interactive-eval) + (eval-region, interactive-eval-region, re-evaluate-defvar) + (swank-pprint, pprint-eval, listener-eval) + (compile-string-for-emacs, disassemble-symbol, describe-to-string) + (describe-symbol, describe-function) + (describe-definition-for-emacs) + (documentation-symbol, init-inspector, inspect-nth-part) + (inspector-pop, inspector-next, describe-inspectee) + (inspect-current-condition): Use it. + +2004-06-10 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-loader.lisp: Initialize swank::*readtable-alist* for SBCL. + + * swank-backend.lisp (default-directory, call-with-syntax-hooks): + New functions. + + * swank.lisp (*readtable-alist*): New configurable. The keys are + package name and the values readtables. The readtable will be + used to READ code originating from Emacs buffers in the associated + slime-buffer-package. + (drop-thread): Simplified. + (*buffer-readtable*): New variable. + (parse-package): New function. + (parse-string): Renamed from symbol-from-string. Make it case + insensitive. + (eval-for-emacs): Initialize the *buffer-readtable*. + (symbol-indentation): Don't consider symbols in the CL package. + Emacs already knows how to indent them. + (compile-file-if-needed): Used for REPL shortcut + 'compile-and-load'. + + * slime.el (pwd): Re-add REPL shortcut. + (slime-repl-push-directory, slime-repl-compile-and-load): Simplified. + 2004-06-10 Luke Gorrie <luke(a)bluetail.com> * slime.el (sldb-step): Command is disabled because the function

1 0

[slime-devel] M-x slime-ensure-typeout-frame ?
by Sung-youn Kim 10 Jun '04

10 Jun '04

Hmm.. After M-x slime-ensure-typeout-frame, the command related messages are still directed to minibuffer with typeout frame open and idle. I use cmucl 18e and emacs21 on Debian sarge. -- _________________ Sung-youn Kim Political Science Dept. Stony Brook University (SUNY at Stony Brook) Office : 631-632-7664 Web : http://www.ic.sunysb.edu/stu/sungyoki

1 0

[slime-devel] Re: sbcl sources support
by Helmut Eller 10 Jun '04

10 Jun '04

I integrated your patch in the CVS version. It does basically the same as your patch, but the functionality is a bit better separated between front-end and backend. As a side-effect, *readtable-alist* can now be used to associate readtables with packages. Helmut. Christophe Rhodes <csr21(a)cam.ac.uk> writes: > Helmut Eller <e9626484(a)stud3.tuwien.ac.at> writes: > >> I think it's rather unlikely, that someone works on SBCL and another >> project with conflicting reader macros. > > Relatively unlikely, I grant you -- but not beyond the bounds of > possibility. (A number of projects I work on have their own > readtables, and it would be awkward if a minor bugfix to sbcl in the > interim caused odd things to happen). > >> What do you think about a command like: >> >> (defun set-sbcl-syntax () >> (setf *readtable* (sb-introspect:sbcl-readtable)) >> (sb-introspect:advice-find-package)) > > What I would like to happen is that, when a user does e.g. M-. to find > the source of an sbcl function, that the normal slime commands work as > expected without user intervention. The precise mechanism to achieve > this doesn't worry me so much (though I think global advising of > find-package, and global setting of *readtable*, is a lot uglier than > advice in the dynamic contour of slime evaluation -- this is in fact a > defect of my patch, which handles slightly too many > BOOTSTRAP-PACKAGE-NOT-FOUND conditions: during evaluation as well as > compilation.) > > The problem from my point of view with the requirement of an explicit > command is that it only marginally lowers the barrier of entry. If > you want a typical use case, I can imagine someone wishing to find the > location of the error emitted from defconstant when a constant is > being redefined, and redefine the checking function; notwithstanding > the fact that there may be better ways of achieving the ultimate aim, > I think this kind of interaction should be supported. I don't think > that this ability to treat the system as incrementally modifiable is > assisted very much (over the current situation) by having to run an > explicit command... > > Cheers, > > Christophe > > (Lest my tone be too negative: for the record I really appreciate the > work you, Luke and others have done. The fact that I'm even > contemplating incremental modification of sbcl via slime should be > testimony to that! :-)

1 0

[slime-devel] abcl
by Andras Simon 10 Jun '04

10 Jun '04

While the list was sleeping, I adapted Helmut's allegro backend for abcl. It is not quite ready for prime time, but is somewhat usable. Actually, it's already at version 2 (or should I say 0.02): originally, I had to patch swank.lisp, but thanks to Peter Graves, who tracked down pretty printing bugs in abcl, this is no longer necessary. Nevertheless, it's probably too early to include it in the official slime sources, but I thought I'd let you know about it anyway. It's temporarily available here: http://www.math.bme.hu/~asimon/slime-abcl.tgz The tar file includes swank-loader.lisp (so back up yours if you untar it in the slime directory) and swank-abcl.lisp. It doesn't work with the latest abcl release, only with the cvs version. (In fact, it's probably better to wait a few hours until anon cvs at sourceforge picks up the latest sources.) Andras

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel June 2004