gmane.lisp.slime.devel

Re: Patch for LispWorks compiler notes error

Martin Simmons — 2013-05-14T15:46:48

Thanks, I've fixed it.

Patch for LispWorks compiler notes error

Robert Smith — 2013-05-12T22:30:53

Hello:

As it stands, SLIME will error when it encounters compiler notes generated
by LispWorks 6 :EXPLAIN functionality. For example:

(defun dist (x y)
  (declare (:explain :variables))
  (sqrt (+ (* x x) (* y y))))

will error with

#<CONDITIONS:COMPILER-NOTE 402026DC23> fell through ETYPECASE expression.
Wanted one of (ERROR STYLE-WARNING WARNING).
   [Condition of type CONDITIONS:CASE-FAILURE]

As a patch, add the two lines prefixed by a + to the function
LISPWORKS-SEVERITY in the file "swank-lispworks.lisp" indicated at the end
of this mail.

Thanks,

Robert


PATCH FOR "swank-lispworks.lisp":

  (defun lispworks-severity (condition)
    (cond ((not condition) :warning)
          (t (etypecase condition
+              #+lispworks6
+              (conditions:compiler-note :note)
               (error :error)
               (style-warning :warning)
               (warning :warning)))))

New contrib: slime-fancy-trace

Luís Oliveira — 2013-05-10T23:47:38

Hello,

The attached patch implements a new contrib that rebinds C-c C-t to an
alternative implementation of slime-toggle-trace-fdefinition that
takes advantage of the slime-parse contrib.

With this contrib loaded, C-u C-t is able to trace methods, setf
functions, local functions, etc, when supported by the SWANK backend.

Cheers,

--
Luís Oliveira
http://r42.eu/~luis/

Re: slime-sexp-at-point in slime-repl buffers

Helmut Eller — 2013-05-10T22:14:33


It would be easier is to make a different command, say
slime-repl-inspect, and bind it to the key where slime-inspect was.

Helmut

Re: slime-sexp-at-point in slime-repl buffers

Marco Baringer — 2013-05-10T17:48:56


I don't really think it should be (when reading slime.el), i don't see
why the normal slime-inspect function has to have an extra layer of
indirection that only the repl code would ever need to use (if there
were other places in the code using this variable i would have a
different opinion, but there aren't, and i can't see any that would make
use of this).

It should of course be apparent when reading the slime-repl.el, but then
it is, and the use of defadvice makes it stand out more as a "warning!
monkey patching here!" (which it is) rather than just a "oh nothing
major, just tweaking a hook" (which it is not).

I see it as an exception to the normal code flow that only applies in
certain cases when the slime-repl contrib is loaded, defadvice is the
most natural way to express that.


yeah, i saw that, and i'm aware of that idiom in slime's code (and in
elisp in general). for something like slime-find-buffer-package i can
totally see various modes/contribs/languages having different concepts
of what a pa

Re: slime-sexp-at-point in slime-repl buffers

Stas Boukarev — 2013-05-10T12:24:57

