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

[slime-devel] SLIME not running on FreeBSD 5.2.1 wiht SBCL 0.8.5
by Christian Hofer 10 May '04

10 May '04

Hi, when I try to start SLIME within Emacs (GNU, Version 21.3.1.) compilation fails with the error: ; compiling file "/home/chr/slime/swank-sbcl.lisp" (written 01 MAY 2004 01:19:50 AM): debugger invoked on condition of type SIMPLE-ERROR in thread 10047: Don't know how to load SB-BSD-SOCKETS I just fetched SLIME fresh from cvs. Does anybody know what went wrong? Thanks for your help, Chris

2 2

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 09 May '04

09 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.370 slime/ChangeLog:1.371 --- slime/ChangeLog:1.370 Fri May 7 17:12:17 2004 +++ slime/ChangeLog Sat May 8 15:01:05 2004 @@ -1,3 +1,8 @@ +2004-05-08 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-cmucl.lisp (find-definitions): Add support for variables + and constants. + 2004-05-07 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * swank-clisp.lisp (compiler-note-location): Use make-location to

1 0

[slime-devel] Re: charset problem with clisp
by Alex Mizrahi 08 May '04

08 May '04

hello AM> as i understand this is the length of message as char.. AM> looks like it's not good to encode bytes as chars - it's a problem AM> with some charsets, representing it in hex or base64 can be much AM> more portable.. i've changed message length encoding/decoding functions to use 8-char hex value instead of that 3-byte binary value, and it fixed the problem - so i can now move from bare console to slime.. with best regards, Alex 'killer_storm' Mizrahi.

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 08 May '04

