slime-devel August 2010

slime-devel@common-lisp.net

28 participants
40 discussions

[slime-devel] Standard output no longer appears in REPL
by Steven E. Harris 25 Jun '11

25 Jun '11

It's been a couple of months since I last used SLIME. Today I noticed that when I evaluate expressions in the REPL that write to *standard-output*, the output appears in the *inferior-lisp* buffer, but not in the REPL as it used to. I'm using GNU Emacs on Windows atop the CLISP Cygwin build. SLIME is up to date with CVS. Is there some new configuration required to restore the old behavior with output streams feeding into the REPL output? -- Steven E. Harris

5 12

[slime-devel] Slime vs Franz Eli
by Chris Kim 13 Apr '11

13 Apr '11

Hi, all, I've been using Slime on top of Franz ACL for quite a while. My experience with Slime is very positive and I like Slime better in every aspects except in following situations. 1. Slime debugger: It prints bunch of Slime (swank: ..... ) related messages that I'm not interested. It's always hard to trying to comb through messages that I'm interested. How can I turn Slime related messages off? 2. While debugging, evaulating expression does not print anything but only the retuned result. Can I have it print to the standard output, i.e., console? 3. Lack of REPL command: Franz Eli supports REPL commands, for example, ":proc" for listing processes, ":pa" to change package and so on. Is there way to add them in? Thank you very much and I appreciate your efforts making Slime the best list-emacs interface. -chris

6 14

[slime-devel] [investigation] Font lock, reader macros and SLIME repl
by Anton Kovalenko 09 Sep '10

09 Sep '10

