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

[slime-devel] slime.el defface slime-repl-inputed-output-face
by Madhu 14 Dec '06

14 Dec '06

[reported to the author] This problem shows up if you use color-theme.el. (Say) M-x color-theme-high-contrast results in the following error: ``face-attribute: Wrong type argument: symbolp slime-repl-inputed-output-face'' The following changelog entry may apply. |2005-05-18 Antonio Menezes Leitao <aml(a)gia.ist.utl.pt> The following appears to fix it by fixing the :inherit properties (I havent checked against all emacses) =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.698 diff -r1.698 slime.el 508c508 < (slime-repl-inputed-output-face)))) --- > slime-repl-inputed-output-face)))

1 0

[slime-devel] #'completion-output-symbol-converter
by Madhu 13 Dec '06

13 Dec '06

When (read-table-case *READTABLE*) is :upcase completing M-V-B<TAB> fails. Similarly :downcase. This is (I believe) because of a change introduced in |2006-10-26 Attila Lendvai <attila.lendvai(a)gmail.com> | (completion-output-symbol-converter): New to handle escaped | symbols for those who need to mess around with symbols like | layered-function-definers::|CONTEXTL::SLOT-VALUE-USING-LAYER|. | When a symbol is escaped then completion is case sensitive. The following patch fixes it [the heuristic] to work as before. --- swank.lisp.~1.422~ 2006-12-10 14:51:16.000000000 +0530 +++ swank.lisp 2006-12-10 16:05:14.000000000 +0530 @@ -3242,7 +3242,7 @@ INPUT is used to guess the preferred case." (ecase (readtable-case *readtable*) (:upcase (cond ((or with-escaping-p - (every #'upper-case-p input)) + (not (some #'lower-case-p input))) #'identity) (t #'string-downcase))) (:invert (lambda (output) @@ -3252,7 +3252,7 @@ (upper (string-downcase output)) (t output))))) (:downcase (cond ((or with-escaping-p - (every #'lower-case-p input)) + (not (some #'upper-case-p input))) #'identity) (t #'string-upcase))) (:preserve #'identity)))

2 1

[slime-devel] inspecting an object from the debugger
by Attila Lendvai 13 Dec '06

13 Dec '06

