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

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 20 May '08

20 May '08

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1354 slime/ChangeLog:1.1356 --- slime/ChangeLog:1.1354 Sat May 17 07:03:19 2008 +++ slime/ChangeLog Mon May 19 09:12:52 2008 @@ -1,3 +1,16 @@ +2008-05-19 Helmut Eller <heller(a)common-lisp.net> + + * swank-sbcl.lisp: Don't require asdf. + +2008-05-19 Helmut Eller <heller(a)common-lisp.net> + + * swank-sbcl.lisp (swank-compile-string): Add reader-conditionals + for sb-ext::restrict-compiler-policy. + +2008-05-19 Geo Carncross <geocar(a)gmail.com> + + * contrib/swank-asdf.lisp: Require asdf. + 2008-05-17 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-prin1-to-string): Bind print-length and

1 0

Re: [slime-devel] leopard + sbcl + sb-thread
by Nikodemus Siivola 19 May '08

19 May '08

On Mon, May 19, 2008 at 4:58 AM, Aaron Feng <aaron.feng(a)gmail.com> wrote: > Hi Nikodemus, > >> This doesn't make sense to me. As far I've understood, the backtrace >> occurred in *inferior-lisp*, and there should be no "more" there after >> typing the "ba" at the debugger prompt. > > When I load up emacs this is *exactly* what I see: > > The value 68089408 is not of type SIMPLE-STRING. > [Condition of type TYPE-ERROR] > > Restarts: > 0: [ABORT] Return to SLIME's top level. > 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {14132649}>) > > Backtrace: > 0: (SB-KERNEL:%SXHASH-SIMPLE-STRING #<unavailable argument>) > 1: ((FLET SB-C::LOOKUP) (#<SB-C::VOLATILE-INFO-ENV "Working"> > #<SB-C::COMPACT-INFO-ENV #1="Auxiliary"> #<SB-C::COMPACT-INFO-ENV #1#>)) > 2: (MACRO-FUNCTION #<error printing object>) > --more-- I kind of wish you had posted this in the first place. :) Because your first message didn't have the [Condition of TYPE-ERROR] I assume that the debugger was the SBCL debugger inside *inferior-lisp*, not the Slime debugger inside an SLDB buffer -- and they work quite differently. At any rate, hitting neither ba not b will get you the backtrace we desire here. Here just clicking on the --more-- is indeed the right thing to do -- and if another --more-- appears further down clicking on it again till you have the full backtrace. ...but you don't need to do that now, since *slime-events* had everything I wanted to know. Just for future reference. In *slime-events* you have: ("The value 68089408 is not of type SIMPLE-STRING." " [Condition of type TYPE-ERROR]" nil) (("ABORT" "Return to SLIME's top level.") ("TERMINATE-THREAD" "Terminate this thread (#<THREAD \"worker\" {1411A649}>)")) ((0 "(SB-KERNEL:%SXHASH-SIMPLE-STRING #<unavailable argument>)") (1 "((FLET SB-C::LOOKUP) (#<SB-C::VOLATILE-INFO-ENV \"Working\"> #<SB-C::COMPACT-INFO-ENV #1=\"Auxiliary\"> #<SB-C::COMPACT-INFO-ENV #1#>))") (2 "(MACRO-FUNCTION #<error printing object>)") (3 "(SWANK::SYMBOL-INDENTATION #<error printing object>)") (4 "((FLET SWANK::CONSIDER) #<error printing object>)") (5 "((FLET SB-IMPL::ITERATE-OVER-HASH-TABLE) #<SB-IMPL::PACKAGE-HASHTABLE :SIZE 95 :FREE 36 :DELETED 0>)") (6 "(SWANK::UPDATE-INDENTATION/DELTA-FOR-EMACS #<HASH-TABLE :TEST EQ :COUNT 124 {14004AC1}> (#<PACKAGE \"SWANK-IO-PACKAGE\"> #<PACKAGE \"SWANK\"> #<PACKAGE \"SWANK-MOP\"> #<PACKAGE \"SWANK-BACKEND\"> #<PACKAGE \"SWANK-LOADER\"> #<PACKAGE \"WEBLOCKS-ASD\"> ...))") (7 "(SWANK::PERFORM-INDENTATION-UPDATE #<SWANK::CONNECTION {14004B11}> (#<PACKAGE \"SWANK-IO-PACKAGE\"> #<PACKAGE \"SWANK\"> #<PACKAGE \"SWANK-MOP\"> #<PACKAGE \"SWANK-BACKEND\"> #<PACKAGE \"SWANK-LOADER\"> #<PACKAGE \"WEBLOCKS-ASD\"> ...))") (8 "(SWANK::RUN-HOOK (SWANK::SYNC-INDENTATION-TO-EMACS SWANK::SYNC-FEATURES-TO-EMACS))") (9 "((LAMBDA NIL))") (10 "((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {1410E8B5}>)") (11 "((LAMBDA NIL))") (12 "((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {13E2D9F5}>)") (13 "(SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {14004B11}> #<CLOSURE (LAMBDA NIL) {1410E77D}>)") (14 "(SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {14004B11}> #<FUNCTION (LAMBDA NIL) {13E2D9F5}>)") (15 "(SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {14004B11}>)") (16 "(SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {1410E75D}>)") (17 "((FLET SB-THREAD::WITH-MUTEX-THUNK))") (18 "(SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {4D01C2D}> T)") (19 "((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)")) Which not only tells us that the error occurs while Slime is updating identation information, we also (quite accidentally) learn that something is amiss: in frame 7 we see "WEBLOCKS-ASD" which is definitely not part of the normal SBCL distribution... and likely there are others as well. Either this is a custom core, or you do have either .sbclrc, or /etc/sbclrc. Additionally, from the MACRO-FUNCTION & LOOKUP frames I can tell that somehow you have, in some package, a symbol whose name is not a string but a number. This is quite an achievement. :) Constructing a bogus symbol like that is not too hard (SAFETY 0 and lying to the compiler can do it), but getting them interned into a package is a lot harder -- I cannot think of a simple mistake that could cause that even in SAFETY 0 code. In other words, something is probably badly wrong with the image even before Slime starts. Where do the extra packages like Weblocks come from? Once you know that, does the same error occur if you start without them? Cheers, -- Nikodemus

2 1

[slime-devel] slime-asdf
by Geo Carncross 19 May '08

19 May '08

Any reason slime-asdf doesn't (require :asdf)? I think asdf already provides :asdf so it shouldn't break anything worse if loaded on a system where (require :asdf) can't possibly work, but it'd make (slime-setup '(slime-asdf)) work obviously on systems where :asdf isn't available by default, but (require :asdf) *does* work (e.g. ECL)

2 1

None
by None 18 May '08

18 May '08

Message

1 0

[slime-devel] leopard + sbcl + sb-thread
by Aaron Feng 18 May '08

18 May '08

I recently enabled sb-thread on sbcl 1.0.14. After the sbcl recompile, slime stopped working. When I start up emacs I get the following message: The value 68089408 is not of type SIMPLE-STRING. Restarts: 0: [ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {14565909}>) I have the latest version of slime, and I also recompiled it. Has anyone seen this behavior? Thanks in advance, Aaron

2 5

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 18 May '08

18 May '08

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1353 slime/ChangeLog:1.1354 --- slime/ChangeLog:1.1353 Thu May 8 18:54:54 2008 +++ slime/ChangeLog Sat May 17 07:03:19 2008 @@ -1,3 +1,15 @@ +2008-05-17 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-prin1-to-string): Bind print-length and + print-level. + +2008-05-17 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-inspector-limit): New variable. + (slime-inspector-insert-content): Use it. + (slime-inspector-fetch-chunk, slime-inspector-fetch) + (slime-inspector-next-range, slime-inspector-join-chunks): New. + 2008-05-08 Geo Carncross <geocar(a)gmail.com> * swank-ecl.lisp (call-with-debugging-environment)

1 0

[slime-devel] Installing SBCL - W32 - SLIME - Emacs - Spawning child process: invalid argument
by St/n_P/rm/n 17 May '08

17 May '08

Installing SBCL - Emacs - W32 - SLIME | Error - Spawning child process: invalid argument - I am posting this in hopes that it might prevent some headaches for others. There don't appear to be many recent discussions of sbcl, slime, emacs on Windows systems and I broke my head on this one for awhile. I was getting the following error when starting Slime: "Spawning child process: invalid argument" Problem was probably in two places: 1) Recent install of the sourceforge Windows Binary of SBCL 1.0.13 had not propagated the environmental variables PATH and SBCL_HOME prior to a system restart 2) I was passing the WRONG string in the .emacs: (setq inferior-lisp-program "C:/Program Files/Steel Bank Common Lisp/1.0.13/sbcl.exe") Slime wasn't looking for the path to the sbcl executable. After a restart the system could initialize SBCL from a command prompt i.e. the system variable was now properly set and Slime was able to connect to the inferior lisp by calling "sbcl" from inside emacs with <M-x Slime> The necessary invocation required in the .emacs is contrary to the instructions in the "Slime User Manual v 1.2 circa April 2005" which suggest providing the path to the lisp system - the following was what I SHOULD have had in the .emacs : (setq inferior-lisp-program "sbcl") I am not sure how this affects other lisps or if it is unique to my system. However, with that change in place, I am happy to report that slime will connect with sblc just fine using the following setup: - GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-05-12 on LENNART-69DE564 (patched) Emacsw32 patched from available: http://ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/ptch/Emacs-23-CvsP080512-… - A recent April 2008 cvs pull of Slime cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime or, a recent cvs snapshot tarball http://common-lisp.net/cgi-bin/viewcvs.cgi/root.tar.gz?root=slime&view=tar - SBCL 1.0.13 from: http://prdownloads.sourceforge.net/sbcl/sbcl-1.0.13-x86-windows-binary.msi ---- With slime installed in w32's default site-list directory the following are the relevant portions of the .emacs : (add-to-list 'load-path "C:/Program Files/Emacs/site-lisp/slime") (require 'slime) (slime-setup) (require 'slime-autoloads) (add-hook 'lisp-mode-hook (lambda () (slime-mode t))) (add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t))) ----

