slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] which version of slime with which version of sbcl?
by frederic.gobry＠epfl.ch 30 Jun '05

30 Jun '05

Hi, I'm a new lisper, and I'm trying to use sbcl and slime together, on Debian (sbcl-0.9.1.41-1 from unstable). I tried slime-1.2.1 which gave strange errors (I don't have them at hand but can reproduce them if you wish), and switched to the CVS version. Now I can connect to the sbcl process, evaluate a few expressions from the REPL, but as soon as I do C-c C-c from a lisp file, I get this error: Unable to display error condition: The value #S(SB-C::DEBUG-SOURCE :FROM :FILE :NAME "/tmp/fileCdgZoa" :CREATED 3329044824 :COMPILED 3329044824 :SOURCE-ROOT 0 :START-POSITIONS #(0) :FUNCTION NIL :PLIST NIL) is not of type SEQUENCE. [Condition of type SB-KERNEL::ARG-COUNT-ERROR] Restarts: 0: [ABORT] Abort SLIME compilation. 1: [ABORT] Abort handling SLIME request. 2: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SWANK-BACKEND::DEBUG-SOURCE-FOR-INFO-ADVICE #<SB-C::SOURCE-INFO >) 1: (SB-FASL:FASL-DUMP-SOURCE-INFO #<SB-C::SOURCE-INFO > #<SB-FASL:FASL-OUTPUT "/tmp/fileCdgZoa.fasl">) 2: ((LAMBDA NIL)) 3: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA NIL) {9BD3955}>) 4: (SB-C::SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >) 5: (COMPILE-FILE "/tmp/fileCdgZoa") >From that point, any evaluation (from the REPL, or from a file) lead to a similar error. Do you have an idea of what's going on? Thanks in advance, Frédéric

3 4

[slime-devel] Re: Summer of Code, mentorship, technical adviser
by Svein Ove Aas 29 Jun '05

29 Jun '05

On 29 Jun 2005 20:41:38 +0200, Luke Gorrie <luke(a)synap.se> wrote: > For the UI part I would suggest beginning by getting familiar with > edebug in Emacs 21 because it's a great model of a stepper. If you > evaluate an elisp definition with `C-u C-M-x' then it is defined in > interpreted fashion for stepping and a breakpoint is automatically set > - i.e. as soon as you call the function you will be in the debugger. > When you're done debugging you just use `C-M-x' to redefine it in the > normal way. Simple & nice inteface. > That *will* come in handy. It doesn't do everything I'm trying to do, but it's a nice model. And, of course, it will help me debug my elisp code - I'll have to learn a lot more of that for this project. > > Writing a stepper will be very good karma :-) > Eh. I need one, and this seemed like a perfect opportunity to write one. ^_^

1 0

[slime-devel] Summer of Code, mentorship, technical adviser
by Heow Eide-Goodman 29 Jun '05

29 Jun '05

Guys, Google has decided to fund the development of a Slime stepper! Woohoo! We have a capable student but our mentors aren't experienced with slime-internals. If anyone is willing to step forward for either a mentorship or technical advisor role, we'd be happy to work with you on this exciting project. Thanks, - Heow

2 2

[slime-devel] Slime hanging on foreign function calls with Lispworks
by Shawn Nicholson 29 Jun '05

29 Jun '05

Hello, I am a new user to slime and have run into something I can't seem to figure out. I am running Lispworks 4.4.5 Professional and Slime 2005-4-27 (LispWorks Port 1525 PID 220). I am attempting to run some code which calls some foreign functions however any attempt to do so causes Slime to hang. The windows click does not happen at all. Any ideas on what I'm missing (or what settings I have incorrect) that would prevent me from making FLI calls? Thanks, Shawn (in-package :cl-user) (defparameter *segman-dll* "C:\\Projects\\SegMan\\hemets\\src\\segman.dll") (fli:register-module *segman-dll*) (fli:define-foreign-function (c_single_click "c_single_click" :source) ((pause :int)) :result-type :void) (defun single-click (&optional (pause 0)) (format t "Executing single click.~%") (c_single_click pause)) (defun test-click () (single-click))

