slime-devel

slime-devel@common-lisp.net

4231 discussions

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

05 Sep '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2348 slime/ChangeLog:1.2349 --- slime/ChangeLog:1.2348 Sat Aug 18 09:34:06 2012 +++ slime/ChangeLog Tue Sep 4 08:03:22 2012 @@ -1,3 +1,9 @@ +2012-09-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-loader.lisp (lisp-version-string): Add "s" to Allegro with + SMP support. + Patch by Dave Cooper. + 2012-08-18 Stas Boukarev <stassats(a)gmail.com> * swank-abcl.lisp (find-definitions): Call ext:resolve before

1 0

[slime-devel] updated lisp-version-string in swank-loader.lisp for Allegro CL 9.0 with SMP
by Dave Cooper 04 Sep '12

04 Sep '12

Hello, I made a proposed change to swanker-loader.lisp to make the unique-dir-name for fasl files be unique for Allegro CL 9.0 with SMP which was released in late July. The fasls produced by the SMP version of Allegro are incompatible with the non-SMP version, so the unique-dir-name for fasls should be named differently. Here is my version of lisp-version-string --- it has just the additional ~@[~A~] in the format, for the possible inclusion of "s" for smp, and the conditional (and (member :smp *features*) "s") as a format argument to match this new format directive. This is compatible with the way the current asdf (2.24) is handling the naming for this new fasl distinction between SMP and non-SMP Allegro. (defun lisp-version-string () #+(or clozure cmu) (substitute-if #\_ (lambda (x) (find x " /")) (lisp-implementation-version)) #+(or cormanlisp scl) (lisp-implementation-version) #+sbcl (format nil "~a~:[~;-no-threads~]" (lisp-implementation-version) #+sb-thread nil #-sb-thread t) #+lispworks (lisp-implementation-version) #+allegro (format nil "~A~A~@[~A~]~A~A" excl::*common-lisp-version-number* (if (eq 'h 'H) "A" "M") ; ANSI vs MoDeRn (and (member :smp *features*) "s") (if (member :64bit *features*) "-64bit" "") (excl:ics-target-case (:-ics "") (:+ics "-ics"))) #+clisp (let ((s (lisp-implementation-version))) (subseq s 0 (position #\space s))) #+armedbear (lisp-implementation-version) #+ecl (ecl-version-string) ) Please advise if this is the correct place and format to submit proposals like this. Best Regards, Dave Cooper Genworks Support

2 1

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

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

14 Jul '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2344 slime/ChangeLog:1.2345 --- slime/ChangeLog:1.2344 Tue Jun 19 12:46:53 2012 +++ slime/ChangeLog Fri Jul 13 06:52:45 2012 @@ -1,3 +1,7 @@ +2012-07-13 Helmut Eller <heller(a)common-lisp.net> + + * slime.el: Don't compile functions that are now in other files. + 2012-06-19 Helmut Eller <heller(a)common-lisp.net> * swank-ecl.lisp (wait-for-input): Provide implementation

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel