[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Dltk-dev] Some questions and observations (extensibility, console, etc)
|
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.
* 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.
* 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.
* 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.
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).
* 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.
William
