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

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 16 Dec '03

16 Dec '03

Index: slime/ChangeLog diff -u slime/ChangeLog:1.162 slime/ChangeLog:1.167 --- slime/ChangeLog:1.162 Mon Dec 15 00:29:19 2003 +++ slime/ChangeLog Mon Dec 15 14:13:53 2003 @@ -1,10 +1,24 @@ 2003-12-15 Luke Gorrie <luke(a)bluetail.com> + * swank-openmcl.lisp (ccl::*warn-if-redefine-kernel*): Support for + interrupting the listener (by Alan Ruttenberg). + +2003-12-15 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank.lisp *start-swank-in-background*: Set to t by default. + + * slime.el (slime-eval-last-expression-display-output): New + command. Bound to C-x M-e. Suggested by Nicolas Neuss. + (slime-display-output-buffer): New function. + (slime-slime-compile-file): Use it. + +2003-12-15 Luke Gorrie <luke(a)bluetail.com> + * swank.lisp (*processing-rpc*, *multiprocessing-enabled*, + *debugger-hook-passback*): New variables. (with-conversation-lock, with-I/O-lock): New macros. (read-next-form): Use with-I/O-lock. - (send-to-emacs): Use with-I/O-lock instead of - without-interrupts*. (But should we have without-interrupts* too?) + (send-to-emacs): Use with-I/O-lock. (swank-debugger-hook): When called asynchronously (i.e. not during RPC) and multiprocessing is enabled, suspend until acknowleged by Emacs. @@ -14,8 +28,9 @@ (eval-string): Dynamically set the *PROCESSING-RPC* flag. (eval-string): Nasty hack with *DEBUGGER-HOOK-PASSBACK* to install debugger hook. Temporary, I swear! - - *debugger-hook-passback*): New variables. + (eval-region, shortest-package-nickname): Report the shortest + package nickname to Emacs (for the REPL prompt). Patch from Marco + Baringer. * swank-backend.lisp: Defined multiprocessing interface.

1 0

[slime-devel] Re: [slime-cvs] CVS update: slime/swank.lisp
by Helmut Eller 16 Dec '03

16 Dec '03

Luke Gorrie <lgorrie(a)common-lisp.net> writes: > (send-to-emacs): Put back WITHOUT-INTERRUPTS* -- not sure exactly what > it's for, but I had no actual reason to remove it so I probably broke > something! The without-interrupts ensures that we don't write partial sexps to the Emacs buffer. If Lisp receives a SIGINT before the expression is completely written, we enter the debugger and send some debugger messages to the stream, but Emacs will not be able to parse it correctly. This occurs very likely if you remove without-interrupts*, set *use-dedicated-output-stream* to nil and run the interrupt-bubbling-idiot test case. Helmut.

2 1

[slime-devel] Error starting slime after update
by Tim Lavoie 16 Dec '03

16 Dec '03

Hi all, I started tinkering with slime a little while back, and it had been working pretty well. I just replaced what I had (whoops) with what is now in CVS, with the "FAIRLY-STABLE" tag specified. I did see Jan Rychter's thread from last month, so I made sure that I toasted and re-fetched the whole works, and had no .elc files around. Any ideas? I get a couple of messages when I start slime: The first appears in the *Warnings* buffer: (3) (error/warning) Error in process filter: (wrong-type-argument stringp nil) This one appears in the minibuffer: itimer "itimer-0" signaled: (file-error "Cannot open load file" "lee-hook") This latter one is quite odd, as "lee-hook" doesn't appear in the slime files, nor in my own XEmacs init files. When I start, slime has wandered off into space, until I break out. Here's the CMUCL backtrace: ;; Loading #p"/usr/local/dl/Lisp/slime/slime/swank-cmucl.x86f". T * ;; Swank ready. Interrupted at #xFFFFE410. Restarts: 0: [CONTINUE] Return from BREAK. 1: [ABORT ] Return to Top-Level. Debug (type H for help) (UNIX::SIGINT-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFE690)) Source: ; File: target:code/signal.lisp (DEFINE-SIGNAL-HANDLER SIGINT-HANDLER "Interrupted" BREAK) 0] back 0: (UNIX::SIGINT-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFE690)) 1: (UNIX::SIGINT-HANDLER 3 #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFE690))[:EXTERNAL] 2: ("Foreign function call land") 3: ("Foreign function call land") 4: ("Foreign function call land") 5: ("Foreign function call land") 6: ("Foreign function call land") 7: (SYSTEM:WAIT-UNTIL-FD-USABLE 8 :INPUT NIL) 8: (ACCEPT-TCP-CONNECTION 8) 9: (SWANK::OPEN-STREAM-TO-EMACS) 10: (SWANK::OPEN-STREAM-TO-EMACS 0)[:EXTERNAL] 11: (SWANK::SETUP-REQUEST-HANDLER 7) 12: (SWANK::SETUP-REQUEST-HANDLER 1 7)[:EXTERNAL] 13: (SWANK::ACCEPT-CONNECTION 5) 14: (SWANK::ACCEPT-CONNECTION 1 5)[:EXTERNAL] 15: (SWANK:CREATE-SWANK-SERVER 0 :REUSE-ADDRESS T :ADDRESS ...) 16: (SWANK:CREATE-SWANK-SERVER 5 0)[:EXTERNAL] 17: (SWANK:START-SERVER "/tmp/tim/slime.11767") 18: (SWANK:START-SERVER 1 "/tmp/tim/slime.11767")[:EXTERNAL] 19: (INTERACTIVE-EVAL (SWANK:START-SERVER "/tmp/tim/slime.11767")) 20: (COMMON-LISP::%TOP-LEVEL) 21: (COMMON-LISP::RESTART-LISP) 0] Any ideas? Thanks, Tim

