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

[slime-devel] Problems with AllegroCL and completion
by Edi Weitz 10 Oct '05

10 Oct '05

Hi! Today I noticed that there seem to be significant problems with AllegroCL (I'm using 7.0 pro on both Windows and Linux) and completion. SLIME is current from CVS. For me the problem is reproducible like that: 1. The TAB key is bound to slime-indent-and-complete-symbol. 2. In the REPL buffer type, say, (use-package :d 3. Now, with the cursor after the "d" type TAB several times in a row very fast. This suffices to completely trash everything for me. On Windows, Emacs goes up to 60% CPU usage and doesn't react anymore, on Linux AllegroCL goes up to 95% CPU usage. Any ideas? Thanks, Edi.

2 5

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 09 Oct '05

09 Oct '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.791 slime/ChangeLog:1.792 --- slime/ChangeLog:1.791 Sat Oct 1 14:00:27 2005 +++ slime/ChangeLog Sun Oct 9 21:17:22 2005 @@ -1,4 +1,32 @@ +2005-10-09 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime, slime-start): Introduce a separate function for + the non-interactive case. `slime-start' takes lots of keyword + arguments and `slime' is reserved for interactive use. + (slime-read-interactive-args): New function. + (slime-maybe-start-lisp, slime-inferior-lisp) + (slime-start-swank-server): Pass all arguments needed to start + the subprocess as a property list. Also store this list in a + buffer-local var in the inferior-lisp buffer, so that we can + cleanly restart the process. + (slime-registered-lisp-implementations): Change the format and + document it. M-- M-x slime can now be used select a registered + implementation. + (slime-symbolic-lisp-name): Deleted. And updated all the functions + which passed it along. + (slime-set-connection-info): Use the new format. + (slime-output-buffer): Don't re-initialize buffer-local variables + if the buffer already exists. This saves the history. From Juho + Snellman. + + * swank-cmucl.lisp (sis/in): Use finish-output instead of + force-output. + + * swank.lisp (connection-info): Include the initial package and + a more self-descriptive format. + 2005-10-01 Juho Snellman <jsnell(a)iki.fi> + * swank-backend (*gray-stream-symbols*): Add :STREAM-LINE-LENGTH to *GRAY-STREAM-SYMBOLS* on implementations that support this extension to gray streams. Reported by Matthew D Swank. @@ -25,8 +53,7 @@ * swank-scheme48/source-location.scm: New file. For M-. * swank-scheme48/module.scm (list-all-package): New function. * swank-scheme48/interfaces.scm (module-control-interface): Export it. - * swank-scheme48/inspector.scm: Add methods for records and and - hashtables. + * swank-scheme48/inspector.scm: Add methods for records and hashtables. (swank:arglist-for-echo-area): Implement it. Only works for functions with enough debug-data (ie. only user-defined functions). * swank-scheme48/completion.scm: New file.

1 0

[slime-devel] non-Latin1 character causes slime to disconnect
by Alan Shields 09 Oct '05

09 Oct '05

Quick way to cause problems: At the repl, do: (code-char 65533) Swank will disconnect. This is an unhandled condition regarding an external format encoding error. Ocurred with SBCL 0.9.4.65 and 09/28/2005 at 9:20 PM's slime CVS. The quick response is "don't do that" - but the character was ocurring in (I think) a backtrace from an external format error. Any assistance would be appreciated. Thanks, Alan

2 3

[slime-devel] REPL history cleared when inferior lisp is restarted
by Juho Snellman 09 Oct '05

09 Oct '05

After the recent changes to slime-output-buffer (2005-09-15), the REPL history is no longer preserved across inferior lisp restarts. I don't understand the code well enough to know what the proper fix is, but the following kludge seems to restore the old behaviour: --- slime.el 27 Sep 2005 22:42:55 -0000 1.552 +++ slime.el 1 Oct 2005 19:41:09 -0000 @@ -2474,7 +2474,8 @@ (setf (slime-connection-output-buffer) (let ((connection (slime-connection))) (with-current-buffer (slime-repl-buffer t connection) - (slime-repl-mode) + (unless (eq major-mode 'slime-repl-mode) + (slime-repl-mode)) (setq slime-buffer-connection connection) (slime-reset-repl-markers) (unless noprompt -- Juho Snellman

2 1

[slime-devel] compile-system problem
by Peter BARABAS 07 Oct '05

07 Oct '05

Hello, I'm using CVS SLIME and went into the following problem: I start slime with M-x slime, then change the current directory with <comma> !d, and do a compile-system. Everything compiles fine, but when I try to call any function with (dora:start) or (dora::list-items) I get: package "DORA" not found. When I do it in a shell as cd .devel/dora && sbcl --eval "(asdf:oos 'asdf:load-op :dora)" --eval "(dora:start)" it works. Am I missing something? Thank you for your reply. -- '(Yours parenthetically), peter barabas. ((call/cc call/cc) (call/cc call/cc))

2 1

[slime-devel] Re: Patch for stepper support in SBCL and (sort of) CLISP
by Svein Ove Aas 06 Oct '05

06 Oct '05

On 10/5/05, Bill Clementson <billclem(a)gmail.com> wrote: > > The basic design is a Lisp evaluator that communicates with the > > stepper UI by way of the condition system - pretty much the same setup > > as my last attempt, except that I'm writing said evaluator myself. I'm > > about halfway done with the evaluator, and haven't really tried doing > > anything about the UI yet; Slime's debugger works fairly well for the > > development bit. > > If you're still looking at approaches for the UI, have you considered > the approach that is taken by edebug in emacs (for elisp code)? I > really like that approach and think that it is an excellent way to > visually present sexp evaluation. > Actually, yes. It's a bit too early to say, though, and I think there will be at least two representations.

1 0

[slime-devel] Re: Patch for stepper support in SBCL and (sort of) CLISP
by Svein Ove Aas 05 Oct '05

05 Oct '05

On 10/5/05, Bill Clementson <billclem(a)gmail.com> wrote: > Hi Svein, > > > Due to a few requests lately, I thought I should mention something: > > This code is obsolete. > > > > It only ever really worked on SBCL, and even there not perfectly. I'm > > rewriting it as something that should work everywhere, but meanwhile > > any non-fatal bugs are going to go unfixed - sorry about that." > > Any progress in getting the SBCL stepper working yet? It always pretty much worked in SBCL, so I assume you're referring to my new implementation. Progress? Some. The basic design is a Lisp evaluator that communicates with the stepper UI by way of the condition system - pretty much the same setup as my last attempt, except that I'm writing said evaluator myself. I'm about halfway done with the evaluator, and haven't really tried doing anything about the UI yet; Slime's debugger works fairly well for the development bit. *IF* I had nothing else to do, I could probably get a workable stepper (sans UI) in a week. As I do, in fact, have other things to do, I'm aiming to complete it by christmas. Partials will be unpredictable, but feel free to pull patches from darcs://brage.info/~svein/repos/slime/, which will contain semi-stable code once I've got such a thing. (At the moment it's practically empty. You could still use it as a CVS gateway, I suppose.) I'll also announce it to slime-dev once I feel confident about letting the ravening hordes at my code. As has been mentioned, all good things come to those who wait - for a tidbit, I've got a framework for step-backwards in place. > Also, what were the problems that you had getting it to work with OpenMCL? (defmacro step (&body body) ,@body) That about summarizes it. I'd been using that macro as a starting point for figuring out how the implementations did it. OpenMCL apparently didn't, but maybe I didn't dig deep enough. I'd appreciate pointers to whitepapers on Lisp evaluation and such, if you have some handy. - Svein Ove Aas

2 1

[slime-devel] loopback interface
by Robert Brown 04 Oct '05

04 Oct '05

Recently, I've been running a Lisp-based server on a batch scheduling system. The scheduler starts up my server on an available machine and then I'd like to connect to it with Slime. I've noticed two things: 1. The code in swank.lisp listens on port 127.0.0.1 <http://127.0.0.1>, which means I cannot connect to my Lisp server from a remote machine. I must log in to the host it's running on and then specify "localhost" when I execute slime-connect in Emacs. If swank is running on host "foo", why doesn't it bind its listening socket with foo's address? 2. I modified swank.lisp so the server code binds its listening connection socket with foo's address. Now I can connect from a remote machine. Is there any convenient way to send whole files across the Slime connection? The Lisp running the swank server has no NFS access to the machine I'm running Emacs on. I'd like to be able to edit files on the Emacs side and send then whole to the Lisp running swank. bob

5 5

[slime-devel] SLIME48: a Swank back end in Scheme48
by Taylor Campbell 04 Oct '05

04 Oct '05

About a month ago, as I was thinking about building a comprehensive development environment for Scheme (& Scheme48 in particular), akin to SLIME, the notion occurred to me that Scheme48 might actually provide the necessary facilities for a realistic Swank back end (as compared to the mostly toy back end Helmut Eller sent here a while ago). So I started working on it a bit in small increments, and pretty soon Emacs was successfully talking to it over TCP to evaluate simple REPL expressions. Last week I implemented SLDB support, after rewriting it from scratch once my initial prototype worked; I spent the whole weekend fixing a really obscure bug involving threads, continuations, & DYNAMIC-WIND; and just today I've gotten it into an almost usable state for REPL work (though not file & module loading & such yet). Currently, I'm not using any source control yet, and I haven't released the code anywhere, but Marco Baringer and several others recommended that I simply add the Scheme48 back end to the main SLIME CVS source repository. If everyone relevant would be OK with this, I'd like to do it, but I see one potential problem with it, assuming that no one would object to including Scheme code in SLIME: I've organized my Scheme48 back end into about a dozen different files, which is pretty different from the existing organization of SLIME code (one monolithic file for the Emacs side; one monolithic file for the bulk of the CL side; one monolithic file for each back end). Would this bother anyone? (I intend, by the way, not to change the Emacs side of SLIME to add anything Scheme-specific; if anything, I'd want only to make slime.el work better with both Scheme & CL -- e.g., Marco Baringer just kindly committed a change I suggested that makes the definition locator code look for definitions where a sequence of parentheses might precede the name being defined, such as in (DEFINE (FOO X) ...) to define FOO in Scheme, or (DEFSTRUCT (BAR ...) ...) to define a BAR structure in CL. There are a few other minor changes like these that would be convenient for Scheme48's back end, but which would not get in the way of the CL back ends, too.) Obligatorily, here's some SLIME48 porn, by the way: <http://www.bloodandcoffee.net/campbell/slime48-sldb-porn.png> (The CL-USER prompt and the mention of a COMMON-LISP-USER package are due to slime.el's hard-coded initial package of COMMON-LISP-USER -- another small change I'd like to make is to allow customization of the initial package. (The temporary solution was for me just to define a COMMON-LISP-USER package in Scheme48, of course.))

12 33

[slime-devel] presentations/repl history problem
by Alan Ruttenberg 03 Oct '05

03 Oct '05

Somewhere in the last ~2 months, a change I made was (searching for the diplomatic word here...) "regressed". The symptom is that when I bring back something from the repl history (via meta-p) that contains a presentation, the presentation is no longer in the right style, and return sends the presentation string rather than for to evaluate to the object, causing an error. I spent a reasonable amount of time this morning looking for the bug but things have changed enough that I can't understand what's going on well enough to find it. Could someone who is familiar with the relevant changes to the presentation system please review this problem and suggest a fix? The presentation stuff, at least on the emacs side, could use some documentation at this point. What are the features? How are they implemented? Thanks, Alan 2005-08-10 Alan Ruttenberg <alanr-l(a)mumble.net> * slime.el move slime-repl-add-to-input-history to slime-repl- send-input so we can see the presentations we copied to input when we reuse history rather than #.(blah...)

1 0