Re: [Dltk-dev] Extensibility

["Jae Gangemi" <jgangemi@xxxxxxxxx>]

  alex: isn't what we currently have for the engine preference page pretty similar to the format preferences - at least in concept? there is a drop down to select the engine, and then if there are additional options available for the engine itself, you are presented w/ a 'link' to go configure them. i remember when i first worked on the engine preference pages, if the engine had configurable options they would appear on the same page as the selector did, but that was changed to the model that currently exists today.

  william: now that i think about it, this functionality already exists in the dltk, but just in a different manor.

  you have the ability to configure an interpreter and a debugging engine on a per project basis - so you can easily handle cases where you have multiple interpreters and/or engines available for use. whether or not the debugging engine is external or 'built-in' (either by specifying a command line option or specifying an additional script to the engine - perl, python, tcl, and ruby all work this way) does not matter. the _javascript_ plugin has an internal debug engine - it doesn't really need to expose the 'Engines' and '_javascript_/JDT' preference pages - i chose to implement that to provide a consistent 'feel' across all the dltk language specific plugins.

  if there are no engine specific debug options available, you don't need to expose anything to the user with regard to the engine. they start a debug session much in the same way someone using the jdt does and are none the wiser. now if your engine does have additional options available, those options need to be made available, and in this case, they are being made on a different set of preference pages then where the interpreter is configured.

  given that, i don't see any reason why you couldn't offer engine configuration options as part of the interpreter install. your DebuggingEngineRunner implemenation just needs to construct the proper command line args to start the debugger - where they come from doesn't matter.

On Sun, Sep 21, 2008 at 7:43 AM, Alex Panchenko <alex@xxxxxxxxx> wrote:

William,

I think that debugging engines preference page should look similar to the formatter: the drop down list and the [Configure...] button to open engine specific dialog. The configure button would be available only for those engines which needs to be configured.

And probably these two fields (drop down list and button) could be placed in the interpreter dialog.

Not all programming languages contain built-in debugging engine. For java there are no external debugging engines since it is already built-in into java.exe and is activated with special command line options. Ruby interpreter does not contain builtin debugging engine - all of them are external to the interpreter.

And some tips on working with DLTK and Eclipse (if you already use it this way - just ignore this part of the message).

Probably it would be more convenient for you to checkout the DLTK sources from CVS, so you can use Eclipse search features:
Ctrl-Shift-G - to search references to the selected element
Ctrl-Alt-H to display call hierarchy of the selected method

Regards,
Alex

----- Original Message -----
From: "William Cook" <william@xxxxxxxxx>

To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx>

Sent: Sunday, September 21, 2008 10:19:10 AM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [Dltk-dev] Extensibility

Jea,
No, this is still more complicated than I mean.
I don't think there should be any notion of "debug engines".
(One never speaks of debug engines for Java or C++, for example).
I think that the interpreter definition should simply include
whatever arguments the users wants to specify for that interpreter to act as
a debugger. The debugger engine would not exist as a concept in the
UI at all, or as java classes within DLTK. At most it would appear in
the argument list of an interpreter, but not be named or have any identity.
There would be no per-project settings for engines. No global
settings for engines. Just interpreters with arguments. Period.
And each project could specify its interpreter, as now.

Simplicity is often the result of exploration and hard work.
Has DLKT arrived at a sufficiently simple model?

-william

