April 2004 - slime-devel - mailman3.common-lisp.net

[slime-devel] Version checking disabled - be thoughtful
by Luke Gorrie 27 Apr '04

27 Apr '04

Allo allo, The automatic version checking between the client and server (based on ChangeLog date) is now disabled. This is based on the theory that the false alarms happen more often than real problems. Just remember that when you 'cvs update' SLIME you should restart both Emacs and Lisp. Otherwise you might end up running different versions of the Elisp and CL code and have strange problems. Historically the biggest single problem for users has been having version mismatches. There is still some separate code that tries to detect any stale byte-compiled version of the Elisp code, and hopefully that's enough to keep things sailing smoothly. -Luke

1 0

Re: [slime-devel] Some remarks
by Helmut Eller 27 Apr '04

27 Apr '04

Edi Weitz <edi(a)agharta.de> writes: > 1. The function slime-remove-notes is bound to C-c M-c while the > manual says M-c. Should be fixed now. > 2. The shortcut ,change-directory uses a function read-directory-name > which I don't seem to have. I'm using GNU Emacs 21.3. I included definition from CVS Emacs. > 3. Is there a specific reason that RET isn't bound to > newline-and-indent (or something similar) as in ILISP but only to > C-j? This is a somewhat theological question. I think the primary reason is that RMS likes to use C-j, but I assume other people like C-j too. I think it is the official convention for all programming modes. Perhaps there is already some way to customize it. Anyway, newline-and-indent does not quite belong to SLIME, it belongs to lisp-mode. All we can do is to override the binding in the lisp-mode-map. I think a discussion about C-j vs. RET would be more productive on emacs.devel or comp.emacs than here. > 4. Load CL-PPCRE, than invoke slime-apropos-package (a cool function > by the way). Now position the cursor above PPCRE-SYNTAX-ERROR and > invoke slime-edit-definition. I get: > > No matching method for the generic-function #<Standard-Generic-Function PCL:COMPUTE-APPLICABLE-METHODS-USING-CLASSES (1) > {281DF8F1}>, > when called with arguments (#<Closure Over Function "DEFUN %DEFINE-CONDITION" > {4879E009}> > (#<CONDITIONS::CONDITION-CLASS PPCRE-SYNTAX-ERROR > {486B867D}>)). > [Condition of type NO-APPLICABLE-METHOD] > > 5. In the same *SLIME Apropos* buffer position the cursor above > CREATE-SCANNER and invoke slime-edit-definition. Now I get: > > Error in function COMMON-LISP::%%TYPEP: > Unknown type specifier: C::FILE-SOURCE-LOCATION > [Condition of type SIMPLE-ERROR] This is due to differences in CMUCL 18e and the current snapshots. I added some workarounds and CVS SLIME shouldn't break, but cannot cannot find the location in 18e. I guess we need better tests to avoid regressions like this. > 6. I think that slime-interactive-eval is a very useful function and > IMHO the C-c : keybinding should also be available in the Slime > REPL. Yeah, I know that you actually don't need to use the > minibuffer while you're in the REPL but in the long run it'd be > easier for my muscle memory to always be sure that C-c : is there > without thinking... :) That's true. Fixed in CVS. > Thanks to all for this great package! And thank you for the feedback. Helmut.

5 8

[slime-devel] SLIME eval-xxx inconsistencies
by Lynn Quam 27 Apr '04

27 Apr '04

Looking at the code in swank.lisp, I suspect a *PACKAGE* bug in the following: (defslimefun oneway-eval-string (string buffer-package) "Evaluate STRING in BUFFER-PACKAGE, without sending a reply. The debugger hook is inhibited during the evaluation." (let ((*buffer-package* (guess-package-from-string buffer-package)) (*package* *buffer-package*) (*debugger-hook* nil)) (eval (read-form string)))) My guess is that (let* ...) was intended so that *PACKAGE* is bound to the new value of *BUFFER-PACKAGE*.

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 27 Apr '04

