[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
