- slime-devel - mailman3.common-lisp.net

im Auftrag von Stas Boukarev
by face book 04 Jul '25

04 Jul '25

im Auftrag von Stas Boukarev

1 0

slime 2.30: Error when evaluating multi-dimensional array literals.
by Mark Harig 30 Jan '25

30 Jan '25

Slime Developers, There appears to be a problem with Slime’s evaluation of multi-dimensional array literals in some buffers. Evaluation of 1-dimensional array literals does not trigger this problem. 1. At the Slime REPL, no error: CL-USER> #(1 2 3) #(1 2 3) CL-USER> #2A((1 2 3) (4 5 6)) #2A((1 2 3) (4 5 6)) 2. Using the Slime command ‘slime-interactive-eval’, no error: M-x slime-interactive-eval Slime Eval: #(1 2 3) => #(1 2 3) M-x slime-interactive-eval Slime Eval: #2A((1 2 3) (4 5 6)) => #2A((1 2 3) (4 5 6)) However, if these array literals are evaluated in the *slime-scratch* buffer using C-x C-e (bound to ‘slime-eval-last-expression’), then the 1-D array literal is evaluated as expected, while the 2-D array literal triggers an error. 3. *slime-scratch* buffer (or any Lisp buffer associated with a Lisp source file): #(x y z) => #(x y z) #2A((1 2) (3 4)) => Execution of a form compiled with errors. Form: ((1 2) (3 4)) Compile-time error: illegal function call [Condition of type SB-INT:COMPILED-PROGRAM-ERROR] Note that if the multi-dimensional array literal is marked in an Emacs buffer and the command ‘slime-eval-region’ is invoked, then the evaluation does not not trigger the error, above. This problem is occurring with slime 2.30, Emacs 29.4, and SBCL 2.3.11. --

2 2

Swank style-warning
by Douglas Katzman 19 Oct '24

19 Oct '24

Can you push something like this to avoid a warning? I don't remember if I can commit. --- a/swank/backend.lisp +++ b/swank/backend.lisp @@ -1386,6 +1386,9 @@ return nil. Return :interrupt if an interrupt occurs while waiting." (declare (ignore streams timeout)) + ;; This defvar can't be moved to 'backend.lisp' because the initializing form isn't evaluable + ;; until an implementation method is loaded for (preferred-communication-style) + (declare (special swank:*communication-style*)) ;; Invoking the slime debugger will just endlessly loop. (call-with-debugger-hook nil

2 1

Slime 2.30: Update installation instructions for package initialization.
by Mark Harig 20 Aug '24

20 Aug '24

Slime Developers, I have tested the following using Emacs 29 (started with `emacs -Q') and Slime 2.30. In the Slime Info manual for version 2.30, the installation instructions in the "Installation" section of the "Getting Started" chapter are incomplete. The text reads: Slime -> Getting Started -> Installation: "The easiest way to install and keep SLIME up-to-date is using Emacs’s built-in package manager. SLIME is available from the MELPA repository. After setting up the MELPA repository, SLIME can be installed via ‘M-x package-install RET slime RET’. You should then define your default Lisp in your ‘.emacs’ as follows: (setq inferior-lisp-program "/opt/sbcl/bin/sbcl") At this point, you should be ready to start *note running SLIME: Running." If the command M-x slime RET is entered after following the instructions above, then the user will see "[Not found]" briefly displayed after M-x slime in the minibuffer. The reason for this is that Emacs's variable `load-path' has not been updated to include the directory in which the `package-install' command has installed Slime. Adding this directory to `load-path' is documented much later in the "Basic Customization" section. Slime -> Getting Started -> Setup Tuning -> Basic Customization: "Once you have the basic no-frills setup working, you can enhance your SLIME installation with bundled extensions: ;; _Setup load-path, autoloads and your lisp system_ (add-to-list 'load-path "~/dir/to/cloned/slime") ..." The simplest solution to this that I have found is to include the function `package-activate-all' in the Emacs user's initialization file (.emacs or some variant). This adds the directory of the installed Slime package to the `load-path'. Instructions to do this could be added to "Installation" section, above, and removed from the "Basic Customization" section. Note: According to the Emacs Lisp reference manual, this should not be necessary because `package-activate-all' is supposed to be run before the user's Emacs initialization file, if the variable `package-enable-at-startup' is set to T. See the section "(elisp) Packaging Basics" in the Elisp manual: " Whenever Emacs starts up, it automatically calls the function ‘package-activate-all’ to make installed packages available to the current session. This is done after loading the early init file, but before loading the regular init file (*note Startup Summary::). Packages are not automatically made available if the user option ‘package-enable-at-startup’ is set to ‘nil’ in the early init file.' ..." Whether the Slime manual should be changed to move the instructions for updating the value of `load-path' or to add instructions to add a call to `package-active-all' to the user's Emacs initialization file, the instructions need to corrected so that new users who are following the instructions will get Slime to start as described. As the instructions are now, Slime will not start after a new installation of the package. --

1 0

Slime 2.30: Discrepancy in eval versus pretty-eval of a `loop' expression
by Mark Harig 29 Jul '24

29 Jul '24

Slime Developers, The following was produced using SBCL version 2.3.11, slime-version "2.30", and Emacs version 29.4. (My copy of slime was installed using the ‘list-packages’ command in Emacs.) For the following ‘loop’ expression, the function ‘slime-eval-last-expression’ returns the correct result: (loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A (GENSYM)) (B (GENSYM)) (C (GENSYM))) But the function ‘slime-pprint-eval-last-expression’ does not return the correct result. Instead, it returns: (loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A . #1=((GENSYM))) (B . #1#) (C . #1#)) in the *slime-description* buffer. Is this a known error, that is, is it an acceptable result? Please let me know if there is any other information you need to reproduce or diagnose this potential error. Thank you. --

3 4

autodoc process filter error
by Gábor Melis 06 Jul '23

06 Jul '23

See the test added for an explanation. I'm not entirely sure that this is the correct place to fix this problem. https://github.com/slime/slime/pull/784

1 0

slime-edit-definition from within of (defpackage )
by Anton Vodonosov 24 Jun '23

24 Jun '23

4 9

Package variance warning on SBCL
by Gábor Melis 14 Jun '23

14 Jun '23

Hello I made a merge request (https://github.com/slime/slime/pull/776) after commit dd179f4a changed the behaviour of loading the swank asdf system when swank has been loaded by swank-loader already. With dd179f4a, loading the asdf system proceeds and produces lots of redefinition warnings and also package variance warnings on SBCL. The latter made asdf:load-system fail when run under Slime. I believe this fix is necessary to compile stuff that depends on swank via ASDF. Please consider merging it. Cheers, Gábor

1 1

Slime usage with .lisp buffer?
by Nicholas Papadonis 02 Jun '23

02 Jun '23

I'm transitioning from 'mit-scheme -edit' (edwin) to Slime. I've installed Slime via MELPA and have the *slime-repl sbcl* up. I also opened a file C-x C-f 't.lisp' and the buffer shows only 'Lisp adoc'. Is this correct? I saw videos where the .lisp buffer showed 'sbcl'. Also, it appears I can evaluate the t.lisp buffer using C-x C-e with results, however am not sure if this is SBCL, Slime or some other method of evaluation. Does anyone know how Slime should behave with respect to a *.lisp buffer and evaluation? Thanks

3 2

Fwd: Unwanted completion function
by Andrew Brace 23 May '23

23 May '23

On Sat, May 20, 2023 at 7:48 PM Vladimir Sedach <vas(a)oneofus.la> wrote: > > You can either eval (slime-c-p-c-unload) after loading SLIME, or > customize slime-contribs to load only the contribs you want > (recommended by the manual). Thank you, these suggestions work. Should the behavior I encountered be considered a bug? Given that slime-completion-at-point-functions is customizable, I expected to be able to control it with M-x customize.

2 1