Guys,
Probably this is a bit controversial, but here are my 5 cents.
We use nothing of DLTK debugging infrastructure on our consulting projects. There's no reason to. Implementing your own clean line-based protocol (with no crazy Base64 payloads inside) only takes a few weeks, together with all the necessary tests and any customizations you would never be able to do with DLTK.
DLTK has a lot of time savers, like indexing and outline. But you should use them wisely. The core launching and debugging API of Eclipse is rather good, you can employ it directly with no fear. You also won't get a crappy interpreter management UI which forces you to name any interpreters you add. (We're lucky that DLTK is not forcing us to name breakpoints, sigh.) <flame mode off>
Disclaimer: I'm not affiliated with xored software and the core DLTK team and do not express their opinion. But I did contribute the initial Ruby type inferencing into DLTK (together with Mikhail Kalugin, who's one of the initial DLTK committers and shares my vision on this), so I have quite a bit of insight…
Free tip: if you end up hunting for why the Debug view misses a correct selection, make sure all your debug model objects implement hashCode and equals. And if green "current line" markers are not erased, make sure you broadcast _thread_ state events and handle hasStackFrames correctly. These are the _only_ tricky bugs we have encountered working with core debugging APIs.
On Sat, Sep 20, 2008 at 3:51 AM, Jae Gangemi
<jgangemi@xxxxxxxxx> wrote:
are you looking to use a different user interface then the debug perspective?
if yes, i am not sure that can be done.
On Fri, Sep 19, 2008 at 4:06 PM, William Cook
<william@xxxxxxxxx> wrote:
Andrew,
The main benefit from DLTK is that it implements the IDE objects needed for the debug model within Eclipse, and it also implements the IDE side of DBGp.
I did take the Python plugin and strip it down and modify it for Scheme.
I just want to remove the *debug engine dialogs* from DLTK. In my case the debug engine is included in the interpreter, which has its own UI, so there is no reason for the user to have to specify a debug engine with separate UI.
My hunting is restricted primarily to my code and the DLTK source code. I sometimes step through Eclipse code but I have not yet had to examine Eclipse too much. It is sufficiently well documented that reading the code has not been necessary (yet).
William
Andrew Mickish wrote:
SUMMARY: I think DLTK is a great thing and hope that all dynamic language IDEs for Eclipse would use it. I would never have been able to make a Scheme debugger without the DLTK to handle the debugging stuff. I also find it very frustrating, but I don't have a broad enough perspective to really tell you how to do things differently.
Can you please explain how using DLTK is easier than interfacing directly with Eclipse?
Is it because you were able to take a working plugin for another language and refactor it to support Scheme?
You said that you think of a debug engine as integrated with an interpreter, and since you want to remove debug from the UI, it sounds like you are handling debugging independently of DLTK or even Eclipse. Can you elaborate on this? I have looked through the documentation under http://wiki.eclipse.org/DLTK and I cannot find any reference to debugging.
When you spend 3 to 5 hours hunting for the right spot to change, what code are you hunting through? Your own code? DLTK? Eclipse?
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
Andrey.