27 Apr '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.348 slime/ChangeLog:1.352 --- slime/ChangeLog:1.348 Sun Apr 25 02:44:15 2004 +++ slime/ChangeLog Mon Apr 26 17:59:39 2004 @@ -1,3 +1,35 @@ +2004-04-26 Luke Gorrie <luke(a)bluetail.com> + + * swank.lisp: Move definition of `with-io-redirection' above + `with-connection' to avoid a CLISP error. This is really weird. + (interactive-eval): Bind *package* to *buffer-package*, so that + `C-x C-e' and related commands evaluate in the expected package. + + * slime.el (sldb-insert-frames): Handle empty backtrace (I got one + in CLISP). + + * swank-allegro.lisp (arglist): Return :not-available if arglist + lookup fails with an error. + + * slime.el: Moved snippets of Common Lisp code into swank.lisp + from the thread control panel. (Remember, no CL code in slime.el!) + + * swank-loader.lisp (*lisp-name*): Include a short version number + in the Lisp name to separate FASL files for different + versions. Only implemented for CMUCL and SBCL sofar. + + * swank.lisp (ed-in-emacs): Avoid mutating the argument. + (spawn-repl-thread): Add a new thread for evaluating REPL + expressions. This same thread is used for all REPL + evaluation. This fixes some issues with variables like * and ** + in at least SBCL. + + * nregex.lisp: Typo fix (thanks Barry Fishman). + + * slime.el (slime-events-buffer): Don't use hideshow-mode in + XEmacs for the *slime-events* buffer. It causes obscure problems + for some users. Still used in GNU Emacs. + 2004-04-25 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * swank-backend.lisp (arglist): Return a list or :not-available.

1 0

[slime-devel] SLIME CMUCL restart-frame
by Lynn Quam 26 Apr '04

26 Apr '04

Sorry for the cross-post, but this question is relevent to both the slime-devel and cmucl-imp lists. I used Symbolics Lisp Machines for many years and found it very useful when in the debugger to be able to edit and recompile a function and then restart the call to the function (restart-frame). Is there any chance that SLIME:RESTART-FRAME will be implemented for CMUCL? I guess I do not know the limitations of the CMUCL stack frames and whether this is possible.

2 1

[slime-devel] SLIME eval-xxx inconsistencies
by Lynn Quam 26 Apr '04

26 Apr '04

I noticed that the different eval-xxx commands when executed in a Lisp-mode buffer have different behavior wrt. the treatment of *PACKAGE*. In particular: SLIME-PPRINT-EVAL-LAST-EXPRESSION and SLIME-EVAL-REGION bind *PACKAGE* to SWANK:*BUFFER-PACKAGE*. The other eval-xxx commands do not bind *PACKAGE* and you (apparently) get the value of *PACKAGE* that is bound in slime-repl. It is not clear to me that this difference in behavior is desirable.

2 1

[slime-devel] CLISP SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 26 Apr '04

26 Apr '04

My previous SLIME installation was a CVS install from 4/18. I've just taken the latest CVS install and the CLISP SLIME implementation (under Windows) breaks. Here is the error: COERCE: #<MACRO #<COMPILED-CLOSURE SWANK::DEFSLIMEFUN>> cannot be coerced to type FUNCTION [Condition of type SIMPLE-TYPE-ERROR] Restarts: 0: [ABORT] Abort handling SLIME request. Backtrace: 0: EVAL frame for form (SWANK:CREATE-SWANK-SERVER 4007)

2 1

Re: [slime-devel] Re: ACL SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 26 Apr '04

26 Apr '04

Luke Gorrie <luke(a)bluetail.com> writes: > Bill_Clementson(a)peoplesoft.com writes: > > > My previous SLIME installation was a CVS install from 4/18. I've just taken > > the latest CVS install and the ACL SLIME implementation (under Windows) > > breaks. Here is the error: > > How about if you hack swank-allegro.lisp with this: > > (defimplementation arglist (symbol) > (handler-case (excl:arglist symbol) > (simple-error () :not-available))) Yep, that did it - thanks! - Bill

1 0

[slime-devel] ACL SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 26 Apr '04

26 Apr '04

My previous SLIME installation was a CVS install from 4/18. I've just taken the latest CVS install and the ACL SLIME implementation (under Windows) breaks. Here is the error: EXCL::DEFUN-PROTO-1 is not a function or macro [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to sldb level 1. 1: [ABORT] Abort handling SLIME request. 2: [ABORT] Abort entirely from this process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR @ #x205164f2>) 1: ((FLET SWANK::SWANK-DEBUGGER-HOOK SWANK::DEBUG-IT)) 2: (SWANK::SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR @ #x205164f2> #<Function SWANK-DEBUGGER-HOOK>) 3: (EXCL::INTERNAL-INVOKE-DEBUGGER "Error" #<SIMPLE-ERROR @ #x205164f2> T) 4: (ERROR SIMPLE-ERROR :FORMAT-CONTROL "~s is not a function or macro" :FORMAT-ARGUMENTS (EXCL::DEFUN-PROTO-1)) 5: (EXCL::.ERROR "~s is not a function or macro" EXCL::DEFUN-PROTO-1) 6: (ARGLIST EXCL::DEFUN-PROTO-1) 7: ((METHOD SWANK-BACKEND:ARGLIST (T)) EXCL::DEFUN-PROTO-1) 8: (SWANK::SYMBOL-INDENTATION EXCL::DEFUN-PROTO-1) 9: ((FLET SWANK::UPDATE-INDENTATION/DELTA-FOR-EMACS SWANK::CONSIDER) EXCL::DEFUN-PROTO-1) 10: ((FLET SWANK::UPDATE-INDENTATION/DELTA-FOR-EMACS #:G2216) EXCL::DEFUN-PROTO-1 EXCL::DEFUN-PROTO-1) 11: (MAPHASH #<Closure (FLET SWANK::UPDATE-INDENTATION/DELTA-FOR-EMACS #:G2216) @ #xab2e87a> #<SYMBOL hash-table (sans values) with 5641 entries @ #x2002c5ca>) 12: (SWANK::UPDATE-INDENTATION/DELTA-FOR-EMACS #<EQ hash-table with 45 entries @ #x2049243a> (#<The ACL-SOCKET package> #<The ACLMOP package> #<The COMMON-LISP package> #<The COMMON-LISP-USER package> #<The COMPILER package> #<The CROSS-REFERENCE package> #<The DEBUGGER package> #<The DEFSYSTEM package> #<The EXCL package> #<The EXCL.SCM package> #<The FOREIGN-FUNCTIONS package> #<The G10 package> #<The GARBAGE package> #<The INSPECT package> #<The KEYWORD package> #<The LEP package> #<The LEP-IO package> #<The MULTIPROCESSING package> #<The NET.URI package> #<The NREGEX package> #<The PROFILER package> #<The SWANK package> #<The SWANK-BACKEND package> #<The SWANK-COMPLETION-TEST package> #<The SWANK-IO-PACKAGE package> #<The SWANK-LOADER package> #<The SYSTEM package> #<The TOP-LEVEL package>)) 13: (SWANK::PERFORM-INDENTATION-UPDATE #S(SWANK::CONNECTION :SOCKET-IO #<MULTIVALENT #2=stream socket #3=connected from #1=localhost/4005 to #1#/1622 @ #x204b28fa> :DEDICATED-OUTPUT #4=#<MULTIVALENT #2# #3#connected from #1#/1623 to #1#/1624 @ #x20492cda> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM @ #x204931f2> :USER-OUTPUT #4# :USER-IO #<TWO-WAY-STREAM @ #x204931da> :CONTROL-THREAD #<MULTIPROCESSING:PROCESS control-thread(724)[1] #5=receive @ #x204a480a> :READER-THREAD #<MULTIPROCESSING:PROCESS reader-thread(8e8)[4] waiting for input @ #x204a4782> :REPL-THREAD #<MULTIPROCESSING:PROCESS Anonymous(890)[5] #5# @ #x204a46fa> :READ #<Function READ-FROM-CONTROL-THREAD> :SEND #<Function SEND-TO-CONTROL-THREAD> :SERVE-REQUESTS #<Function SPAWN-THREADS-FOR-CONNECTION> :CLEANUP NIL :INDENTATION-CACHE #<EQ hash-table with 45 entries @ #x2049243a> :INDENTATION-CACHE-PACKAGES NIL) (#<The ACL-SOCKET package> #<The ACLMOP package> #<The COMMON-LISP package> #<The COMMON-LISP-USER package> #<The COMPILER package> #<The CROSS-REFERENCE package> #<The DEBUGGER package> #<The DEFSYSTEM package> #<The EXCL package> #<The EXCL.SCM package> #<The FOREIGN-FUNCTIONS package> #<The G10 package> #<The GARBAGE package> #<The INSPECT package> #<The KEYWORD package> #<The LEP package> #<The LEP-IO package> #<The MULTIPROCESSING package> #<The NET.URI package> #<The NREGEX package> #<The PROFILER package> #<The SWANK package> #<The SWANK-BACKEND package> #<The SWANK-COMPLETION-TEST package> #<The SWANK-IO-PACKAGE package> #<The SWANK-LOADER package> #<The SYSTEM package> #<The TOP-LEVEL package>)) 14: (SWANK::UPDATE-CONNECTION-INDENTATION #S(SWANK::CONNECTION :SOCKET-IO #<MULTIVALENT #2=stream socket #3=connected from #1=localhost/4005 to #1#/1622 @ #x204b28fa> :DEDICATED-OUTPUT #4=#<MULTIVALENT #2# #3#connected from #1#/1623 to #1#/1624 @ #x20492cda> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM @ #x204931f2> :USER-OUTPUT #4# :USER-IO #<TWO-WAY-STREAM @ #x204931da> :CONTROL-THREAD #<MULTIPROCESSING:PROCESS control-thread(724)[1] #5=receive @ #x204a480a> :READER-THREAD #<MULTIPROCESSING:PROCESS reader-thread(8e8)[4] waiting for input @ #x204a4782> :REPL-THREAD #<MULTIPROCESSING:PROCESS Anonymous(890)[5] #5# @ #x204a46fa> :READ #<Function READ-FROM-CONTROL-THREAD> :SEND #<Function SEND-TO-CONTROL-THREAD> :SERVE-REQUESTS #<Function SPAWN-THREADS-FOR-CONNECTION> :CLEANUP NIL :INDENTATION-CACHE #<EQ hash-table with 45 entries @ #x2049243a> :INDENTATION-CACHE-PACKAGES NIL)) 15: (SWANK::SYNC-STATE-TO-EMACS) 16: (SWANK::EVAL-FOR-EMACS (SWANK:BACKTRACE 2 41) NIL 2) 17: (SYSTEM::..RUNTIME-OPERATION . :UNKNOWN-ARGS) 18: (FUNCALL SWANK::EVAL-FOR-EMACS (SWANK:BACKTRACE 2 41) NIL 2) 19: (SYSTEM::..RUNTIME-OPERATION

2 1

[slime-devel] repl-thread
by Luke Gorrie 26 Apr '04

26 Apr '04

Ahoy, I checked in a change so that the REPL has a dedicated thread for evaluating all expressions. Hopefully by reusing the same thread we're less vulnerable to the implementation-specific threading nuances, e.g. now *, +, **, etc are working again in SBCL. It seems to work fine under SBCL and LispWorks. If someone running Franz or OpenMCL could confirm that I didn't break them I'd be much obliged. P.S., I'm finding the multithreading code quite comprehensible with this simple message-passing interface. Nice one Helmut! -Luke

1 0