slime-devel April 2015

slime-devel@common-lisp.net

63 participants
80 discussions

[patch] RET on no part in *inspector* buffer
by João Távora 08 Apr '15

08 Apr '15

I wonder if anyone else is seeing the same error in the latest slime. Press RET any non-interactive part of the *slime-inspector* buffer and get a "wrong number of arguments" error instead of the intended "no object at point". Here's a possible patch: diff --git a/slime.el b/slime.el index 106b0fa..38df505 100644 --- a/slime.el +++ b/slime.el @@ -6645,16 +6645,16 @@ that value. 2. If point is on an action then call that action. 3. If point is on a range-button fetch and insert the range." (interactive) - (let ((opener (lexical-let ((point (slime-inspector-position))) + (let* ((opener (lexical-let ((point (slime-inspector-position))) (lambda (parts) (when parts (slime-open-inspector parts point))))) (new-opener (lambda (parts) (when parts - (slime-open-inspector parts))))) - (destructuring-bind (property value) - (slime-inspector-property-at-point) - (case property + (slime-open-inspector parts)))) + (property-at-point (slime-inspector-property-at-point)) + (value (second property-at-point))) + (case (first property-at-point) (slime-part-number (slime-eval-async `(swank:inspect-nth-part ,value) new-opener) @@ -6664,7 +6664,7 @@ that value. (slime-action-number (slime-eval-async `(swank::inspector-call-nth-action ,value) opener)) - (t (error "No object at point")))))) + (t (error "No object at point"))))) (defun slime-inspector-operate-on-click (event) "Move to events' position and operate the part." -- João Távora

1 1

error in process filter: Keyword argument :coding-system not one of (:coding-systems)
by Thorsten Jolitz 08 Apr '15

08 Apr '15

Hi List, I continue to get this error ,-------------------------------------------------------------------- | error in process filter: Keyword argument :coding-system not one of | (:coding-systems) `-------------------------------------------------------------------- when calling Slime with a PicoLisp swank implementation, besides having changed the :encoding to what I believe is a valid value. original version: ,-------------------------------------------------------------------- | (de swank:connection-info () | (list | ':pid *Pid | ':style 'nil | ':encoding '(:coding-system "utf-8" :external-format "utf-8") [...] `-------------------------------------------------------------------- changed to new version: ,------------------------------------------------ | (de swank:connection-info () | (list | ':pid *Pid | ':style 'nil | ':encoding '(:coding-system "utf-8-unix") [...] `------------------------------------------------ What am I missing here? PS I just recently cloned the newest slime from the 'unofficial' github repo. -- cheers, Thorsten

1 0

slime in git
by Peter Stirling 08 Apr '15

08 Apr '15

Hi, I updated slime from git today and have been having problems with it (linux x86 and x86-64 sbcl). When I use quicklisp to load drakma it gets somewhere in flexi-streams and then hangs, the sbcl process stops using any cpu and I can't interrupt with C-cC-c. I can use the restart-inferior-lisp command from the repl, and if I do so, then at the second attempt to quickload it gets further, but hangs again further along. I assume that this is because it re-uses some of the fasls from the previous compilation, because if I delete the ~/.cache/common-lisp/ directory then it behaves as before. I attach a sample session, you don't see it, but each time I got a prompt before the very last I had to use restart-inferior-lisp. It's important to state that if I start sbcl from a terminal, then it successfully quickoads drakma, even if I delete the fasl cache, so there must be some interaction that is going wrong between sbcl and slime. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

3 5

Navigating SLIME Common Lisp code with lispy.el screencast
by Oleh 08 Apr '15

08 Apr '15

Hi all, I've just posted a new screencast at https://vimeo.com/86825511. It showcases using https://github.com/abo-abo/lispy for navigating SLIME's Common Lisp code base. It's also possible to navigate the Elisp, Scheme and Clojure code. I'm using CEDET functionality, so the parsing has to be done only once per directory and then it's saved to CEDET's db. Feedback welcome. regards, Oleh

3 5

Slime keybindings for Compiling etc dont work in emacs
by Chintan Pathak 08 Apr '15

08 Apr '15

I am using emacs 24 and ubuntu 13.10. I have slime setup and get the CL-USER REPL on invocation. When I write a program and compile using C-c C-c or C-c C-k, it says these are undefined. How do I verify that these keychord combinations are infact setup?

5 5

swank seems not to be strong enough
by z_axis 08 Apr '15

08 Apr '15

The stumpwm never encounter any problem if not starting swank server. However, sometimes stumpwm will exit X if starting swank server as : (progn (defvar *swank-p* nil) (defcommand swank () () (setf stumpwm:*top-level-error-action* :break) (if *swank-p* (message "Swank server already running") (progn (setf *swank-p* t) (message "Starting swank on port 4005") ;(ql:quickload :swank) (push #p"~/quicklisp/dists/quicklisp/software/slime-20130615-cvs/" asdf:*central-registry*) (asdf:oos 'asdf:load-op :swank) (setf (symbol-value (intern "*log-output*" :swank)) nil) (funcall (intern (string '#:create-server) :swank) :port 4005 :style :spawn :dont-close t) ; :coding-system "utf-8-unix" (echo-string (current-screen) "Starting Swank...Done") ))) (defkey-root "s-l" "swank")) Regards!

1 0

Translation of Clisp messages into Esperanto
by Sian Mountbatten 08 Apr '15

08 Apr '15

Dear List I have translated all the messages of clisp version 2.49 as released by Debian/sid (version 2.49-8.2), into Esperanto (the international language). I am now currently translating all the messages of SLIME (version 20130626-1). Again, into Esperanto. The REPL is not yet done, but nearly everything else is done. Sincerely -- Sian Mountbatten (hejma retejo http://www.poenikatu.co.uk/>) Lernas Komunan Lispon (CLISP). Mi estas asociano de FSF (n-ro 10888). Helpu nin subteni programaran liberecon! http://www.fsf.org/jf?referrer=10888

2 1

Re: [slime] swank-loader could use ASDF (#65)
by howard 08 Apr '15

08 Apr '15

Could you guys all take me off your address list Regards Howard -------- Original message -------- From: Faré <fahree(a)gmail.com> Date: To: Helmut Eller <eller.helmut(a)gmail.com> Cc: João Távora <joaotavora(a)gmail.com>,slime-devel <slime-devel(a)common-lisp.net> Subject: Re: [slime] swank-loader could use ASDF (#65) On Wed, Jan 8, 2014 at 2:53 AM, Helmut Eller <eller.helmut(a)gmail.com> wrote: > On Wed, Jan 08 2014, Faré wrote: > >>> As I said in a another message, I had experiences like this: >>> >>> 1. (asdf:load-system foo), >>> 2. then had some load-time problem, >>> 3. cleaned out the cache, >>> 4. and magically (asdf:load-system foo) worked. >>> >> Are these experiences recent? > > Maybe not. But I still clean the cache whenever there's the slightest > suspicion that ASDF could be related to a problem. I'm sure you can fix > bugs once identified, but fixing trust is another issue. > Actually, before ASDF2 (mid 2010), no one could "fix bugs once identified": there was no single person in charge, no way to push bug fixes, a lot of bugs, and a good reason not to trust ASDF. But the situation changed completely 3-4 years ago when I took over, made asdf upgradable so that bug fixes could be pushed, and started fixing the bugs and pushing the fixes. ASDF is a completely different beast these days, and well tested thanks to Robert Goldman, Anton Vodonosov, Dave Cooper and more. If your bad experiences were with versions of ASDF older than that, I invite you to reconsider this trust issue. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Whatever you do will be insignificant, but it is very important that you do it. — Gandhi

2 1

08 Apr '15

1 0

Re: [slime] swank-loader could use ASDF (#65)
by joaotavora＠gmail.com 08 Apr '15

08 Apr '15

> I'm only worried about slow startup time. E.g. (require :asdf) takes > about 3 seconds in CCL. if you have ever used ABCL you know that slow > startups are no fun. My ultimate use case for this feature is this one in particular. emacs -Q (require 'package) ;;; unnecessary since emacs 24.1 M-x install-package slime-foo RET ;;; third party slime-foo contrib depends on third party ;;; slime-bar that depends on slime-repl that depends on slime. They ;;; all get installed, in the appropriate ~/.emacs.d/elpa. ;;; ;;; or using the el-get package manager M-x el-get slime-foo RET ;;; same thing happens but they all end up in ~/.emacs.d/el-get Now they all the .el files are spread across across the correct places, having been compiled by the respective package manager. Here is a mock tree of what the file system looks like now: . |-- slime-3.0/ | |-- slime-autoloads.el | |-- slime.el | |-- slime.elc | |-- swank.asd | |-- asdf.lisp | `-- swank.lisp |-- slime-bar-0.5/ | |-- slime-bar-autoloads.el | |-- slime-bar.asd | |-- slime-bar.el | |-- slime-bar.elc | `-- slime-bar.lisp |-- slime-foo-0.1/ | |-- slime-foo-autoloads.el | |-- slime-foo.asd | |-- slime-foo.el | |-- slime-foo.elc | `-- slime-foo.lisp `-- slime-repl-3.0/ |-- slime-repl-autoloads.el |-- slime-repl.el |-- slime-repl.elc |-- slime-repl.asd `-- slime-repl.lisp When the user "M-x slime" the three contribs are setup and loaded. The supporting lisp files are compiled into fasls and stored somewhere appropriate. If a user "M-x slime-connect"s to some running lisp where a swank server is already running, we must attempt to compile any needed supporting lisp there as well. (this might be problematic and we could just assume that the target has the same contribs). Now I think this could be done with or without ASDF. But I think ASDF would make it much simpler. According to Francois, startup times are seem OK. M-x slime on sbcl takes well more than two seconds for me. But * One could see more numbers across more versions: * It's true that for a first time M-x slime on a new lisp implementation, compiling asdf.lisp into a fasl is going to take some time. In those cases I think M-x should show "Compiling ASDF, this only happens once". > The advantage for swank-loader seems marginal to me. I think with well crafted ASDF systems (and who better than François) this file could well dissapear. > A slightly different idea: assume we have a Makefile and a required > "make install" step. During that install step we assume that > quicklisp exists or simply download it. If we have quicklisp we have > everything we could wish for. I don't understand, Quicklisp takes at least as long to load as ASDF, since it bundles it. I must be missing something. Also, in the ELPA use-case, the user never "make"s anything. We could package quicklisp, but I think that's going well beyond the scope of slime.

8 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel April 2015