slime-devel December 2008

slime-devel@common-lisp.net

38 participants
44 discussions

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] clhs-lookup for reader macros
by Stas Boukarev 27 Feb '09

27 Feb '09

I added reader macros for hyperspec-lookup, hope this would be useful. -- With Best Regards, Stas.

2 1

[slime-devel] [PATCH] a few small fixes
by Stelian Ionescu 27 Feb '09

27 Feb '09

The first patch replaces old-style backquoting with the new-style in contrib/bridge.el(when compiling the file I got a warning that old-style backquotes are deprecated since version 21 and will be removed soon). The other patches fix two typos. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

2 1

[slime-devel] Problem with truncation of strings in debugger
by Jeff Workman 26 Feb '09

26 Feb '09

When I evaluate (format t "~A" (some-str-function)) on a longish string in debugger with E, the string is printed truncated, which seems like the wrong behavior to me. Also, surprisingly when I evaluate (setf *str* (some-str-function)) from debugger, the string stored in *str* is truncated as well. That suggests to me that the debugger is modifying the behavior of (format nil ...) or other functions I use in constructing strings used internally in my program, which would obviously be very bad and could interfere with operation of the program. I'm using SBCL 1.0.20 on Linux (and cvs slime) btw.

3 3

[slime-devel] [bug] ecl-swank chokes on cl-ppcre docstring
by Daniel Herring 30 Jan '09

30 Jan '09

Here's the original offender (and fix): diff of cl-ppcre-2.0.1/util.lisp:45,46 (defmacro with-unique-names ((&rest bindings) &body body) - "Syntax: WITH-UNIQUE-NAMES ( { var | (var x) }* ) declaration* form* + "Syntax WITH-UNIQUE-NAMES ( { var | (var x) }* ) declaration* form* Steps to reproduce: * load ECL in Slime * evaluate a form like the following (defmacro break-slime (&rest args) "Syntax: this-is-bad" (list args)) * Slime complains "THIS-IS-BAD is not of type CONS. [Condition of type TYPE-ERROR]" This is caused by grovel-docstring-for-arglist in slime/swank-ecl.lisp. By bad luck, Edi happened to use a docstring which *almost* matched the format... Slime/swank should handle it more gracefully. Later, Daniel P.S. After tracking that down, I updated to the latest Slime CVS; but slime broke. Another bug report...

2 2

[slime-devel] Inspector doc
by Madhu 17 Jan '09

17 Jan '09

Helu, I'm having trouble using the inspector effectively: some objects are truncated, some lists are truncated etc. These boil down to bindings of printer variables [the debug state, etc] Can the inspector related variables be documented, and the rationale spelt out as to which output is being truncated, why, and under what circumstances? Could the hardcoded constants be documented as being hardcoded? I suspect this is not too much to ask if the new inspector is a "better thought out" replacement, the design could be explained in a few paragraphs in comments in the code or in a separate doc. I think it is an important enough component of SLIME to define the behaviour outside of the code which implements it. -- Madhu

4 8

[slime-devel] More features by default
by Luis Oliveira 15 Jan '09

15 Jan '09

Hello Helmut, I would like to suggest that the slime-fancy contrib be loaded by default. Some of those features have become rather fundamental to me and, I suspect, to many other SLIME users as well. IMHO, it would be unfortunate if newcomers didn't get to experience the CLOS inspector, autodoc, presentations, the REPL(!), etc, because of inadequate default settings. I believe said newcomers will quite likely find SLIME somewhat anemic and underwhelming. I hope you take this suggestion into consideration and I'd be glad to prepare a patch with the necessary trivial changes to slime.el and slime.texi. Thanks. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

11 21

[slime-devel] text properties in REPL
by Madhu 10 Jan '09

10 Jan '09

How about a global switch which would be checked before propertising any string in SLIME? I'm facing emacs rendering-speed issues so I'm asking. And its not like you can do M-x font-lock-mode and turn display properties off Also, any hope of REPL history behaviour getting reverted so it works like minibuffer history, especially for searching? -- Madhu

6 22

[slime-devel] request for pecifying location fasl-files
by Knut Olav Bøhmer 10 Jan '09

10 Jan '09

Hi, I would like to be able to specify where slime should place it's fasl-files when running slime-compile-and-load-file. The location should be per-buffer/filename configurable by placing variable-definition in the header of a .lisp file or by a hook that runs when a .lisp file is opened. I have attached an example implementation that I use, and have used for a long time. It works for me. -- Free Software Consultant Cell: +47 - 47 34 40 08 Phone: +47 - 21 53 69 00, Fax: +47 - 21 53 69 09 Addr: Nydalsveien 30b, 0484 Oslo <http://www.freecode.no/>

5 4

[slime-devel] SBCL with globally redirected IO
by Gábor Melis 02 Jan '09

02 Jan '09

With current HEAD I cannot start sbcl if *globally-redirect-io* is T. Same as: http://paste.lisp.org/display/72603 With slime from Dec 22 it works fine. Cheers, G

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 December 2008