1 0

[slime-devel] swank-sbcl fails on FreeBSD
by Julian Stecklina 29 Jun '05

29 Jun '05

Hello, swank-sbcl.lisp refers to the alien "linux_no_threads_p" which does not exist on my SBCL 0.8.17 (yeah, someone should probably update the ports :-/) on FreeBSD. The following patch fixes avoids this: Regards, -- Julian Stecklina "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." - Guy Steele, Java spec co-author

2 2

[slime-devel] C-c C-c of a function referencing a large constant takes a long time to compile
by David Steuber 29 Jun '05

29 Jun '05

Hello slime-devel, This evening I discovered a nasty annoyance with Slime and OpenMCL when doing C-c C-c to compile a function. The function makes reference to a 46x46x46x46 constant array of integers (defined with DEFCONSTANT). Any such function that refers to the array takes over a minute to compile with C-c C-c. If I have openmcl running in a terminal, the same function will recompile instantly. Here are a few bits of relevant code and *slime-events*: (DEFCONSTANT +LETTER-FREQUENCY-HYPERCUBE+ #4A((((6384784 ... (defun start-decoder (cipher-text pos) (let (m1 (pf 0)) (dotimes (a +modulo+) (dotimes (b +modulo+) (dotimes (c +modulo+) (dotimes (d +modulo+) (let ((sp (aref +letter-frequency-hypercube+ a b c d))) (when (< 0 sp) (let* ((w (modadd a (aref cipher-text pos))) (x (modadd b (aref cipher-text (+ 1 pos)))) (y (modadd c (aref cipher-text (+ 2 pos)))) (z (modadd d (aref cipher-text (+ 3 pos)))) (pfp (* sp (aref +letter-frequency-hypercube+ w x y z)))) (when (< pf pfp) (setf m1 (list a b c d) pf pfp))))))))) m1)) (:emacs-rex (swank:compile-string-for-emacs "(defun start-decoder (cipher-text pos)\n (let (m1 (pf 0))\n (dotimes (a +modulo+)\n (dotimes (b +modulo+)\n (dotimes (c +modulo+)\n (dotimes (d +modulo+)\n (let ((sp (aref +letter-frequency-hypercube+ a b c d)))\n (when (< 0 sp)\n (let* ((w (modadd a (aref cipher-text pos)))\n (x (modadd b (aref cipher-text (+ 1 pos))))\n (y (modadd c (aref cipher-text (+ 2 pos))))\n (z (modadd d (aref cipher-text (+ 3 pos))))\n (pfp (* sp (aref +letter-frequency-hypercube+ w x y z))))\n (when (< pf pfp)\n (setf m1 (list a b c d)\n pf pfp)))))))))\n m1))\n" "two-time-pad.lisp" 5674 "/Users/david/usr/src/ITA Software Puzzles/Two-Time Pad/") nil t 540) (:return (:ok ("T" "65.65")) 540) I'm running SLIME 2005-06-21, OpenMCL 0.14.3-050610a, and Carbon Emacs from CVS on 2005-06-12, OS X 10.3.9, GCC 3.3 from Xcode 1.5.

2 3

[slime-devel] Allegro/CMUCL patch for presentations.lisp
by Matthias Koeppe 28 Jun '05

28 Jun '05

I am sending another patch related to presentations. It contains improvements specific to CMUCL and Allegro CL. Would someone like to handle this (and the previous) patch? Cheers, Matthias 2005-06-28 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * present.lisp (slime-stream-p) [cmu]: Handle indenting-streams whose base streams are SLIME streams. These occur in logical blocks in pretty-printing. [allegro]: Handle xp-simple-streams whose base streams are SLIME streams. * present.lisp (presenting-object-1) [allegro]: Unconfuse the pretty printer. * present.lisp [allegro]: Add fwrappers for printing pathnames and unreadable objects as presentations. --- present.lisp.~1.4.~ 2005-05-24 04:42:01.000000000 +0200 +++ present.lisp 2005-06-28 15:04:16.680297000 +0200 @@ -82,8 +82,13 @@ ;(slime-stream-p (ccl::xp-base-stream (slot-value stream 'ccl::xp-structure))) (slime-stream-p (ccl::%svref (slot-value stream 'ccl::xp-structure) 1))) #+cmu - (and (typep stream 'pretty-print::pretty-stream) - (slime-stream-p (pretty-print::pretty-stream-target stream))) + (or (and (typep stream 'lisp::indenting-stream) + (slime-stream-p (lisp::indenting-stream-stream stream))) + (and (typep stream 'pretty-print::pretty-stream) + (slime-stream-p (pretty-print::pretty-stream-target stream)))) + #+allegro + (and (typep stream 'excl:xp-simple-stream) + (slime-stream-p (excl::stream-output-handle stream))) (loop for connection in *connections* thereis (or (eq stream (connection.dedicated-output connection)) (eq stream (connection.socket-io connection)) @@ -94,20 +99,39 @@ (declare (ignore stream)) *enable-presenting-readable-objects*) +;; If we are printing to an XP (pretty printing) stream, printing the +;; escape sequences directly would mess up the layout because column +;; counting is disturbed. Use "annotations" instead. +#+allegro +(defmacro annotating ((base-stream stream) &body body) + `(if (typep ,stream 'excl:xp-simple-stream) + (excl::schedule-annotation ,stream (lambda (.ignore. ,base-stream .ignore2.) + (declare (ignore .ignore. .ignore2.)) + ,@body) + nil) + (let ((,base-stream ,stream)) + ,@body))) +#-allegro +(defmacro annotating ((base-stream stream) &body body) + `(let ((,base-stream ,stream)) + ,@body)) + (defun presenting-object-1 (object stream continue) "Uses the bridge mechanism with two messages >id and <id. The first one says that I am starting to print an object with this id. The second says I am finished" (if (and *record-repl-results* *can-print-presentation* (slime-stream-p stream)) (let ((pid (swank::save-presented-object object))) - (write-string "<" stream) - (prin1 pid stream) - (write-string "" stream) + (annotating (base-stream stream) + (write-string "<" base-stream) + (prin1 pid base-stream) + (write-string "" base-stream)) (multiple-value-prog1 (funcall continue) - (write-string ">" stream) - (prin1 pid stream) - (write-string "" stream))) + (annotating (base-stream stream) + (write-string ">" base-stream) + (prin1 pid base-stream) + (write-string "" base-stream)))) (funcall continue))) ;; enable presentations inside listener eval, when compiling, when evaluating @@ -371,3 +395,15 @@ (fwrappers::fwrap 'lisp::%print-pathname #'presenting-pathname-wrapper) (fwrappers::fwrap 'lisp::%print-unreadable-object #'presenting-unreadable-wrapper) ) + +#+allegro +(progn + (excl:def-fwrapper presenting-unreadable-wrapper (object stream type identity continuation) + (swank::presenting-object object stream (excl:call-next-fwrapper))) + (excl:def-fwrapper presenting-pathname-wrapper (pathname stream depth) + (presenting-object-if (can-present-readable-objects stream) pathname stream + (excl:call-next-fwrapper))) + (excl:fwrap 'excl::print-unreadable-object-1 + 'print-unreadable-present 'presenting-unreadable-wrapper) + (excl:fwrap 'excl::pathname-printer + 'print-pathname-present 'presenting-pathname-wrapper)) -- Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe

2 1

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 28 Jun '05

28 Jun '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.716 slime/ChangeLog:1.717 --- slime/ChangeLog:1.716 Tue Jun 21 20:28:58 2005 +++ slime/ChangeLog Tue Jun 28 10:40:07 2005 @@ -1,3 +1,8 @@ +2005-06-28 Gabor Melis <mega(a)hotpop.com> + + * swank-sbcl.lisp (threaded stuff): horrible hack to make threaded + SBCL 0.9.2 work. (also, Happy Birthday Christophe!) + 2005-06-21 Edi Weitz <edi(a)agharta.de> * swank.lisp (find-matching-packages): Also use nicknames.

1 0

Re: [slime-devel] Re: [Openmcl-devel] C-c C-c of a function refer encing a large constant takes a long time to compile
by Hoehle, Joerg-Cyril 27 Jun '05

27 Jun '05

Hi, David Steuber wrote: >SLIME or Swank (perhaps the swank-openmcl backend) are definitely doing >something to make this take a long time. I just have no idea how to >figure out what. I suspect some interaction between EVAL-WHEN and top-level vs. non top-level. I've also had a couple of situations (in CLISP, cmucl or sbcl, but I forgot which package and when) where e.g. C-c C-c would not work and even spit out incomprehensible error messages, while e.g. C-x C-e followed by (compile 'foo) would work fine. My belief is the difference that evaluating (funcall (compile nil '(lambda() (defun foo ...)))) -- which is what I believe SLIME does (cf. swank-compile-string) -- may have different results from evaluating 1. (defun foo) -- causes it to be defined at top-level 2. (compile 'foo) Look at the CLHS apropos EVAL-WHEN and you'll see the door open to a lot of hairy behaviour. People mostly using COMPILE-FILE on lots of top-level definitions will never encounter that, because it's the typical, well-tested use-case. The above is not. You'll be hit by these differences when you'll see non-trivial EVAL-WHEN ... in the macroexpansions of the forms you evaluate or compile individually in SLIME. Sigh, I wish I had kept notes about those non-top-level problems, to beter talk about these. BTW, IIRC, there's a few situations where the old lisp-mode (inf-lisp.el) is less likely to run into trouble than SLIME, precisely because it just uses a simpler way to compilation and evaluation. Again, I forgot the details. Also, I've wondered whether platform-specific solutions may help. E.g. in CLISP, (locally #+clisp (declare (compile)) ...whatever...) might be a better approach to compilation, devoid of top-level vs. non top-level EVAL-WHEN expansion issues. CLHS specifies that LOCALLY maintains top-levelness, but (declare compile) is specific to CLISP. Actually, I think this could be an excellent idea for swank-clisp:defimplementation swank-compile-string. Or just use (load (make-string-input-stream "(print 123)"):compiling t :verbose nil) [looking closer at swank-*.lisp] Well forget about my talking, it appears only clisp uses (funcall(compile(lambda #))). Allegro, Lispworks, sbcl, openmcl go through a temp file, and cmucl uses ext:compile-from-stream on a string-input-stream, at least in slime-1.2.1. Regards, Jorg Hohle.

1 0

Re: [slime-devel] feture suggjestion
by Knut Olav Bøhmer 27 Jun '05

27 Jun '05

OK, then I'll try to implement it, when I get time. (which will not be before the end of July, if not then, then next year. I hope someone has more time for this than I :) killing threads in a infinite loop is like killing any other thread. slime-list-threads (C-c C-x t) then arrow up and down to your (un)favorite thread of choice, then press "k". On 6/23/05, Jeffrey Cunningham <jeffrey(a)cunningham.net> wrote: > I like it. Incidentally, how do you kill any thread caught in an > infinite loop? I've been trying to figure this out for sometime. > > --Jeff Cunningham > > > > On Thu Jun 23, 2005 at 12:02:06PM +0200, Knut Olav B?hmer wrote: > > When I'm in a buffer editing my lisp-code, and decide to test the > > code, by pressing C-x C-e, slime forks of a new thread with the name > > "worker". The problem starts when I have several threads running from > > different buffers with the name "worker", and one of the threads ends > > in an infinite loop or deadlock, and I want to kill one of the > > threads. Then I don't know which thread is doing what. > > > > So If the thread got the name "worker + buffer name" then I would have > > slightly more control. > > > > Good Idea? > > > > > > -- > > Knut Olav Bøhmer > > tlf: +47 47400777 > > _______________________________________________ > > slime-devel site list > > slime-devel(a)common-lisp.net > > http://common-lisp.net/mailman/listinfo/slime-devel > > > --Jeff > > -- Knut Olav Bøhmer tlf: +47 47400777

3 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