08 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.369 slime/ChangeLog:1.370 --- slime/ChangeLog:1.369 Thu May 6 15:55:21 2004 +++ slime/ChangeLog Fri May 7 17:12:17 2004 @@ -1,3 +1,16 @@ +2004-05-07 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-clisp.lisp (compiler-note-location): Use make-location to + instead of `(:location ...). This initializes the new hint slot + automatically. + +2004-05-07 Barry Fishman <barry_fishman(a)att.net> + + * swank.lisp (prin1-to-string-for-emacs, arglist-to-string): CVS + CLISP prints NIL as |COMMON-LISP|::|NIL| if *print-readably* is + true. Set *print-readably* to nil for a more Emacs friendly + printer syntax. + 2004-05-06 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el (slime-maybe-list-compiler-notes): Display the notes

1 0

[slime-devel] Problems with Slime with CLISP on Linux
by Barry Fishman 07 May '04

07 May '04

I have problems running Slime with the CVS version of CLISP on Linux. They are due to the unusual behavior of CLISP to *print-readably*. For example: * (let ((*print-readably* t)) (prin1 '#'+)) #'|COMMON-LISP|::|+| #'+ This I assume is tecnically correct but a bit overkill. If set *print-readably* nil, as in the attached patch, things seem to work, although I suspect there may be problems with an expression I haven't tried. Has nobody else seen these problems? *** swank.lisp-sav 2004-05-06 17:01:52.000000000 -0400 --- swank.lisp 2004-05-06 17:20:44.000000000 -0400 *************** *** 719,725 **** (defun prin1-to-string-for-emacs (object) (with-standard-io-syntax (let ((*print-case* :downcase) ! (*print-readably* t) (*print-pretty* nil) (*package* *swank-io-package*)) (prin1-to-string object)))) --- 719,725 ---- (defun prin1-to-string-for-emacs (object) (with-standard-io-syntax (let ((*print-case* :downcase) ! #-clisp (*print-readably* t) #+clisp (*print-readably* nil) (*print-pretty* nil) (*package* *swank-io-package*)) (prin1-to-string object)))) *************** *** 856,861 **** --- 856,862 ---- (*print-case* :downcase) (*print-pretty* t) (*print-circle* nil) + #+clisp (*print-readably* nil) (*print-level* 10) (*print-length* 20)) (pprint-logical-block (nil nil :prefix "(" :suffix ")") -- Barry Fishman

3 7

[slime-devel] Re: [slime-cvs] CVS update: slime/ChangeLog slime/slime.el slime/swank-openmcl.lisp
by Luke Gorrie 07 May '04

07 May '04

Marco Baringer <mbaringer(a)common-lisp.net> writes: > + * swank-openmcl.lisp (*buffer-offset*, *buffer-name*): Supply > + default values. This avoids unbound value errors when compiling an > + asdf system signals errors. Do you know why the errors come about? I think the idea of not having default bindings for those variables is to trap bugs elsewhere. This might be one.

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 07 May '04

07 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.367 slime/ChangeLog:1.369 --- slime/ChangeLog:1.367 Tue May 4 15:17:43 2004 +++ slime/ChangeLog Thu May 6 15:55:21 2004 @@ -1,3 +1,23 @@ +2004-05-06 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-maybe-list-compiler-notes): Display the notes + listing after C-c C-c only if there are no annotations in the + buffer. CMUCL creates usually one warning with an error location + and an almost redundant warning without at the end of the + compilation unit. Don't display the listing in this common case. + + (slime-reindent-defun): Pass nil as the third arument to + indent-region. + +2004-05-06 Marco Baringer <mb(a)bese.it> + + * slime.el (slime-repl-sayoonara): Don't attempt to quit the lisp + if we're not connected. + + * swank-openmcl.lisp (*buffer-offset*, *buffer-name*): Supply + default values. This avoids unbound value errors when compiling an + asdf system signals errors. + 2004-05-04 Alan Shutko <ats(a)acm.org> * slime.el (slime-compiler-notes-show-details/mouse): New command. @@ -7,7 +27,7 @@ * swank-cmucl.lisp (arglist): Handle byte-code functions better. We don't know much about the actual argument list, only the number - of arguments. Return at lest something mildly interesting like + of arguments. Return at least something mildly interesting like (arg0 arg1 &optional arg2 ...) (function-location): Special-case byte-code functions.

1 0

[slime-devel] OpenMCL backend broken by OpenMCL 0.14.2
by Will 06 May '04

06 May '04

Hello, OpenMCL 0.14.2 is now out and SLDB does not work with it. The following is an excerpt from my conversation with Gary Byers discussing MAP-BACKTRACE: Gary Byers <gb(a)clozure.com> writes: ... > > Yes; this is now wrong. Low-level stack-walking functions that > used to take a TCR ("thread context record") as an argument now > either default to walking the current thread's stacks or take > another thread's "backtrace context". Since this is trying to > do a backtrace on the current thread, it never needed to pass > the current TCR around. > >(The whole issue is that you can't just arbitrarily look at > another thread's stack in general, since it's likely to be > moving around as you're looking at it. Even if you could, the > information in the TCR is only accurate at certain points in the > thread's execution. You can look at certain parts of another > thread's stack if you're sure that that thread is in a break > loop while you're looking.) > > It looks like the function that this function maps takes a TCR > as an argument; if that function passes that TCR to other > low-level stack-walking code, it'll run into the same problem. > Passing NIL explictly may work. Setting the 'tcr' variable to NIL instead of CCL::%CURRENT-TCR in MAP-BACKTRACE does allow the debugger to present the first backtrace, but it seems broken upon using some of the restarts. Unfortunately this is all voodoo to me, but hopefully it is helpful to someone =) Regards, Will

3 2

[slime-devel] Font-lock trickery
by Nikodemus Siivola 05 May '04

05 May '04

Instead of doing something useful I spent the first part of the day coaxing/cargo-culting emacs to fontify user-definied defoo forms nicely. In case someone else is was annoyed by the this lack of angry-fruit-saladness, here goes (eg. add this to lisp-mode-hook): ;; Fontification for user-defined defoo macros (font-lock-add-keywords 'lisp-mode '(("(\\(def.*?\\)\\>[ '(]*\\(setf[ ]+\\sw+)\\|\\sw+\\)?" (1 font-lock-keyword-face) (2 (let ((name (match-string 2))) (when name (cond ((string-match "^\\*" name) font-lock-variable-name-face) ((string-match "^\\+" name) font-lock-constant-name-face) (t font-lock-function-name-face))))))) t) Won't take effect without restarting emacs -- or some other trickery that I'm not aware of. Cheers, -- Nikodemus

2 1

[slime-devel] SLIME Edit Definition
by Lynn Quam 05 May '04

05 May '04

I note that Edit Definition (meta-dot) in SLIME is inaccurate in positioning "point" when the buffer(file) has been modified by adding, removing or rearranging parts of the buffer(file). I recognize that this is, in general, a difficult problem. Is the "pragmatic solution" to do "Compile/Load File" when changes to the buffer make the source code location information useless? Back in the "good old days" with (1mhz) Symbolics Lisp Machines and the ZWEI editor, "buffer sectionization" did a pretty good job of keeping track of the source code locations. This allowed top level white-space and modifications of function defintions to be made without losing track of the source code location. Are there any thoughts about makeing slime.el smarter about changes to the Lisp source code?

5 12