Re: [ptp-dev] Question about performance tools framework in PTP

[Wyatt Spear <wspear@xxxxxxxxxxxxxx>]

The directory request is only supposed to show up when no execution
step has been specified.  That is, when there is performance data to process
just sitting on a the file-system somewhere.  This is a bug on my side
but it should be pretty easy to fix.

It may be possible to pass the defunct launch object (which should contain job completion status and a bunch of metadata), or a relevant
subset of its content, to the analysis phase.  I can look into that.  As I think on it now, having feedback on if a job completed or not would solve some headaches in the TAU plugins too...

Greg's
remote api reference has been very helpful.  It shouldn't be too
difficult to swap my local file calls for remote-enabled equivalents. 
My main concern there is continuing to support non-parallel launching
when the PTP is not installed.  I would need to use one API when the
PTP plugins are present and another when they aren't.

Regards,
Wyatt

On Thu, Apr 23, 2009 at 1:41 PM, Dave Wootton <dwootton@xxxxxxxxxx> wrote:

Wyatt
I think this might work for me. I created a simple extension using the
AbstractPerformanceDataManager class and I do see the job completion
notification. Since the method invoked at job completion gives me access
to the launch configuration, I think I can get the path to the executable
from there and use that to locate my data files.

One thing I see is that I get a directory selection dialog asking me for
the directory containing the performance data. If I pick an arbitrary
directory, then I get the notification of job completion. If I cancel the
dialog then I don't get the job notification. Is there a way to suppress
this directory selector dialog and still get the job completion
notification? My intent is that when my plugin gets the job completion
notification, it will use the pathname for the executable and the current
working directory set up by my plugin to figure out what data files to
retrieve without prompting the user, so this selector dialog is not needed
in my case.

I  might need job completion status, but think I can manage without it.
The potential problem is that if I get job completion notification on  a
failed job, I will still look for performance data, and possibly retrieve
old data since the failed execution didn't create new data.

Thanks
Dave



Wyatt Spear <wspear@xxxxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx

04/22/2009 02:34 PM

Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] Question about performance tools framework in PTP






Dave,

An already-implemented feature that may work for you is the
org.eclipse.ptp.perf.dataManagers extension point.  This lets you define
an Eclipse plugin to process performance data as part of an xml defined
workflow.  If your post-execution processing can fit into the
org.eclipse.ptp.perf.AbstractPerformanceDataManager abstract class you can
implement it with this extension point.  Then add an analysis step to your
xml document like:
<analyze>
       <utility command="Data_Manager_ID" group="internal"/>
</analyze>

Where "Data_Manager_ID" is replaced by the name returned by your
implementation of the AbstractPerformanceDataManager.  The 'process'
method in your implementation will be invoked automatically after the
execution step successfully completes.

Take a look at AbstractPerformanceDataManager and let me know if that
looks like it will fit your needs.  If not I can tweak it, or I can start
looking for a way for you to hook more directly into the execution
system.  If you just need to know when it's time to start running your
performance data processing I think this will work.


I will start digging around a little bit for a common
remote-file-selection system.  I assume the PTP must already have
something like that in place that I can hook into...


Regards,
Wyatt

On Wed, Apr 22, 2009 at 7:46 AM, Dave Wootton <dwootton@xxxxxxxxxx> wrote:
Wyatt
The problem with multiple tabs is fine as it is since it seems to be
complicated to fix.

I don't know the details of the remote file APIs. In my case I would use
remote access both for the parallel (PTP) case and the serial case, which
complicates the logic.

My plugin currently doesn't touch any of the Eclipse or PTP launch APIs.
The performance launch configuration is currently independent of my code.
I talked with Greg a while back about where I could hook into PTP, where I
think all I need is notification of job start and finish with completion
status, and that giving me access to the job/process object containing all
the job info including application name would probably be sufficient.
Dave



Wyatt Spear <wspear@xxxxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx
04/21/2009 10:08 PM
Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] Question about performance tools framework in PTP






Greetings,

I believe multiple tabs/tools of the same name have internally different
ids in case they are being used by different tools.  I'm not sure of the
best way to error-check or manage this case, off the top of my head,
though.  I could just start numbering multiple tabs of the same name, but
that wouldn't tell which tool was using which...

You can get rid of the command box by adding the attribute
displayoptions="false"
to the toolpane tag.  I should probably make that false by default.

Currently all file selection widgets are local only.  If you could point
me toward the API for selecting remote files used by the remote-enabled
components of the PTP, though, I could see about adding remote support to
the framework on that level.

I will have a look at the API tomorrow and try to find a good place for
grabbing job status information.  The specifics will probably depend on
where your plugin touches the launch API already because there are
probably a few different places to attach status listeners or grab the
progress object.

Let me know if you run into anything you would like to see added to
support your use-case, additional widget options, extension points, etc.

Regards,
Wyatt

On Tue, Apr 21, 2009 at 6:15 PM, Dave Wootton <dwootton@xxxxxxxxxx> wrote:

Wyatt
I downloaded the latest code and now I can see where I can enter the
executable path in the application tab. I can run my application and see
the environment variables are being sent across correctly.

I experimented a bit with your sample XML file and can see how I can
generate multiple sub-tabs in the performance analysis tab. It looks like
I can implement what I want with the panel support you have now. Without
fully implementing what I want to do, I can't tell if there is something
missing but I think this is close to what I could use.

A couple things I noticed, that don't block me from using this.

I was able to add the same tab twice by specifying the XML file in my
plugin.xml and then again by adding the same XML file as a workflow XML
file in the tool selection panel. I don't know if it's worth the trouble,
or even a good idea to prevent this.

Is there any way to specify that the box at the top of the panel where
command strings are shown as they are built is hidden? I wouldn't be using
it for my tools, and it might be a minor distraction to users who wonder
why there is this empty box at the top of the pane. This isn't that big a
deal either way.

Do the directory and file  type optvalues deal with remote filesystems or
are they strictly local files and directories? I'm currently thinking all
I need is the text and toggle types but might have a use for the directory
type if it (and files) supported remote files. Again, this is not
something I really need, just something to think about.

I still need to look at notifications for job start and finish. You
suggested that I register my code as a listener on the IProgressMonitor in
some way, but I'm not sure where I should be looking. I originally was
going to look at PTP job launch as one place to put my hooks, but I need
this to work for both parallel and serial applications, so if you are
thinking of a place where I can hook to get these notifications and the
information I need, that might be the better solution.

Thanks
Dave


Wyatt Spear <wspear@xxxxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx
04/21/2009 05:00 PM


Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] Question about performance tools framework in PTP








Dave,

I just checked in a fix that should let you select a regular application
path for a parallel launch.  There are still a couple minor bugs to work
out but this should be enough to let you continue working on your tool
integration.

Regards,
Wyatt




_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev


_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev


_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev