Feature Requests item #1943407, was opened at 2008-04-15 17:12
Message generated for change (Comment added) made by xorian
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=410430&aid=1943407&group_id=34164
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Evaluator
Group: None
>Status: Closed
Priority: 2
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Scott Venier (scottven)
Summary: waiting on possibly identical... message
Initial Comment:
It would be useful to get more information printed when waiting on an identical tool so we can tell which tool/function it is waiting on.
Today:
18/Waiting on possibly identical tool
24/Waiting on possibly identical function
I dont think that printing the full function of the one it is waiting is the right answer since that would clutter up the log file with long statements. Is there another reasonable option?
1.) Could the statement give the thread number of the command it is waiting on - e.g.
18/Waiting on possibly identical tool (5)
2.) Could the statement give some X number of chars of the command it is waiting on - e.g.
18/Waiting on possibly identical tool (../toolX -debug -c)
Cheers,
-John Kelley
john.a.kelley@...
----------------------------------------------------------------------
>Comment By: Kenneth C. Schalk (xorian)
Date: 2008-10-06 18:41
Message:
This has been implemented in:
/vesta/vestasys.org/vesta/eval/116
----------------------------------------------------------------------
Comment By: Kenneth C. Schalk (xorian)
Date: 2008-04-16 17:36
Message:
Logged In: YES
user_id=304837
Originator: NO
For tools, I think the obvious thing to do would be include
the thread label, host name, and the command name of the
tool (i.e. the leading prefix of the line printed when the
tool started):
18/Waiting on possibly identical tool (5/somehost: /usr/bin/gcc)
The thread label alone might be sufficient, but doesn't
really seem like enough. We could include more of the
command line, but I don't think there's a good choice as to
which part of the command line to include. There are some
cases where the distinguishing arguments are early in the
command line, some where they are late in the command line,
and some where they are in the middle.
For user-defined functions, we could use the name the
function was defined with.
24/Waiting on possibly identical function (some_func_name)
There's no point including a thread label, as no thread
labels (or messages at all) are printed when starting a
function call.
Of course in many cases that may not be enough information
to be useful. There should probably be an option to include
the full immutable path the SDL file for the model or where
the function was defined. Probably the sensible thing to do
would be to include the same text as in the sourceFunc
annotation stored in the cache.
For models I'm not sure there's any useful abbreviation. If
we're going to print anything, it would have to be the full
path to the immutable version of the model in the
repository.
Let's plan on having two modes. The default will print
abbreviated messages:
18/Waiting on possibly identical tool (5/somehost: /usr/bin/gcc)
24/Waiting on possibly identical function (some_func_name)
7/Waiting on possibly identical model
With more verbose output enabled (probably a command-line
option, though a config file setting might be acceptable),
we'll print more information:
18/Waiting on possibly identical tool (5/somehost: /usr/bin/gcc -c -O0 -g2
-DSOME_MACRO=123 foo.c)
24/Waiting on possibly identical function
(/vesta/example.com/foo/bar/pkg/checkout/1/2/build.ves/some_func_name(),
line 63, col 12)
7/Waiting on possibly identical model
(/vesta/example.com/foo/bar/pkg/checkout/1/2/build.ves)
>From a little discussion about this at Intel, it would be
nice if the user-defined function case this could include
some sort of summary of the arguments which were included in
the primary key. (Since the evaluator waits based primary
key, this could be important to distinguish different
cases.) If we're going to do that, the same text should go
into the sourceFunc annotation. We will want to make sure
we don't include the entire printed representation of a
large complex value (binding, list, etc.). The depth-based
value printing added back in eval/102 should make that
pretty easy.
A couple thoughts on the implementation (all in
ApplyCache.C):
- The description of the possibly identical thing should be
stored in a member variable of the PKKey class. There
shouldn't be any reason to incorporate it into the result of
PKKey::Hash though, or to compare it in PKKey::operator==.
- The description needs to be an argument to
WaitForDuplicateEval, but probably nothing else.
Finally, if we're improving this area it's probably worth
adding a message for "we waited for a possible duplicate but
it turned out not to be a duplicate".
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=410430&aid=1943407&group_id=34164
|