Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] Extensibility 
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>
To: "DLTK Developer Discussions" <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
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
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

Back to the top