Jae Gangemi wrote:
>
>   oh - i get it now...
>
>   for each interpreter you have defined, you could define a set of
> debugging engines that are available to be used for said interpreter,
> instead of defining one engine to be used with
> every interpreter. you'd need to include engine preferences for each
> interpreter that supported i, and the ability to define those settings
> on a per project basis...
>
>   i don't see why functionality like that couldn't exist, but it would
> be a fair amount of work, and serious consideration would have to be
> given to the user experience, especially when dealing with changing
> debugging engine preferences since those will be accessed much more
> frequently then those of the interpreter.
>
>   if there are plans to revisit that portion of dltk in the future,
> perhaps consideration can be given...
>
> On Sat, Sep 20, 2008 at 3:56 PM, William Cook <william@xxxxxxxxx
> <mailto:william@xxxxxxxxx>> wrote:
>
>     About Engines:
>     Yes, but each person is more likely to just use one
>     interpreter/engine combination,
>     so you are designing for the rare case when people switch debug
>     engines on the
>     same interpreter. In my model, i can support this by having two
>     interpreters
>     configured to use the same interpreter executable but different
>     engines. But
>     again, i think this is a rare case and so supporting it should not
>     be the
>     focus of the design. In general, the entire debug engine thing could
>     just
>     be a command line argument on the interpreter. I think that having
>     good variable
>     substitution in the argument list (for plugin folders, for example)
>     would be much
>     more useful.
>
>     Tanks for the tip on rendering. Even when I spend 3 hours looking
>     for the right
>     place to make a change, i don't always find the right one. Frustrating!
>
>     William
>
>     Alex Panchenko wrote:
>
>         Hi William,
>
>         Debugging engines concept is here since there could be different
>         ways to debug the same script. For example for ruby DLTK
>         supports 3 debugging engines:
>         - DLTK ruby implementation based on pure ruby interpreter (slow)
>         - DLTK ruby implementation based on native module ruby-debug
>         - ActiveState ruby debugger
>         All of these debugging engines speak DBGP and could be used with
>         the same interpreter.
>         So debugging engines are here not as pure engineering exercise,
>         they just reflect the real life.
>
>         If you don't need multiple engines - you can provide just one,
>         if you don't need UI for it - just don't create additional
>         property/preference pages.
>
>         Regarding the command line rendering - you can try to override
>         renderCommandLine in AbstractInterpreterRunner class, now it is:
>
>         protected String[] renderCommandLine(InterpreterConfig config) {
>          return config.renderCommandLine(interpreterInstall);
>         }
>
>         The role of InterpreterConfig is just a data structure to
>         collect all arguments together, that's why there are no methods
>         to override it. Though if you need some new methods/extensions
>         please post your ideas.
>         The general mission of DLTK is to make tasks simpler. If you
>         found that something is harder - please ask question or suggest
>         changes/patches to the DLTK.
>
>         Regards,
>         Alex
>
>         ----- Original Message -----
>         From: "William Cook" <william@xxxxxxxxx <mailto:william@xxxxxxxxx>>
>         To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx
>         <mailto:dltk-dev@xxxxxxxxxxx>>
>         Sent: Sunday, September 21, 2008 12:34:43 AM GMT +06:00 Almaty,
>         Novosibirsk
>         Subject: [Dltk-dev] Extensibility
>
>         I think that DLTK is over-engineered to require Interpeter Types
>         and Debug Engines. I wish you could just specify an interpreter and
>         give appropriate options and be done with it. I wonders if
>         the Eclipse launch configuration dialogs could be reused to specify
>         the interpreter and its attributes.
>
>         On other example I had is the order of command rendering. Currently
>         the interpreter arguments in the interpreter are put after the
>         interpreter arguments from the launch configuration. Here's what
>         I had to do:
>
>         Original problem:
>         * I have some trouble with the order of arguments. It seems to be
>                1) Interpreter path
>                2) interpreter arguments *from the launch configuration*
>                3) Interpreter arguments *from the interpreter definition*
>                4) script path
>                5) script arguments
>         It seems to me that the #2 and #3 components are backwards, and
>         this causes problems with Gambit
>
>         So I hunt around and find where this functionality is defined:
>         in InterpreterConfig.renderCommandLine
>         Its a nice routine that I could override. But I cannot easily
>         replace the InterpeterConfig class with my own, because
>         AbstractScriptLaunchConfigurationDelegate says
>             new InterpreterConfig
>         in the middle of a fairly large routine, createInterpreterConfig
>         (its about 60 lines long with lots of good code). If the
>         creation of InterpeterConfig  was through a factory, then I
>         would not have had to copy this code.
>
>         But I can replace AbstractScriptLaunchConfigurationDelegate with
>         my own, so i copy createInterpreterConfig and change the line to:
>             new SchemeInterpreterConfig
>         Then I get an error because getScriptEnvironment is private, so
>         i copy it too.
>
>         I create class SchemeInterpreterConfig and implement
>                renderCommandLine
>         But I find that there are several other overloaded versions of
>         it, and one of them doesn't even include item #3 in the command
>         line at all! I track this down, and it is called by ScriptLaunchUtil
>         and then i track that down and it appears never to be used. So
>         I assume it is dead code and move on. Anyway, it now seems to
>         be working.
>
>         At this point I am taking DLKT as a *library* and just implementing
>         my Scheme system using it. I know people have suggested that I
>         change DLKT itself. But I would rather not just hack on it,
>         because it seems very close to release and it is useful to see
>         how much you an do without changing it. I might later, however.
>
>         William
>
>         _______________________________________________
>         dltk-dev mailing list
>         dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
>         https://dev.eclipse.org/mailman/listinfo/dltk-dev
>         _______________________________________________
>         dltk-dev mailing list
>         dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
>         https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
>
>         __________________________________________________
>         D O T E A S Y - "Join the web hosting revolution!"
>                     http://www.doteasy.com
>
>     _______________________________________________
>     dltk-dev mailing list
>     dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/dltk-dev
>
>
>
>
> --
> -jae
> __________________________________________________
> D O T E A S Y - "Join the web hosting revolution!"
> http://www.doteasy.com
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev

--
-jae