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

[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

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

05 May '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.363 slime/ChangeLog:1.367 --- slime/ChangeLog:1.363 Sun May 2 15:09:50 2004 +++ slime/ChangeLog Tue May 4 15:17:43 2004 @@ -1,3 +1,42 @@ +2004-05-04 Alan Shutko <ats(a)acm.org> + + * slime.el (slime-compiler-notes-show-details/mouse): New command. + (slime-compiler-notes-mode-map): Use it. + +2004-05-04 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * 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 + (arg0 arg1 &optional arg2 ...) + (function-location): Special-case byte-code functions. + + * swank-backend.lisp (with-struct): New macro. + +2004-05-04 Thomas F. Burdick <tfb(a)OCF.Berkeley.EDU> + + * slime.el (slime-reindent-defun): New command on C-M-q. Reindent + the current Lisp defun after trying to close any unmatched + parenthesis. If used within a comment it just calls fill-paragraph. + +2004-05-04 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-goto-location-position): Regexp fix. + (slime-reindent-defun): New command on M-q. Reindent the current + Lisp defun after trying to close any unmatched parenthesis. + + * swank.lisp: Remove (declaim (optimize ...)). The side-effect + this has on people's environment seems harmful (I saw someone + having trouble on the OpenMCL list). + + * swank-cmucl.lisp (source-location-from-code-location): Fixed a + bug where the source-file-cache was not really used. + Now always report the location based on source file (cached or + not) even if modified -- not falling back on regexps, which was + probably a misfeature. + + * slime.el: Remove `slime-cleanup-definition-refs'. + 2004-05-02 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el (slime-start-and-load): New command. Suggested by

1 0

[slime-devel] swank-backend:arglist in CMUCL
by rydis＠CD.Chalmers.SE 05 May '04

05 May '04

Hi, I was looking at ripping some useful stuff from SLIME to Hemlock, and noticed that swank-backend:arglist doesn't seem to work very well with byte-compiled functions in my current version. (Which is CMUCL from CVS per 2004-04-20; SLIME as of earlier today.) All calls to swank-backend:arglist on a function that has been byte-compiled gives (C:&MORE C::CONTEXT COUNT). The problem seems to be that kernel:%function-self, called by arglist, in that case, returns a general-ish #<Function "DEFUN INITIALIZE-BYTE-COMPILED-FUNCTION>, which has that kind of arglist. "Test case": * (let ((c::*byte-compile* t)) (compile (defun foo (bar &rest zot) (list* bar zot)))) ; Converted FOO. ; Byte Compiling LAMBDA (BAR &REST ZOT): ; Byte Compiling Top-Level Form: FOO NIL NIL * (swank-backend:arglist 'foo) (C:&MORE C::CONTEXT COUNT) Regards, 'mr -- [Emacs] is written in Lisp, which is the only computer language that is beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_

2 2