| Re: [Dltk-dev] The Console plugins.. |
Hi Johan,
I suppose it is a good idea to improve our current console stuff.
Current consoles infrastructure allow implementation of TCP/IP only consoles.
Each console could have its own protocol, with one exception first line should be console identifier.
Current Consoles UI could send user output to console implementation, and ask for code completions, etc.
As I see we could modify current console infrastructure to support any kind of consoles, not only TCP.
This will allow us to create console implementation which work through DBGp protocol and be integrated with our Debug infrastructure.
Today Tcl console implemented with its own protocol, including completion, etc.
For debuggers case I suppose this is only way to make console functionality.
I think it is possibly to make any kind of completions using DBGP eval.
But if we want console, without debug, it will require DBGp protocol implementation with minimal functionality.
Maybe it will be a good idea to support both variants.
DBGp console for debug cases, and any kind of console for run case.
For current _javascript_ console, it seems we broke it then add environments support.
Best regards,
Andrei Sobolev.
String[] args = new String[] { "127.0.0.1 <http://127.0.0.1>", port, id };Hi Johan,
Nice to hear about this, the idea to run console via DBGp protocol is floating around for a long time and it was just lack of resources and lack of initial vision to implement it over DBGp from the beginning. Thanks for reviving it.
0.95 will be released in a few days and now it looks to be a great time to think about Core Components rewrites/improvements (as well as 1.0 plan in general). Better and generic Console implementation is definitely on this list. As we discussed some time ago internally, there are some obstacles for a fast switch to DBGp. For example we do not have DBGp implementation for TCL, so this modification will force us to implement DBGp (at least part of it) on TCL side if we want console to be available for all the users, etc.
Anyway it's good time to get console in shape, I'll discuss how this may affect existing Ruby and TCL stuff with Xored guys and share our thoughts on the list. In the meantime your ideas and code is very welcome, let's sync up on switch to DBGp details in few days.
Kind Regards,
Andrey
----- Original Message -----
From: "Johan Compagner" <jcompagner@xxxxxxxxx>
To: "DLTK Developer list" <dltk-dev@xxxxxxxxxxx>
Sent: Tuesday, June 17, 2008 10:07:59 PM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] The Console plugins..
Hi,
i quickly build my own scripting console where you can just execute (eval) strings to a running debug session (if a break point is hit)
But i also looked at the org.eclipse.dltk.console.* plugins
But that thing completely doesnt work for me at alle (and i get null pointer errors) because at first it tries to do this:
private _javascript_Console createConsoleInstance(IScriptInterpreter interpreter, String id) {
if (interpreter == null) {
try {
id = "default";
interpreter = new _javascript_Interpreter();
// _javascript_ConsoleUtil
// .runDefaultTclInterpreter((_javascript_Interpreter) interpreter);
} catch (Exception e) {
return null;
}
}
return makeConsole((_javascript_Interpreter) interpreter, id);
}
And then the 2 lines that are commented now..
in that call this happens:
ScriptConsoleServer server = ScriptConsoleServer.getInstance();
String id = server.register(interpreter);
String port = Integer.toString(server.getPort());
------------------------------------------------------------------------
// TODO: Add environments support
IExecutionEnvironment exeEnv = (IExecutionEnvironment) EnvironmentManager
.getLocalEnvironment().getAdapter(IExecutionEnvironment.class);
IFileHandle scriptFile = _javascript_LaunchingPlugin.getDefault()
.getConsoleProxy(exeEnv);
ScriptLaunchUtil.runScript(_javascript_Nature.NATURE_ID, scriptFile,
null, null, args, null);
but that is really not working for our case..
Because that just tries to run a script.. That cant happen for us because our scripts are already running in a rhino debug environment (remotely)
So my question is why is it this way? Why isnt it just connection to the active suspended IScriptThread/ScriptFrame ?
i just do it in one simple method:
private String execute(String txt)
{
IScriptThread scriptThread = getActiveScriptThread();
if (scriptThread != null)
{
IScriptStackFrame frame = null;
try
{
IStackFrame[] stackFrames = scriptThread.getStackFrames();
if (stackFrames.length == 0) return null;
frame = (IScriptStackFrame) stackFrames[stackFrames.length-1];
}
catch (DebugException ex1)
{
ex1.printStackTrace();
}
IScriptEvaluationResult syncEvaluate = scriptThread.getEvaluationEngine().syncEvaluate(txt, frame);
if (syncEvaluate.getValue() != null)
{
try
{
return syncEvaluate.getValue().getValueString();
}
catch (DebugException ex)
{
return ex.toString();
}
}
return syncEvaluate.getException().toString();
}
return null;
}
and that works great.. Through the dbgp protocol and debug connection..
But i get a very itchy feeling now that for many parts i am now duplicating code :( (History/Code completion)
So why does the current ScriptConsole implementation not go through the dbgp protocol?
I just enable my view based on a SUSPEND and disable it again on a RESUME event from the DebugPlugin..
One little problem if there where 2 launches that both are suspended. I have no idea what is the selected one is (but that should be a listener somewhere i guess)
Are there any plans to rewrite the console so that i works through the protocol and with an existing debugging session?
johan
_______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
_______________________________________________