[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] [perf] Generalizing performance framework tools
|
OK I have checked in some of these changes. I have not moved any existing
stuff outside of 'internal'; please do at your leisure and let me know.
I don't want to break the tau-specific code.
I added ToolOptionsConstants and ToolOptionsUtilities.
I also took the liberty of modifying ToolMaker to use the new constants;
please have a look and assure that looks ok to you. It seemed
straightforward.
Do you use these elsewhere? seems like you set them here so you ought to
retrieve them somewhere too, but maybe it's right there using the same
variables.
If you do retrieve them elsewhere then they should probably use the same
constants.
I also added the executable name as a key/value attribute pair in the
launch configuration as we discussed offline yesterday
I did this for CDT launches in PerformanceLaunchDelegate
and for parallel launches in ParallelPerformanceLaunchDelegate
I left comments around it in ParallelPerformanceLaunchDelegate since I
can't currently test this;
as you mentioned I had to manually construct the path+separator
+executableName to be symmetric with how cdt launch executables are stored.
Please have a look and remove the comments if it looks right to you.
I am checking in everything to HEAD; we should probably copy to ptp_2_0
branch before Greg does a maintenance build for 2_0, as I'd like these
fixes/updates to be in 2.0 if possible
..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
wspear
<wspear@cs.uorego
n.edu> To
Sent by: "Parallel Tools Platform general
ptp-dev-bounces@e developers" <ptp-dev@xxxxxxxxxxx>
clipse.org cc
Subject
04/09/08 09:31 AM Re: [ptp-dev] [perf] Generalizing
performance framework tools
Please respond to
Parallel Tools
Platform general
developers
<ptp-dev@eclipse.
org>
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
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
