finding an implementation of SWANK interface
Hi! Maybe I'm missing something, but I don't know how do I find defimplementation of some definterface. E.g. I want to go to swank/backend:activate-stepping, but EMACS only sends me to definterface, and I have to grep for defimplementation. I don't know how should I handle this, but I added a simple defparameter into defimplementation form. Now, when I'm asking for definition of swank/backend:activate-stepping, I see two suggested source locations: (defvar swank/backend:activate-stepping) (defun swank/backend:activate-stepping) defun is for definterface, defvar is for defimplementation. This works at least in SBCL, I guess it is handy. Patch is attached. This may seem a bit ugly, but SBCL does not suggest a way to extend its definition database with new classes, so I see no good way to go. WBR, Budden
Hi Budden, On Tue, Dec 19, 2017 at 11:26 AM, 73budden . <budden73@gmail.com> wrote:
defun is for definterface, defvar is for defimplementation. This works at least in SBCL, I guess it is handy. Patch is attached. This may seem a bit ugly, but SBCL does not suggest a way to extend its definition database with new classes, so I see no good way to go.
Helmut implemented what seemed like an elegant solution to this issue back in 2014: <https://github.com/slime/slime/commit/74ef7010d79fad14db43d6ff989f177a7a8986b5> Sadly, it had to be reverted because ran into SBCL's compiler lock. <https://github.com/slime/slime/commit/f63fd440f1beeadd155b871f5d9fc8729c2dfc0d> Perhaps you can come up with a solution? Perhaps there's a way to force compilation of these methods ahead of time? Something else? -- Luís Oliveira http://kerno.org/~luis/
Thanks for the feedback! Thanks for a feedback.
... Sadly, it had to be reverted because ran into SBCL's compiler lock. Perhaps you can come up with a solution?
No. I'm trying to do some SBCL hacking, but I'm (yet) not experienced enough to fix such things. The patch I suggested is extremely simple, it works in SBCL and there is a good chance it would work on other CL implementations too. It is not elegant, but for me it is still better than grep. And I see no extreme difference between my patch showing implementation as "defvar" and Helmut's one, which I guess shows implementation as "defmethod". Anyway there's no explicit statement that actually they are "definterface" and "defimplementation". I admit my solution is essentially uglier, but it works while Helmut's does not. Slightly better thing would be to show the exceprt from docstring together with "defvar" and "defun", so that it would be clear that "defvar" stands for "defimplementation". But I'm not sure I have the resources to implement that :) 2017-12-19 14:56 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
Hi Budden,
On Tue, Dec 19, 2017 at 11:26 AM, 73budden . <budden73@gmail.com> wrote:
defun is for definterface, defvar is for defimplementation. This works at least in SBCL, I guess it is handy. Patch is attached. This may seem a bit ugly, but SBCL does not suggest a way to extend its definition database with new classes, so I see no good way to go.
Helmut implemented what seemed like an elegant solution to this issue back in 2014: <https://github.com/slime/slime/commit/74ef7010d79fad14db43d6ff989f177a7a8986b5>
Sadly, it had to be reverted because ran into SBCL's compiler lock. <https://github.com/slime/slime/commit/f63fd440f1beeadd155b871f5d9fc8729c2dfc0d>
Perhaps you can come up with a solution? Perhaps there's a way to force compilation of these methods ahead of time? Something else?
-- Luís Oliveira http://kerno.org/~luis/
Maybe something like this hack in the LispWorks backend could be generalized: https://github.com/slime/slime/blob/master/swank/lispworks.lisp#L60 __Martin
On Tue, 19 Dec 2017 16:29:18 +0300, 73budden said:
Thanks for the feedback!
Thanks for a feedback.
... Sadly, it had to be reverted because ran into SBCL's compiler lock. Perhaps you can come up with a solution?
No. I'm trying to do some SBCL hacking, but I'm (yet) not experienced enough to fix such things. The patch I suggested is extremely simple, it works in SBCL and there is a good chance it would work on other CL implementations too. It is not elegant, but for me it is still better than grep. And I see no extreme difference between my patch showing implementation as "defvar" and Helmut's one, which I guess shows implementation as "defmethod". Anyway there's no explicit statement that actually they are "definterface" and "defimplementation". I admit my solution is essentially uglier, but it works while Helmut's does not.
Slightly better thing would be to show the exceprt from docstring together with "defvar" and "defun", so that it would be clear that "defvar" stands for "defimplementation".
But I'm not sure I have the resources to implement that :)
2017-12-19 14:56 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
Hi Budden,
On Tue, Dec 19, 2017 at 11:26 AM, 73budden . <budden73@gmail.com> wrote:
defun is for definterface, defvar is for defimplementation. This works at least in SBCL, I guess it is handy. Patch is attached. This may seem a bit ugly, but SBCL does not suggest a way to extend its definition database with new classes, so I see no good way to go.
Helmut implemented what seemed like an elegant solution to this issue back in 2014: <https://github.com/slime/slime/commit/74ef7010d79fad14db43d6ff989f177a7a8986b5>
Sadly, it had to be reverted because ran into SBCL's compiler lock. <https://github.com/slime/slime/commit/f63fd440f1beeadd155b871f5d9fc8729c2dfc0d>
Perhaps you can come up with a solution? Perhaps there's a way to force compilation of these methods ahead of time? Something else?
-- Luís Oliveira http://kerno.org/~luis/
On Tue, Dec 19, 2017 at 1:29 PM, 73budden . <budden73@gmail.com> wrote:
... Sadly, it had to be reverted because ran into SBCL's compiler lock. Perhaps you can come up with a solution?
No. I'm trying to do some SBCL hacking, but I'm (yet) not experienced enough to fix such things.
I wonder if we can play with compute-applicable-method to force compilation of the interfaces/implementations ahead of time? <https://github.com/guicho271828/inlined-generic-function> might hold some tips on how to do that. This might a fun project if you'd like to explore the MOP. Martin's idea is promising too. Regarding your patch, I really dislike defining special variables without the earmuffs. I've been bitten by such variables in the past and it's quite annoying and confusing. (defconstant would be slightly better, but still I'd rather pursue the other two ideas first. :-( Cheers, -- Luís Oliveira http://kerno.org/~luis/
Not in connection with any one issue in particular, I'm trying to make the compiler re-entrant. That ought to be a sufficient remedy to this, right? On Tue, Dec 19, 2017 at 9:36 AM, Luís Oliveira <luismbo@gmail.com> wrote:
On Tue, Dec 19, 2017 at 1:29 PM, 73budden . <budden73@gmail.com> wrote:
... Sadly, it had to be reverted because ran into SBCL's compiler lock. Perhaps you can come up with a solution?
No. I'm trying to do some SBCL hacking, but I'm (yet) not experienced enough to fix such things.
I wonder if we can play with compute-applicable-method to force compilation of the interfaces/implementations ahead of time? <https://github.com/guicho271828/inlined-generic-function> might hold some tips on how to do that. This might a fun project if you'd like to explore the MOP.
Martin's idea is promising too.
Regarding your patch, I really dislike defining special variables without the earmuffs. I've been bitten by such variables in the past and it's quite annoying and confusing. (defconstant would be slightly better, but still I'd rather pursue the other two ideas first. :-(
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
On Tue, Dec 19, 2017 at 2:53 PM, Douglas Katzman <dougk@google.com> wrote:
Not in connection with any one issue in particular, I'm trying to make the compiler re-entrant. That ought to be a sufficient remedy to this, right?
Yes, indeed. Looking forward to that. :-) Cheers, -- Luís Oliveira http://kerno.org/~luis/
I see you point and I agree that what I suggest is ugly, but, as I said, for me it is better than grep, and improvement do not worth further efforts, so I'll simply continue using it by myself Really good SBCL-specific solution would be to add some sort of lispwork's dspec facility for SBCL, so that M-. would show exactly (swank/backend::definterface foo) (swank/backend::defimplementation foo) I have a patch to do things like that for asdf:defsystem and SBCL's function encapsulations (advices), so I see (ASDF/PARSE-DEFSYSTEM:DEFSYSTEM :BUDDEN-TOOLS) in my M-. for :budden-tools Code is here: https://bitbucket.org/budden/budden-tools/src/default/sbcl--find-definition-sources-by-name--patch.lisp?at=default&fileviewer=file-view-default https://bitbucket.org/budden/budden-tools/src/default/asdf-3.1.4-tools.lisp?at=default&fileviewer=file-view-default But here's not the sbcl-devel :)
Hi!
(defconstant would be slightly better, but still I'd rather pursue the other two ideas first. :-( Maybe deftype? It is quite unlikely that one would ever want to define a type with the same name as the name of SWANK interface.
2017-12-19 17:36 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
On Tue, Dec 19, 2017 at 1:29 PM, 73budden . <budden73@gmail.com> wrote:
... Sadly, it had to be reverted because ran into SBCL's compiler lock. Perhaps you can come up with a solution?
No. I'm trying to do some SBCL hacking, but I'm (yet) not experienced enough to fix such things.
I wonder if we can play with compute-applicable-method to force compilation of the interfaces/implementations ahead of time? <https://github.com/guicho271828/inlined-generic-function> might hold some tips on how to do that. This might a fun project if you'd like to explore the MOP.
Martin's idea is promising too.
Regarding your patch, I really dislike defining special variables without the earmuffs. I've been bitten by such variables in the past and it's quite annoying and confusing. (defconstant would be slightly better, but still I'd rather pursue the other two ideas first. :-(
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
It looks to cause issues with CCL - I didn't recognize what exactly (yet). 2017-12-31 2:14 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
On Sat, Dec 30, 2017 at 6:55 PM 73budden . <budden73@gmail.com> wrote:
Maybe deftype? It is quite unlikely that one would ever want to define a type with the same name as the name of SWANK interface.
I think that should work much better.
Luís
participants (4)
-
73budden . -
Douglas Katzman -
Luís Oliveira -
Martin Simmons