Re: [Dltk-dev] Some questions and observations (extensibility, console,

["Johan Compagner" <jcompagner@xxxxxxxxx>]

For javascript the interpreters and debugging engine is also a bit
hacky yes, this is because in js the default interpreter is just build
in (rhino) and i need to choose a file  but there is no executable
file... What i do know is just pick a random file because internally
it only checks if there is one  and nothing more..

We implemented our own debug engine thats just default selected and
there is only 1 so our end users never have to go to those
preferences.

For our end users the scriptengine configuration is just done through
plugin_customizations.ini file where we just have an xml string that
has a default rhino config pushed.

I think to make this easier a plugin should be able to programatically
define a scriptenigine configuration (and then also a debuggable
enigine i think these 2 should be combined as one)

Johan



On 9/19/08, 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.
>
>>     * 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
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
>