Re: [ptp-dev] [perf] Framework questions

[wspear <wspear@xxxxxxxxxxxxxx>]

One quick correction:  It isn't the label, but the option name that creates the argument retrieval string.  So instead of ALGORITHM_ARGUMENT_SAVED you would use -ANAALGO_ARGUMENT_SAVED
-Wyatt

On Tue, Feb 26, 2008 at 6:22 PM, wspear <wspear@xxxxxxxxxxxxxx> wrote:

Greetings,

You can specify a tool-definiton XML file located inside a plugin using the org.eclipse.ptp.perf.perfworkflow extension point.  This extension point just takes the location of a workflow xml file with respect to your plugin's top level directory.  Check out the org.eclipse.ptp.perf.tau plugin to see it in action.

The extension point for custom performance data analysis operations is named org.eclipse.ptp.perf.perfdatamanager.  All this extension point requires is the specification of a class that extends org.eclipse.ptp.perf.AbstractPerformanceDataManager.  Happily, the 'process' method this defines is passed the relevant ILaunchConfiguration, so all the relevant data will be readily available.  Your implementation of the process method can perform whatever manipulations on the relevant performance data you like.  In addition to the ILaunchConfiguration object, you are given the location of the project directory (many tools put their performance data there by default) and the name of the project (convinient for organizing and naming processed data).

For example, in TAU's use of this extension point, the process method conducts a series of manipulations on profile files found in the project directory.

The other important method here is getName.  The string returned by this method is the identifier of the analysis operation when it is specified within the tool-definiton XML file. The TAU extension returns the string "process-TAU-data".  So when you want to define an analysis phase that uses TAU's profile analysis capabilities, you put the following in the xml file:

    <analyze>
        <utility command="process-TAU-data" group="internal"/>
    </analyze>

Note that the xml file has three distinct components, represented by compile, execute and analyze tags.  The group="internal" attribute is important because it tells the framework that the command, process-TAU-data, is not a program installed on your computer, but a operation defined within Eclipse itself.  <utility command="paraprof"> would attempt to find the paraprof program and run it within the top level directory of your project, by default.

The UI-creation features of the framework were made with the creation of a single string of arguments to be fed to a program, so its support for extracting individual options is fairly rudimentary at the moment. I can improve this later on.  There are a couple ways to do this, but the following is probably easiest.

Given your ILaunchConfiguration object named configuration...
configuration.getAttribute((String)name_of_option, (String)some_default); 
Will return the option associated with the name_of_option string.  If that isn't found it will return the default.  The strings used to reference the values look like <All caps version of option label>_ARGUMENT_SAVED

So the value entered in the text box of your Algorithm option could be referenced by configuration.getAttribute("ALGORITHM_ARGUMENT_SAVED","");  Which would return the empty string if the user had never saved a value for this option.

The org.eclipse.ptp.perf.tau plugin makes use of this extension, so you can see it in action there.  Please let me know if you have any more questions or if anything seems like it ought to be added or adjusted.

Thanks,
Wyatt

On Tue, Feb 26, 2008 at 5:14 PM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:

Wyatt,
I'm using the tool framework to launch a tool that runs on the user's
executable, and needs options set by the user.
I have an xml file that the user specifies in preferences, and my tool,
with its options set by the user, appears quite nicely in the profiling
launch configuration.

So, in my xml i specify option names and tooltips, and the type (boolean,
string, file, or directory) of the option to be filled in by the user, and
a UI is generated to get this info from the user.  Very nice.
For example, a boolean toggle-able option,
<togoption label="Option" optname="-myOption"
                 tooltip="Hover text here" defstate="true" />
A text (string) toggle-able option:
 <togoption label="Algorithm" optname="-anaalgo" tooltip="algorithm"
defstate="true">
                 <optvalue type="text" default="simple"></optvalue>
</togoption>

Both of the above options would be checked, by default, and the text field
would be prefilled with a default value of "simple"

So for the above, the command line that would be generated (after the tool
name) could look like, if not modified by the user:
      -myOption -anaalgo simple

I think you added an attribute to include an option in the command line
that is generated, but make it not visible in the UI.
I'll give that a try.  (visible=false)

Can we have a non-toggle option? That is, the user can't "uncheck" it?
Aha, i think i just set required=true.

Next I will try specifying the xml in a plug-in extension, instead of
having the user specify it.  I think you said I should look in
And I need to know how to launch another operation when the tool execution
is complete
(in my case, i want to open a view.)
What I also need is a way to get some of the option information to pass to
the view so i know how to obtain the results of the tool (the output file
in my case).
I know you said it's difficult to get hold of the ILaunchConfiguration.
Could it (or something) perhaps be *passed* to my operation that gets
called?




..Beth

Beth Tibbitts  (859) 243-4981  (TL 545-4981)
High Productivity Tools / Parallel Tools  http://eclipse.org/ptp
IBM T.J.Watson Research Center

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