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

[patch] Don't load slime-asdf contrib if ASDF is too old
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello, Loading slime-asdf when ASDF is too old signals an error which will cause a SLIME connection to be aborted. In order to avoid this, the attached patch checks the ASDF version before attempting to load the swank-asdf contrib. Cheers, Luís

1 1

loading Swank with swank.asd is broken
by Robert Brown 08 Apr '15

08 Apr '15

Recent changes have broken swank.asd. It no longer loads the Swank server code into a Lisp when I execute (asdf:load-system 'swank). Please switch to an ASDF file that looks more like the following. Thanks. Bob (defsystem swank :name "Swank" :description "Swank server." :version "0.1" :license "public domain" :serial t :components ((:file "swank-backend") #+(or cmu scl sbcl ecl) (:file "swank-source-path-parser") #+(or cmu scl sbcl ecl) (:file "swank-source-file-cache") #+clisp (:file "xref") #+(or clozure clisp) (:file "metering") #+allegro (:file "swank-allegro") #+armedbear (:file "swank-abcl") #+clisp (:file "swank-clisp") #+clozure (:file "swank-ccl") #+cmu (:file "swank-cmucl") #+cormanlisp (:file "swank-corman") #+ecl (:file "swank-ecl") #+lispworks (:file "swank-lispworks") #+sbcl (:file "swank-sbcl") #+scl (:file "swank-scl") #+(or allegro clisp clozure cormanlisp ecl lispworks sbcl) (:file "swank-gray") (:file "swank-match") (:file "swank-rpc") (:file "swank")))

3 2

[Failed] capitaomorte/slime#28 (ongoing - 9004977)
by Travis CI 08 Apr '15

08 Apr '15

Build Update for capitaomorte/slime ------------------------------------- Build: #28 Status: Failed Duration: 3 minutes and 13 seconds Commit: 9004977 (ongoing) Author: Joao Tavora Message: add .gitignore View the changeset: https://github.com/capitaomorte/slime/compare/c59839f920b6^...9004977b31b6 View the full build log and details: https://travis-ci.org/capitaomorte/slime/builds/16413311 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration

1 0

slime + chokes on temporary-file-directory set to "~/temp" on Windows
by Mirko Vukovic 08 Apr '15

08 Apr '15

I am running Windows versions Emacs and CLISP. If I have temporary-file-directory set to "~/temp", slime loading will report ;; Loaded file C:\Users\977315\documents\.slime\fasl\2013-09-29\clisp-2.49-windows-x86\swank.fas ... *** - OPEN: Directory #P"C:\\Users\\...\\documents\\.emacs.d\\~\\temp\\" does not exist I set temporary-file-directory to an absolute path, such as ""c:/Users/.../AppData/Local/Temp/" slime loads OK. I grepped slime's lisp files for temporary-file-directory, but did not see it. I tested this with clisp -norc option. Is this a bug - since on Windows Emacs accepts `~' for the home directory? Thanks, Mirko

2 1

Does posting via Gmane work?
by Thorsten Jolitz 08 Apr '15

08 Apr '15

Hi List, I'm new to the newsgroup (list), and made two attempts to post a question via Gnus/Gmane yesterday: 1. While unsubscibed, I posted via Gmane to /nntp+news.gmane.org:gmane.lisp.slime.devel/ received a confirmation email and replied, then receiving an email "you are authorized now...". But nothing happened. 2. Then I subscribed with /slime-devel+subscribe-nomail(a)common-lisp.net/ reveiced a subscription confirmation and reposted via Gmane. Again, nothing happened. But the Gmane page of the group says: ,-------------------------------------------------------------------- | Group gmane.lisp.slime.devel | Description SLIME: the Superior Lisp Interaction Mode for Emacs | Address slime-devel@... | Status posting allowed `-------------------------------------------------------------------- so posting via Gmane should work. What am I missing/ doing wrong? -- cheers, Thorsten

3 2

SLIME 2.4 released
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello all, SLIME 2.4 is released! https://github.com/slime/slime/releases/tag/v2.4 I've also updated the on-line HTML and PDF documentation and added a link to the GitHub releases page to the website. Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

custom reader and custom rpcs
by Alexander Popolitov 08 Apr '15

08 Apr '15

Hi everyone! So, here is my proposed enhancement to swank (see patch-file in the attachment). The idea is, that executing arbitrary code on the lisp core, which swank allows by default, is not always desirable. Hence, patch does following things: 1) Add SWANK::*READER* variable, which, when bound to a function when calling SETUP-SERVER, causes this function to be used when reading forms in SWANK-RPC::READ-FORM 2) SWANK::DISPATCH-EVENT's DESTRUCTURING-CASE is substituted by more flexible lookup in the hashtable. If SWANK::*VALID-RPC* list is bound to new value when calling SETUP-SERVER, then in this particular server only those new RPC's will be active. 1st change is useful, I think, not only for securing the reader in a way that I did in my CL-SECURE-READ system, but also if you actually want learn SWANK talk some non-s-exp-based protocol. So, what do you think? Yours sincerely, Alex

4 5

slime-repl.el and slime-presentations.el contrib fixes
by joaotavora＠gmail.com 08 Apr '15

08 Apr '15

Hi, If noone opposes, I'd like to push the commits in postscript to slime master. They target the slime-repl.el and slime-presentations.el contribs only, but the topmost one might be worthy of some more analysis, since it now makes every interactive REPL request two packets heavier. The fixes and functionality added target returning objects from the debugger to the slime-repl.el REPL, with or without the slime-presentations.el contrib (which according to my analysis never actually worked and/or has been broken for at least some years). João commit 41cc9eba408a28c02e46f80d40b8dea5d3c34b34 Author: Joao Tavora <joaotavora(a)gmail.com> Date: Thu Jan 30 21:23:51 2014 +0000 Allow "copy-to-repl" from *sldb* buffers from other threads. The previous change didn't deal with the edge case where the *sldb* buffer is associated with a thread different from the REPL's. In these cases the *, / and + variables weren't being set in the REPL where they're useful. This change fixes that by setting these variables in from correct REPL buffer. * contrib/slime-repl.el (slime-repl-eval-string): slime-eval SWANK:SET-REPL-VARIABLES when SWANK acknowledges with OK. * contrib/swank-repl.lisp (*last-repl-form*, *last-repl-values*): new variables. (*repl-set-variables-function*): new variable. (set-repl-variables): new function, extracted from REPL-EVAL, switches to *REPL-SET-VARIABLES-FUNCTION* if that is non-nil. (repl-eval): don't set auto variables here, defer that for later. commit a89789b6e7d78f65de71642fc675261657791421 Author: Joao Tavora <joaotavora(a)gmail.com> Date: Thu Jan 30 16:10:23 2014 +0000 Unbreak "copy-to-repl" functionality in slime-presentations.el The `slime-copy-presentation-to-repl' function simply copied a presentations text to the REPL, which made these objects ephemeral. For *inspector* the presentation was mispointing as soon as the user navigated away*. For *sldb* the presentation it just didn't work. For this functionality, slime-presentation.el uses the same strategy as slime-repl.el. A new `sldb-copy-down-to-repl' is also offered in slime-repl.el. * contrib/slime-presentations.el (slime-copy-presentation-to-repl): Unbreak. Use same `slime-repl-send-string' strategy as slime-repl.el. * contrib/slime-repl.el (sldb-mode-map): Bind M-RET to `sldb-copy-down-to-repl' in `sldb-mode-map'. (sldb-copy-down-to-repl): New function, much like `slime-inspector-copy-down-to-repl' * contrib/slime-repl.el (slime-inspector-copy-down-to-repl): Use only first return value of SWANK:INSPECTOR-NTH-PART.

1 2

Quesstion about Alt-. navigation to function definitions
by Jeff Cunningham 08 Apr '15

08 Apr '15

Hi, Some time ago I could put the point on a function and press Alt-. and slime would take me to the function definition (or a list of possibilities in the case of generics, etc). After one of the updates I did awhile back it stopped working in many circumstances although it contines to work in others. The case it doesn't work in is the one that effects me on a daily basis. Here's two examples: 1. I have a piece of development code with multiple files. The main file loads the other lisp files wherein functions are defined. The only way I can get the operation to work is if I manually compile each function individually. Simply loading the file at any point will reset slime back to not knowing where they are again. 2. Similar situation, only this time using ASD: (in-package :cl-user) (defpackage :ftis-v43-asd (:use :cl :asdf)) (in-package :ftis-v43-asd) (defparameter *ftis-v43-directory* (make-pathname :name nil :type nil :version nil :defaults (parse-namestring *load-truename*))) (asdf:defsystem #:ftis-v43 :depends-on (:cl-extra :cl-ppcre :graham :cl-fad :json-pt :html5 :cl-who :cl-gd-ext) :serial t :components ((:file "ftis-v43-package") (:file "common") (:file "vectors") (:file "waveforms") (:file "interface") (:file "model") (:file "post-processing") (:file "octave") (:file "verify") (:file "make-html-pages"))) And the package.lisp file like this: (defpackage :ftis-v43 (:use :cl :cl-extra :cl-ppcre :cl-fad :graham :cl-gd-ext :json-pt :html5 :cl-who) (:shadowing-import-from :cl-who :str :htm :fmt) (:export #:gen-vhdl-vectors #:gen-1ping-per-setname #:gen-vhdl-mping-vectors #:gen-mping-per-setname #:run-verification #:compare-model-octave #:compare-model-octave-all #:unpack-new-tarball #:process-vhdl-tarball #:process-all-vhdl-tarballs)) The behavior is identical: Alt-. does not work until I manually open one of the source files and compile that function. Other packages I've written and load through ASD work as they should. I can't see any difference in the way they are constructed. Is there any remedy for this? Using grep to move around works but is annoyingly cumbersome and time consuming. Regards, --Jeff

7 29

Proposal: add :host keyword to create-server.
by Frank 08 Apr '15

08 Apr '15

Hello, Currently create-server binds to *loopback-interface* which happens to be "127.0.0.1". BTW: *loopback-interface* is not exported, maybe it should? For remote access binding to the loopback is not really helpful. What about adding a :host keyword to create-server to expose the address we want the server to bind to? I added a patch for your review. The patch is against the latest slime versions available from quicklisp. -Frank

3 4