Eclipse Community Forums: Dynamic Languages Toolkit (DLTK)

Help

Home

Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » debug engine overview

Show: Today's Messages :: Show Polls :: Message Navigator

debug engine overview [message #6384]

Sun, 10 June 2007 22:52

Jae Gangemi

Messages: 28
Registered: July 2009

Junior Member

could someone provide a quick overview in how the debugging
engine/framework works.

i see that there is no longer spawned via launch configuration
delegates, so i'm trying to understand how that entire process works. i
know that the debugger attaches to the ide, instead of the other way
around.

leaving aside remote debugging, if i wanted to debug a program locally,
wouldn't i still want the ability to have a debug launch shortcut that
started up the interpreter process from inside the ide?

thx!

Report message to a moderator

Re: debug engine overview [message #6403 is a reply to message #6384]

Wed, 13 June 2007 12:23

Dmitriy Kovalev

Messages: 14
Registered: July 2009

Junior Member

Hello, Jae

You can investigate these classes for better understanding how the DLTK
debug infrastructure works:
- DebuggingEngineRunner
- DebuggingEngineManager
- IInterpreterRunnerFactory (RubyBasicDebuggerRunnerFactory as an
implementation)
- ScriptLaunchUtil

Of course for local debugging you should start interpreter process from
IDE. Each debugging engine can make this operation in its own way. You
can see existing Tcl and Ruby implementations.

If you have another questions relating to DLTK debugging, please ask!

Jae Gangemi wrote:
> could someone provide a quick overview in how the debugging
> engine/framework works.
>
> i see that there is no longer spawned via launch configuration
> delegates, so i'm trying to understand how that entire process works. i
> know that the debugger attaches to the ide, instead of the other way
> around.
>
> leaving aside remote debugging, if i wanted to debug a program locally,
> wouldn't i still want the ability to have a debug launch shortcut that
> started up the interpreter process from inside the ide?
>
> thx!
>

Report message to a moderator

Re: debug engine overview [message #6422 is a reply to message #6403]

Wed, 13 June 2007 13:51

Jae Gangemi

Messages: 28
Registered: July 2009

Junior Member

thanks!

i spent some time poking around in the code last night and got a
better understanding of what is going on under the covers.

has any thought been given to remote debugging? that's what i'm most
interested in getting working at the moment. it seems like a simpler
case then local debugging b/c you don't have to worry about the
debugging engine on the client side of things.

On 2007-06-13 08:23:48 -0400, Dmitriy Kovalev <kds@xored.com> said:

> Hello, Jae
>
> You can investigate these classes for better understanding how the DLTK
> debug infrastructure works:
> - DebuggingEngineRunner
> - DebuggingEngineManager
> - IInterpreterRunnerFactory (RubyBasicDebuggerRunnerFactory as an
> implementation)
> - ScriptLaunchUtil
>
> Of course for local debugging you should start interpreter process from
> IDE. Each debugging engine can make this operation in its own way. You
> can see existing Tcl and Ruby implementations.
>
> If you have another questions relating to DLTK debugging, please ask!
>
>
> Jae Gangemi wrote:
>> could someone provide a quick overview in how the debugging
>> engine/framework works.
>>
>> i see that there is no longer spawned via launch configuration
>> delegates, so i'm trying to understand how that entire process works. i
>> know that the debugger attaches to the ide, instead of the other way
>> around.
>>
>> leaving aside remote debugging, if i wanted to debug a program locally,
>> wouldn't i still want the ability to have a debug launch shortcut that
>> started up the interpreter process from inside the ide?
>>
>> thx!

--
-jae

Report message to a moderator

Re: debug engine overview [message #6441 is a reply to message #6422]

Thu, 14 June 2007 15:30

Andrei Sobolev

Messages: 17
Registered: July 2009

Junior Member

Hi Jae Gangemi,

Actually DLTK for now has only remote debugger implementation via DBGp
protocol. But we don't have launching shortcuts for it.

Andrei.

> thanks!
>
> i spent some time poking around in the code last night and got a better
> understanding of what is going on under the covers.
>
> has any thought been given to remote debugging? that's what i'm most
> interested in getting working at the moment. it seems like a simpler
> case then local debugging b/c you don't have to worry about the
> debugging engine on the client side of things.

Report message to a moderator

Re: debug engine overview [message #6478 is a reply to message #6441]

Sat, 16 June 2007 04:41

Jae Gangemi

Messages: 28
Registered: July 2009

Junior Member

i actually have an implementation for this, but it is in need of some
cleanup so it can work for all of the languages.

on a seperate note - it seems that in order for me to get any useful
information out of the Process object that is created to run the perl
interpreter (if an error occurred, etc), i need to hook into it's
stdout and stderr.

i've already got code that does this in a non-blocking manner
(seperate reading threads), but short of re-implementing runRaw in my
debugging engine implementation, are there any other ways to hook into
this? it seems that perl is the bastard child compared to the rest when
it comes executing processes in from java.

perhaps some pre/post hooks could be put into the runRaw method that
would allow me to wire up stdout/err and then get my results and
cleanup?

--
-jae

On 2007-06-14 11:30:13 -0400, Andrei Sobolev <andrei.sobolev@xored.com> said:

> Hi Jae Gangemi,
>
> Actually DLTK for now has only remote debugger implementation via DBGp
> protocol. But we don't have launching shortcuts for it.
>
> Andrei.
>
>> thanks!
>>
>> i spent some time poking around in the code last night and got a
>> better understanding of what is going on under the covers.
>>
>> has any thought been given to remote debugging? that's what i'm most
>> interested in getting working at the moment. it seems like a simpler
>> case then local debugging b/c you don't have to worry about the
>> debugging engine on the client side of things.

Report message to a moderator

Re: debug engine overview [message #6552 is a reply to message #6478]

Tue, 19 June 2007 13:18

Dmitriy Kovalev

Messages: 14
Registered: July 2009

Junior Member

Hello Jae,

If I understand correctly, you derived your class from
DebuggingEngineRunner and overrode method 'run' to handle stdout/stderr
of the Process that you launched. I think we should extend our core
classes to allow handle situations like you have. It would be very
helpful if you can send your sources related to interpreter launching to
kds@xored.com In this situation I can investigate your code and
implement good general solution.

--
Dmitriy Kovalev

Jae Gangemi wrote:
>
> i actually have an implementation for this, but it is in need of some
> cleanup so it can work for all of the languages.
>
> on a seperate note - it seems that in order for me to get any useful
> information out of the Process object that is created to run the perl
> interpreter (if an error occurred, etc), i need to hook into it's stdout
> and stderr.
>
> i've already got code that does this in a non-blocking manner (seperate
> reading threads), but short of re-implementing runRaw in my debugging
> engine implementation, are there any other ways to hook into this? it
> seems that perl is the bastard child compared to the rest when it comes
> executing processes in from java.
>
> perhaps some pre/post hooks could be put into the runRaw method that
> would allow me to wire up stdout/err and then get my results and cleanup?
>

Report message to a moderator

Re: debug engine overview [message #6570 is a reply to message #6552]

Tue, 19 June 2007 15:22

Jae Gangemi

Messages: 28
Registered: July 2009

Junior Member

On 2007-06-19 09:18:14 -0400, Dmitriy Kovalev <kds@xored.com> said:

> Hello Jae,
>
> If I understand correctly, you derived your class from
> DebuggingEngineRunner and overrode method 'run' to handle stdout/stderr
> of the Process that you launched. I think we should extend our core
> classes to allow handle situations like you have. It would be very
> helpful if you can send your sources related to interpreter launching
> to kds@xored.com In this situation I can investigate your code and
> implement good general solution.

that is correct.

in this situation, i only need to hook into the Process object to
determine why the program couldn't be started using the debugging
engine.

let me get things cleaned up a bit, and i'll create a patch.

--
-jae

Report message to a moderator

Previous Topic:	Python exemplary IDE
Next Topic:	PreferencesMessages.DLTKEditorPreferencePage_returnKeyword

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Jul 27 15:46:20 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter