Why doesn't CUSP use the Eclipse debug UI and model?
2 views
Skip to first unread message
William
Oct 1, 2008, 11:57:24 PM10/1/08
to Cusp Development
Eclipse has a standard user interface for threads, stack frames and
such. I'm curious why Cusp doesn't use it? Instead it seems to have
some kind of emacs emulation in its own window. Wouldn't it be easier
to just use the Eclipse infrastructure rather than recreating it?
I've been doing some serious Lispish development but for some reason I
started using Scheme instead of CL. I implemented a basic Scheme
debugger plugin for Eclipse, but I'm still not very happy. CL seems to
have better debugger infrstracuture (in SLIME) and so it should be
possible to hook this up to Eclipse. Since I already have Scheme code
that interfaces with Eclipse DLTK, it might not be that hard to
interface it to SWANK.
Here's my plugin:
Schemeide
http://schemeide.sourceforge.net/
Right now it mostly does auto-formatting and debugging. It works with
Gambit 4.2.9 on MacOS, Win32, and Linux. I am using the standard DBGp
protocol, so it should be pretty easy to modify other scheme
environments to work with my plugin. For information on the protocol,
see http://www.xdebug.org/docs-dbgp.php . The source code for the
Gambit interface to DGBp is included on sourceforge.
The IDE is still alpha quality, with many features still to do. But it
seems to be usable, at least for easy stack inspection of problems.
Function breakpoints still need to be entered manually. And the
interaction between the output window and debug mode is not good. I'll
be working on it since I'm using it daily in my Scheme work. I think
its a reasonable foundation and it will eventually be a good Scheme
IDE.
William
such. I'm curious why Cusp doesn't use it? Instead it seems to have
some kind of emacs emulation in its own window. Wouldn't it be easier
to just use the Eclipse infrastructure rather than recreating it?
I've been doing some serious Lispish development but for some reason I
started using Scheme instead of CL. I implemented a basic Scheme
debugger plugin for Eclipse, but I'm still not very happy. CL seems to
have better debugger infrstracuture (in SLIME) and so it should be
possible to hook this up to Eclipse. Since I already have Scheme code
that interfaces with Eclipse DLTK, it might not be that hard to
interface it to SWANK.
Here's my plugin:
Schemeide
http://schemeide.sourceforge.net/
Right now it mostly does auto-formatting and debugging. It works with
Gambit 4.2.9 on MacOS, Win32, and Linux. I am using the standard DBGp
protocol, so it should be pretty easy to modify other scheme
environments to work with my plugin. For information on the protocol,
see http://www.xdebug.org/docs-dbgp.php . The source code for the
Gambit interface to DGBp is included on sourceforge.
The IDE is still alpha quality, with many features still to do. But it
seems to be usable, at least for easy stack inspection of problems.
Function breakpoints still need to be entered manually. And the
interaction between the output window and debug mode is not good. I'll
be working on it since I'm using it daily in my Scheme work. I think
its a reasonable foundation and it will eventually be a good Scheme
IDE.
William
Sergey Kolos
Oct 2, 2008, 4:53:53 AM10/2/08
to Cusp Development
On Oct 2, 4:57 am, William <w7c...@gmail.com> wrote:
> Eclipse has a standard user interface for threads, stack frames and
> such. I'm curious why Cusp doesn't use it? Instead it seems to have
> some kind of emacs emulation in its own window. Wouldn't it be easier
> to just use the Eclipse infrastructure rather than recreating it?
and we don't know intimately what Eclipse provides. So using whole
Eclipse infrastructure would require huge time investment before we
even could start coding Cusp. I think Tim chose right strategy to
first implement functionality that is available in slime and then work
on moving this functionality to be more Eclipse like. Otherwise I
don't think we would ever see Cusp be made usable at all. Also the
mapping between lisp development concepts and model that Eclipse
provides is not one-to-one and should be interpretted carefully.
This being said, we are not rejecting the idea of using Eclipse
infrastructure.
> that interfaces with Eclipse DLTK, it might not be that hard to
> interface it to SWANK.
startec coding Cusp. But we will investigate how we could leverage it
in future Cusp development - thanks for the reference.
Scott Michel
Oct 3, 2008, 12:44:56 AM10/3/08
to Cusp Development
On Oct 2, 1:53 am, Sergey Kolos <sergey.ko...@gmail.com> wrote:
> On Oct 2, 4:57 am, William <w7c...@gmail.com> wrote:
>
> > Eclipse has a standard user interface for threads, stack frames and
> > such. I'm curious why Cusp doesn't use it? Instead it seems to have
> > some kind of emacs emulation in its own window. Wouldn't it be easier
> > to just use the Eclipse infrastructure rather than recreating it?
> On Oct 2, 4:57 am, William <w7c...@gmail.com> wrote:
>
> > Eclipse has a standard user interface for threads, stack frames and
> > such. I'm curious why Cusp doesn't use it? Instead it seems to have
> > some kind of emacs emulation in its own window. Wouldn't it be easier
> > to just use the Eclipse infrastructure rather than recreating it?
> > that interfaces with Eclipse DLTK, it might not be that hard to
> > interface it to SWANK.
Given the interactive environment that the REPL gives you, would it
> > interface it to SWANK.
make sense to have the Eclipse IDE switch over to the debug
perspective on a non-syntax compile error (which invokes the SBCL
debugger and offers various ways to restart the evalution)? :-)
William
Oct 3, 2008, 10:46:15 AM10/3/08
to Cusp Development
I understand that Eclipse can have a pretty steep learning curve.
But it seems to me that you have implemented a lot of code
to make your stack browser work. To use the Eclipse GUI for
stacks, all you have to do is instantiate a few debug model
classes. It is the kind of thing you can do in a few days:
http://www.eclipse.org/articles/Article-Debugger/how-to.html
Rather than complain about what I think is an obviously
incorrect choice, I am volunteering to modify CUSP to use
the Eclipse debugger infrastructure.
I have very limited time right now, so it will probably take me
a few months (a half-day every week or so).
I would also evaluate whether the launching framework
would help. My guess is that you use a pure REPL model,
so that to run your program you type in an expression,
you don't click a "run program" button. I personally would
like it if there was a "main" expression and you could just
say "run" from anywhere and it would run the main program.
I don't like having to go find the text of the main expression
and type/paste it into the REPL or othewise execute it.
But before I start I'd like to have your support, at least
in principle, for this project. If you can point out some of the
unclear mappings between the Lisp debug model and Eclipse,
that would help me in planning the integration. I am not
sure that we need to use DLTK. It is somewhat over-engineered,
unfortunately, and it is hard to take parts and not others.
As for Scott's question about debug mode and compile
errors. I don't know! It doesn't seem terrible to me that
you should switch perspectives. But if there is some way to
prevent it, that would be good too. We could also just
extend the Lisp perspective to allow more debugging
windows when appropriate.
WIlliam
But it seems to me that you have implemented a lot of code
to make your stack browser work. To use the Eclipse GUI for
stacks, all you have to do is instantiate a few debug model
classes. It is the kind of thing you can do in a few days:
http://www.eclipse.org/articles/Article-Debugger/how-to.html
Rather than complain about what I think is an obviously
incorrect choice, I am volunteering to modify CUSP to use
the Eclipse debugger infrastructure.
I have very limited time right now, so it will probably take me
a few months (a half-day every week or so).
I would also evaluate whether the launching framework
would help. My guess is that you use a pure REPL model,
so that to run your program you type in an expression,
you don't click a "run program" button. I personally would
like it if there was a "main" expression and you could just
say "run" from anywhere and it would run the main program.
I don't like having to go find the text of the main expression
and type/paste it into the REPL or othewise execute it.
But before I start I'd like to have your support, at least
in principle, for this project. If you can point out some of the
unclear mappings between the Lisp debug model and Eclipse,
that would help me in planning the integration. I am not
sure that we need to use DLTK. It is somewhat over-engineered,
unfortunately, and it is hard to take parts and not others.
As for Scott's question about debug mode and compile
errors. I don't know! It doesn't seem terrible to me that
you should switch perspectives. But if there is some way to
prevent it, that would be good too. We could also just
extend the Lisp perspective to allow more debugging
windows when appropriate.
WIlliam
Sergey Kolos
Oct 3, 2008, 1:36:15 PM10/3/08
to Cusp Development
On Oct 3, 3:46 pm, William <w7c...@gmail.com> wrote:
> I understand that Eclipse can have a pretty steep learning curve.
> But it seems to me that you have implemented a lot of code
> to make your stack browser work. To use the Eclipse GUI for
> stacks, all you have to do is instantiate a few debug model
> classes. It is the kind of thing you can do in a few days:
>
> http://www.eclipse.org/articles/Article-Debugger/how-to.html
>
> Rather than complain about what I think is an obviously
> incorrect choice, I am volunteering to modify CUSP to use
> the Eclipse debugger infrastructure.
> I have very limited time right now, so it will probably take me
> a few months (a half-day every week or so).
it would be very nice.
> I would also evaluate whether the launching framework
> would help. My guess is that you use a pure REPL model,
> so that to run your program you type in an expression,
> you don't click a "run program" button. I personally would
> like it if there was a "main" expression and you could just
> say "run" from anywhere and it would run the main program.
> I don't like having to go find the text of the main expression
> and type/paste it into the REPL or othewise execute it.
starting repl. My first reaction about your proposal was
negative, but after some thought it makes sense. I think we'll
need to think more about how to use launching framework.
> But before I start I'd like to have your support, at least
> in principle, for this project. If you can point out some of the
> unclear mappings between the Lisp debug model and Eclipse,
> that would help me in planning the integration. I am not
> sure that we need to use DLTK. It is somewhat over-engineered,
> unfortunately, and it is hard to take parts and not others.
> As for Scott's question about debug mode and compile
> errors. I don't know! It doesn't seem terrible to me that
> you should switch perspectives. But if there is some way to
> prevent it, that would be good too. We could also just
> extend the Lisp perspective to allow more debugging
> windows when appropriate.
>
> WIlliam
find time to implement them.
Scott Michel
Oct 6, 2008, 1:04:57 PM10/6/08
to Cusp Development
I still think that you all need to carefully classify the errors that
_should_ trip the debugger perspective. Instantiating a few debug
classes likely forces a perspective change to the Debug perspective.
I'm not convinced that a forced perspective change is a good thing,
especially when Lisp's concept of a run time error is vastly different
from what Java and C++ categorize as run time errors.
As the "stupid" example, syntax errors do trip sbcl's debugger (and
openmcl/ccl's debugger). Consequently, I'm of the opinion that
debugging should be an explicit user choice.
Breakpoints, single stepping: Good.
Automatic perspective switching because sbcl's debugger got invoked:
Bad
_should_ trip the debugger perspective. Instantiating a few debug
classes likely forces a perspective change to the Debug perspective.
I'm not convinced that a forced perspective change is a good thing,
especially when Lisp's concept of a run time error is vastly different
from what Java and C++ categorize as run time errors.
As the "stupid" example, syntax errors do trip sbcl's debugger (and
openmcl/ccl's debugger). Consequently, I'm of the opinion that
debugging should be an explicit user choice.
Breakpoints, single stepping: Good.
Automatic perspective switching because sbcl's debugger got invoked:
Bad
Scott Michel
Oct 6, 2008, 1:10:43 PM10/6/08
to Cusp Development
On Oct 3, 10:36 am, Sergey Kolos <sergey.ko...@gmail.com> wrote:
> > I would also evaluate whether the launching framework
> > would help. My guess is that you use a pure REPL model,
> > so that to run your program you type in an expression,
> > you don't click a "run program" button. I personally would
> > like it if there was a "main" expression and you could just
> > say "run" from anywhere and it would run the main program.
> > I don't like having to go find the text of the main expression
> > and type/paste it into the REPL or othewise execute it.
I seem to recall that the launch framework would be used to customize
> > would help. My guess is that you use a pure REPL model,
> > so that to run your program you type in an expression,
> > you don't click a "run program" button. I personally would
> > like it if there was a "main" expression and you could just
> > say "run" from anywhere and it would run the main program.
> > I don't like having to go find the text of the main expression
> > and type/paste it into the REPL or othewise execute it.
how the REPL is launched. At least that's the direction in which I'm
headed with managing Lisp implementations. If you really needed to
canonicalize a Lisp application's invocation, you could easily just
add another launch configuration without changing the fundamental
character of interacting with a REPL.
A "main" expression (and generally bundling up Lisp applications) has
historically been a problem. Personally, I think you would negatively
change the character of Cusp and Lisp interaction if all one could do
is launch a Lisp application. The REPL is an integral part of working
with Lisp.
Scott Michel
Oct 7, 2008, 12:59:20 AM10/7/08
to Cusp Development
Slightly better example: I've been playing with Horner's method (yes,
it's a simple example, but it's primarily a didactic exercise for a
colleague). I implemented horners using defgeneric and defmethod, one
for lists and one for arrays/vectors. I left out the defmethod for the
vector and accidentally invoked the generic using a vector argument in
the REPL.
Should cusp invoke the Eclipse debugger in this case, when I've
clearly fumbled in the REPL?
The code (abbreviated):
(defgeneric horners (coeffs p0))
(defmethod horners ((coeffs list) (p0 real)) ...)
#| (defmethod horners ((coeffs array) (p0 real) ...) |#
FYI: Horner's method is an O(1) algorithm for evaluating polynomials,
e.g., (horners '(4 2 -5 1) 3) evaluates 4x^3 + 2x^2 -5x - 1 at x = 3,
by noting that the polynomial can be rewritten as ((4x + 2)x - 5)x -
1. It's a popular question on the computer science GRE, also pops up
when doing binary multiplication without a hardware multiplier (the
shift-add method).
it's a simple example, but it's primarily a didactic exercise for a
colleague). I implemented horners using defgeneric and defmethod, one
for lists and one for arrays/vectors. I left out the defmethod for the
vector and accidentally invoked the generic using a vector argument in
the REPL.
Should cusp invoke the Eclipse debugger in this case, when I've
clearly fumbled in the REPL?
The code (abbreviated):
(defgeneric horners (coeffs p0))
(defmethod horners ((coeffs list) (p0 real)) ...)
#| (defmethod horners ((coeffs array) (p0 real) ...) |#
FYI: Horner's method is an O(1) algorithm for evaluating polynomials,
e.g., (horners '(4 2 -5 1) 3) evaluates 4x^3 + 2x^2 -5x - 1 at x = 3,
by noting that the polynomial can be rewritten as ((4x + 2)x - 5)x -
1. It's a popular question on the computer science GRE, also pops up
when doing binary multiplication without a hardware multiplier (the
shift-add method).
Reply all
Reply to author
Forward
0 new messages