Hi BRATs
I made (quite severe) changes to BRAT. These should result in a
version bump, but I'll wait a few days, 'cause more is comming that
way.
* It's now possible to communicate the status and state of a module to
the outside world i.e., a container or application. This is done
with the method
SetStatus(kOk|kProblem|kFailure|kDisaster)
GetStatus()
SetState(kSetup|kInit|kBegin|kEvent|kEnd|kFinish)
GetState()
For errors, you can also use
Problem(<location>, <format string>, ...)
Failure(<location>, <format string>, ...)
Disaster(<location>, <format string>, ...)
in increasing serverity.
A Status == Disaster, will cause a container to stop execution of
the current module loop (in Init, Book, Begin, Event, End, and
Finish), and set it's status to failure.
At the moment, the status of a module is not reset
automatically. The module writer may want to do that on entry in a
method. There are plans (but nothing concrete) to implement this. In
the case the module is in some container, it's probably fairly easy,
but may be difficult otherwise.
The state information is usefull to detect if someone is trying to
modify a parameter at a point in the execution where it's not
allowed to.
Therefore, your code should set the state and inspect the state
apporopiately.
Please also refer to the class description of BrModule and
BrModuleContainer.
* Added the class BrTriggerFilter. This inspects the trigger word
(upper 8 bits) and compares it with the selected triggers. If one of
these does not match the trigger, then it sets its status to
kDisaster, and the event is proceed no more by the containter.
Hence, you can use this as the first module in you module pipeline
(container) to only select the interresting events.
IMHO, it's also an excellent example of how to communicate status to
the outside of a module. See also test/TestTrigger.cxx test
application.
I strongly suggest that modules that act like filters (like
deselecting bad events) are named as Br<Filter type>Filter, as these
are different from regular modules in that they don't produce data,
and may stop execution.
* Changed the user level interface to RUNDB. There's a manager called
BrRunInfoManager. You can register runs with this manager, and it'll
provide you with a BrRunInfo object, that contains all the
information from tables Runs and Files from RUNDB (see the DAQ web
pages).
BrRunInfoManager has the method Update() that will update the
BrRunInfo object to the next Run asked for.
BrRunInfo has the method Bool_t NextSequnce that'll update the
internal members for the next sequnce in the run. It returns kTRUE
if there are is a new sequences, kFALSE otherwise.
Please note that this is not thouroughly test, so use with
caution. For production, do not use this yet!
Any comments are welcome.
Yours,
Christian -----------------------------------------------------------
Holm Christensen Phone: (+45) 35 35 96 91
Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305
DK-2200 Copenhagen N Web: www.nbi.dk/~cholm
Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Fri Jan 19 2001 - 14:10:46 EST