Hello SLIME developers, Both in the lisp-mode and in slime REPL, there is currently one major thing that Emacs isn't getting right: constructs using reader macros like #P"/home/" and #2A((1 0) (0 1)) are regarded as two sexps instead of one. E.g. command for wrapping a sexp may turn #P"/home/" into (#P)"/home/", etc. It gets even more awful with paredit-mode (that I prefer to use), but the problem is noticeable even without it. I have investigated one possible solution to it, and here are the results. First, I decided to limit the scope of solution to some predefined "shape" of reader macro: for starters, when #\# is used as dispatch macro character, and its reader function calls READ to get the sexp following #[numarg]<char>. This is the case with all standard reader-macros and many implementation-specific and user-defined ones. Furthermore, I discarded the possibility to consult SWANK for the buffer's *readtable* (SWANK doesn't *know* it, anyway). To get right behavior for #P, #2A and the like, the most appropriate syntax for all macro-characters seems to be `expression prefix': we want Emacs to regard the whole #P thing as it would regard a quote, backquote or comma. Let's use the feature of font-lock mode in modern emacsen: syntactic keywords (in a nutshell, it's when a code used for text-coloring is [ab]used to add syntax-table properties to some text fragments). `parse-sexp-lookup-properties' set to true causes the sexp machinery to look into syntax-table properties of individual characters. Let's add a syntactic keyword to lisp-mode: (defun aak:add-lisp-reader-macros-syntactic-keyword () "Register # numarg macro-character as a font lock syntactic keyword, turning it into expression prefix." (set (make-local-variable 'parse-sexp-lookup-properties) t) (set (make-local-variable 'font-lock-syntactic-keywords) '(("\$\\W\\|$\$\\#\$[0-9]*[A-Za-z]\$" (2 "'"))))) (add-hook 'lisp-mode-hook 'aak:add-lisp-reader-macros-syntactic-keyword) With the hook above, any lisp-mode buffer with font-lock mode enabled gets good enough navigation/wrapping/unwrapping for previously misinterpreted items. I decided to leave macro-characters handled by this regexp to [A-Za-z], because normal behavior of reading the following sexp can't really be expected from other characters: readtable additions along the lines of #"something" and #{something} are also popular, and we can't get _them_ right without knowing a concrete syntaxt they expect. Another decision that has its merits is to limit it further to _standard_ macro-characters only. Now I wanted the same thing to be active for slime-repl mode. The only obstacle was that slime-repl mode is currently font-lock-unfriendly: when some faces are set programmatically and some left to font-lock, the programmatically-set faces should use font-lock-face property instead of face property (the latter gets overridden by font-lock results). A workaround that I use currently is the following advice to add-text-properties: (defadvice add-text-properties (before aak:slime-propertize-with-font-lock-face activate) (when (eq 'slime-repl-mode major-mode) (let* ((props (ad-get-arg 2)) (face (getf props 'face))) (when face (push face props) (push 'font-lock-face props) (when (memq 'face (getf props 'rear-nonsticky)) (push 'font-lock-face (getf props 'rear-nonsticky))) (ad-set-arg 2 props))))) When in slime-repl mode, it copies face property to font-lock-face property, and also makes it rear-nonsticky when face is requested to be. It's the only part that really touches SLIME, and I think it would better insert font-lock-face property itself, together with face property (don't forget rear-nonstickyness). This duplication (face => font-lock-face) does no harm when font-lock mode is disabled, but enables slime-repl buffer to be used with font-lock enabled as well. Another hook to enable font-lock mode in slime buffers: (defun aak:enable-font-lock-for-slime-repl () "Enable font lock mode in slime REPL buffer." (font-lock-fontify-buffer) ;; don't know why it's needed.. (font-lock-mode 1)) (add-hook 'slime-repl-mode-hook 'aak:add-lisp-reader-macros-syntactic-keyword) (add-hook 'slime-repl-mode-hook 'aak:enable-font-lock-for-slime-repl) NB. The problem that I'm trying to solve is even more important for slime-repl buffers, where incorrect sexp wrapping tends to break _presentations_ apart. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia

4 7

[slime-devel] C-c C-k, swank-compile-file, and compile-file's failurep
by Tobias C Rittweiler 03 Sep '10

03 Sep '10

Should C-c C-k try to load a resulting fasls file ALWAYS? Should it only do so if COMPILE-FILE did not return T as failurep? >From glancing, SBCL's and CMUCL's swank backends do the latter. Most other backends use an implementation dependent :LOAD keyword argument to COMPILE-FILE which I haven't checked what their semantics are on this matter. I wouldn't be surprised if the differ. The thing is that I sometimes want the first behaviour (early stage of development), sometimes the latter (precious state in the image). If C-c C-k always loaded, you could get the other behaviour by using C-c M-k instead (compile only) and C-c C-l afterwards if compilation didn't fail. If C-c C-k regarded failurep, you could force loading afterwards by C-c C-l. So both behaviours are available. I just pledge for consistency across backends. -T.

3 3

[slime-devel] gdb support for cmucl/sparc
by Raymond Toy 31 Aug '10

31 Aug '10

Here are a couple of replacement functions that make slime disassemble work with cmucl/sparc. The disassembly works for me on cmucl/sparc. The foreign source location appears to work, but the only foreign function I've been able to test with is call_into_lisp which doesn't have any line info. But slime recognizes that and prints a message to that affect. Ray > (defun frame-ip (frame) > "Return the (absolute) instruction pointer and the relative pc of FRAME." > (if (not frame) > (sys:int-sap (ldb (byte vm:word-bits 0) -1)) > (let ((debug-fun (di::frame-debug-function frame))) > (etypecase debug-fun > (di::compiled-debug-function > (let* ((code-loc (di:frame-code-location frame)) > (component (di::compiled-debug-function-component debug-fun)) > (pc (di::compiled-code-location-pc code-loc)) > (ip (sys:without-gcing > (sys:sap-int > (sys:sap+ (kernel:code-instructions component) pc))))) > (values ip pc))) > (di::interpreted-debug-function > (sys:int-sap (ldb (byte vm:word-bits 0) -1))) > (di::bogus-debug-function > #-x86 > (let* ((real (di::frame-real-frame (di::frame-up frame))) > (fp (di::frame-pointer real))) > #+(or) > (progn > (format *debug-io* "Frame-real-frame = ~S~%" real) > (format *debug-io* "fp = ~S~%" fp) > (format *debug-io* "lra = ~S~%" > (kernel:stack-ref fp vm::lra-save-offset))) > (values > (sys:int-sap > (kernel:get-lisp-obj-address > (kernel:stack-ref fp vm::lra-save-offset))) > 0)) > #+x86 > (let ((fp (di::frame-pointer (di:frame-up frame)))) > (multiple-value-bind (ra ofp) (di::x86-call-context fp) > (declare (ignore ofp)) > (values ra 0)))))))) > > (defun foreign-frame-p (frame) > #-x86 > (let ((ip (frame-ip frame))) > (and (sys:system-area-pointer-p ip) > (typep (di::frame-debug-function frame) 'di::bogus-debug-function))) > #+x86 > (let ((ip (frame-ip frame))) > (and (sys:system-area-pointer-p ip) > (multiple-value-bind (pc code) > (di::compute-lra-data-from-pc ip) > (declare (ignore pc)) > (not code))))) > > (defun gdb-exec (cmd) > (with-temporary-file (file filename) > (write-string cmd file) > (force-output file) > (let* ((output (make-string-output-stream)) > ;; gdb on sparc needs to know the executable to find the > ;; symbols. Without this, gdb can't disassemble anything. > ;; NOTE: We assume that the first entry in > ;; lisp::*cmucl-lib* is the bin directory where lisp is > ;; located. If this is not true, we'll have to do > ;; something better to find the lisp executable. > (lisp-path > #+sparc > (list > (namestring > (probe-file > (merge-pathnames "lisp" > (car (lisp::parse-unix-search-path lisp::*cmucl-lib*)))))) > #-sparc > nil) > (proc (ext:run-program "gdb" `(,@lisp-path "-batch" "-x" ,filename) > :wait t > :output output))) > (assert (eq (ext:process-status proc) :exited)) > (assert (eq (ext:process-exit-code proc) 0)) > (get-output-stream-string output))))

2 2

[slime-devel] Bugtracker for Slime at Launchpad
by Stas Boukarev 31 Aug '10

31 Aug '10

Though there wasn't much consensus on what bugtracker to use I went ahead and registered one at Launchpad: https://bugs.launchpad.net/slime/ -- With Best Regards, Stas.

1 0

[slime-devel] Binding C-a / HOME
by pjb＠informatimago.com 30 Aug '10

30 Aug '10

There's a bug in slime, it binds HOME to slime-repl-bol, and does it so that it's very hard to rebind it to the normal beginning-of-buffer. I tried to override slime-repl-bol, but of course, then C-a doesn't work as beginning-of-line anymore. Please, don't bind HOME! -- __Pascal Bourguignon__ http://www.informatimago.com/

5 5

[slime-devel] Daily ChangeLog diff
by Helmut Eller 29 Aug '10

29 Aug '10

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2131 slime/ChangeLog:1.2132 --- slime/ChangeLog:1.2131 Wed Aug 25 04:20:09 2010 +++ slime/ChangeLog Sat Aug 28 20:00:09 2010 @@ -1,3 +1,11 @@ +2010-08-28 Stas Boukarev <stassats(a)gmail.com> + + * swank-cmucl.lisp (*gdb-program-name*): Determine gdb location + from PATH. + (gdb-exec): Use *gdb-program-name* instead of "gdb". + (gdb-command): Mac OS X compatibility. + Patch by Raymond Toy. + 2010-08-25 Stas Boukarev <stassats(a)gmail.com> * swank-sbcl.lisp (exec-image): Use (car sb-ext:*posix-argv*) if

1 0

[slime-devel] Some small fixes/enhancements for swank-cmucl
by Raymond Toy 29 Aug '10

29 Aug '10

Here are a couple of small fixes. They're not patches, but the changes are very simple. If you want a patch, I can send that too. First, let swank-cmucl figure out where gdb is: (defvar *gdb-program-name* (ext:enumerate-search-list (p "path:gdb") (when (probe-file p) (return p)))) Also, disassemble-frame doesn't work on Mac OS X. I guess the prompt is not quite right. Here is replacement that works for me: (defun gdb-command (format-string &rest args) (let ((str (gdb-exec (format nil "interpreter-exec mi2 \"attach ~d\"~%~ interpreter-exec console ~s~%detach" (getpid) (apply #'format nil format-string args)))) (prompt (format nil #-(and darwin x86) "~%^done~%(gdb) ~%" #+(and darwin x86) "~%^done,thread-id=\"1\"~%(gdb) ~%"))) (subseq str (+ (or (search prompt str) 0) (length prompt))))) Not sure about the (or (search prompt str) 0) part, but it might be better to suck in the whole string than to error out when search return NIL. Ray

2 1

[slime-devel] gdb-exec and gdb for cmucl
by Raymond Toy 29 Aug '10

29 Aug '10

I noticed that gdb-exec has this: (ext:run-program "gdb" ...) Should "gdb" be replaced by *gdb-program-name*? I suppose it's ok if gdb and *gdb-program-name* are the same but they might be different since *gdb-program-name* is currently hardwired to /usr/bin/gdb. Ray

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 August 2010