On Fri, Sep 19, 2008 at 4:01 PM, William Cook
<william@xxxxxxxxx> wrote:
Jae,
Oh no. It seems that perhaps I have not been clear on any of my points.
Let me try to clarify.
Jae Gangemi wrote:
On Fri, Sep 19, 2008 at 11:37 AM, William Cook <william@xxxxxxxxx <mailto:william@xxxxxxxxx>> wrote:
* Remove the concept of "debug engines". I think of debug engine
setup as being part of an interpreter, not a separate concept. I
wanted to remove the debug engine parts of the UI, but this seems
difficult because it is burned into the core of DLTK.
the 'debug engine' is actually independent of the interpreter that is used. any debugging engine should be able to be used by any interpreter as long as the engine for that language implements the dbgp protocol.
if you don't want to offer debug support, just don't create any debug launch configurations and don't include any of the debugging preference pages.
My understanding is that a "debug engine" is a piece of code that implements the language side of the DBGp protocol for a given language, while DLTK implements the IDE side. The debug engine that I have written for Gambit Scheme is completely specific to the Gambit interpreter. My guess is that debug engines will tend to be implementation-specific, although I can imagine a generic one for Smalltalk or Python. Hence I think of the debug engine as being part of the interpreter, not separate.
I *do* want debugging support. I just want to think of the language interpreter has having a debug engine in it, rather than there being a separate debug engine. But DLTK seems to require that the user know about debug engines.
what you want to do can be done w/o the user needing to know about your debugging engine - this topic should probably be part of it's own thread. feel free to start it w/ answers to the following and we'll go from there:
- how do you 'activate' your debugging engine?
- is it pluggable to the interpreter or built right in (could the interpreter be used w/ some other engine that doesn't speak dbgp)?
* Get rid of the "system libraries" idea, which I don't think I want
to mess with in my extension. I think this is impossible.
if you don't want to have any system libraries, you should be able to override the protected String retrivePaths(...) method in your AbstractInterpreterInstallType implementation to just return an empty string, and it should be treated as if no system libraries are installed (which i believe is a valid use case regardless).
I want to get rid of the UI, but it seems to be non-trivial. I could be wrong about that.
what specific ui parts are you referring too?
* Add a field to the "new interpeter" setup dialog. This looks to be
impossible without copying and replacing a large number of classes.
could you elaborate on this further? you have to add an implementation of AddScriptInterpreterDialog to your project anyway, so you should be able to override the createDialogFields() method to add a field to the wizard. if that is not sufficent, i'm sure something could be done to accomidate you.
Yes, I could probably override createDialogFields, but it seems like the data handling to store the new data would be difficult, if I wanted to store it in the same place as the other information. Again, I gave up when it started to look complicated. I don't know if its possible or not.
it's possible, but i am not sure of all the pieces that would need to be changed (although i'm sure w/ some refactoring the number of pieces could drop significantly). you could start a separate thread on this if you're up for taking on the task - if you ask questions you'll get support.
* Create a default interpreter setup, because I am going to include
some interpreters inside my Scheme plugin update site. This lets the
system be more easy to install. The setup needs to be created with
code. It was a struggle, but I finally managed to make it work.
have you looked at the _javascript_ plugin? it comes bundled w/ the rhino interpreter already configured (although you do need to 'check' it in the preferences to enable, not sure if that is by design or a bug).
Ok, i'll take a look at how they do it. Thanks!
feel free to refactor the code into something more generic and submit a patch.
COMMENTS: One big source of problems it that many of the "new" calls
within DLTK are hard-coded. Thus you cannot override classes very
easily. A good dependency injection or factory model is sorely
needed! On the one hand I think that DLTK could be much easier to
use if it was more generic and allowed plugging in a few things for
parsing (even the interpreter setup could be pretty much generic, i
think). On the other hand, I want to disable features and this seems
impossible.
could you elaborate further on this? there's no reason that these things can not be changed and/or made more flexible.
Rather than call "new Foo" everywhere, one pattern is to call
"Factory.getFactory().createFoo();" such that the factory is
instantiated from a class name defined in an extension point. Another
way is to have a general extension point mechanism (dependency
injection) and call Factory.create("org.eclipse.dltk.core.Foo")
where the class name that is created can be configured for each class.
sorry - i should have been more specific - i was talking examples in the code that would be more beneficial if they were provided by a factory.
QUESTIONS: I have a few questions...
* How are we actually supposed to rely on DLTK? I see that DLTK is
installed with Eclipse now, so that means we are not supposed to
make changes to it when developing our plugins? That was always my
assumption. But I am concerned about the versioning nightmare that
will likely ensue as DLTK changes and all the languages try to stay
in sync.
that depends - i currently do not have dltk installed into my main eclipse installation, instead i have the sources checked out and they are loaded into pde environment.
if you want to actively use dltk in your 'main' install, you can still develop new features against the head, you just need to make sure that when you launch the pde environment, you aren't including the dltk plugins that come bundled w/ eclipse and instead use those of the checked out source.
Yes, I am completely happy with the *developer* experience. I'm trying to
understand how end users will deal with things, if DLTK is updated
separately from my Scheme plugin, I can imagine that there could be
interface and functionality problems (as when I upgraded from DLTK 0.95).
that's always going to happen. as the provider of the plugin, you have to say you support eclipse version x and dltk version x. if a new version is released and the api changes, the user can not upgrade until you have synced w/ the changes.
* I like DBGP but I'm unhappy about the (recent?) change to use its
console interfaces rather than Eclipse standard consoles when
debugging. I understand that this allows for remote debugging, which
is neat. But I its going to cause more pain in my debug engine to
try to get Scheme to use an alternative console. How hard would it
be to have an option, as someone suggested?
i'm not familiar enough w/ the console interfaces to comment on this. i know that i haven't hooked into any dltk specific console classes, so unless something is happening under the hood, it seems that the regular eclipse consoles are used, even w/ remote debugging.
The issue is not the console itself, it is how STDin and STDout are
(or are not) connected to the console. With DLTK 0.95 the normal
standard in/out don't seem to be connected when in debug mode, although
they are connected in run mode. In debug mode we are supposed to use
the DBGp in/out protocol instead of stdin/stdout.
this could be a bug or just not implemented yet.
