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

[slime-devel] linefeed in string frame arguments in sldb
by Alan Ruttenberg 13 May '04

13 May '04

If backtrace (in openmcl, at least), if you have a string argument that has a linefeed then then the linefeed messes up the display of the backtrace. Ideally I think it would be nice to replace the linefeeds with a special glyph (which I don't know how to do), but failing that I'm inclined to replace them with the string <<lf>> or \n or somesuch. Is anyone else bothered by this problem and/or have a better solution? -Alan

2 1

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

13 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.373 slime/ChangeLog:1.375 --- slime/ChangeLog:1.373 Tue May 11 17:02:28 2004 +++ slime/ChangeLog Thu May 13 00:47:51 2004 @@ -1,3 +1,36 @@ +2004-05-12 Alan Ruttenberg <alanr-l(a)mumble.net> + * swank-openmcl.lisp: Fixes to support openmcl 0.14.2 changes in + backtrace protocol, from Gary Byers. + - Replace string "tcr" to "context". + - Change the call to %current-tcr in map-backtrace to get-backtrace-context, + defined so as to be back compatible with 0.14.1. + - Change the call to %catch-top to explicitly use %current-tcr + instead of the passed in tcr-which-is-now-called-context. + + Users of map-backtrace (outside of slime code) note: The tcr position in the + function call is now occupied by the backtrace "context" which is always nil. + If you really need the tcr then you need to call %current-tcr yourself now. + + Gary comments: The part that's a little hard to document about + the new "context" stuff - used to walk the stacks of thread A from + thread B - is that thread B has to be aware of when a context + becomes invalid (a context describing part of thread A's stack is + valid while thread A's sitting in a break loop and becomes invalid + as soon as it exits that break loop.) A thread sort of announces + when a context becomes valid and when it becomes invalid; whether + and how SWANK could hook into that isn't yet clear. + + * swank-openmcl.lisp: Minor changes to backtrace display: Anonymous + functions names in function position surrounded by #<>. Use prin1 instead of + princ to print function arguments (so strings have "s around them). + prefix symbol and list arguments by "'" to make them more look like a + valid function call. Let me know if you don't like this... + +2004-05-12 Luke Gorrie <luke(a)bluetail.com> + + * slime.el: Fixes for outline-mode in *slime-events* from Edi + Weitz. + 2004-05-11 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el (slime-events-buffer): Disable outline-mode by default. @@ -1665,7 +1698,7 @@ * slime.el, swank-backend.lisp, swank-cmucl.lisp, swank-sbcl.lisp, swank.lisp: Profiler support. -2004-01-23 Alan Ruttenberg <alanralanr(a)comcast.net> +2004-01-23 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl.lisp: Bind ccl::*signal-printing-errors* to nil inside debugger so that error while printing error take us down. @@ -1784,7 +1817,7 @@ "Eval Region", "Scratch Buffer", "Apropos Package..." Added some bold to default SLDB faces. -2004-01-19 Alan Ruttenberg <alanralanr(a)comcast.net> +2004-01-19 Alan Ruttenberg <alanr-l(a)mumble.net> *swank-openmcl.lisp in frame-catch-tags, ppc32::catch-frame.catch-tag-cell -> 0, ppc32::catch-frame.csp-cell -> 3. FIXME when this code is more stable in openMCL. @@ -1854,7 +1887,7 @@ a buffer local variable. Reported by Janis Dzerins. (slime-batch-test): Wait until the connection is ready. -2004-01-18 Alan Ruttenberg <alanralanr(a)comcast.net> +2004-01-18 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl: Implement frame-catch-tags. Added debugger functions sldb-restart-frame, sldb-return-from-frame. Should probably be added to backend.lisp @@ -2390,11 +2423,11 @@ (slime-open-inspector): Minor indentation fixes. (slime-net-output-funcall): Removed. Was unused. -2003-12-19 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-19 Alan Ruttenberg <alanr-l(a)mumble.net> * slime.el 1.157 fix bug in sldb-princ-locals I introduced when adding fonts to sldb -2003-12-19 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-19 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl.lisp 1.42 in request-loop register output stream to be periodically slushed per Gary Byer's email. * slime.el 1.156 @@ -2406,12 +2439,12 @@ * null-swank-impl.lisp: Deleted this old file. See swank-backend.lisp instead. -2003-12-18 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-18 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl.lisp 1.41 in openmcl (break) now goes into slime debugger. (setq swank:*break-in-sldb* nil) to disable that. -2003-12-17 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-17 Alan Ruttenberg <alanr-l(a)mumble.net> * slime.el 1.155 Allow font choices for backtrack. Add group for customizing them: sldb. Whole thing is enabled with sldb-enable-styled-backtrace which is off by default, for now. @@ -2426,7 +2459,7 @@ '(sldb-selected-frame-line-face ((t (:foreground "brown" :weight bold :height 1.2)))) '(sldb-topline-face ((t (:foreground "brown" :weight bold :height 1.2)))) -2003-12-17 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-17 Alan Ruttenberg <alanr-l(a)mumble.net> * slime.el 1.154 Allow some face choices in the inspector. Try '(slime-inspector-label-face ((t (:weight bold)))) @@ -2434,7 +2467,7 @@ '(slime-inspector-type-face ((t (:foreground "DarkRed" :weight bold)))) You can also set slime-inspector-value-face -2003-12-17 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-17 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl.lisp 1.40 Fix an error with frame-source-location-for-emacs when the @@ -2550,7 +2583,7 @@ (slime-popup-thread-control-panel): When true, automatically popup the thread-control buffer when a new thread suspends. -2003-12-14 Alan Ruttenberg <alanralanr(a)comcast.net> +2003-12-14 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl.lisp (eval-in-frame, inspect-object and friends): Most of this is copied from swank-cmucl. The parts between &&&&&

1 0

[slime-devel] checked in changes to swank-openmcl.lisp to support openmcl 0.14.2
by Alan Ruttenberg 13 May '04

13 May '04

Check the change log for details. Users of map-backtrace (outside of slime code) note: The tcr position in the function call is now occupied by the backtrace "context" which is always nil in 0.14.2. If you really need the tcr then you need to call %current-tcr yourself now. Tested in 0.14.1 and 0.14.2. Let me know if you have any trouble with it. -Alan

1 0

[slime-devel] OpenMCL 0.14.2 SWANK brokenness...
by Brian Downing 13 May '04

13 May '04

When trying to start SLIME (CVS as of five minutes ago) on OpenMCL 0.14.2: Welcome to OpenMCL Version (Beta: Darwin) 0.14.2! ? ;; Compiling /Users/bdowning/.emacs.d/slime/swank-backend.lisp... ;; Compiling /Users/bdowning/.emacs.d/slime/nregex.lisp... ;; Compiling /Users/bdowning/.emacs.d/slime/swank-openmcl.lisp... ;Compiler warnings for "/Users/bdowning/.emacs.d/slime/swank-openmcl.lisp" : ; Unused lexical variable FRAME-NUMBER, in an anonymous lambda form inside (COMPUTE-BACKTRACE (T T)). ; Unused lexical variable DSPEC, in (LIST-CALLERS (T)). ;; Compiling /Users/bdowning/.emacs.d/slime/swank-gray.lisp... ;; Compiling /Users/bdowning/.emacs.d/slime/swank.lisp... ; Warning: These Swank interfaces are unimplemented: ; (ADD-FD-HANDLER ADD-SIGIO-HANDLER LIST-CALLEES MACROEXPAND-ALL PROFILE PROFILE-PACKAGE PROFILE-REPORT PROFILE-RESET PROFILED-FUNCTIONS REMOVE-FD-HANDLERS REMOVE-SIGIO-HANDLERS UNPROFILE WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES) ; While executing: SWANK-BACKEND::WARN-UNIMPLEMENTED-INTERFACES #P"/Users/bdowning/.emacs.d/slime/swank-loader.lisp" ? > Error in process listener(1): value #<CCL::LISTENER-SOCKET #x64BC39E> is not of the expected type INTEGER. > While executing: CCL::C_GETSOCKNAME > Type :POP to abort. Type :? for other options. 1 > -bcd

4 3

[slime-devel] cannot start slime
by Henrique Rodrigues 12 May '04

12 May '04

good evening, it's my first time using slime, but i can't seem to make it start. after configuring my .emacs, i try to run the command "slime", but after displaying the message "Swank started at port: 1038" it breaks. the backtrace shows: Debugger entered--Lisp error: (wrong-type-argument stringp nil) looking-at(nil) hs-hide-block-at-point() slime-log-event((:open-dedicated-output-stream 1040)) slime-dispatch-event((:open-dedicated-output-stream 1040) #<process SLIME Lisp>) slime-process-available-input() slime-net-filter(#<process SLIME Lisp> "^@^@%(:open-dedicated-output-stream 1040)\n") i don't really understand what's going on, but shouldn't it try to open the stream on port 1038, where swank is listening? what can i do to fix this? thank you, henrique rodrigues -- Henrique Miguel Teodoro Rodrigues http://www.rnl.ist.utl.pt/~hmtr Engenharia Informatica e de Computadores - Instituto Superior Tecnico

7 18

Re: [slime-devel] cmucl/multiprocessing
by Helmut Eller 12 May '04

12 May '04

Gabor Melis <gabor.melis(a)essnet.se> writes: > Hmm. Setting swank:*communication-style* to :spawn seems to work. In this configuration, the debugger is executed in the correct thread, and the frame-pointer should point to the correct stack. But be warned, CMUCL's multithreading is non-preemptive, and interrupting will not work if a thread is busy executing an endless loop. > I thought > that slime-multiprocessing implies :spawn but looking at the code I can see > that's not the case. That's true. Not sure if it should, because that would override any setting in the .swank.lisp file. What do you think?

2 1

[slime-devel] cmucl/multiprocessing
by Gabor Melis 12 May '04

12 May '04

I am using aserve under cmucl and call the INIT-ASERVE-CMU function as the README suggests (otherwise latency is unbearable). INIT-ASERVE-CMU looks like this: #'(LAMBDA () (BLOCK INIT-ASERVE-CMU (UNLESS (FIND-IF #'(LAMBDA (ASERVE-SYSTEM::PROC) (STRING= (MULTIPROCESSING:PROCESS-NAME ASERVE-SYSTEM::PROC) "Top Level Loop")) (MULTIPROCESSING:ALL-PROCESSES)) (MULTIPROCESSING::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS)))) After running it slime-space no longer shows the arglist. This is slime HEAD. Tried it under sbcl-mt. Naturally, since init-aserve-cmu need not be run, everything works fine. I may even use it but compilation notes do not work and I'd miss them very much. Gabor

3 8

[slime-devel] How to start Slime/Swank?
by Ian Phillips 12 May '04

12 May '04

Hi, stupid newbie question here: I'm having problems starting swank (and, by implication, Slime as well). When I start emacs and do an "M-x slime" I get this error: ; compiling file "/usr/share/common-lisp/source/swank/swank-source-path-parser.lisp" (written 09 MAY 2004 09:42:59 PM): debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread 26812: The name :SWANK-BACKEND does not designate any package. You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. I'm running emacs 21.3.50, and slime HEAD from CVS earlier today. I'm trying to use SBCL 0.8.10 as the backend. Looking into it a little further, I see that if I just run sbcl from a shell and the do (require 'swank) or (asdf:operate 'asdf:load-op :swank) then I get the same result. I thought at first that thjis was telling me that I needed to specify SBCL as a backend somewhere. I'm not too sure now though, I think that what is actually happening is that the swank files (in /usr/share/common-lisp/sources/swank) are getting loaded in the wrong order and that something is doing an (in-package :swank-backend) before the defpackage call has been loaded and run. So, am I right? And if so, how can I make sure that the files are loaded in the correct sequence? Another thought is: maybe there's a way to precompile all of this stuff (into a FASL file I think) and then it should "just work" ? Any help would be gratly appreciated at this point. Cheers, Ian. -- #ifndef __COMMON_SENSE__ | Ian Phillips #include <std_disclaimer> | TIBCO Software Inc. #endif | www.tibco.com

2 2

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 12 May '04

12 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.372 slime/ChangeLog:1.373 --- slime/ChangeLog:1.372 Mon May 10 09:54:00 2004 +++ slime/ChangeLog Tue May 11 17:02:28 2004 @@ -1,3 +1,14 @@ +2004-05-11 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-events-buffer): Disable outline-mode by default. + (slime-inhibit-ouline-mode-in-events-buffer): New variable. + (slime-expected-failures): Reduce the number for SBCL. + + * swank-sbcl.lisp (resolve-note-location): Resolve the location if + we are called by swank-compile-string. The pathname argument is + never :stream in SBCL, so the method written for CMUCL was never + called. + 2004-05-10 Luke Gorrie <luke(a)bluetail.com> * swank.lisp (from-string): Bind *READ-SUPPRESS* to NIL.

1 0

[slime-devel] Slime with SBCL on OS X is broken
by Thomas F. Burdick 11 May '04

11 May '04

Got my Mac back from being repaired yesterday, and tried to update my SLIME. Compiling today's CVS with sbcl-0.8.8 dies when it catches a SIGBUS when compiling swank.lisp. I'll try cvs time-travel between April 9 and today sometime over the next week, if no one gets to it first, but if anyone has time, this is a heads-up.

2 3

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

11 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.371 slime/ChangeLog:1.372 --- slime/ChangeLog:1.371 Sat May 8 15:01:05 2004 +++ slime/ChangeLog Mon May 10 09:54:00 2004 @@ -1,3 +1,20 @@ +2004-05-10 Luke Gorrie <luke(a)bluetail.com> + + * swank.lisp (from-string): Bind *READ-SUPPRESS* to NIL. + (swank-compiler): Bind a restart to abort compilation but still + report the compiler messages already trapped. + (string-to-package-designator): Function that uses READ to + case-convert package names. + (apropos-list-for-emacs): Use it. + + * slime.el (slime-eval-with-transcript): Don't print the "=>" + prefix in messages showing evaluation results. It mucks up + alignment in multi-line messages. + (sldb-eval-in-frame): Don't print "==>" prefix on evaluation + results, for the same reason. + (slime-show-source-location): Move the point to the source + location in addition to highlighting the matching parens. + 2004-05-08 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * swank-cmucl.lisp (find-definitions): Add support for variables

1 0

[slime-devel] Multiple connections to a single Lisp image
by Luke Gorrie 10 May '04

10 May '04

Ahoy, Currently it is possible for a Lisp image to support multiple SLIME connections. Are we using this functionality, and if so how? Originally it was used to support a connection-per-thread model, but that has been replaced and now all threads share a single multiplexed connection. I was thinking of deleting the 'connection' record and moving its fields into global variables. Thoughts? -Luke

2 1

[slime-devel] Random notes, *read-suppress*
by Luke Gorrie 10 May '04

10 May '04

Ahoy, On the weekend I tried actually /using/ SLIME. It's not bad but, gee wiz, it isn't hard to run into trouble :-). A couple of notes. If you have your own reader-macros then make sure they respect *READ-SUPPRESS*. We set this while searching for source locations, and it took me a while to realise that some of my reader-macros were broken: they couldn't handle their recursive READs returning NIL. This is confusing to debug if you didn't know that *READ-SUPPRESS* exists, so read the Hyperspec if in doubt. I generally had some trouble working with majorly broken packages that want to bring up the debugger lots of times while failing to compile. It helped to add a new ABORT restart that aborts compilation but still presents the compiler messages that have been gathered so far. I also hit a bug in the May snapshot of CMUCL that is triggered by my "cache source files as strings for location-finding" change: reader-errors coming from non-file streams hit a type error before the real error is reported. Raymond Toy says it should be fixed in 19A, and meanwhile here is a "hotfix" (might only apply to May snapshot): ;;; Avoid calling FILE-LENGTH on STREAM. It might not be a file stream. (in-package :c) (defun careful-read (stream eof pos) (handler-case (let ((*features* (backend-features *target-backend*))) (read stream nil eof)) (error (condition) (if (null (peek-char nil stream nil)) (unexpected-eof-error stream pos condition) (progn (normal-read-error stream pos condition) (ignore-error-form stream pos))) '(cerror "Skip this form." "Attempt to load a file having a compile-time read error.")))) (defun unexpected-eof-error (stream pos condition) (declare (type stream stream) (type unsigned-byte pos)) (let ((eof-pos (file-position stream)) (res nil)) (file-position stream pos) (loop (let ((line (read-line stream nil nil))) (unless line (return)) (when (or (find #\" line) (find #\( line)) (setq res line) (return)) (unless (or res (zerop (length line))) (setq res line)))) (compiler-error-message "Read error in form starting at ~D:~%~@[ \"~A\"~%~]~A" pos res condition) (file-position stream eof-pos) (undefined-value)))

1 0

[slime-devel] SLIME not running on FreeBSD 5.2.1 wiht SBCL 0.8.5
by Christian Hofer 10 May '04

10 May '04

Hi, when I try to start SLIME within Emacs (GNU, Version 21.3.1.) compilation fails with the error: ; compiling file "/home/chr/slime/swank-sbcl.lisp" (written 01 MAY 2004 01:19:50 AM): debugger invoked on condition of type SIMPLE-ERROR in thread 10047: Don't know how to load SB-BSD-SOCKETS I just fetched SLIME fresh from cvs. Does anybody know what went wrong? Thanks for your help, Chris

2 2

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 09 May '04

09 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.370 slime/ChangeLog:1.371 --- slime/ChangeLog:1.370 Fri May 7 17:12:17 2004 +++ slime/ChangeLog Sat May 8 15:01:05 2004 @@ -1,3 +1,8 @@ +2004-05-08 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-cmucl.lisp (find-definitions): Add support for variables + and constants. + 2004-05-07 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * swank-clisp.lisp (compiler-note-location): Use make-location to

1 0

[slime-devel] Re: charset problem with clisp
by Alex Mizrahi 08 May '04

08 May '04

hello AM> as i understand this is the length of message as char.. AM> looks like it's not good to encode bytes as chars - it's a problem AM> with some charsets, representing it in hex or base64 can be much AM> more portable.. i've changed message length encoding/decoding functions to use 8-char hex value instead of that 3-byte binary value, and it fixed the problem - so i can now move from bare console to slime.. with best regards, Alex 'killer_storm' Mizrahi.

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 08 May '04

08 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.369 slime/ChangeLog:1.370 --- slime/ChangeLog:1.369 Thu May 6 15:55:21 2004 +++ slime/ChangeLog Fri May 7 17:12:17 2004 @@ -1,3 +1,16 @@ +2004-05-07 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-clisp.lisp (compiler-note-location): Use make-location to + instead of `(:location ...). This initializes the new hint slot + automatically. + +2004-05-07 Barry Fishman <barry_fishman(a)att.net> + + * swank.lisp (prin1-to-string-for-emacs, arglist-to-string): CVS + CLISP prints NIL as |COMMON-LISP|::|NIL| if *print-readably* is + true. Set *print-readably* to nil for a more Emacs friendly + printer syntax. + 2004-05-06 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el (slime-maybe-list-compiler-notes): Display the notes

1 0

[slime-devel] Problems with Slime with CLISP on Linux
by Barry Fishman 07 May '04

07 May '04

I have problems running Slime with the CVS version of CLISP on Linux. They are due to the unusual behavior of CLISP to *print-readably*. For example: * (let ((*print-readably* t)) (prin1 '#'+)) #'|COMMON-LISP|::|+| #'+ This I assume is tecnically correct but a bit overkill. If set *print-readably* nil, as in the attached patch, things seem to work, although I suspect there may be problems with an expression I haven't tried. Has nobody else seen these problems? *** swank.lisp-sav 2004-05-06 17:01:52.000000000 -0400 --- swank.lisp 2004-05-06 17:20:44.000000000 -0400 *************** *** 719,725 **** (defun prin1-to-string-for-emacs (object) (with-standard-io-syntax (let ((*print-case* :downcase) ! (*print-readably* t) (*print-pretty* nil) (*package* *swank-io-package*)) (prin1-to-string object)))) --- 719,725 ---- (defun prin1-to-string-for-emacs (object) (with-standard-io-syntax (let ((*print-case* :downcase) ! #-clisp (*print-readably* t) #+clisp (*print-readably* nil) (*print-pretty* nil) (*package* *swank-io-package*)) (prin1-to-string object)))) *************** *** 856,861 **** --- 856,862 ---- (*print-case* :downcase) (*print-pretty* t) (*print-circle* nil) + #+clisp (*print-readably* nil) (*print-level* 10) (*print-length* 20)) (pprint-logical-block (nil nil :prefix "(" :suffix ")") -- Barry Fishman

3 7

[slime-devel] Re: [slime-cvs] CVS update: slime/ChangeLog slime/slime.el slime/swank-openmcl.lisp
by Luke Gorrie 07 May '04

07 May '04

Marco Baringer <mbaringer(a)common-lisp.net> writes: > + * swank-openmcl.lisp (*buffer-offset*, *buffer-name*): Supply > + default values. This avoids unbound value errors when compiling an > + asdf system signals errors. Do you know why the errors come about? I think the idea of not having default bindings for those variables is to trap bugs elsewhere. This might be one.

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 07 May '04

07 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.367 slime/ChangeLog:1.369 --- slime/ChangeLog:1.367 Tue May 4 15:17:43 2004 +++ slime/ChangeLog Thu May 6 15:55:21 2004 @@ -1,3 +1,23 @@ +2004-05-06 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-maybe-list-compiler-notes): Display the notes + listing after C-c C-c only if there are no annotations in the + buffer. CMUCL creates usually one warning with an error location + and an almost redundant warning without at the end of the + compilation unit. Don't display the listing in this common case. + + (slime-reindent-defun): Pass nil as the third arument to + indent-region. + +2004-05-06 Marco Baringer <mb(a)bese.it> + + * slime.el (slime-repl-sayoonara): Don't attempt to quit the lisp + if we're not connected. + + * swank-openmcl.lisp (*buffer-offset*, *buffer-name*): Supply + default values. This avoids unbound value errors when compiling an + asdf system signals errors. + 2004-05-04 Alan Shutko <ats(a)acm.org> * slime.el (slime-compiler-notes-show-details/mouse): New command. @@ -7,7 +27,7 @@ * swank-cmucl.lisp (arglist): Handle byte-code functions better. We don't know much about the actual argument list, only the number - of arguments. Return at lest something mildly interesting like + of arguments. Return at least something mildly interesting like (arg0 arg1 &optional arg2 ...) (function-location): Special-case byte-code functions.

1 0

[slime-devel] OpenMCL backend broken by OpenMCL 0.14.2
by Will 06 May '04

06 May '04

Hello, OpenMCL 0.14.2 is now out and SLDB does not work with it. The following is an excerpt from my conversation with Gary Byers discussing MAP-BACKTRACE: Gary Byers <gb(a)clozure.com> writes: ... > > Yes; this is now wrong. Low-level stack-walking functions that > used to take a TCR ("thread context record") as an argument now > either default to walking the current thread's stacks or take > another thread's "backtrace context". Since this is trying to > do a backtrace on the current thread, it never needed to pass > the current TCR around. > >(The whole issue is that you can't just arbitrarily look at > another thread's stack in general, since it's likely to be > moving around as you're looking at it. Even if you could, the > information in the TCR is only accurate at certain points in the > thread's execution. You can look at certain parts of another > thread's stack if you're sure that that thread is in a break > loop while you're looking.) > > It looks like the function that this function maps takes a TCR > as an argument; if that function passes that TCR to other > low-level stack-walking code, it'll run into the same problem. > Passing NIL explictly may work. Setting the 'tcr' variable to NIL instead of CCL::%CURRENT-TCR in MAP-BACKTRACE does allow the debugger to present the first backtrace, but it seems broken upon using some of the restarts. Unfortunately this is all voodoo to me, but hopefully it is helpful to someone =) Regards, Will

3 2

[slime-devel] Font-lock trickery
by Nikodemus Siivola 05 May '04

05 May '04

Instead of doing something useful I spent the first part of the day coaxing/cargo-culting emacs to fontify user-definied defoo forms nicely. In case someone else is was annoyed by the this lack of angry-fruit-saladness, here goes (eg. add this to lisp-mode-hook): ;; Fontification for user-defined defoo macros (font-lock-add-keywords 'lisp-mode '(("(\\(def.*?\\)\\>[ '(]*\\(setf[ ]+\\sw+)\\|\\sw+\\)?" (1 font-lock-keyword-face) (2 (let ((name (match-string 2))) (when name (cond ((string-match "^\\*" name) font-lock-variable-name-face) ((string-match "^\\+" name) font-lock-constant-name-face) (t font-lock-function-name-face))))))) t) Won't take effect without restarting emacs -- or some other trickery that I'm not aware of. Cheers, -- Nikodemus

2 1

[slime-devel] SLIME Edit Definition
by Lynn Quam 05 May '04

05 May '04

I note that Edit Definition (meta-dot) in SLIME is inaccurate in positioning "point" when the buffer(file) has been modified by adding, removing or rearranging parts of the buffer(file). I recognize that this is, in general, a difficult problem. Is the "pragmatic solution" to do "Compile/Load File" when changes to the buffer make the source code location information useless? Back in the "good old days" with (1mhz) Symbolics Lisp Machines and the ZWEI editor, "buffer sectionization" did a pretty good job of keeping track of the source code locations. This allowed top level white-space and modifications of function defintions to be made without losing track of the source code location. Are there any thoughts about makeing slime.el smarter about changes to the Lisp source code?

5 12

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 05 May '04

05 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.363 slime/ChangeLog:1.367 --- slime/ChangeLog:1.363 Sun May 2 15:09:50 2004 +++ slime/ChangeLog Tue May 4 15:17:43 2004 @@ -1,3 +1,42 @@ +2004-05-04 Alan Shutko <ats(a)acm.org> + + * slime.el (slime-compiler-notes-show-details/mouse): New command. + (slime-compiler-notes-mode-map): Use it. + +2004-05-04 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-cmucl.lisp (arglist): Handle byte-code functions better. + We don't know much about the actual argument list, only the number + of arguments. Return at lest something mildly interesting like + (arg0 arg1 &optional arg2 ...) + (function-location): Special-case byte-code functions. + + * swank-backend.lisp (with-struct): New macro. + +2004-05-04 Thomas F. Burdick <tfb(a)OCF.Berkeley.EDU> + + * slime.el (slime-reindent-defun): New command on C-M-q. Reindent + the current Lisp defun after trying to close any unmatched + parenthesis. If used within a comment it just calls fill-paragraph. + +2004-05-04 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-goto-location-position): Regexp fix. + (slime-reindent-defun): New command on M-q. Reindent the current + Lisp defun after trying to close any unmatched parenthesis. + + * swank.lisp: Remove (declaim (optimize ...)). The side-effect + this has on people's environment seems harmful (I saw someone + having trouble on the OpenMCL list). + + * swank-cmucl.lisp (source-location-from-code-location): Fixed a + bug where the source-file-cache was not really used. + Now always report the location based on source file (cached or + not) even if modified -- not falling back on regexps, which was + probably a misfeature. + + * slime.el: Remove `slime-cleanup-definition-refs'. + 2004-05-02 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el (slime-start-and-load): New command. Suggested by

1 0

[slime-devel] swank-backend:arglist in CMUCL
by rydis＠CD.Chalmers.SE 04 May '04

04 May '04

Hi, I was looking at ripping some useful stuff from SLIME to Hemlock, and noticed that swank-backend:arglist doesn't seem to work very well with byte-compiled functions in my current version. (Which is CMUCL from CVS per 2004-04-20; SLIME as of earlier today.) All calls to swank-backend:arglist on a function that has been byte-compiled gives (C:&MORE C::CONTEXT COUNT). The problem seems to be that kernel:%function-self, called by arglist, in that case, returns a general-ish #<Function "DEFUN INITIALIZE-BYTE-COMPILED-FUNCTION>, which has that kind of arglist. "Test case": * (let ((c::*byte-compile* t)) (compile (defun foo (bar &rest zot) (list* bar zot)))) ; Converted FOO. ; Byte Compiling LAMBDA (BAR &REST ZOT): ; Byte Compiling Top-Level Form: FOO NIL NIL * (swank-backend:arglist 'foo) (C:&MORE C::CONTEXT COUNT) Regards, 'mr -- [Emacs] is written in Lisp, which is the only computer language that is beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_

2 2