It's not apparent when reading the code that it may be redefined
somewhere else at some other time. Slime uses variables for cases like
this, see `slime-find-buffer-package-function', for example.

Re: SLIME talk at the Emacs Conference

Luke Gorrie — 2013-05-10T05:29:32

Howdy all,

Here's a recording of the Emacs conference talk that I gave:
http://www.youtube.com/watch?v=eZDWJfB9XY4

Cool that about half the people in the room had actually used SLIME
themselves.


On 7 March 2013 11:28, Helmut Eller <eller.helmut< at >gmail.com> wrote:

Testing subscriber post

Drew C — 2013-05-09T22:28:41

This should simply go through non-moderated.

 -- drewc

Re: slime-sexp-at-point in slime-repl buffers

Marco Baringer — 2013-05-09T21:59:06


why?

- the slime-repl is a contrib and i don't want to modify the "builtin"
  slime-sexp-at-point to support functionality which may or may not be
  loaded.

- this late modification of existing functions is exactly what defadvice
  is supposed to do, the presence of advice is clearly shown by
  describe-function and it can be disabled if needed.

There are obviously (many) other ways to implement this (buffer local
variables, custom flags, redefinition, etc.), but none of them seem as
clear, to me at least, as a simple defadvice.

Re: slime-sexp-at-point in slime-repl buffers

Stas Boukarev — 2013-05-09T21:06:56

I object to the use of defadvice.

slime-sexp-at-point in slime-repl buffers

Marco Baringer — 2013-05-09T16:22:25

Calling slime-inspect at a prompt in the slime repl buffer without any
other input will suggest the prompt itself ("CL-USER>" or whatever) as
the default value to inspect. I can not think of any case where this
behaviour would be useful :)

The attached patch advises slime-sexp-at-point, when the slime-repl.el
contrib is loaded, to ignore the prompt text (if point is in the input
area, otherwise the normal behaviour of slime-sexp-at-point applies).

Unless anyone objects to the patch (or the implementation) i'll commit
this later tomorrow.

Daily ChangeLog diff

Helmut Eller — 2013-04-03T09:44:01

Re: [PATCH] hiding swank frames from debugger backtrace on Allegro

Luís Oliveira — 2013-04-02T21:17:46

On Tue, Apr 2, 2013 at 10:10 PM, Alan Ruttenberg
<alanruttenberg< at >gmail.com> wrote:

The other implementations I looked at definitely do different things.
What would, say, the ABCL and ACL backends have in common? Not sure if
it's easy to share code amongst SWANK backends.

Cheers,

--
Luís Oliveira
http://r42.eu/~luis/

Re: [PATCH] hiding swank frames from debuggerbacktrace on Allegro

Stas Boukarev — 2013-04-02T14:41:13

Applied, thanks.

patch for "Failed test on CCL"

Ben Hyde — 2013-03-28T01:58:28

The issue reported in http://article.gmane.org/gmane.lisp.slime.devel/10751  i.e. that when using CCL  swank complains of a test failing upon a fresh connection maybe resolved by adding #+ccl (ccl::*print-abbreviate-quote* t) as shown:

(defun decoded-arglist-to-string (decoded-arglist
                                  &key operator highlight
                                  print-right-margin)
  (with-output-to-string (*standard-output*)
    (with-arglist-io-syntax
      (let ((*print-right-margin* print-right-margin)
            #+ccl (ccl::*print-abbreviate-quote* t))
        (print-decoded-arglist decoded-arglist 
                               :operator operator 
                               :highlight highlight)))))

  - ben

fyi ccl's *print-abbreviate-quote* is an extension, see also http://paste.lisp.org/display/136370

Re: Where to look the trace output ?

Helmut Eller — 2013-03-23T07:23:58


Which thread calls unmap-message-window?  Probably not the same thread
that processes REPL requests.  The binding of *trace-output* is
probably different in that other thread.

Helmut

Where to look the trace output ?

z_axis — 2013-03-23T01:04:56

STUMPWM> *trace-output*
  #<SWANK-BACKEND::SLIME-OUTPUT-STREAM  #x38924796>
STUMPWM> (trace unmap-message-window) => NIL

But i see no trace output after the message window disappears.


Sincerely!

Re: Can i make slime enter the specified package once slime-connect successfully ?

z_axis — 2013-03-22T23:31:30

It works great! thx

在 Fri, 22 Mar 2013 15:12:25 +0800，Jingtao Xu <jingtaozf< at >gmail.com> 写道:

Re: Can i make slime enter the specified package once slime-connect successfully ?

Jingtao Xu — 2013-03-22T07:12:25

Yes, you can add hook function slime-connected-hook in emacs,for example,

(defun slime-repl-setup-initial-packages ()
  (loop for package in '(:ab :project-a :project-b :project-c)
       do
       (when (slime-eval `(cl:if (cl:find-package ,package) t))
         (slime-repl-set-package package)
         (return))))
(add-hook 'slime-connected-hook 'slime-repl-setup-initial-packages t)

Regards,
jingtao.

With best regards,jingtao.


On Fri, Mar 22, 2013 at 2:19 PM, z_axis <z_axis< at >163.com> wrote:

Can i make slime enter the specified package once slime-connect successfully ?

z_axis — 2013-03-22T06:19:13

Now i have to call (in-package :foo) after  slime-connect ?

Sincerely!

[PATCH] hiding swank frames from debugger backtraceon Allegro

Luís Oliveira — 2013-03-14T11:31:08

Hello,

As you well know, SLIME's debugger, when invoked, will inevitably add
some frames to the current stack, which SWANK attempts to hide. On
Allegro, when signalling an error from the REPL, those extra frames look
something like this:

  0: ((FLET (:TOP-LEVEL-FORM "swank-allegro.lisp" 4123) SWANK-
       BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT) #<Function (:INTERNAL
       SWANK::DEBUG-IN-EMACS 0)>)
  1: (SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT #<Function
       (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>)
  2: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR < at > #x218114d2>)
  3: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR < at > #x218114d2>)
  4: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1))
  5: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0)
       #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-
       DEBUGGER-HOOK 1) < at > #x218115f2>)
  6: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK-
       DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1)
       < at > #x218115f2>)
  7: (