slime-devel June 2009

slime-devel@common-lisp.net

35 participants
59 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] Proposed patch for asdf-loading under ALLEGRO
by Robert Goldman 05 Jan '10

05 Jan '10

ASDF operations using SLIME and SWANK won't work under Allegro's Modern (case-sensitive) lisp, because the symbol names are not in all caps as in ANSI lisp. Here's a small patch that makes it work under ACL mlisp as well as under normal ANSI lisps: Index: swank-asdf.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/contrib/swank-asdf.lisp,v retrieving revision 1.7 diff -b -u -F '^(def' -r1.7 swank-asdf.lisp --- swank-asdf.lisp 23 Oct 2008 21:28:03 -0000 1.7 +++ swank-asdf.lisp 25 May 2009 16:40:10 -0000 @@ -26,7 +26,9 @@ (defun operate-on-system (system-name op Example: \(operate-on-system \"SWANK\" \"COMPILE-OP\" :force t)" (with-compilation-hooks () - (let ((operation (find-symbol operation-name :asdf))) + (let ((operation (or (find-symbol operation-name :asdf) + #+allegro + (find-symbol (string-downcase operation-name) :asdf)))) (when (null operation) (error "Couldn't find ASDF operation ~S" operation-name)) (apply #'asdf:operate operation system-name keyword-args))))

2 1

Re: [slime-devel] random returning the same value
by Tobias C. Rittweiler 30 Nov '09

30 Nov '09

Patrick May <pjm(a)spe.com> writes: > Hi, > > I'm using Slime in Aquamacs with CCL. When I evaluate (random > 100) repeatedly in CCL started from a shell, I get a randomly > generated number between 0 and 99 inclusive. When I do the same with > C-x C-e within Slime, I get the same number every time. (random 100 > (make- > random-state)) gives the same behavior, but (random 100 (make-random- > state t)) works properly. > > Is Slime caching something or have I hosed up my environment? Sorry for the late response. CCL's swank backend uses threads by default, and threads inherit values from the global environment. *RANDOM-STATE* probably becomes thread-local automatically in CCL, resulting in the behaviour you described. It should work when you type in the form at the Slime REPL which evaluates all forms in the same thread. -T.

4 4

[slime-devel] Error in `post-command-hook' ?
by Alberto Riva 21 Aug '09

21 Aug '09

I recently upgraded Slime, and now I keep getting these very annoying warnings, usually when I do something in the modeline, but also at other apparently random times: (1) (error/warning) Error in `post-command-hook' (setting hook to nil): (wrong-type-argument natnump t) If I turn debug on, this is what I get: Debugger entered--Lisp error: (wrong-type-argument natnump t) signal(wrong-type-argument (natnump t)) set-itimer-restart(("run-with-idle-timer<2>" 0.2 0.2 eldoc-print-current-symbol-info t t nil (19018 24548 646301)) t) timer-set-idle-time(("run-with-idle-timer<2>" 0.2 0.2 eldoc-print-current-symbol-info t t nil (19018 24548 646301)) 0.2 t) eldoc-schedule-timer() I'm using Allegro CL 8.1 and XEmacs 21.4.21. I also observed the problem that was reported here earlier: slime-bug("Caught error during fontification while searching for forms that are suppressed by reader-conditionals. The error was: (cl-assertion-failed (<= (point) limit)) but I was able to stop XEmacs doing whatever it was doing with C-g before it ran out of memory. Thanks, Alberto

2 1

[slime-devel] *STANDARD-OUTPUT* going to *inferior-lisp*
by graham＠gorgeous.org 17 Jul '09

17 Jul '09

*STANDARD-OUTPUT* of functions called from the REPL is going to *inferior-lisp* not to the REPL as it used to. I noticed this when calling DISASSEMBLE; the disassembly appears in the *inferior-lisp* buffer. I'm using SBCL 1.0.29 on Windows with SLIME 2009-06-29. This behaviour was introduced well before today, though I haven't done the usual CVS binary search to find out when. I'm open to the idea that this is not a general problem and that something in my setup is screwing with SLIME, but what could it be? Thanks in advance as usual, Graham

4 7

[slime-devel] Slime and ECL
by Matthew Mondor 14 Jul '09

14 Jul '09

Hello, I was unsure to which of the lists this belonged best so I posted it to both slime-devel and ecls-list (if I understand, swank which is part of slime handles the implementation-specifics)... Is slime known to be broken with ECL? I initially tried with ECL 8.12.0 and first had an unknown utf8-unix external format error (so I adapted my ~/.emacs to temporarily not use utf-8 mode, which helped). Then there was another error related to missing ext:+ecl-version-number+ constant (which I could declare in ~/.eclrc, which also helped). However, there then was another error: "Wrong number of arguments passed to function #<compiled-function SI:IHS-TOP>". I then tried using ECL 9.6.0 (or .1? the ecl-9.6.0 archive had a directory named ecl-9.6.1), built with unicode support. The utf8 related error still occurs when utf8 mode is enabled, the +ecl-version-number+ constant is already defined this time, yet the ihs-top function being called with the wrong number of arguments still occurs. Backtrace: > LAMBDA > swank-backend:call-with-debugger-hook > swank:swank-debugger-hook > lambda > swank-backend:call-with-debugger-hook > lambda > swank::call-with-bindings > swank::call-with-connection > swank::simple-serve-requests > swank::serve-requests > swank::serve-connection > swank::serve > swank::setup-server > swank:start-server > si:bytecodes [Evaluation of: (progn (load "/home/mmondor/emacs-scripts/slime/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") "/tmp/slime.9787" :coding-system "iso-latin-1-unix"))] > si:bytecodes [Evaluation of: (si:top-level)] My experience with slime and ecl is limited, I used to use it with SBCL only previously. The reason why my initial tries were with ECL 8.12 was because I got it working properly with threads, when the bootstrap ecl_min appears to segfault and its signal handler stuck in an endless loop when I try to build 9.6.0/1 with threading support (it builds fine non-threaded). But this is another matter which I didn't spend time to debug yet. :) Thanks, -- Matt

3 4

[slime-devel] SWANK STREAMS clobbered with lispworks
by Madhu 11 Jul '09

11 Jul '09

On Lispworks, the output associated with an editor window goes to the Output Browser pane. So evaluating a line such as (format t "foo~%"), or (format *standard-output* "foo~%") with C-M-x in an editor pane would print "foo" in the Output Browser. However, when using SLIME, once emacs has connected to Lispworks over SWANK, the output starts goes to the terminal on which Lispworks was initially started. This is because the value of *STANDARD-OUTPUT* in the editor pane gets clobbered and set to a Synonym stream to *TERMINAL-IO*. This behaviour is observed on LWL with any version of slime, and is not desirable. How can one get the `output stream' back so output from the Lispworks IDE can be seen inside the IDE ? -- Madhu

6 18

[slime-devel] [PATCH] operator-arglist
by Terje Norderhaug 02 Jul '09

02 Jul '09

The operator-arglist slimefun uses #'pprint-fill to format an arglist without enclosing parentheses. Unfortunately, for longer arglists, a consequence is that the output might be pretty printed based on the output width on the server lisp, potentially leading to unwanted linebreaks and whitespace in the result. For example, using Clozure, evaluate operator-arglist for #'cl:directory: (swank::operator-arglist "DIRECTORY" "COMMON-LISP") => "(DIRECTORY PATH &KEY DIRECTORIES FILES ALL DIRECTORY-PATHNAMES INCLUDE-EMACS-LOCKFILES TEST FOLLOW-LINKS)" Such results may require a cleanup to be presented by the client on one line or with the preferred width. It would be preferable to have the result single spaced and without linebreaks, leaving the formatting to the swank client: "(DIRECTORY PATH &KEY DIRECTORIES FILES ALL DIRECTORY-PATHNAMES INCLUDE-EMACS-LOCKFILES TEST FOLLOW-LINKS)" Here is a patch that writes the function name and arglist as a list on a single line: diff -u slime-2009-06-30/swank.lisp patch/swank.lisp --- slime-2009-06-30/swank.lisp 2009-06-29 00:15:06.000000000 -0700 +++ patch/swank.lisp 2009-06-30 14:04:48.000000000 -0700 @@ -3005,7 +3005,7 @@ (let ((args (arglist (parse-symbol name (guess-buffer-package package)))) (*print-escape* nil)) (cond ((eq args :not-available) nil) - (t (format nil "(~a ~/pprint-fill/)" name args)))))) + (t (princ-to-string (cons name args))))))) -- Terje Norderhaug

2 2

[slime-devel] Lispworks thread-attributes
by Terje Norderhaug 02 Jul '09

02 Jul '09

Here is a candidate implementation of thread-attributes for LispWorks: ; swank-lispworks.lisp (defimplementation thread-attributes (thread) (list :priority (mp:process-priority thread) :idle (mp:process-idle-time thread))) -- Terje Norderhaug

2 1

[slime-devel] Profile package support in ECL and Slime
by Marko Kocić 01 Jul '09

01 Jul '09

Here are two patches, one for ECL, one for SLIME that enables slime profile-package. Regards, Marko Kocić

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 June 2009