dear list, seems like when the inspector is opened up in the slime debugger, then it's running the swank side queries/actions in a different thread then the debugger is sitting in. to test this with cvs head see the following: (this is slime cvs head, sbcl cvs head) DT> (defclass foo () ((foo-slot))) DT> (defvar *global*) DT> (defmethod swank::inspect-slot-for-emacs (class (object foo) slot) (let ((result (call-next-method))) (append result `((:action "[test action]" ,(lambda () (setf (slot-value object 'foo-slot) *global*))))))) DT> (let ((*global* 42)) (break "~A" (make-instance 'foo))) ; Evaluation aborted pressing the action results in a *global* is unbound error. is there some fundamental problem behind this or it's just a simple bug? would be nice if someone with more insight into connection/thread handling could take a look at this. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)

1 1

[slime-devel] Slime merges windows when closing down a macroexpansion ..
by Lars Rune Nøstdal 13 Dec '06

13 Dec '06

The problem is that Slime merges windows whenever I compile something C-c-k and when I'm done watching a macro-expansion (closing it with q). This seems to be have been happening for a while as I've been following CVS HEAD; the problem is not visible in FAIRLY-STABLE. ..it's starting to get really annoying and I've gone back to FAIRLY-STABLE now; am I the only one seeing this? -- Lars Rune Nøstdal http://nostdal.org/

1 1

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 13 Dec '06

13 Dec '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1018 slime/ChangeLog:1.1019 --- slime/ChangeLog:1.1018 Fri Dec 8 08:32:45 2006 +++ slime/ChangeLog Tue Dec 12 10:40:19 2006 @@ -1,3 +1,20 @@ +2006-12-12 Nikodemus Siivola <nikodemus(a)random-state.net> + + * swank.lisp (inspect-for-emacs integer): Pad the hex formatted + value to eight digits, "Code-char:" instead of "Corresponding + character:", "Integer-length:" instead of "Length:", + "Universal-time:" instead of "As time". + (inspect-object): Use TYPE-FOR-EMACS instead of TYPE-OF. + (inspect-in-emacs): New function, analogous to ED-IN-EMACS. + + * swank-backend.lisp (type-for-emacs): New generic function, + defaults to TYPE-OF for non-integers, and returns FIXNUM or BIGNUM + for integers. + + * slime.el (destructure-case): Indicate in the error message that + it was the Elisp destructure-case that failed to avoid confusion. + (slime-check-eval-in-emacs-enabled): More verbose error message. + 2006-12-07 Marco Baringer <mb(a)bese.it> * swank.lisp (init-inspector): Added eval parameter. If NIL we

1 0

[slime-devel] problem compiling files defining packages
by Lynn Winebarger 12 Dec '06

12 Dec '06

Hi, First, I want to thank the developers for this Lisp IDE. It's very cool. But.... I was trying to compile a file with C-c M-k, and the file started out (defpackage "my-package" (:intern <stuff>) (:use "COMMON-LISP")) (in-package "my-package") Now, this is my first attempt at compiling a CL file (under SBCL 0.9.18), with or with a package involved. And it kept spitting out errors for the stuff after these two lines, and I could not for the life of me see why. Clearly it had something to do with the package declaration, because when I commented the above two lines out, I was able to compile the rest of the file. So I drop into a command line SBCL session, and the file compiled just fine. Anyway, I just wanted to let you know, this was very confusing for a CL newbie (been a Schemer for years, just not CL). It doesn't appear to be in the documentation anywhere. I did find some emails that looked vaguely related from the archives of this list using the gmane interface, but it wasn't something I could easily understand. I'm wondering, as CL developers, how do you get around this issue? It seems like it would be a problem. Thanks, Lynn

3 3

[slime-devel] slime.el (slime-repl-merge-histories)
by Madhu 11 Dec '06

11 Dec '06

[Reported to the author 060520] Currently the function slime-repl-merge-histories appears to be buggy in not deleting duplicates, and maintaining order. For example: ELISP> (slime-repl-merge-histories '(1 2 3 4 5) '(2 3 4 8)) (8 1 5 2 3 4) ELISP> (slime-repl-merge-histories '(1 2 3 4 5 1 2 3 4 5) '(2 3 4 8)) (8 1 5 1 5 2 3 4) I believe the desired result is: (2 3 4 8 1 5) so M-p in a fresh repl will pick the last (latest) item from the previous repl session. I believe the following Changelog entry applies, |2005-10-11 Stefan Kamphausen <skampi(a)gmx.net> and would suggest a simpler function that uses delete-duplicates (for strings): (defun slime-repl-merge-histories (old-hist new-hist) "Merge entries from OLD-HIST and NEW-HIST." (remove-duplicates (append new-hist old-hist) :test 'string= :from-end t)) -- Madhu -- ======================================================================= Open system or closed system, enlightenment or ideology, those are the questions. "John C. Mallery" <jcma(a)ai.mit.edu> enometh(a)meer.net http://www.meer.net/~enometh/ 803 Clayton St #2 San Francisco CA 94117 H:415-242-3375 W:408-343-6255 You have new mail

2 1

[slime-devel] Console raw during a SLIME session
by Sean Charles 10 Dec '06

10 Dec '06

Hi, Can anybody help me out here, I am stuck as I don't know what SLIME does with the I/O once it is running. I am writing a data-entry application, console based, and it must be able to perform read-char without having to press return. To effect this I have had to resort to the following development methodology :- (a) open a new xterm or Terminal.app (OS X 10.4.8) window (b) $ stty cbreak (c) $ sbcl (d) load my code (e) start my application It works just fine, my functions getting a date etc all respond to the correct number of keystrokes but the problem is that it doesn't seem to work from SLIME mode ie the "stty cbreak" doesn't seem to be in force if I execute it from within Emacs. So, does anybody know what I have to do to make it such that a single key press is all I need to get read-char to come back with the keypress inside SLIME+EMACS... it's a bit of a pain having to test it from the shell every time I do something major to the application. is there an even Lispier way of doing this, am I missing something, unaware of something... I have only been using Lisp for about four months now and the size of that HyperSpec still makes my brain hurt ;-) Many thanks, Sean Charles

3 4

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 09 Dec '06

09 Dec '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1017 slime/ChangeLog:1.1018 --- slime/ChangeLog:1.1017 Thu Dec 7 06:09:46 2006 +++ slime/ChangeLog Fri Dec 8 08:32:45 2006 @@ -1,4 +1,4 @@ -2006-12-07 mb <mb(a)bese.it> +2006-12-07 Marco Baringer <mb(a)bese.it> * swank.lisp (init-inspector): Added eval parameter. If NIL we don't eval FORM but limit our selves to cl:read'ing it and

1 0

[slime-devel] How to debug a crash?
by Harald Hanche-Olsen 08 Dec '06

08 Dec '06

I have a certain Lisp file that appears to be toxic to the emacs/slime combination. If I edit the file while slime is running (by which I just mean there is a slime-repl buffer with an active lisp in it), emacs crashes. If I edit the same file without slime being active, or edit another lisp file in slime's presence, no crash. Also, I get no crash if emacs runs in a terminal. I should mention that the file in question contains some nonstandard lisp syntax. I have a reader macro that reads in something like @2006-12-03 and converts it to a date. But of course, this is harmless if read with standard syntax: It just becomes another symbol. I am somewhat at a loss as to how I can get enough information out of the crash so as to gain some notion about why and how this happens. A bit of background: The slime is from cvs, downloaded in the past few days. The lisp is sbcl 1.0. I am running GNU Emacs 23.0.0, the emacs-unicode-2 branch out of cvs (somewhat stale) on Mac OS X 10.4.8. If I start sbcl in a terminal window, run (swank:create-server :dont-close) and the connect from slime and trigger the bug, this is what I see in the terminal ;; swank:close-connection: end of file on #<sb-sys:fd-stream for "a constant string" {11CFA201}> which I suppose is the expected result if emacs just goes away for any reason. The crash leaves a backtrace in Library/Logs/CrashReporter/emacs.crash.log which could actually be informative, since my emacs is not stripped. I include it below, in case anybody can make sense out of it. But the following excerpt makes me wonder if it is really some incoming data from the superior lisp that is causing the trouble? 37 emacs 0x0015e68c read_process_output + 1236 (process.c:5088) 38 emacs 0x00160fd4 wait_reading_process_output + 4200 (process.c:4697) 39 emacs 0x0000bcd0 sit_for + 216 (dispnew.c:6412) 40 emacs 0x000be990 read_char + 3016 (keyboard.c:2777) 41 emacs 0x000c1b18 read_key_sequence + 2440 (keyboard.c:8872) 42 emacs 0x000c3768 command_loop_1 + 1064 (keyboard.c:1540) Is there an easy way to get a trace of the traffic between emacs and the superior lisp? I know that some such information is traced on the emacs side, but since emacs crashes, I cannot see it there. - Harald ---------------------------------------------------------------- PS. Sorry, but I won't include the toxic file, as it contains information of a private nature. Anyway, here is the full backtrace. Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0110afff Thread 0 Crashed: 0 emacs 0x00145934 char_quoted + 120 (syntax.c:301) 1 emacs 0x0014ae84 Fbackward_prefix_chars + 604 (syntax.c:2868) 2 emacs 0x00125d8c Ffuncall + 844 (eval.c:2898) 3 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 4 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 5 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 6 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 7 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 8 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 9 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 10 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 11 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 12 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 13 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 14 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 15 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 16 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 17 emacs 0x001259d4 apply_lambda + 248 (eval.c:3013) 18 emacs 0x00125198 Feval + 1312 (eval.c:2283) 19 emacs 0x0012553c Fprogn + 60 (eval.c:432) 20 emacs 0x00128010 Flet + 504 (eval.c:1053) 21 emacs 0x00125280 Feval + 1544 (eval.c:2306) 22 emacs 0x0012553c Fprogn + 60 (eval.c:432) 23 emacs 0x00125888 funcall_lambda + 800 (eval.c:3081) 24 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 25 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 26 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 27 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 28 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 29 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 30 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 31 emacs 0x001571bc Fbyte_code + 2264 (bytecode.c:695) 32 emacs 0x001258b8 funcall_lambda + 848 (eval.c:3088) 33 emacs 0x00125f7c Ffuncall + 1340 (eval.c:2968) 34 emacs 0x00127848 Fapply + 532 (eval.c:2394) 35 emacs 0x001278b4 apply1 + 88 (eval.c:2659) 36 emacs 0x001237ec internal_condition_case_1 + 352 (eval.c:1522) 37 emacs 0x0015e68c read_process_output + 1236 (process.c:5088) 38 emacs 0x00160fd4 wait_reading_process_output + 4200 (process.c:4697) 39 emacs 0x0000bcd0 sit_for + 216 (dispnew.c:6412) 40 emacs 0x000be990 read_char + 3016 (keyboard.c:2777) 41 emacs 0x000c1b18 read_key_sequence + 2440 (keyboard.c:8872) 42 emacs 0x000c3768 command_loop_1 + 1064 (keyboard.c:1540) 43 emacs 0x00123aec internal_condition_case + 344 (eval.c:1474) 44 emacs 0x000b538c command_loop_2 + 64 (keyboard.c:1329) 45 emacs 0x00123660 internal_catch + 256 (eval.c:1211) 46 emacs 0x000b5078 command_loop + 148 (keyboard.c:1311) 47 emacs 0x000b5190 recursive_edit_1 + 176 (keyboard.c:1001) 48 emacs 0x000b5308 Frecursive_edit + 256 (keyboard.c:1063) 49 emacs 0x000b4ba8 main + 4496 (emacs.c:1800) 50 emacs 0x000024d0 _start + 348 (crt.c:272) 51 emacs 0x00002370 start + 60

3 6