[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
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 JavaScriptConsole createConsoleInstance(IScriptInterpreter
interpreter, String id) {
if (interpreter == null) {
try {
id = "default";
interpreter = new JavaScriptInterpreter();
// JavaScriptConsoleUtil
//
.runDefaultTclInterpreter((JavaScriptInterpreter) interpreter);
} catch (Exception e) {
return null;
}
}
return makeConsole((JavaScriptInterpreter) 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());
String[] args = new String[] { "127.0.0.1 <http://127.0.0.1>",
port, id };
// TODO: Add environments support
IExecutionEnvironment exeEnv = (IExecutionEnvironment)
EnvironmentManager
.getLocalEnvironment().getAdapter(IExecutionEnvironment.class);
IFileHandle scriptFile = JavaScriptLaunchingPlugin.getDefault()
.getConsoleProxy(exeEnv);
ScriptLaunchUtil.runScript(JavaScriptNature.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
------------------------------------------------------------------------
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
