headers
Marco Baringer | 1 Dec 2007 06:35

Daily ChangeLog diff

Index: slime/ChangeLog
diff -u slime/ChangeLog:1.1252 slime/ChangeLog:1.1253
--- slime/ChangeLog:1.1252	Thu Nov 29 07:36:06 2007
+++ slime/ChangeLog	Fri Nov 30 08:10:40 2007
 <at>  <at>  -1,7 +1,22  <at>  <at> 
+2007-11-30  Helmut Eller  <heller <at> common-lisp.net>
+
+	Handle byte-functions without debug-info.
+
+	* swank-cmucl.lisp (byte-function-location): Return an error
+	if the component has no debug-info.
+
+2007-11-30  Helmut Eller  <heller <at> common-lisp.net>
+
+	Disable the pretty-printer for backtraces.
+	Would be nice if we could print newlines in strings as \n.
+
+	* swank.lisp (*backtrace-printer-bindings*):  New varaible.
+	(backtrace, frame-locals-for-emacs): Use it.
+
 2007-11-29  Tobias C. Rittweiler  <tcr <at> freebits.de>

 	* swank.lisp (valid-function-name-p): Fixed wrt. setf functions.
-	
+
 2007-11-29  Helmut Eller  <heller <at> common-lisp.net>

 	Prettify package names for slime-repl-set-package.
Permalink | Reply | 0 comments |
headers
Alan Caulkins | 1 Dec 2007 10:25

Swank restart-server Patch

I run a long-lived lisp image that I access remotely, and I'd like to
be able to update slime dynamically without stopping and restarting
the whole image. The catch is that after the re-load, I need to
restart the Swank listener thread in case the code for its function
has changed. Although the current CVS version of Slime can stop a
running Swank server by using kill-nth-thread, it doesn't expose the
socket that the thread was listening to. Subsequent threads can't bind
to the port number because there is already a socket using it, and
without a reference to the socket object, it can't be closed.

The attached patch provides this access by defining a new package
variable, *listener-sockets*. There are also two new functions:
stop-server and restart-server. I'm using SBCL 2.6.18, and I have only
tested this code with :spawn style servers, but even though I don't
use :fd-handler or :sigio, I have provided code for them if anyone is
interested in trying it out.

With these changes, an online update to a remote lisp should be
possible from the Slime REPL as follows:

     <cvs update slime>
     (load ".../swank.asd")
     (asdf:oos 'asdf:load-op 'swank)
     (swank:restart-server :port 4005 :style :spawn :dont-close t)
     <slime-disconnect and restart emacs>

This code works well for me, but I'm not very familiar with Slime
implementation details, so it would not surprise me if I've missed
something important in my patch. I hope it proves useful to others.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Terrence Brannon | 2 Dec 2007 01:00
Picon
Gravatar

(1) archives (2) *** - invalid byte #x90 in CHARSET:CP1252 conversion

(1) the archives of this list are not searchable, perhap we should
archive via google groups?

(2) When starting SLIME under clisp on Cygwin, I get the error: *** -
invalid byte #x90 in CHARSET:CP1252 conversion
Startup transcript follows:

(load "/home/Administrator/mydocs/dl/slime-2.0/swank-loader.lisp" :verbose t)
(swank:start-server
"/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/slime.4924"
:external-format :iso-latin-1-unix)

  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

*** - invalid byte #x90 in CHARSET:CP1252 conversion
The following restarts are available:
ABORT          :R1      ABORT
ABORT          :R2      ABORT
(Continue reading)

Permalink | Reply | 2 comments |
headers
Juho Snellman | 2 Dec 2007 01:07
Picon
Picon
Favicon

Re: (1) archives (2) *** - invalid byte #x90 in CHARSET:CP1252 conversion

"Terrence Brannon" <metaperl <at> gmail.com> writes:
> (1) the archives of this list are not searchable, perhap we should
> archive via google groups?

http://dir.gmane.org/gmane.lisp.slime.devel

--

-- 
Juho Snellman
Permalink | Reply | 0 comments |
headers
Helmut Eller | 2 Dec 2007 08:48

Re: A little swank.asd/swank-loader.lisp rectification.

* Samium Gromoff [2007-11-30 13:14+0100] writes:

>> I noticed this patch adds 4 files and a lot of complexity.
>
> It makes the ASDF load path use the generic .fasl storage policy,
> so at a certain conceptual level it removes complexity.
>
> Moreso, it makes data more explicit -- namely the contrib list
> and the constituent file list are now specified at separate,
> well-known locations, prone to creative tampering.
>
> Making the policies that were hidden to be explicit is bound
> to produce that feeling of complexity.
>
> But yes, the loading is now less self-contained.

Adding so many files is to much clutter.

Helmut.
Permalink | Reply | 0 comments |
headers
Helmut Eller | 2 Dec 2007 09:37

Re: (1) archives (2) *** - invalid byte #x90 in CHARSET:CP1252 conversion

