slime-devel

slime-devel@common-lisp.net

4231 discussions

[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

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

14 Jan '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.200 slime/ChangeLog:1.204 --- slime/ChangeLog:1.200 Mon Jan 12 23:23:38 2004 +++ slime/ChangeLog Wed Jan 14 01:54:11 2004 @@ -1,3 +1,58 @@ +2004-01-14 Luke Gorrie <luke(a)bluetail.com> + + * swank-openmcl.lisp (emacs-connected): Typo fix (missing + close-paren). + +2004-01-13 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-input-complete-p): Tolerate extra close parens. + (slime-idle-state): Don't active the repl. + (slime-insert-transcript-delimiter): Insert output before prompt. + (slime-open-stream-to-lisp): Initialize the process-buffer with + the connection buffer. + (slime-repl-activate): Deleted. + (slime-repl-eval-string, slime-repl-show-result) + (slime-repl-show-abort): Better handling of abortion. + (slime-compile-file): Insert output before prompt. + + * swank-lispworks.lisp (create-socket): Fix condition message. + + * swank-openmcl.lisp (*swank-in-background*): Set to :spawn. + (emacs-connected): Initialize ccl::*interactive-abort-process*. + + * swank.lisp (*swank-in-background*): New variable. + (start-server): Start swank in background, depending on + *swank-in-background*. + + * swank-cmucl.lisp, swank-sbcl.lisp (*swank-in-background*): Set + to :fd-handler. + + * swank-clisp.lisp (accept-connection): Remove superfluous call to + socket-wait. + + New more direct socket interface. The new interface is closer to + the functions provided by the implementations. For Lispworks we + use some non-exported functions to get a sane interface. The + interface also includes add-input-handler and a spawn function + (not used yet). The idea is that most of the logic can be shared + between similar backends. + + * swank-gray.lisp (make-fn-streams): New function. + (stream-read-char-no-hang, stream-read-char-will-hang-p): Moved to + here from swank-clisp.lisp. + + * swank-allegro.lisp, swank-clisp.lisp, swank-cmucl.lisp, + swank-lispworks.lisp, swank-openmcl.lisp, swank-sbcl.lisp: + (create-socket, local-port, close-socket, accept-connection) + (add-input-handler, spawn): Implement new socket interface. + + * swank.lisp (start-server, open-dedicated-output-stream &etc): + Use new socket functions. + + * swank-backend.lisp (create-socket, local-port, close-socket) + (accept-connection, add-input-handler, spawn): New functions. + (accept-socket/stream, accept-socket/run): Deleted. + 2004-01-13 Luke Gorrie <luke(a)bluetail.com> * swank-clisp.lisp: Updated for new network interface but not

1 0

[slime-devel] swank-openmcl
by Marco Baringer 13 Jan '04

13 Jan '04

that was a lot easier than i thought. -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

2 1

[slime-devel] swank-openmcl.lisp
by Marco Baringer 13 Jan '04

13 Jan '04

i'm in the process of porting the new backend to openmcl and i've managed to get emacs to block every single time i try to connect to slime. so far i've localized the problem to something inside slime-init-connection, but since emacs is blocked i can't get any debugging info (like the contents of stlime-events or access to inferior-lisp). whats the best way to go about debugging lime? -- Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel