Hi all,
I've been working on a few things that would make things a lot easier
to deal with in BRAT. However that means interferring with some of the
classes already in BRAT. I believe I haven't made any classes lose
functionality and that the transition should be as smooth as
possible. Anyway, let me summarise what I've done. If you have no
serious objections to this, I'll commit it to CVS Weednesday (CET).
* Defined standard BrModule methods in BrIOModule.
This will make it possible to put a BrIOModule (and it's
descendents) into a BrModuleContainer pipe-line. Since classes like
BrRawDataInput, BrEventIO, and BrGeantInput has the method
Event(BrEvent*) and not Event(BrEventNode* , BrEventNode*), I had to
do some trick in BrIOModule::Event(BrEventNode* , BrEventNode*),
which basically involves finding out if the module is a reader or a
writer, and if the appropiate BrEventNode really is a BrEvent object
(using ROOT's RTTI).
For this tho work, one should really set the "IO Mode" of a
BrIOModule. This is a bitmask set like
ioModule->SetIOMode(BrIOModule::kBrReadFile|BrIOModule::kBrJobFile)
Further, there are two different kinds of files. One that last an
entire job or one that only last for one run. That is also set in
the IO mode, as illustrated above.
Note, that one can still use Open, Close and Event(BrEvent*)
directly, should one really need that.
* Changed BrRawDataInput to use signals Stop, Failure, Abort, and
added specialised method OpenNext.
Again, this was done to make it possible to put an BrRawDataInput
module in a module pipe-line.
BrRawDataInput has two non-standard file modes
BrRawDataInput::kBrRawDataFile
BrRawDataInput::kBrEventbuilderStream
that's the reason why this module had to be treated
specially. BrGeantInput may also need some attention.
Note, that one can still use Open, Close and Event(BrEvent*)
directly, should one really need that.
* Add the (simple) class BrHistIOModule.
To do away with rather clumpersome (at least in terms of
BrMainModule) lines like
TFile* histoFile = new TFile("hists.root", "RECREATE");
if (!histoFile) {
cerr << "Couldn't open file \"histo.root\"" << endl;
return 1;
}
I made the BrIOModule BrHistIOModule. It is like all other
BrIOModules: it can be put in a module pipeline, and it will open
it's file at Init time and close it at Finish time. Here's how to
use it:
BrModuleContainer* container =
new BrModuleContainer("container", "A Module Container");
BrHistIOModule* histModule =
new BrHistIOModule("histModule", "A histogram module");
histModule->AddFile("myhistograms.root");
container->AddModule(histModule);
... the remaining modules should be defined and added to the
... container AFTER this
container->Init(); // Opens file myhistograms.root and stays there
container->Book(); // Books histogram in myhistograms.root
... and so on
* BrAppOptionManager and BrAppOption classes changed to not use
BrExceptions.
This was done so that we can use BrAppOptionManager in the
configuration scripts to TestMainModule.
CINT still has a hard time to deal with exceptions in a good way, so
this was needed.
Therefore, I'd like to discourage the use of exceptions until Masa
Goto changes CINT so that it will deal with exceptions in a proper
way. I know I've probably been the most extensive user of
exceptions, but as a danish politician once said: "You have an
opinion until you take a new one" (looses a bit in the translation)
:-)
Note that the exception code isn't gone; it's only conditional on
the preprocessor (damn - that keeps poping up today) flag
USE_EXCEPTIONS.
* BrDb... classes changed no to use BrException classes.
Rational as above.
* Better user authentification in BrDb.
Up until now, we've had to supply user name and password directly in
the code (or via BrAppStringOption), thereby exposing passwords!
BrMainDb* mainDb = new BrMainDb(<user>, <passwd>, <host>, <db>);
Now, if the user doens't specify a password (<passwd>="" or
<passwd>=0) , BrDb will look in the file ~/.brahmsdbrc for lines of
the form
<host> <db> <user> <passwd>
that matches the <host>, <db>, and <user> given above. Also, if the
user doesn't give a user name (<user>="" or <user>=0), BrDb will
again look for lines mathching the given <host>, <db> pair.
If BrDb doesn't find a line in the file ~/.brahmsdbrc that matches,
then it'll prompt the user for the missing information, using an
non-echoing prompt for the password.
For your protection, BrDb insists on the file ~/.brahmsdbrc to be
read- and write-able only by the user (Octal mode 600), and if it's
not, tell you so.
This should increase the security (something that RCF is very
concerned about) as well as make the code more flexible.
* Added the method Int_t BrMainModule::Main() to do EVERYTHING.
This method takes care of everything from Init to Finish!
* Made the method BrModule::Info() const obsolete in favour of
BrModule::Print(Option_t* option="B") const.
Since the method TObject::Print(Option_t* option="") const is the
proper way for a ROOT based class to print information to the user,
I thought that we should live up to that, and so I did away with
BrModule::Info (it's now a small wrapper for Print("B"); )
This change has propegated to many classes.
A good skeleton for <some module>::Print() is
void <some module>::Print(Option_t* option)
{
// Module Information method
//
// Options: (see also BrModule::Print)
//
TString opt(option);
opt.ToLower();
BrModule::Print(option);
if (opt.Contains("d"))
cout << endl
<< " Original author: <your name>" << endl
<< " Modifications: " << endl
<< " $Author$" << endl
<< " $Date$" << endl
<< " $Revision$ " << endl
<< endl
<< "-------------------------------------------------" << endl;
}
Note that a non-const version exist for backward compatiblity with
ROOT pre3
I'll also commit an example of using TestMainModule for something
usefull into my area at brahms_app (cholm_app) soon (probably
tomorrow).
Let me know if you think any of this is a bad idea, but before
Wednesday (and do remember the time-zone difference).
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 : Mon Mar 05 2001 - 13:25:42 EST