Re: REPL mode

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

> This is a proof of concept, to see if our own REPL is actually better
> than the (not-so-) inferior-lisp mode.

So far I'm hooked! And I see you've already fixed most of the things
mentioned in your last mail.

I hacked in some other little things, like a `slime-lisp-package'
variable that roughly tracks *PACKAGE* and is used for the repl's
package, so you can do (in-package ...) etc.

> There are also problems with output buffering, e.g., when you evaluate
> (labels ((foo () (foo) t)) (foo)) in the listener, CMUCL puts you in
> the (tty-) debugger, but you can't see it because the output is
> buffered somewhere.

It looks like things are getting buffered in the
slime-output-stream. I added an extra `force-output' call (before
completing an evaluation request) to help, but it's easy to reproduce
this problem with "(loop (format t "Hello~%") (sleep 1))" in the
REPL. Possibly something to do with inheriting `string-output-stream'
buffering semantics? I haven't grokked the stream code.

It feels really good to have the REPL to me. Features-wise I think
we've got enough for a respectable 1.0 release. Just the small matter
of filling in the details and tidying up 

Cheers,
Luke

[PATCH] add eldoc support

This patch lets SLIME support Eldoc (i.e. flashing argument lists in
the minibuffer).  Inspired by semantic/cedet, which does this for
many languages.

/s

--- slime.el.~1.61.~	Wed Oct 29 17:18:24 2003
+++ slime.el	Sat Nov  1 18:06:03 2003
 <at>  <at>  -1771,20 +1771,40  <at>  <at> 
 	     (slime-function-called-at-point/line))
     (slime-arglist (symbol-name (slime-function-called-at-point/line)))))

-(defun slime-arglist (symbol-name)
+(defvar slime-arglist-cache (make-hash-table :test 'equal)
+  "Cache for Slime arglist info (useful with Eldoc).")
+
+(defun slime-arglist (symbol-name &optional show)
   "Show the argument list for the nearest function call, if any."
   (interactive (list (slime-read-symbol "Arglist of: ")))
-  (slime-eval-async 
-   `(swank:arglist-string ,symbol-name)
-   (slime-buffer-package)
-   (lexical-let ((symbol-name symbol-name))
-     (lambda (arglist)
-       (message "%s" (slime-format-arglist symbol-name arglist))))))
+  (unless show
+    (setq show #'message))
+  (let ((val (gethash symbol-name slime-arglist-cache)))
+    (if val
+        (funcall show "%s" val)

Re: [PATCH] add eldoc support

On Sat, 1 Nov 2003, Sean O'Rourke wrote:

> This patch lets SLIME support Eldoc (i.e. flashing argument lists in
> the minibuffer).  Inspired by semantic/cedet, which does this for
> many languages.

I applied your patch (both against 1.61 and 1.70), but I must have screwed up
something in the process, because it doesn't seem to work. It shows the elisp
arglists, and when I press space (i.e., slime-space), emacs enters the debugger
with

Debugger entered--Lisp error: (void-variable show)
  (funcall show "%s" (let* (... ...) (let ... ...)))
  (lambda (G20750 arglist) (funcall show "%s" (let* ... ...)))(--symbol-name-- "(&environment env name
args &body body)")
  apply((lambda (G20750 arglist) (funcall show "%s" (let* ... ...))) --symbol-name-- "(&environment env
name args &body body)")
  (lambda (&rest --cl-rest--) (apply (quote ...) (quote --symbol-name--)
--cl-rest--))("(&environment env name args &body body)")
  funcall((lambda (&rest --cl-rest--) (apply (quote ...) (quote --symbol-name--) --cl-rest--))
"(&environment env name args &body body)")

etc.

What am I missing?

In the meantime, here's some experimental code that I use for the same
purpose. Since it is SBCL only, and also to make it easier to try
without messing with the slime sources, I post it as a collection of

swank.lisp 1.50 breaks Slime

Version 1.49 works fine, but 1.50 (and 1.51) gives me this when I
start Slime:

---8<--- (From *Messages* and the Slime-repl:)
Polling "/tmp/slime.8009".. (Abort with `M-x slime-disconnect'.)
 [2 times]
Connecting to Swank on port 41288..
Disconnected.
error in process filter: slime-state/event-panic: The SLIME protocol
  reached an inconsistent state.
error in process filter: The SLIME protocol reached an inconsistent
  state.

The event was:
(:new-features ("ASDF" "MK-DEFSYSTEM"
"COMMON-LISP-CONTROLLER" "PCL-STRUCTURES" "PORTABLE-COMMONLOOPS" "PCL"
"PYTHON" "PENTIUM" "I486" "LINKAGE-TABLE" "MP" "GENCGC" "CMU18"
"CMU18E" "RELATIVE-PACKAGE-NAMES" "CONSERVATIVE-FLOAT-TYPE"
"RANDOM-MT19937" "HASH-NEW" "X86" "LINUX" "GLIBC2" "UNIX" "COMMON"
"CMU" "NEW-COMPILER" "COMMON-LISP" "ANSI-CL" "IEEE-FLOATING-POINT"))

The state stack was:
(slime-evaluating-state slime-idle-state)
---8<---

This is with Emacs 21.3+1-4 and CMUCL 18e-7 on Debian.

--

-- 
Johannes Groedem <OpenPGP: 5055654C>

Re: swank.lisp 1.50 breaks Slime

Johannes Groedem <johs+n <at> ifi.uio.no> writes:

> Version 1.49 works fine, but 1.50 (and 1.51) gives me this when I
> start Slime:

It looks like your slime.el and swank.lisp are out of sync. In
particular, the `:new-features' message is a protocol extension that
was added to both sides the other day.

Maybe you have an out-of-date byte compiled copy of slime.el or
something?

Cheers,
Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Re: swank.lisp 1.50 breaks Slime

* Luke Gorrie <luke <at> bluetail.com>:

> Maybe you have an out-of-date byte compiled copy of slime.el or
> something?

I deleted the byte compiled copy when I updated.  Um, but now it
works, somehow, so I guess I must have fucked up something.  Sorry.

--

-- 
Johannes Groedem <OpenPGP: 5055654C>

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Re: swank.lisp 1.50 breaks Slime

Luke Gorrie writes:

> Maybe you have an out-of-date byte compiled copy of slime.el or
> something?

By the way, can slime.el be compiled? Since README doesn't mention
this, and there is apparently no automated build procedure like that
for .lisp files, I assumed that it shouldn't.

Paolo
--

-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Re: swank.lisp 1.50 breaks Slime

Paolo Amoroso <amoroso <at> mclink.it> writes:

> Luke Gorrie writes:
> 
> > Maybe you have an out-of-date byte compiled copy of slime.el or
> > something?
> 
> By the way, can slime.el be compiled? Since README doesn't mention
> this, and there is apparently no automated build procedure like that
> for .lisp files, I assumed that it shouldn't.

It should be okay to byte-compile - if not it's a bug. I just did a
little tweaking and it seems to work for me. I don't usually do this,
because when I byte-compile I always end up with troubles like
Johannes had.

Byte-compiling did flush out some bugs embarrassing bugs that I fixed
on the way past - so I'll do it more often 

-Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Slime and XEmacs

Hot from the ChangeLog:

  2003-11-03  Luke Gorrie  <luke <at> bluetail.com>

  	* slime.el (slime-display-buffer-region): Hacked to fix completely
  	inexplicable XEmacs problems.

Thank you! I was about to ask whether SLIME is expected to work with
XEmacs. I guess the question still stands -- should I report problems
encountered with XEmacs, or is it a known fact that it acts, well,
strange?

--J.

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel

Re: Slime and XEmacs

Jan Rychter <jan <at> rychter.com> writes:

> Hot from the ChangeLog:
>   
>   2003-11-03  Luke Gorrie  <luke <at> bluetail.com>
>   
>   	* slime.el (slime-display-buffer-region): Hacked to fix completely
>   	inexplicable XEmacs problems.
> 
> Thank you! I was about to ask whether SLIME is expected to work with
> XEmacs. I guess the question still stands -- should I report problems
> encountered with XEmacs, or is it a known fact that it acts, well,
> strange?

You're welcome . Definitely we're supposed to be XEmacs
compatible. In practice it's not always quite right, because primarily
I use GNU 21 and Helmut uses GNU 20. So, by all means, please report
XEmacs problems to the list and we'll fix 'em up.

-Luke

_______________________________________________
slime-devel site list
slime-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/slime-devel