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?
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,
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,
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-...
https://bitbucket.org/budden/budden-tools/src/default/asdf-3.1.4-tools.lisp?...
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/
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
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
-
73budden . -
Douglas Katzman -
Luís Oliveira -
Martin Simmons