Helmut Eller | 1 Aug 08:50 2004
Picon

Re: Finding source of functions compiled with slime-compile-defun.

Peter Seibel <peter <at> javamonkey.com> writes:

> Again, having not looked into it in any great detail, is there any way
> to communicate source location back to Lisp so it can find the source
> of functions compiled with C-c C-c?

excl::*source-pathname* seems to be the right place for Allegro CL.  I
committed some code to set this variable when compiling with C-c C-c.

Helmut.

Luke Gorrie | 1 Aug 09:00 2004
Picon

Daily ChangeLog diff

Index: slime/ChangeLog
diff -u slime/ChangeLog:1.492 slime/ChangeLog:1.493
--- slime/ChangeLog:1.492	Fri Jul 30 14:41:25 2004
+++ slime/ChangeLog	Sat Jul 31 23:46:48 2004
 <at>  <at>  -1,3 +1,15  <at>  <at> 
+2004-08-01  Helmut Eller  <e9626484 <at> stud3.tuwien.ac.at>
+
+	* swank-allegro.lisp (swank-compile-string): Use a temporary file
+	and set excl::*source-pathname* manually.  This way we can find
+	the source buffer of functions compiled with C-c C-c.
+	(call-with-temp-file, compile-from-temp-file): New functions.
+	(list-callers, function-callers, in-constants-p)
+	(map-function-constants): Implements list callers by groveling
+	through the constants pools of named functions.
+
+	* swank-lispworks.lisp: Minor refactoring.
+
 2004-07-30  Helmut Eller  <e9626484 <at> stud3.tuwien.ac.at>

 	* slime.el (slime-connection): Say "No default connection
 <at>  <at>  -10,7 +22,10  <at>  <at> 

 	* swank-cmucl.lisp (call-with-debugging-environment): Only handle
 	DI::UNHANDLED-CONDITION not all DI:DEBUG-CONDITIONs.
-	
+
+	* swank-backend.lisp (sldb-condition): Show the original condition
+	in the message.
+
 2004-07-30  Luke Gorrie  <luke <at> bluetail.com>
(Continue reading)

Helmut Eller | 1 Aug 09:02 2004
Picon

Re: swank/xref and slime-load-file

Jonathan Meeks <jdmmmmm <at> sbcglobal.net> writes:

> I think there is a bug in slime-load-file.
>
> I have noticed that when a file has its *.lisp extension in the
> parameter to slime-load-file, swank/xref is not able to find its
> callees (with slime-list-callees). 
>
> When called interactively, the extension is stripped and
> slime-list-callees works.  So, shouldn't the extension be stripped by
> slime-load-file when called non-interactively, as well?

Most implementations load the fasl file if the filename has no
extension (and if there is a fasl file in the directory).  I think the
problem you are seen is more related to interpreted functions.  When
you load the .lisp file, the loaded functions are usually interpreted
and not compiled.  That's at least the situation for CMUCL. 

slime-list-callees currently only works for compiled and byte-compiled
functions; interpreted functions are basically ignored.  Also CMUCL
doesn't record the source location for interpreted functions.  

To support slime-list-callees for interpreted functions we probably
need to walk the IR code.  To record the source location we would need
a little change to CMUCL itself.  Not sure if interpreted code is
important enough for the added complexity.

Helmut.

(Continue reading)

Jonathan Meeks | 1 Aug 18:09 2004

Re: swank/xref and slime-load-file


At Sun, 01 Aug 2004 09:02:13 +0200,
Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> wrote:
> Most implementations load the fasl file if the filename has no
> extension (and if there is a fasl file in the directory).  I think the
> problem you are seen is more related to interpreted functions.  When
> you load the .lisp file, the loaded functions are usually interpreted
> and not compiled.  That's at least the situation for CMUCL. 
> 
> slime-list-callees currently only works for compiled and byte-compiled
> functions; interpreted functions are basically ignored.  Also CMUCL
> doesn't record the source location for interpreted functions.  
> 
> To support slime-list-callees for interpreted functions we probably
> need to walk the IR code.  To record the source location we would need
> a little change to CMUCL itself.  Not sure if interpreted code is
> important enough for the added complexity.

Yes, that appears to be the issue.  

Would it be worth adding a load/compile/re-xref command from within
the lisp-mode buffer?  I have my own hacked up elisp for personal use
but could generalize it if anyone is interested.

Also, I am not sure if this has been mentioned before, but how
difficult would it be to add some sort of specially bound variable
that has the output from the last command in the REPL?  An comparable
example exists in ipython.

--Jonathan
(Continue reading)

Alan Caulkins | 1 Aug 15:41 2004
Picon

Extra Swank threads after slime-disconnect

Hello list,

To start, I'm new to the list, and I'd like to congratulate everyone on
creating such a wonderful piece of software. I've been continually
impressed by SLIME ever since I started keeping up with it a few months
ago. However, I think I've found a bug in Swank's spawn connection-style.
I've been connecting to an already-running sbcl (on Linux) as per the
instructions found on on Bill Clemenson's weblog, linked from CLiki's
SLIME-HOWTO page.

fatman <at> hubris:~$ sbcl --load slime.lisp
This is SBCL 0.8.13, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
.
<snip>
.
;; Swank started at port: 4005.
*

My slime.lisp is simple:
(load "lib/emacs/slime/swank-loader.lisp")
(swank::create-swank-server 4005 :spawn #'swank::simple-announce-function t)

Before connecting to Swank for the first time, there are 2 sbcl threads
running:

fatman <at> hubris:~$ ps -e | grep sbcl
 9831 pts/0    00:00:04 sbcl
 9832 pts/0    00:00:00 sbcl

(Continue reading)

Alan Caulkins | 1 Aug 16:00 2004
Picon

Re: Extra Swank threads after slime-disconnect

Oops. It looks like I got the polarity wrong on that diff I just sent.
Guess it was a long night.

-A

			Linux: The ultimate video game.

506a507,510
> (defun kill-connection-threads (connection)
>   (kill-thread (connection.control-thread connection)
>   (kill-thread (connection.repl-thread connection))))
>
613c617,618
<                      :serve-requests #'spawn-threads-for-connection))
---
>                      :serve-requests #'spawn-threads-for-connection
>                        :cleanup #'kill-connection-threads))

Peter Seibel | 1 Aug 22:15 2004

Re: Finding source of functions compiled with slime-compile-defun.

Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> writes:

> Peter Seibel <peter <at> javamonkey.com> writes:
>
>> Again, having not looked into it in any great detail, is there any way
>> to communicate source location back to Lisp so it can find the source
>> of functions compiled with C-c C-c?
>
> excl::*source-pathname* seems to be the right place for Allegro CL.  I
> committed some code to set this variable when compiling with C-c C-c.

Cool. Thanks.

-Peter

--

-- 
Peter Seibel                                      peter <at> javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

Alain.Picard | 2 Aug 06:21 2004

Package gets lost in narrowed buffer


Dear Slimers,

This might be a strange way of working, but I quite often
"narrow" my lisp buffers, to work on only a few definitions.
Recently, SLIME seems to lose track of the package in that
situation and evaluates the C-cC-c requests in the USER
package, instead of the correct package.

Cheers,

Luke Gorrie | 2 Aug 07:07 2004

Re: RFC: SLIME homepage suggestion

Nikodemus Siivola <tsiivola <at> cc.hut.fi> writes:

> [1] http://www.bluetail.com/~luke/oktoberfest.jpg
See also http://www.bluetail.com/~luke/misc/portugal.jpg

Spotted a week ago in a Portuguese paper by Thibault Langlois from
this list. Exact meaning unknown. :-)

Luke Gorrie | 2 Aug 07:27 2004

Re: Package gets lost in narrowed buffer

Alain.Picard <at> memetrics.com writes:

> This might be a strange way of working, but I quite often
> "narrow" my lisp buffers, to work on only a few definitions.

The strange part is that I didn't notice this, since I do that too.
Nice catch, fixed now.


Gmane