2 1

[slime-devel] * load-pathname*, *load-truename*
by Alan Ruttenberg 16 Dec '03

16 Dec '03

One might argue that evaluating or loading a compiled expression inside an emacs buffer visiting a file should be as close as possible to what happens when the file is loading. To this end what do you think about wrapping forms evaluated with slime-eval-defun and friends with (let* ((*load-pathname* <emacs (buffer-file-name)>) (*load-truename* (and (probe-file *load-pathname*) (truename *load-pathname*)000 <expression> ) or something like it. For example, evaluating an asdf defsystem form depends on this... -Alan

4 4

[slime-devel] Inactive *inferior-lisp* buffer
by Paolo Amoroso 15 Dec '03

15 Dec '03

Just after starting SLIME, the *inferior-lisp* buffer is apparently inactive. It contains: ; Loading #p"/home/paolo/.cmucl-init.lisp". CMU Common Lisp 18e, running on plato With core: /opt/cmucl-18e/lib/cmucl/lib/lisp.core Dumped on: Thu, 2003-04-03 15:47:12+02:00 on orion See <http://www.cons.org/cmucl/> for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS 18e (based on PCL September 16 92 PCL (f)) * ; Loading #p"/home/paolo/src/slime/swank-loader.lisp". ;; Loading #p"/home/paolo/src/slime/swank-backend.x86f". ;; Loading #p"/home/paolo/src/slime/swank.x86f". ;; Loading #p"/home/paolo/src/slime/swank-source-path-parser.x86f". ;; Loading #p"/home/paolo/src/slime/swank-cmucl.x86f". T * ;; Swank ready. But if I type any form in it and press ENTER, it is not evaluated and the prompt no longer appears. *slime-repl* works fine instead. Is this the expected behavior? I can't tell because I don't use *inferior-lisp* often. I'm using SLIME CVS sources updated a couple of hours ago, CMUCL 18e and GNU Emacs 20.7.2 under Debian Woody. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

2 1

[slime-devel] slime-interrupt in openmcl
by Alan Ruttenberg 15 Dec '03

15 Dec '03

Currently breaks things by interrupting the listener process in the inferior lisp. Here's one way to fix it (in swank-openmcl.lisp) (defun create-swank-server (port &key (reuse-address t) (announce #'simple-announce-function)) "Create a Swank TCP server on `port'." (let ((server-socket (ccl:make-socket :connect :passive :local-port port :reuse-address reuse-address))) (funcall announce (ccl:local-port server-socket)) (setq ccl::*interactive-abort-process* ;; tell openmcl which process you want to be interrupted when sigint is received (ccl:process-run-function "Swank Request Processor" #'swank-accept-connection server-socket)))) Then add this redefinition (defun ccl::force-break-in-listener (p) (ccl::process-interrupt p #'(lambda () (ccl::ignoring-without-interrupts (let ((*swank-debugger-stack-frame* nil) (previous-p nil)) (block find-frame (map-backtrace #'(lambda(frame-number p tcr lfun pc) (declare (ignore frame-number tcr pc)) (when (eq (ccl::lfun-name lfun) 'swank::eval-region) (setq *swank-debugger-stack-frame* previous-p) (return-from find-frame)) (setq previous-p p)))) (invoke-debugger) (clear-input *terminal-io*)))))) -Alan

4 7

[slime-devel] Partial multiprocessing support on CMUCL
by Luke Gorrie 15 Dec '03

15 Dec '03

Ahoy, I checked in some multiprocessing support under CMUCL. [While writing this mail, I realised that it's seriously broken -- you'll notice my tone changes towards the bottom of the mail :-)] With respect to what I said a "version one" should be, this is about half finished. It might at least be a major improvement for people already living on the edge and using threads :-) Obligatory screenshot, debugging three McCLIM Listener processes here: http://www.bluetail.com/~luke/misc/lisp/slime-threads.png To use it, add this to your .emacs: (setq slime-multiprocessing t) (setq slime-global-debugger-hook t) (That second line installs the slime debugger hook globally -- this is a convenience to automatically setup the hook that Dan made for Aranaida use.) And this to your ~/.swank.lisp: (setq swank::*start-swank-in-background* t) ;; Use SERVE-EVENT The good parts: Threads that "asynchronously" hit an error -- i.e. not while performing an RPC for Emacs -- will suspend until Emacs decides to debug them. The Lisp side uses locks so that only one thread will enter a conversation with Emacs at a time. If several threads hit the debugger at once, they will always be debugged one-at-a-time. The Emacs side has a new "thread control" buffer (top right of the screenshot) listing all suspended threads. You press RET to "give the goahead" to one of them so that it enters the debugger. The sharp edges and bare wires: I haven't done anything about input and output streams, aside from using a lock to atomic'ify all reads and writes to the Emacs socket. There an obscure-ish race condition: if you "gohead" a thread into the debugger, but send an RPC before it actually hits the debugger, the protocol will reach an inconsistent state and bail out. Also, something really horrible that just occured while writing this mail: there is no coherent scheme to say which thread is supposed to be reading from the Emacs socket. There is a 'conversation-lock' that prevents two threads from actually entering into talks with Emacs at the same time, but nothing to tell the SERVE-EVENT loop that "hey, this other thread is being debugged just now, so don't try to take the I/O-lock and read from Emacs just because the file descriptor becomes readable." It seems to work anyway, but I can't say why. Shades of Java. This is likely to be a problem to port to OpenMCL just now. OpenMCL doesn't use SERVE-EVENT (which mysteriously seems to work) but instead has a dedicated thread calling READ-FROM-EMACS to get and evaluate requests. That thread should typically be blocking in a read with the I/O-lock held, preventing any other thread (e.g. one trying to do debugging) from reading from Emacs. At the moment the only workaround I can think of is a bit.. unspeakable. HELP, HELP! SAVE ME! I don't know how to write correct multithreaded programs! How do people do synchronization in Lisp? Do you use higher-level abstractions than locks and shared variables, or is there some book I can read to actually understand how to program with those things? The mind boggles. Please someone stop me before I write a homebrew message-passing system. Cheers, Luke

3 6

[slime-devel] Why does this trigger a slime bug?
by Alan Ruttenberg 15 Dec '03

15 Dec '03

I'm used to typing (inspect foo) into the listener so I tried (defun inspect (thing) (swank::eval-in-emacs `(slime-open-inspector ,(swank::inspect-object thing)))) which triggers a slime-bug. If I M-x debug-on-entry slime-state/event-panic and then abort, nothing seems too disturbed. -Alan

1 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 15 Dec '03

15 Dec '03

Index: slime/ChangeLog diff -u slime/ChangeLog:1.159 slime/ChangeLog:1.162 --- slime/ChangeLog:1.159 Sat Dec 13 05:15:44 2003 +++ slime/ChangeLog Mon Dec 15 00:29:19 2003 @@ -1,9 +1,92 @@ +2003-12-15 Luke Gorrie <luke(a)bluetail.com> + + * swank.lisp (*processing-rpc*, *multiprocessing-enabled*, + (with-conversation-lock, with-I/O-lock): New macros. + (read-next-form): Use with-I/O-lock. + (send-to-emacs): Use with-I/O-lock instead of + without-interrupts*. (But should we have without-interrupts* too?) + (swank-debugger-hook): When called asynchronously (i.e. not + during RPC) and multiprocessing is enabled, suspend until + acknowleged by Emacs. + (install-global-debugger-hook): Install a SLIME-DEBUGGER-FUNCTION + globally on *DEBUGGER-HOOK*. + (startup-multiprocessing-for-emacs): Called to initialize multiprocessing. + (eval-string): Dynamically set the *PROCESSING-RPC* flag. + (eval-string): Nasty hack with *DEBUGGER-HOOK-PASSBACK* to + install debugger hook. Temporary, I swear! + + *debugger-hook-passback*): New variables. + + * swank-backend.lisp: Defined multiprocessing interface. + + * swank-cmucl.lisp: Implmemented the multiprocessing interface. + + * slime.el (slime-multiprocessing): When true, use + multiprocessing in Lisp if available. + (slime-global-debugger-hook): When true, globally set + *debugger-hook* to use the SLIME debugger. For use with + SERVE-EVENT and multiprocessing. + (slime-handle-oob): Handle :AWAITING-GOAHEAD message from threads + that have suspended to wait for Emacs's attention. + (slime-give-goahead): New command to allow a suspended thread to + continue (bound to RET in the thread-control-panel). + (slime-thread-control-panel): New command to display a buffer + showing all threads that are suspending waiting for Emacs's + attention. Bound to `C-c C-x t'. + (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> + + * swank-openmcl.lisp (eval-in-frame, inspect-object and friends): + Most of this is copied from swank-cmucl. The parts between &&&&& + are what I added for openmcl. I piggyback off the inspector which + is shipped with openmcl, so inspecting won't look the same as it + would in cmucl, I imagine. Still, it's a start. eval in frame + uses frame-locals to get bindings so if you have debug settings + low or don't have *save-local-symbols* set you won't be able to + evaluate. + +2003-12-14 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-lispworks.lisp (tracedp, toggle-trace-fdefinition): Moved + to swank.lisp. + + * swank-allegro.lisp (create-swank-server): Add support for + BACKGROUND and CLOSE argument. + (call-with-debugging-environment): Use excl::int-newest-frame to + avoid the kludge with *break-hook*. + (sldb-abort): New function. + (frame-source-location-for-emacs): Dummy definition. + (compile-file-for-emacs): The argument is called + :load-after-compile and not :load. + (xref-results-for-emacs): Use dolist instead of loop. + + * swank-openmcl.lisp (create-swank-server): Add support for + BACKGROUND and CLOSE argument. + (open-stream-to-emacs): Support for dedicated output stream. + + * swank.lisp: *start-swank-in-background*, + *close-swank-socket-after-setup*, *use-dedicated-output-stream*: + Moved here from swank-cmucl. + (sldb-continue): Don't pass the condition as argument, because + that doesn't work with Allegro. + (toggle-trace-fdefinition, tracedp): Replace backend specific code + with portable, but ugly, calls to eval. + + * swank-cmucl.lisp (compile-system-for-emacs): Add method for + CMUCL. + + * slime.el (slime-goto-source-location): Better regexp for package + qualified symbols. Allow dashes in the name and two colons. + Reported by Alan Ruttenberg. + 2003-12-13 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * swank-openmcl.lisp (create-swank-server): Interrupt the right thread. Patch by Alan Ruttenberg. Not yet enabled, due to lack of test platform. - (sldb-disassemble): Implement sldb-disasssemble command. Patch by + (sldb-disassemble): Implement sldb-disassemble command. Patch by Alan Ruttenberg. Remove #' from lambdas.

1 0

[slime-devel] mirroring slime's cvs repo with arch
by Marco Baringer 15 Dec '03

15 Dec '03

UnCommon Web uses slime's debugging functions to provide some server debugging tools. however both slime and ucw are moving targets and i occasionaly have problems integrating the two, if slime were to use arch, or if an arch interface to slime's cvs repo existed, i would be able to specify exactly which version of slime works with which version of ucw. What i would like to do is create a read-only arch repository which maps slime's cvs repository. This would require: 1) a place to put the arch repo under public_html. 2) a loginfo script which keeps the two repos in sync. would you guys be willing to do this? [If, for whatever reason, this idea doesn't appeal that's fine, I will simply create this slime repo inside the bese project and do the updates manually.] -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

3 2