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

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

16 Jan '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.205 slime/ChangeLog:1.210 --- slime/ChangeLog:1.205 Wed Jan 14 18:44:40 2004 +++ slime/ChangeLog Fri Jan 16 02:28:23 2004 @@ -1,3 +1,86 @@ +2004-01-16 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank.lisp (changelog-date): Use *compile-file-truename* instead + of *compile-file-pathname*. + (with-I/O-lock, with-a-connection): The usual CLISP fixes. + + * slime.el: Numerous REPL related fixes. + +2004-01-16 Luke Gorrie <luke(a)bluetail.com> + + * swank-openmcl.lisp: Multiprocessing support. + + * swank.lisp (changelog-date): make-pathname portability fix + (from alanr). + (with-io-redirection): Use (current-connection) instead of + *dispatching-connection* (from alanr). + + * slime.el (slime-init-output-buffer): XEmacs portability fix, and + use header-line-format to show info about Lisp in Emacs21. + +2004-01-15 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-sbcl.lisp, swank-cmucl.lisp (remove-input-handlers): New + method. + + * swank-allegro.lisp (excl:stream-read-char-no-hang): Import it. + (emacs-connected): Add default method. The method for + no-applicable-method doesn't seem to work. ACL bug? + + * swank-loader.lisp (compile-files-if-needed-serially): Don't + handle compilation errors. We must compile everything because + changelog-date requires *compile-file-truename*. + + * slime.el: (slime-changelog-date) + (slime-check-protocol-version): New functions. + (slime-handle-oob): Handle :check-protocol-version event. + (slime-init-output-buffer): Print some info about the remote Lisp. + (slime-connect): Use it. + (slime-note-transcript-start): Renamed from + slime-insert-transcript-delimiter. + (slime-note-transcript-end): New function. + (slime-with-output-end-mark, slime-repl-insert-prompt) + (slime-repl-show-result, slime-compile-file) + (slime-show-evaluation-result): Insert output from eval commands + after the prompt and asynchronous output before the prompt. Needs + documentation. + (repl-test, repl-read, interactive-eval-output): New tests. + (slime-flush-output): Accept output from all processes. + + * swank.lisp (serve-requests): New function. + (setup-server): Use it. + (start-server): Pass backgroud to setup-server. + (create-connection): Check the protocol version. + (changelog-date): New function. + (make-output-function): Use write-string instead of princ. + + * swank-backend.lisp (remove-input-handlers): New function. + +2004-01-15 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-aux-connect, slime-handle-oob): Support for + (:open-aux-connection port) message where Lisp requests that + Emacs make a connection. These are "auxiliary" connections which + don't (or at least shouldn't) have their own REPL etc. + + * swank.lisp: New support for multiprocessing and multiple + connections + commentary. + (with-a-connection): Macro to execute some forms "with a + connection". This is used in the debugger hook to automatically + create a temporary connection if needed (i.e. if the current + thread doesn't already have one). + (open-aux-connection): Helper function to create an extra + connection to Emacs. + + * swank-sbcl.lisp: Implemented multiprocessing. Not perfect. + + * swank-cmucl.lisp: Implemented new multiprocessing interface. + (create-socket): Make FDs non-blocking when multiprocessing is + enabled. + (startup-multiprocessing): Set *swank-in-background* to :spawn. + + * swank-backend.lisp: Changed multiprocessing interface. + 2004-01-15 Wolfgang Jenkner <wjenkner(a)inode.at> * swank-clisp.lisp (with-blocked-signals): New macro.

1 0

[slime-devel] Bug report
by Ivan Boldyrev 16 Jan '04

16 Jan '04

Resent Slime from CVS HEAD has bug: 1. Load Lisp file. 2. Run slime (CMU CL). 3. Switch to Lisp text buffer. 4. Load file with C-c C-l And REPL is not usable: Assertion failed: (<= (point) slime-repl-input-end-mark) BTW, is it proper place for bugreports? -- Ivan Boldyrev Perl is a language where 2 x 2 is not equal to 4.

3 3

[slime-devel] sldb-quit and debugger for non-repl process
by Alan Ruttenberg 16 Jan '04

16 Jan '04

Following onto my previous message, if I do get a debugger, when I execute sldb-quit I get another error: Can't throw to tag SWANK::SLIME-TOPLEVEL -Alan

2 1

[slime-devel] issues in recent changes
by Alan Ruttenberg 15 Jan '04

15 Jan '04

Just trying them out in openmcl. First thing I run into is that changelog date broke when *compile-file-pathname* was a logical host. In changelog date I think you want (make-pathname :name "ChangeLog" :directory dir :host (pathname-host *compile-file-pathname*))) I'm not making changes myself because logical pathnames can be platform dependent and I don't want to break another platform. Second: I run (process-run-function "foo" (lambda() (invoke-debugger)) ) and this doesn't pop up a sldb window. Upon investigation a problem seems to be that in slime-debug, there is (when (open-stream-p (connection.socket-io *main-connection*)) (with-a-connection () (with-io-redirection ((current-connection)) (swank-debugger-hook c next))))))) *dispatching-connection* is nil with-a-connection checks (current-connection) which succeeds, since there is *main-connection* But then with-io-redirection looks at *dispatching-connection* for its connection. Don't know if this is due to swank-openmcl not being up to date. Is someone currently working on swank-openmcl? -Alan

1 0

[slime-devel] Re: [slime-cvs] CVS update: slime/ChangeLog
by Helmut Eller 15 Jan '04

15 Jan '04

Wolfgang Jenkner <wjenkner(a)common-lisp.net> writes: > + * swank-clisp.lisp (with-blocked-signals): New macro. > + (without-interrupts): Use it. I get now errors/warnings like: WARNING: clos::make-init-form[linux::sigset_t][common-lisp::simple-error]: clos::no-applicable-method: When calling #1=#Y(clos::make-load-form #22Y(00 00 00 00 01 00 00 00 11 17 69 00 00 69 00 01 69 00 02 9C 02 03) (common-lisp::t . common-lisp::t) #(clos::no-method-caller clos::no-applicable-method #1#) #(1. 1. common-lisp::nil common-lisp::nil common-lisp::nil common-lisp::nil) (0.) common-lisp::nil) with arguments WARNING: clos::make-init-form[linux::sigset_t][common-lisp::simple-error]: clos::no-applicable-method: When calling ... Do others see this too? Helmut.

2 1

[slime-devel] Lisp is not ready for requests from the REPL, can it be any other way?
by Dirk Gerrits 15 Jan '04

15 Jan '04

Hi. I've noticed that when one's program is running, one is still free to use SLIME. However, attempting to evaluate an expression produces the message "Lisp is not ready for requests from the REPL". Pretty understandable, because Lisp can only do one thing at a time. But I was wondering if it is possible to 'fix' this. Ie I would like to be able to inspect variables and redefine functions etc. *while the program is running*. Can SLIME help me do this? Or should I post a question to comp.lang.lisp? Thanks in advance, Dirk Gerrits

6 7

[slime-devel] Feature request
by Ignas Mikalajunas 15 Jan '04

15 Jan '04

As we can see there are lot's of fake bug reports associated with using incompatible slime.el version. I think there should be some way to put a function into swank like (equired-slime-version) so slime.el could check whether it is up to date on connect and recompile itself or at least warn the user. Ignas Mikalajunas

4 3

[slime-devel] Partial multiprocessing support, take 2
by Luke Gorrie 15 Jan '04

15 Jan '04

Ahoy, I checked in some very basic multiprocessing support. It works with SBCL and CMUCL and it should be easy to port. Threads automatically create new connections on-demand and can all talk to Emacs at the same time. There is no flow-control, so if 20 threads hit the debugger at once then you can expect 20 layers of SLDB buffers to pop up :-). There is no real policy for standard I/O streams or for interrupting yet -- "it does what it does". There is some commentary in swank.lisp about how multiple-connections work from the Lisp side (short version: one per thread created on demand). I also changed (shrunk) the multiprocessing interface in swank-backend, it should be implementable in 20 lines or so and all that's needed for a port. For people already using threads it should be a great improvement. For people not using threads it shouldn't break anything. There's a caveat for SBCL: spawning threads from SLIME (e.g. the REPL) doesn't work properly. When you spawn a thread in SBCL it inherits the dynamic bindings from its parent, but it seems to get some things that were supposed to be thread-specific/temporary in the bargain. I'll ask Dan about this stuff when he gets back online. BTW, there is a job opening for a threads user-interface designer/hacker. Helmut and I aren't threads users, so we're not the guys to do this stuff. It would be better for some threads hacker(s) to muck around and figure out a good UI, and we can help with the infrastructure (which is hopefully mostly there now). Cheers, Luke

2 3

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 15 Jan '04

15 Jan '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.204 slime/ChangeLog:1.205 --- slime/ChangeLog:1.204 Wed Jan 14 01:54:11 2004 +++ slime/ChangeLog Wed Jan 14 18:44:40 2004 @@ -1,3 +1,11 @@ +2004-01-15 Wolfgang Jenkner <wjenkner(a)inode.at> + + * swank-clisp.lisp (with-blocked-signals): New macro. + (without-interrupts): Use it. + (*use-dedicated-output-stream*, *redirect-output*): Don't set them + here, use the default settings. + Make :linux one of *features* if we find the "LINUX" package. + 2004-01-14 Luke Gorrie <luke(a)bluetail.com> * swank-openmcl.lisp (emacs-connected): Typo fix (missing

1 0

[slime-devel] Backend carnage! Battle stations!
by Luke Gorrie 14 Jan '04

14 Jan '04

Howdy, I just checked in some incompatible changes to the backend interface. I've only updated the CMUCL backend so far, and I'm hoping to fix SBCL (and maybe LispWorks) this evening. Backend hackers please join in :-). The ChangeLog gives the gist, and diff'ing swank-cmucl.lisp against FAIRLY-STABLE will show how the CMUCL backend was updated. Everyone else might want to stick to FAIRLY-STABLE (just updated) for a day or two 'til the dust settles. The basic change is to move most of the protocol logic into portable code. Now the backends provide a generic callback-based TCP server interface which is used by swank.lisp to implement the basic protocol, parts of I/O redirection, and the dedicated output channel. Hopefully it also buys enough generality that multithreading experiments can go forward without breaking backends again. It should be mostly a matter of deleting code and adapting what remains. The new interfaces are documented in swank-backend.lisp. Questions & flames welcome :-) Cheers, Luke

5 10