slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] too-eager *print-circle* binding in debugger
by Nikodemus Siivola 28 Jun '09

28 Jun '09

Test case: (error "~a" "duh") in terminal: debugger invoked on a SIMPLE-ERROR: duh in Slime: #1=#1# [Condition of type SIMPLE-ERROR] ...which is a bit suboptimal... Cheers, -- Nikodemus

3 4

[slime-devel] Daily ChangeLog diff
by Helmut Eller 28 Jun '09

28 Jun '09

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1793 slime/ChangeLog:1.1794 --- slime/ChangeLog:1.1793 Thu Jun 25 00:06:15 2009 +++ slime/ChangeLog Sat Jun 27 11:10:29 2009 @@ -2,6 +2,11 @@ * swank-ecl.lisp: Profiling support by Marko Kocić +2009-06-27 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-beginning-of-symbol): Skip over #., #-, and #+. + ([test] symbol-at-point.15 .. 17): Test it. + 2009-06-24 Nikodemus Siivola <nikodemus(a)random-state.net> Add :WAIT keyword argument to support blocking in

1 0

Re: [slime-devel] Connection to Emacs lost. condition: junk in string
by Kelly McDonald 28 Jun '09

28 Jun '09

Not sure if this is going to get threading hooked up correctly as I just joined the list. >Recently when I evaluate a relatively big function in slime (more that 6 >lines of code) I lose connection with swank. >I tried Emacs with different versions and slime with different versions, so >I don't know where else I can look for an error. >Could it be something with network on this particular workstation? I had this same behavior when evaluating a ~30k section of code. After a bit of debugging , I found that My setup: sbcl 1.0.29 (both binary x86 and local built 64bit - no threads enabled) slime/swank from git (or was that cvs?) 1) Threads were not available 2) the read-packet was getting interrupted by another swank event, it would read the packet length from the stream, but the first event had not finished yet so it was reading random characters in the first event to determine the length of the next packet and it crashed in parse-integer 3) wait-for-event was being recalled before the event had completely decoded. 4) I had turned logging on and I had seen (READ: 003999 - 6 digit packet length) (wait-for-event: ~s ~s~%) (READ: strjunk) being printed, instead of (READ:003999) (READ:validpacket). (I added some other logging points as well) 5) I think the problem was somewhere in wait-for-event/event-loop - but I didn't totally understand the code enough (and didn't have time enough) do debug any further. 6) I enabled threads in sbcl and the problem went away. Sorry I could not provide a patch or more information. If you have something for me to try, please let me know and I will test. Kelly McDonald

2 4

[slime-devel] renaming symbols locally
by Nikodemus Siivola 27 Jun '09

27 Jun '09

I got fed up doing this manually, and wrote the following. I'm know there are pre-existing versions and this isn't probably the best one, but it has one feature I missed: it checks for conflict potential before starting the renaming. Something like this would be nice to have in Slime, I think. Is there a contrib that would be appropriate for this? Also, this is way too deep in elisp-land for me to feel quite confident that this is a sane way to do this. (defun ns:slime-rename-symbol-in-defun (old new) "Replace `old' with `new' in the current defun." (interactive "sSymbol to replace: \nsSymbol to replace with: ") (catch 'abort (let ((count 0)) (save-excursion (destructuring-bind (start end) (slime-region-for-defun-at-point) ;; First scan to see if we have conflicts... (let ((size (length new)) (p start)) (goto-char start) ;; KLUDGE: no forward-op for slime-symbols, but this gets most ;; things right when used with SLIME-SYMBOL-AT-POINT. (forward-thing 'symbol) (loop while (and (< (point) end) (> (point) p)) do (let ((symbol (slime-symbol-at-point))) (when (equalp symbol new) (slime-beginning-of-symbol) (when (ns:slime-highlight-y-or-n-p (format "Pre-existing %s, abort? " new) (point) (+ (point) size)) (throw 'abort nil)) (slime-end-of-symbol))) (setf p (point)) (forward-thing 'symbol))) ;; ...then scan again to replace. (let ((size (length old)) (p start)) (goto-char start) (forward-thing 'symbol) (loop while (and (< (point) end) (> (point) p)) do (let ((symbol (slime-symbol-at-point))) (when (equalp symbol old) (slime-beginning-of-symbol) (when (ns:slime-highlight-y-or-n-p "Rename? " (point) (+ (point) size)) (delete-char size) (insert-string new) (incf count)) (slime-end-of-symbol))) (setf p (point)) (forward-thing 'symbol)))) (message "%d occurrances of %s replaced with %s" count old new) t)))) (defun ns:slime-highlight-y-or-n-p (string start end) "Ask a y-or-n-p question using `string' with the region delimited by `start' and `end' highlighted." (let (hilite) (unwind-protect (progn (setf hilite (make-overlay start end)) (overlay-put hilite 'face 'slime-highlight-face) (y-or-n-p string)) (when hilite (delete-overlay hilite))))) Cheers, -- Nikodemus

2 2

[slime-devel] slime-symbol tweaking
by Nikodemus Siivola 27 Jun '09

27 Jun '09

While I appreciate that it is better to try not too hard here, I run into #.foo not completing often enough. This: (defun slime-beginning-of-symbol () "Move to the beginning of the CL-style symbol at point." (while (re-search-backward "\\(\\sw\\|\\s_\\|\\s\\.\\|\\s\\\\|[#@|]\\)\\=" nil t)) (re-search-forward "\\=#[<|]" nil t) (when (and (looking-at "@") (eq (char-before) ?\,)) (forward-char)) (when (and (looking-at "#\\.")) (forward-char 2))) addresses the issue. Normally I would just commit this, but given the recent work on slime-symbol I was not sure if could be controversial? Cheers, -- Nikodemus

3 4

[slime-devel] [Patch] CCL source notes processing error
by Stas Boukarev 26 Jun '09

26 Jun '09

In new versions of CCL compiler-warning-nrefs slot in the compiler-warning class is now a list, not an integer. -- With best regards, Stas.

1 1

[slime-devel] Slime with ECL startup bug
by Ghost99 26 Jun '09

26 Jun '09

After i run Slime on Emacs, using ECL as inferior-lisp-program, i see a lot of type conversion errors from gcc. When i post it on ecl bug-tracker, them answers: Slime contains lisp code that is executed by the different Common Lisp implementations. Unfortunately the slime port for ECL has been out of date for quite some time. Patches were submitted to the Slime maintainers and so far it seems they work, but they might only be available in CVS. Please do not report Slime problems here, but to the Slime mailing list. If _they_ find out it is _not_ a Slime problem, then bug reports will be accepted here. Full slime output can be downloaded from here http://sourceforge.net/tracker/download.php?group_id=30035&atid=398053&file… I have last versions of ECL (from GIT) and Slime (from CVS), and upgrade them every day. Emacs-22.3 System x86_64 GNU/Linux. Gentoo.

2 1

[slime-devel] Invalid characters and contrib/slime-repl.el
by Mark Cox 26 Jun '09

26 Jun '09

Hi slime-devel, When an invalid character is sent to the remote lisp from the REPL, an error is signalled leaving the cursor in a funny position. The following patch to SLIME-REPL-EVAL-STRING fixes that by calling the :abort result handler. Is there a case for putting this error handling in SLIME-DISPATCH- EVENT (:emacs-rex path) so all components get the :abort message when an error in transmission occurs? Thanks Mark Index: slime-repl.el =================================================================== RCS file: /project/slime/cvsroot/slime/contrib/slime-repl.el,v retrieving revision 1.22 diff -r1.22 slime-repl.el 521,526c521,533 < (slime-rex () < ((list 'swank:listener-eval string) (slime-lisp-package)) < ((:ok result) < (slime-repl-insert-result result)) < ((:abort) < (slime-repl-show-abort)))) --- > (let ((send-error t)) > (unwind-protect > (progn > (slime-rex () > ((list 'swank:listener-eval string) (slime-lisp-package)) > ((:ok result) > (slime-repl-insert-result result)) > ((:abort) > (slime-repl-show-abort)) > ) > (setf send-error nil)) > (when send-error > (slime-repl-show-abort)))))

2 1

[slime-devel] allegro compiler-note
by Gábor Melis 26 Jun '09

26 Jun '09

Hello Previously, handling of compiler-note in call-with-compilation-hooks was commented out. It isn't now, and I'm getting a host of uninteresting "Closure XXX will be stack allocated" notes and nothing else. Since compiler-note is defined as (or excl::compiler-note compiler::compiler-note) neither of which is public I wonder if it's intended to be handled by the user. I have this in my .swank.lisp for now: #+allegro ;;; Silence those notes on allegro. (defun swank-backend::compiler-note-p (object) (declare (ignore object)) nil) Cheers, Gabor

1 0

[slime-devel] Daily ChangeLog diff
by Helmut Eller 26 Jun '09

26 Jun '09

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1784 slime/ChangeLog:1.1786 --- slime/ChangeLog:1.1784 Sun Jun 14 13:07:03 2009 +++ slime/ChangeLog Mon Jun 15 14:17:47 2009 @@ -1,3 +1,15 @@ +2009-06-15 Helmut Eller <heller(a)common-lisp.net> + + * swank-openmcl.lisp: Explicitly require CCL version 1.3. + +2009-06-15 Helmut Eller <heller(a)common-lisp.net> + + * swank-openmcl.lisp (emacs-inspect [t]): Honor the type returned + by inspector::line-n. + (emacs-inspect [compiled-lexical-closure]): Deleted. Let CCL's + inpector handle this case. Which does it better and it's less work + for us. + 2009-06-14 Helmut Eller <heller(a)common-lisp.net> Some workarounds for SBCL on Windows. Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.217 slime/contrib/ChangeLog:1.218 --- slime/contrib/ChangeLog:1.217 Sun Jun 14 12:47:34 2009 +++ slime/contrib/ChangeLog Tue Jun 16 02:36:40 2009 @@ -1,3 +1,10 @@ +2009-06-16 Tobias C. Rittweiler <tcr(a)freebits.de> + + * slime-fontifying-fu.el (slime-search-suppressed-form): + Additional exit constraint for the loop; make sure we'r still in + the limit. + (slime-compute-region-for-font-lock): Simplify. + 2009-06-14 Tobias C. Rittweiler <tcr(a)freebits.de> * slime-fontifying-fu.el (slime-search-suppressed-form): Retry the

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel