More details can be found in the FeatureLog files for each package.
It is suggested that this addtional info be made the default.
Mark Fischler points out that although this would change the behavior of the log output, it would not change it in any way that would invalidate automated verification (since the timestamp output, if enabled, inherently varies from job to job).
The time zone is hard to get in a portable way, but Greenwich Mean Time is not. The suggested output format is, then, 19-Nov-2002 16:38:17 [21:38 GMT]. In some cases, the date in GMT will differe from the local date; but given the local date and time and the GMT time, no ambiguity can exist.
Implemented in v2.2, R-03-04-04
The proposed enhancement to make this usage sensible is as follows:
Framework code:
int V = whatever; // Higher V allows more output.
errlog.setDebugVerbosity (V);
errlog(2) << "someString" << moreData << endmsg;
// If V < 2 then this message is ignored with little runtime penalty.
// If V >= 2 then this message is acted upon.
errlog(ELincidental, "--DEBUG--") << "someString" << moreData << endmsg;
Implemented in v2.2, R-03-04-04
Mark Fischler pointed out a couple of workarounds which would not require more severity levels. However...
Mark Fischler and Jim Kowalkowski note that using this package as a debugging outlet, depending on severity levels to control verbosity, is a bad idea for a couple of major reasons:
This proposed enhancement was rejected in favor of ErrorLogger 013, which accomplishes the same benefits.
Leo Michelotti points out that the user can use the specialized matrix forms, and get this improved speed, in the existing package. However, user code that (for what ever reason) works with generalized ("generic") matricies would benefit from this change.
Mark Fischler points out that this improvement must be tested quite thoroughly, since it impcacts currently working code and only improves speed.
The code implementing this has in fact been written and tested. When we are convince that the testing covers all cases adequately, we intend to check the changes in.
Implemented in v2.2 R-20-10-28
M. Fischler agrees that calling exit() directly is a violation of an implied contract with the framework people -- the framework should have the only authority to do that. We have the mechanisms to avoid this problem, using the ErrorLogger or Exceptions package (which were not available when LinearAlgebra was written).
Three possible improvements would be:
"LinearAlgebra Fault" and level ELsevere.
Assumedly the framework will cause this not to abort the program.
ELerror because upon (the unexpected) return from
error() all heck can break loose. Typically at least a
divide by zero is about to happen, and if the framework has not
set up to handle this, then the job will terminate anyway.
ZMexceptions and replace
each call to error() with a ZMthrow. If this is done, we should
probably do the work to supply a return value from the routine (in each case)
which, if not sensible, at least will not force an immediate abort situation.
This problem was fixed in release R-02-07-24.
MF notes that two interface decisions are needed: How the name of the destination gets supplied, and what happens if a user looks up a name and it is not present.
The syntax to be implemented will look like:
// in the setup code
ELdestControl logfile;
logfile = logger->attach(ELoutput ( "filename.log" ), "myLogFile" );
// in later code, where that logfile has been lost
ELdestControl logfile
bool handleFound;
handleFound = errlog.getELdestControl ("myLogFile", logfile);
if (!handleFound) { ... oops, wrong name -- user chooses what to do here }
If somebody searchs for a name which is not found, the object returned will be a default ELdestControl, and controlling anything using that will result in nops. In that case, an error of severity SEVERE2 will be declared on the errlog.
This was done, and appears in release R-02-04-23.
MF notes, and ET concurs, that the reason is that the function (actually operator()(v) is virtual and the calling overhead is large relative to the work, which was inlined in CLHEP 1.6.
If we can inline this method the unfavorable difference will go away.
Unfortunately, the function is virtual in Hep3RotationInterface precisely to allow polymorphic use of rotations of various kinds. Fortunately, neither CDF nor D0 ever use the base classes, or use Rotations in a polymorphic manner. Removing this ability will greatly simplify the code and may speed up Run II executables as well.
MP and WB point out that to try to have our cake and eat it by doing inline virtual would be inferior because
Plans and Priority
I will strip out the inheritance structure and inline all methods where this is remotely sensible. No methods will be inherited in the rotation classes.
This is a goodly amount of work; fortunately most is straightforward and in fact simplifies the package. I will start on it right away, since CLHEP users would like the improvement sooner rather than later. A deadline to try for is to have the new code working by Feb 20, when Geant4 people will be here to investigate spped issues.
Documentation modifications, and perhaps expansion of testing coverage, will follow.
This was done, and appears in release R-02-04-23.
(phi, theta, psi)but expects to read input in the form
phi theta psi(no punctuation).
Leo Michelotti notes that Scott is "correct, abundantly so."
Mark Fischler notes that this fix can be done without affecting the behavior of existing correct programs, by making operator>> more flexible. This will take some work, along with some testing, but it is straightforward.
This was done and appears in release R-01-11-29.
Also, when told about aximAngle, PM stated that it was hard to see that this function was available; deltaPhi() would be a better name.
Liz Sexton-Kennedy notes that even if the code using deltaR() is repaired locally, we should not leave this trap in our library.
Mark Fischler notes that this problem, of course, is not restricted to LorentzVector::deltaPhi(). SpaceVector::deltaPhi() has the same behavior, and also the azimAngle() method without a reference direction has the same flaw.
The proposed course of action is to fix this:
This was done and appears in release R-01-11-29.
Mark Fischler notes that
The proposal, pending CLHEP acceptance, is to have eta() return 0 if the vector is zero.
This was done and appears in release R-01-11-29.
errlog << item1 << nobr << item2 << item3;
Therefore, the proposal is to simply remove this feature from the documentation and do without it. This, of course, alters no code.
This documentation change has been made, as of v2.1.4 or earlier.
Mark Fischler presents the following technical information:
Mark Fischler after some thought and discussions suggests (5/25) the following possible approaches: It is not yet clear which of the four solutions to choose:
Walt Brown suggests (5/29) creating a new templated class, which takes the user-specified mutex class as a template argument. This turns out to be the right solution, with the templated class ThreadSafeErrorLog < Mutex > available as a replacement for ErrorLog.
This approach was done, and appears in release 2.1 (R-01-07-11).
Mark Fischler after discussion with Liz suggests the following
interface:
If code goes through a wrapper module to formulate and ZMthrow a
ZMexception, the desired line numner and file name would be those of the
line calling the wrapper, not the line of the ZMthrow inside the wrapper.
M. Fischler
notes that we indeed would have to supply something new. The ZMthrow_
method does directly take a line and file, but the ZMthrow macro
does more than just calling ZMthrow_() -- it also tests the return value
and if indicated either does a C++ throw or calls abort().
I think the cleanest syntax that would help is a method
Scott has put together an alternate
logging behavior that suppresses these.
However, "it was not entirely straightforward to do this with the
interfaces provided, and the result is kind of ugly."
He suggests it would be much easier if the library
provided a global switch to alter the formatting of the exceptions
in this manner.
M. Fischler
says the right way to do this is by a logging behavior. What I should do is
take Scott's "kind of ugly" behavior, clean it up and make it into
provide a new behavior ZMexLogFormatted which everybody can use.
This has the same behavior as
ZMexLogAlways,
but omits any information which might routinely differ per run.
The choice of name ZMexLogFormatted is deliberate: Later, if somebody wants
more detailed control (such as "suppress the file completely") this can be
provided by methods to modify the default behavior of this new logger, and the
change will be locallized to a single class.
If this behavior is provided, we should of course use Scott's code, and
just clean up anything that appears "ugly."
M. Fischler
after coding and testing the feature notes that the name is not very
illuminating. Since the purpose of this log behavior is to make validation
easier, the name ZMexValidationStyle seems better.
I suggest adding to ZMexception static methods to modify each of the
ZMexClassInfo fields set in the constructor:
Wolfgang Wagner
requested an access method to ELstatistics which returns a
copy of the ELstatistics map.
Mark Fischler
responds that while we shoiuld not expose the internal map (which in some
future implementation may be some other sort of structure)
there is no problem with a method supplying a method which returns a
std::map
At March ZOOM meeting
it was decided to go ahead with this.
Matthew Worcester
writes that the experts would like to be able to output hex numbers in the
error logger. This can't be done via manipulators.
Earlier comments
from several people expressed the same request.
ZOOM developers
point out that they previously tried to do this and that it was hard to
do in a portable manner since the hex manipulator has different signatures
on different platforms.
Mark Fischler
sucggests the following limited substitute: A method of ELdestControl
Matthew Worcester
writes that he has diagnostic ELinfo messages and when the thresholds are set
high enough that these are ignored, the processing of them still severely
impacts his code performance. He would like this effect to go away.
Mark Fischler
finds that a typical ignored error message can eat about 15 usec.
Though this is not very long, there is a nearly trivial change that could
cut that to about .5 usec. The proposal is to add a method of ErrorLog
Walter Brown
notes three main ways to attack the code bloat:
This was done and appears in release R-01-12-21.
Currently, the user is being asked to evaluate how far these steps go toward
relieving the code bloat.
Parent Pages:
ErrorLogger 007: Multiple module inclusion/exclusion
Liz Sexton writes that users want to be able to filter messages by a
module list, not just one. In particular, they have interactive users who
would benefit by being able to flexibly control filtering. This should be
by methods of the ELdestControl, akin to filterModule().
At any given time, either the `respondToModule' list or the
`ignoreModule' list may be active, but not both. At the start, the
destination is in the same state as it would be in right after
respondToModule("*").
The current routines (which of course would not be removed) can be re-written
in terms of the new ones:
Clear `respondToModule' list, and filter out all messages,
except those coming from any module that is later added to the
`respondToModule' list.
Add this module to the `respondToModule' list, and
remove it (if present) from the `ignoreModule' list.
Add this module to the `ignoreModule' list, and
remove it (if present) from the `respondToModule' list.
Clear `ignoreModule' list, and respond to all messages,
except those coming from any module that is later added to the
`ignoreModule' list.
dest.ignoreModule("*");
dest.respondToModule("a");
dest.respondToModule("*");
dest.ignoreModule("a");
Exceptions 001: ZMthrow with specified line/file
Scott Snyder
suggests we provide an alternate version of ZMthrow that allows
specifying the file/line number.
ZMthrow_from ( ZMexception & ex, int line, std::string file );
Scott would then be able to do:
throw_foo ( __LINE__, __FILE__ );
with
void throw_foo (int line, std::string file) {
... prepare error message s ...
ZMthrow_from (Exc_Foo (s), line, file);
}
The implementation of the ZMthrow_from method will be easy and safe.
Exceptions 002: Control of message format
Scott Snyder
points out that for regression tests which capture the output of test
programs and comparing against expected output, it is desirable to be
able to supress time stamps the full pathnames of sources.
Exceptions 003: Override of assigned severity
M. Fischler
noticed that while you can set up non-standard haldlers and
logging behaviors for types of ZMexceptions coming from a library routine,
there is no way to assign a severity other than the one it is constructed
with.
In one program it would have been useful to demote a ZMsevere down
to ZMwarning.
ZMexception::setSeverity(const ZMexSeverity & s);
ZMexception::setName(const std::string & name);
ZMexception::setFacility(const std::string & facility);
If we are anyway doing one or both of enhancements 001 and 002, this
additional change will be very simple and safe.
ErrorLogger 003: ELstatistics::statisticsMap()
ErrorLogger 004: ELdestControl::setHexTrigger()
with ELoutput doing the following when an int k is sent: If abs(k) is
at least m, then output k in the form (for example) 65534 [0000FFFE].
An experiment could choose to set this trigger at, say, 101, and then all big
ints would come out in this dual form.
void setHexTrigger (int m);
ErrorLogger 005: ErrorLog::setDiscardThreshold()
If you do this, any message sent to that logger with a lower severity will
be discarded as quickly as possible; and further items streamed to that
log (until the next message) will be discarded as quickly as possible.
void setDiscardThreshold (ELseverityLevel sev);
Exceptions 005: code-shortening ctor for ZMexClassInfo
Scott Snyder
points out that each time a user-defined ZMexception is defined,
the ctor for its ZMexClassInfo generates more than 3K of code.
Most of the code being generated for this file was the static initialization
code that calls these ctors for each of the instances.
He provides suggestiions that he finds cuts the code by a factor of 3.
Mark Fischler (mf@fnal.gov), Walter Brown (wb@fnal.gov), John Marraffino
(marafino@fnal.gov), Philippe Canal (pcanal@fnal.gov)