slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] select-window
by Christophe Rhodes 30 Aug '08

30 Aug '08

Hi, Emacs 21 (21.4.1 to be precise) doesn't seem to support 2-argument select-window, used in slime-pop-to-buffer in today's CVS. Best, Christophe

2 1

[slime-devel] new inspector on hash-tables
by Madhu 30 Aug '08

30 Aug '08

* (defparameter $ht (make-hash-table)) * (loop for i below 2048 do (setf (gethash i $ht) i)) M-x slime-inspect $ht error in process filter: Wrong type argument: listp, :action

2 1

[slime-devel] sbcl: continual warnings about releasing threads ... me too
by Jason Addison 30 Aug '08

30 Aug '08

I just wanted to say "me too" on this issue. Mac OS X 10.5.4; Intel sbcl 1.0.19 (compiled to enable threads) slime from 8/28/08 I tried the work around (remove the SB-EXT:WITH-TIMEOUT form in RECEIVE-IF in swank-sbcl.lisp) mentioned earlier. I'm not sure if I did it correctly ... (defimplementation receive-if (test &optional timeout) (let* ((mbox (mailbox (current-thread))) (mutex (mailbox.mutex mbox))) (assert (or (not timeout) (eq timeout t))) (loop (check-slime-interrupts) (sb-thread:with-mutex (mutex) (let* ((q (mailbox.queue mbox)) (tail (member-if test q))) (when tail (setf (mailbox.queue mbox) (nconc (ldiff q tail) (cdr tail))) (return (car tail)))) (when (eq timeout t) (return (values nil t))) (handler-case ;(sb-ext:with-timeout 0.2 (sb-thread:condition-wait (mailbox.waitqueue mbox) mutex);) (sb-ext:timeout ())) ) ))) It seems to be working??? Thanks, Jason

2 1

Re: [slime-devel] Threading warnings on SBCL 1.0.19 Darwin x86
by sblist＠me.com 29 Aug '08

29 Aug '08

Apologies folks for the cross-threading, this is related to the issue many have experienced running SLIME on a threaded SBCL under Darwin x86. On 29-Aug-08, at 3:22 AM, Nikodemus Siivola wrote: > No, sorry for my bogus knowledge. Last time I checked, which was > probably during 10.4, the only timed wait I found was the IIRC > SemaphoreWait or similar which did not like SBCL at all. (Mysterious > messages to terminal is not usually a good sign...) Support for a timeout value appears to be there for futexes, and I think all of the lutex platforms support pthread_cond_timedwait. It should be fairly simple to support a :TIMEOUT optional parameter in CONDITION-WAIT. To address the issue, are there any major concerns with the following approach? Index: src/code/target-thread.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v retrieving revision 1.93 diff -r1.93 target-thread.lisp 393,398c393,399 < (progn < ;; FIXME: This doesn't look interrupt safe! < (setf (mutex-%owner mutex) nil) < (with-lutex-address (queue-lutex-address (waitqueue-lutex queue)) < (with-lutex-address (mutex-lutex-address (mutex-lutex mutex)) < (%lutex-wait queue-lutex-address mutex-lutex-address))) --- > (unwind-protect > (progn > (setf (mutex-%owner mutex) nil) > (with-lutex-address (queue-lutex-address (waitqueue-lutex queue)) > (with-lutex-address (mutex-lutex-address (mutex-lutex mutex)) > (%lutex-wait queue-lutex-address mutex-lutex-address)))) > ;; restore the owner of the mutex if we are interrupted Regards, - Scott Bell

1 0

[slime-devel] Threading warnings on SBCL 1.0.19 Darwin x86
by Scott Bell 29 Aug '08

29 Aug '08

Hi folks, I'm receiving the following warning messages in the *slime-repl sbcl* buffer after updating to the latest CVS yesterday: WARNING: Releasing #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :LUTEX #<unknown pointer object, widetag=#x5E {120B1017}>), owned by another thread: NIL This message occurs many times a second and quickly populates the buffer with thousands of lines. I was able to reproduce this issue with SBCL 1.0.18 and 1.0.19 on Darwin x86 (Mac OS X 10.5.4). Regards, - Scott Bell

6 7

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 27 Aug '08

27 Aug '08

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1474 slime/ChangeLog:1.1480 --- slime/ChangeLog:1.1474 Mon Aug 25 11:29:49 2008 +++ slime/ChangeLog Wed Aug 27 14:03:45 2008 @@ -1,3 +1,20 @@ +2008-08-27 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (sldb-setup): Insert "No backtrace" if the backtrace is + empty. + +2008-08-27 Anton Vodonosov <avodonosov(a)yandex.ru> + + * swank-ecl.lisp: Add :load-toplevel and :execute to EVAL-WHENs to + fix loading. + +2008-08-27 Helmut Eller <heller(a)common-lisp.net> + + * swank-cmucl.lisp (remove-sigio-handlers): Fix thinko. + + * swank.lisp (decode-message): Don't ignore EOF. + (swank-debugger-hook): Remove the default-debugger restart. + 2008-08-25 Tobias C. Rittweiler <tcr(a)freebits.de> * slime.el (slime-compute-modeline-package): Used `when-let' before its definition. Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.124 slime/contrib/ChangeLog:1.125 --- slime/contrib/ChangeLog:1.124 Fri Aug 22 17:15:01 2008 +++ slime/contrib/ChangeLog Wed Aug 27 13:53:11 2008 @@ -1,3 +1,9 @@ +2008-08-27 Helmut Eller <heller(a)common-lisp.net> + + * swank-arglists.lisp (variable-desc-for-echo-area): Limit the + length to one line to avoid (some) problems with big or circular + values. Reported by Stas Boukarev. + 2008-08-22 Stelian Ionescu <sionescu(a)common-lisp.net> * swank-listener-hooks.lisp: Add missing IN-PACKAGE.

1 0

[slime-devel] Fancy Inspector broken?
by Ariel Badichi 27 Aug '08

27 Aug '08

Hello, It seems that the fancy inspector is broken in the latest SLIME. When I try to inspect, say, the symbol FOO, I get: error in process filter: let*: Wrong type argument: listp, :action error in process filter: Wrong type argument: listp, :action I use SBCL 1.0.19.25. Ariel

1 0

[slime-devel] bit-vectors
by Stas Boukarev 27 Aug '08

27 Aug '08

When I place cursor after special variable containing bit-vector, slime tries to display it whole in minibuffer, which is slow and if size of vector is very large it may crash slime: (defparameter *foo* (make-array 20000000 :element-type 'bit)) *FOO* -- With Best Regards, Stas.

2 2

[slime-devel] [PATCH] fix compilation of swank-ecl.lisp
by Stelian Ionescu 27 Aug '08

27 Aug '08

The attached patch adds a few EVAL-WHENs to fix compilation. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

3 3

[slime-devel] CMUCL Flow control
by Madhu 27 Aug '08

27 Aug '08

Helu You may recall unanswered issues I've raised in the past where incorrect SLIME code crashes CMUCL and buries it in an ldb prompt. I suspect this has not been addressed in the recent overhaul of the communication code and believe bug can be illustrated [in current CVS with the following steps] In the repl, type ,---- | CL-USER> (inspect (make-instance 'standard-object)) `---- This responds with an assertion failed, in the [possibly buggy] repl code refuses to accept input. Then prints: ,---- | #<STANDARD-OBJECT {5894AE15}> is an instance of #<STANDARD-CLASS STANDARD-OBJECT | {2831D1C5}>. | > `---- At the > prompt enter `q' RET At the REPL hit C-c 4 times. Slime loses the connection and CMUCL is dead in ldb> Is this reproducible by others? I believe the fix I had suggested earlier would still protect the CMUCL from dying. -- Madhu

2 5

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