* Terrence Brannon [2007-12-02 01:00+0100] writes:

> (2) When starting SLIME under clisp on Cygwin, I get the error: *** -
> invalid byte #x90 in CHARSET:CP1252 conversion
> Startup transcript follows:
>
> (load "/home/Administrator/mydocs/dl/slime-2.0/swank-loader.lisp" :verbose t)
> (swank:start-server
> "/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/slime.4924"
> :external-format :iso-latin-1-unix)

It is a bit strange that you don't see something like 
";; Loading file swank-loader.lisp".

Do you also get those errors if you execute the above forms in a
normal CLISP session (without Emacs)?  You can also try to remove the
:external-format argument.  If you get errors, please show us a
backtrace.

If everything works in the normal session you can try to start Swank
with swank:create-server instead of start-server and then connect from
Emacs with M-x slime-connect.

You can also try to change default-process-coding-system in Emacs to
latin-1 if it isn't already.

Helmut.
Permalink | Reply | 0 comments |
headers
Helmut Eller | 2 Dec 2007 09:20

Re: Swank restart-server Patch

* Alan Caulkins [2007-12-01 10:25+0100] writes:

> This code works well for me, but I'm not very familiar with Slime
> implementation details, so it would not surprise me if I've missed
> something important in my patch. I hope it proves useful to others.

A way to close those sockets is a good feature.  The implementation
could be improved a bit, though.  For now I committed the patch as it
was.

Helmut.
Permalink | Reply | 0 comments |
headers
Marco Baringer | 3 Dec 2007 06:35

Daily ChangeLog diff

Index: slime/ChangeLog
diff -u slime/ChangeLog:1.1253 slime/ChangeLog:1.1254
--- slime/ChangeLog:1.1253	Fri Nov 30 08:10:40 2007
+++ slime/ChangeLog	Sun Dec  2 03:44:33 2007
 <at>  <at>  -1,3 +1,19  <at>  <at> 
+2007-12-02  Alan Caulkins <fatman <at> maxint.net>
+
+	Make it possible to close listening sockets.
+
+	* swank.lisp (stop-server, restart-server): New functions.
+	(*listener-sockets*): New variable.
+	(setup-server): Store open sockets in *listener-sockets*.
+
+2007-12-02  Helmut Eller  <heller <at> common-lisp.net>
+	
+	Add hook to customize the region used by C-c C-c.
+	Useful to recognize block declarations in CMUCL sources.
+
+	* slime.el (slime-region-for-defun-function): New variable.
+	(slime-region-for-defun-at-point): Use it.
+
 2007-11-30  Helmut Eller  <heller <at> common-lisp.net>

 	Handle byte-functions without debug-info.
Permalink | Reply | 0 comments |
headers
Terrence Brannon | 4 Dec 2007 01:38
Picon
Gravatar

win32 SLIME : long time and huge buffer to generate 100, 000 data items

I'm wondering if there is some way to tell SLIME to not try to report
all output  from the inferior lisp? My emacs buffer-menu shows the
slime-repl as huge and ever-growing:

     * *slime-repl sbc: 123816001  REPL

I'm building a huge data structure and need some way of SLIME sending
the command but turning off output from SBCL.

Here is the code that is taking a long time to run:

(defvar *datasize* 100000 "size of dataset")

(defun gendata ()
  (dotimes (i *datasize*)
    (let* (
	   (m (random (1+ i)))
	   (n (random (1+ m)))
	   (text (write (generate 'sentence)))
	   )
      (list :text text :m m :n n)))
  )

(setf *d* (gendata))

--

-- 
http://www.aliveandwell.org/ | http://www.SlowChess.com |
http://mostholy.wholefoodfarmacy.com
Permalink | Reply | 3 comments |
headers
Gary King | 4 Dec 2007 04:47
Favicon
Gravatar

Re: win32 SLIME : long time and huge buffer to generate 100, 000 data items

Hi Terrence,

IIUC, the issue is that you don't want SLIME to print *d* once it has  
been set. This is a somewhat common problem with interactive Lisp use  
and large data items. The "problem" is that setf returns the last  
value and the Lisp printer then tries to print it. There are two easy  
ways around it.

1. (setf *d* (gendata) foo nil)

This sets *d* to (gendata) and foo to nil and then returns nil.

2 (progn (setf *d* (gendata)) nil)

This sets *d* to (gendata) and then returns nil.

You can also look at the values of *print-length* and *print-level*  
(note that some Lisps have other printer control variables that may  
need to be set to completely avoid "run away" printing.

HTH,

On Dec 3, 2007, at 7:38 PM, Terrence Brannon wrote:

> I'm wondering if there is some way to tell SLIME to not try to report
> all output  from the inferior lisp? My emacs buffer-menu shows the
> slime-repl as huge and ever-growing:
>
>     * *slime-repl sbc: 123816001  REPL
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane