slime-devel October 2005

slime-devel@common-lisp.net

54 participants
48 discussions

[slime-devel] cmucl with slime crashes on solaris
by Mario S.Mommer 11 Oct '05

11 Oct '05

Hi, With the current cmucl snapshot for sparc (but with earlier versions this also happens), and a current slime from cvs, I get the following behaviour. I start with ; SLIME 2005-10-11 CL-USER> (tagbody tag (format t "oo~%") (sleep 5) (go tag)) oo Then I interrupt the lisp process. So far so good. When I hit "q", I get a segfault from cmucl. After that, things stop working normally. Mario. PS: the backtrace: Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #xFF14D878. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to Top-Level. Backtrace: 0: (UNIX::SIGSEGV-HANDLER #<#1=unused-arg> #<#1#> #.(SYSTEM:INT-SAP #x000391D8)) 1: (UNIX::SIGSEGV-HANDLER 3 #<#1=unused-arg> #<#1#> #.(SYSTEM:INT-SAP #x000391D8))[:EXTERNAL] 2: ("call_into_lisp+#xB7 [#x1BBCF] /local/mommer/local/lib/cmucl/bin/lisp") 3: (LISP::SUB-SERVE-EVENT NIL 0) 4: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 5: (LISP::DO-INPUT #<Stream for Standard Input>) 6: (LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL (LISP::*EOF*)) 7: (LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (LISP::*EOF*)) 8: (LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (LISP::*EOF*)) 9: (LISP::SYNONYM-IN #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*)) 10: (READ-CHAR #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*) NIL) 11: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) T) 12: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 13: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) ...)[:EXTERNAL] 14: (LISP::READ-INTERNAL #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 15: (READ #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL) 16: (LISP::%TOP-LEVEL) 17: ((LABELS LISP::RESTART-LISP SAVE-LISP))

2 1

[slime-devel] path's for slime
by Vadim Potapenko 11 Oct '05

11 Oct '05

I install lisp-box for windows on WindowsNT, but i've some access problems for ordinary users. What rights must be set on directories? Or maybe i can change paths?

2 1

[slime-devel] SLIME 2005-10-09 vs. inferior-lisp-program
by Peter BARABAS 10 Oct '05

10 Oct '05

Hello, I've just updated my SLIME from CVS and got the following error in the minibuffer while doing M-x slime: "Process inferior-lisp not running" inferior-lisp-program is set to "/usr/bin/sbcl --noinform". If I set it to ""/usr/bin/sbcl" M-x slime works. -- '(Yours parenthetically), peter barabas. ((call/cc call/cc) (call/cc call/cc))

2 1

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel October 2005