Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] debugger

Greg & Nathan

> > So basically, we make the runtime model and the debug model the same?
> 
> The two models will share this functionality. Runtime is IPProcess
> and up (nodes, machines, etc.) and debug is IPProcess down (threads,
> stack frames, etc).
>

We (Clement and I) are trying to merge our stuff together, but seems
that we are unclear about some things....

1. After the user selects the preferred run time (or monitoring
system) in the preference page.... what happened when the user clicks
the "run" button ???
I do assume that the ParallelLaunchConfigurationDelegate will call
execSimulatedMS() or execORTEMS() based on the chosen monitoring
system....
(footnote: well, currently it's not like that, it just calls execMI().....)
But, am I correct to assume this????

2. What happened when the user clicks the "debug" button???

Basically...  how to make the debug model and the runtime model the same.....

3. Why does ParallelLaunchConfigurationDelegate call execMI??
Looking at ParallelLaunchConfigurationDelegate.java (before my stuff
was added).... it doesn't call execSimulatedMS() nor execORTEMS()....

> > The IProcess is part of the platform debug model, does
> > ptp.core.IPProcess extend debug.core.model.IProcess ?
> 
> Not currently. But it may need to if necessary.

4. Just wondering why there is no java.lang.Process in
org.eclipse.ptp.internal.core.PProcess ??? Is it because it's designed
that way (i.e. the actual java.lang.Process lives in remote
machines)???

We do need java.lang.Process to be given to DebugPlugin (to register
it in the debug view).... Of course... we can always fool it by
passing a wrapper to java.lang.Process (without the actual operating
system process))



Thanks,
Donny


Back to the top