1 0

[slime-devel] Inspector features regressed
by Madhu 17 May '08

17 May '08

The default slime inspector used to support a variable called SWANK::*SLIME-INSPECT-CONTENTS-LIMIT* which was useful if you had to inspect large objects for certain programs with some characterestics. This customization has been removed[1] by Helmut's patches of 2008-02-09, replaced with hardcoded behaviour which is a pain in the ass for a few use cases [that I commonly use I can elaborate on these, if someone is interested] Is there some way to get the earlier functionality before, specifically where the limit can be specified and used in the "dynamic extent" of an inspector session? -- Madhu [1] Around July 2007, some [clueless] changes to the inspector broke this functionality, and I had reported these to the mailing list, and submitted my local patches, which were ignored until the functionality was removed. As in the case of slime history behaviour, the concern here is that existing useful functionality has again been removed in the [false name] of simplifying things, and replaced with something significantly worse.

4 7

[slime-devel] Pictures in the REPL -- Big Dirty hack
by Patrick Collison 17 May '08

17 May '08

Hey, I wanted to be able to display images in my SLIME repl, so that I could do stuff like http://collison.ie/img/google-charts.png. I played around with swank.lisp and slime.el for an hour, and hacked together something that mostly works. The code is ugly as sin, but I'm posting it here in case anyone wants to similarly subvert their SLIME installation. If there's any interest in having this be a part of the SLIME distribution, I'm happy to look at cleaning it up... Patch against CVS slime at collison.ie/code/slime-pictures.patch. When applied, test it out with something like: (swank:make-picture :url "http://www.gnu.org/graphics/gnu-head.png" :type 'png) Cheers, Patrick

7 9

[slime-devel] emacs print-level
by petdog 17 May '08

17 May '08

Hi, this will be very quick. It seems nobody got bitten by that yet, so I guess I should leave a trace "on the internet": using slime with emacs' print-level set will fail badly. I suspect print-length is equally dangerous.

3 3