Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] [perf] Generalizing performance framework tools

Greetings Beth,

It's good to see some user feedback on the framework!

1:  Agreed, internal is not the place for that.
2:  There is already a utility class for the perf framework; org.eclipse.ptp.perf.internal.BuildLaunchUtils.  Probably this should not be in 'internal' either.  Right now it contains routines related to getting tool paths and running tools, but I think it would be okay to add the toolOption name getter there.  Alternatively, a new utility class for argument management methods might go in the ToolOpts plugin, since the xml definitions and argument naming fall under that.
3:  Yes, if there are constants clearly in the domain of the toolOptions plugin they should have their own class in there.

Thanks for looking in to all this.  Feel free to make these changes.  Otherwise, I'll get to it myself hopefully this evening or tomorrow....

-Wyatt

On Wed, Apr 9, 2008 at 9:13 AM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:

Wyatt,
Some  observations in trying to use the performance tools framework to
launch my external tools.
(1 )IPerformanceLaunchConfigurationConstants probably needs to not be in an
'internal' package, since my client code is using it
(2) We need a general way to get user-specified values out at the end,
without knowing the translation that you do on the keys.
  To get an option value out of the launch configuration:
          e.g. in the XML that specifies the info that the UI is built
from, i have <togoption label="Report" optname="-repfile"   ...
             and later, in my postprocessing code (my derivation of
AbstractPerformanceDataManager)  i do ILaunchConfiguration.getAttribute
("-REPFILE_ARGUMENT_SAVED", "defaultValue")
            to get the value the user entered.
     I propose putting in a utility method that does this translation for
you, so the client code doesn't have to know that translation process.
     I have tried putting it AbstractPerformanceDataManager as
                   getConfigAttribute(ILaunchConfiguration config, String
key, String defaultValue)
     but it seems there ought to be a more general place to put it so that
you
     can use it when you stash that value as well, in
ToolMaker.finishToolOption()
    Do you have a suggestion for where it should go?  Make a general
ToolUtility class there perhaps?
(3) Should we put a constants class in the toolopts plugin instead of
continuing to add to the IPerformanceLaunchConfigurationConstants in the
main org.eclipse.ptp.perf plugin,
       to store constants used in that plugin?

I'm happy to make the changes if you agree or have other suggestions...


..Beth

Beth Tibbitts  (859) 243-4981  (TL 545-4981)
High Productivity Tools / Parallel Tools  http://eclipse.org/ptp
IBM T.J.Watson Research Center
Mailing Address:  IBM Corp., 745 West New Circle Road, Lexington, KY 40511

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



Back to the top