slime-devel August 2012

slime-devel@common-lisp.net

5 participants
8 discussions

[slime-devel] cutting and pasting S-expressions from buffer to REPL
by Faheem Mitha 27 Dec '14

27 Dec '14

Hello everyone, I've recently started using SLIME with SBCl on Debian, where SLIME defaults to using SBCL, at least when it is installed. So far I am very impressed. I haven't been able to take off and fly yet, but I'm on the runway.:-) I'm particularly impressed by the underlining source which has compile errors, and doing a popup on mouseover feature. I don't know whose idea this was, but it is pretty damn cool. Does anyone know the history of this feature? So, I have a question about SLIME. When debugging, or indeed otherwise, I find it useful to copy and paste S-expressions from a buffer to the REPL. I've been using the mouse for this, which is decidedly sub-optimal. I hate using the mouse. I was thinking that it would be handy to have a command which would copy and paste S-expressions from a buffer to the REPL, while at the same time switching the buffer to the REPL. The S-expression would be chosen by having the cusor to the right of the closing expression. I'm not sure if this position has a name. I don't know if this command already exists. I could not find it in the manual. If it doesn't, could someone tell me what code would tell emacs to do this? My knowledge of Emacs programming is non-existent. Please CC me on any reply. Thanks. Regards, Faheem

6 14

Re: [slime-devel] unexpected behavior of eval-when with CCL when compiling with C-c C-k
by Faheem Mitha 31 Aug '12

31 Aug '12

Hi Helmut, Thanks very much for the detailed and helpful reply. May I post this as an answer to the SO question? If you don't want to post it yourself, that is. On Thu, 30 Aug 2012, Helmut Eller wrote: > On Thu, Aug 30 2012, Faheem Mitha wrote: > >> Hi, >> >> I recently posted a question at >> >> http://stackoverflow.com/questions/12156902/unxpected-behavior-with-eval-wh… >> >> Brief summary: >> >> The following code should (I think) set *read-default-float-format* to >> double float. Well, it does compile with C-c C-k, but running >> >> *read-default-float-format* >> >> in the REPL afterwards gives SINGLE-FLOAT. >> >> So the value of *read-default-float-format* in the REPL has not changed >> from the default value of SINGLE-FLOAT. >> >> Note, however, that the >> >> (print *read-default-float-format*) >> >> in the code does return DOUBLE-FLOAT. >> >> Rainer Joswig, in his answer to this question, says that this is >> because the compilation and the REPL are on different threads (if I >> understand him correctly), but I'd like some evidence of this. > > SLIME creates a new thread for C-c C-k. As compiling could potentially > take a long time, using a new thread seems like a reasonable thing to > do. Therefore the code that compiles and loads your code is a different > thread than the REPL thread. > > For evidence, evaluate (princ ccl:*current-process*) in the REPL and > inside the eval-when form. Ah. I tried the function "all-processes". *current-process* is better. >> Also, this code works fine with SBCL. >> In addition to wanting to understand why this is happening, I'd like >> to know whether it is possible to work around this, and set >> *read-default-float-format* in a file, rather than having to set it on >> the command line. >> >> I'm not sure whether this issue has something to do with SLIME, so I'm >> posting here first. >> >> Platform and versions. I'm using Debian squeeze x86. The version of >> SLIME is from Debian unstable, 1:20120525-2. CCL is the 1.8 release. I >> tried it both with the upstream binaries from >> http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl, and >> a binary package created by me - see Package ccl at >> mentors.debian.net. The result was the same in each case. >> >> Thanks in advance. Please CC me on any reply. > > When CCL creates a new thread it binds some special variables in the new > thread. *READ-DEFAULT-FLOAT-FORMAT* is one of them. You can see the > full list of those variables with (ccl::standard-initial-bindings). > Also look at the documentation of MAKE-PROCESS[1]. I think > CCL:DEF-STANDARD-INITIAL-BINDING can be used to change those variables > for future thread, but I know no easy way to change them in all existing > threads. When it says MAKE-PROCESS here, it actually means thread, right? This terminology is a little confusing. The documentation says "See DEF-STANDARD-INITIAL-BINDING" but there is no further information about DEF-STANDARD-INITIAL-BINDING that I could find. It seems this is a function. I found one example of usage which looks like (ccl::def-standard-initial-binding *read-default-float-format* 'double-float) Is this correct usage? So, this changes the default value of *read-default-float-format* for all future threads? Should this be called in CCL's init file or somewhere else? One last question, which is tangentially related. Is there some easy way to find out what CCL (or, more generally, any CL implementation) function is called by C-c C-k? Regards, Faheem > Helmut > > [1] http://ccl.clozure.com/ccl-documentation.html#f_make-process

2 1

[slime-devel] unexpected behavior of eval-when with CCL when compiling with C-c C-k
by Faheem Mitha 30 Aug '12

30 Aug '12

Hi, I recently posted a question at http://stackoverflow.com/questions/12156902/unxpected-behavior-with-eval-wh… Brief summary: The following code should (I think) set *read-default-float-format* to double float. Well, it does compile with C-c C-k, but running *read-default-float-format* in the REPL afterwards gives SINGLE-FLOAT. So the value of *read-default-float-format* in the REPL has not changed from the default value of SINGLE-FLOAT. Note, however, that the (print *read-default-float-format*) in the code does return DOUBLE-FLOAT. Rainer Joswig, in his answer to this question, says that this is because the compilation and the REPL are on different threads (if I understand him correctly), but I'd like some evidence of this. Also, this code works fine with SBCL. In addition to wanting to understand why this is happening, I'd like to know whether it is possible to work around this, and set *read-default-float-format* in a file, rather than having to set it on the command line. I'm not sure whether this issue has something to do with SLIME, so I'm posting here first. Platform and versions. I'm using Debian squeeze x86. The version of SLIME is from Debian unstable, 1:20120525-2. CCL is the 1.8 release. I tried it both with the upstream binaries from http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl, and a binary package created by me - see Package ccl at mentors.debian.net. The result was the same in each case. Thanks in advance. Please CC me on any reply. Regards, Faheem ####################################################################### (eval-when (:compile-toplevel :load-toplevel :execute) (require :asdf) (require :cl-rmath) (setf *read-default-float-format* 'double-float)) (print *read-default-float-format*)

2 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 19 Aug '12

19 Aug '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2347 slime/ChangeLog:1.2348 --- slime/ChangeLog:1.2347 Sat Aug 4 16:48:19 2012 +++ slime/ChangeLog Sat Aug 18 09:34:06 2012 @@ -1,3 +1,8 @@ +2012-08-18 Stas Boukarev <stassats(a)gmail.com> + + * swank-abcl.lisp (find-definitions): Call ext:resolve before + finding definitions, for the symbol may be not autoloaded yet. + 2012-08-04 Stas Boukarev <stassats(a)gmail.com> * swank-sbcl.lisp (call-with-debugging-environment): Use

1 0

[slime-devel] Daily ChangeLog diff
by Helmut Eller 14 Aug '12

14 Aug '12

Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.549 slime/contrib/ChangeLog:1.550 --- slime/contrib/ChangeLog:1.549 Sat Aug 4 15:35:13 2012 +++ slime/contrib/ChangeLog Mon Aug 13 13:50:34 2012 @@ -1,3 +1,9 @@ +2012-08-13 Stas Boukarev <stassats(a)gmail.com> + + * swank-arglists.lisp (extra-keywords/slots): Check for + slot-definition-initfunction being present before calling + slot-definition-initform. + 2012-08-04 Stas Boukarev <stassats(a)gmail.com> * swank-arglists.lisp (test-print-arglist): bind

1 0

[slime-devel] Strange scores in slime-fuzzy-completion / feature request.
by pjb＠informatimago.com 10 Aug '12

10 Aug '12

In a new lisp file type: (defpackage :slime-fuzzy-misfeature (:use :cl)) (in-package :slime-fuzzy-misfeature) (defun f () (let ((pos 4) (siz 2)) (+ pos siz))) (defstruct pt h v) (defun g (p) (let ((pos-h (pt-h p)) (pos-v (pt-v p))) (+ ))) C-x C-s C-c C-l Then move after the + in g, and type po M-TAB We get these fuzzy completion choices: For help on how the use this buffer, see `slime-fuzzy-completions-mode'. Flags: boundp fboundp generic-function class macro special-operator package Completion: Flags: Score: ----------------------------------------------------------- -------- -------- pop -f---m-- 24.70 pos -------- 24.70 pos-h -------- 22.20 pos-v -------- 22.20 position -f------ 21.13 position-if -f------ 20.70 position-if-not -f------ 20.41 … 1- pop is bound to a function not a variable, we're completing a variable: it should not be proposed at all! 2- pos is not in scope it should not be proposed at all. In general it looks like shorter symbols are proposed with higher scores. Instead, symbols in scope (taking account namespaces) should have higher scores. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

2 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 05 Aug '12

05 Aug '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2345 slime/ChangeLog:1.2347 --- slime/ChangeLog:1.2345 Fri Jul 13 06:52:45 2012 +++ slime/ChangeLog Sat Aug 4 16:48:19 2012 @@ -1,3 +1,11 @@ +2012-08-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-sbcl.lisp (call-with-debugging-environment): Use + sb-debug::resolve-stack-top-hint instead of just + sb-debug:*stack-top-hint*, because now it can contain things other + than just frames. + * clean up: (signal (make-condition ...)) => (signal ...) + 2012-07-13 Helmut Eller <heller(a)common-lisp.net> * slime.el: Don't compile functions that are now in other files. Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.548 slime/contrib/ChangeLog:1.549 --- slime/contrib/ChangeLog:1.548 Wed May 23 13:55:43 2012 +++ slime/contrib/ChangeLog Sat Aug 4 15:35:13 2012 @@ -1,3 +1,9 @@ +2012-08-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-arglists.lisp (test-print-arglist): bind + *print-right-margin* to 1000 instead of NIL, because the default + value on ABCL is less than the length of the tested arglist. + 2012-05-23 Christophe Rhodes <csr21(a)cantab.net> * swank-media.lisp: add provide.

1 0

[slime-devel] semantic indentation
by Evrim Ulu 01 Aug '12

01 Aug '12

Hello, I'm looking for a solution to my indentation problem. I have functions named like <:html, <:body, <package1:a-tag. I want them to be indented as '(&body) so that on the next line indentation is neat. For example, like this: (<:html :some-property "foo" (<:body ...)) I've read this, http://common-lisp.net/project/slime/doc/html/Semantic-indentation.html Is there a way to tell swank/slime indent all symbols in a package for instance (find-package '<) and indent all exported symbols as '(&body)? Thanks, evrim.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel August 2012