Christian,
The changes you propose sound good. I especially like the BrAppXXXOption
being able to have multiple values. I had been frustrated with that
limitation and at one time had thought to launch into making it happen
before finding another bandaid. This will allow some cleanup elsewhere.
Kris
Christian Holm Christensen wrote:
> Hi all,
>
> I have a few changes that I'd like to commit to BRAT ASAP. I think
> you'll like most of 'em, but one (see point 4) below can give some
> users minor problems, so I thouhgt I'd give you a heads up
>
> Changes to come:
> ----------------
> 1) BrAppOption and subclasses automatically adds themselves to the
> singleton BrAppOptionManager object - that is, no need to send the
> message BrAppOptionManager::AddOption - in fact it will generate a
> warning.
>
> 2) BrAppIntOption, BrAppFloatOption and BrAppStringOption can take
> multiple values. That is, you can specify many runs as
>
> bratmain <config> -r <run1> -r <run2> ...
>
> and process these values like
>
> for (Int_t i = 0; i < runOption->GetNValues(); i++) {
> cout << runOption->GetValue(i) << endl;
>
> Defualt behaviour of BrApp[Int|Float|String]Option::GetValue() is to
> return the 0'th value.
>
> BrAppBoolOption does _not_ take multiple values, since I don't think
> that makes sense. Feel free to argue.
>
> 3) Introducing the concept of file sets. This is a bit hairy, but I'll
> try to outline it.
>
> One can bundle several files in to sets. If an input module
> reaches end of file, on a file in a set, it opens the next file, but
> with out changing the level - that is, the opening and closing of
> files in a set is done in the Event method.
>
> The input module does change level when ever it reaches the end of
> a set. That is, when all files in a set has been processed, the
> event loop is terminated, and the job start a new run level.
>
> Several sets can be added to an IO module, thereby giving the user
> the possiblity of having a tight coupling between BrModule 'run'
> levels and actual DAQ runs. Hence a job can process many runs,
> where each run may have one or more files each.
>
> If the flag BrIOModule::kBrJobFile is set, there's only one file
> set, and additional filesets are concatenated.
>
> Note that the concept of filesets does not apply to _output_
> modules. A new output file can _only_ be opened in Init or Begin.
>
> This affects BrIOModule (alot), BrEventIO, BrRawDataInput and
> BrHistIOModule.
>
> 4) BrModule::Info(Int, const char*, const char*, ...) method for
> pretty-printing verbosity messages. The arguments are similar to
> forexample TObject::Warning, but does not change the state of the
> module. Also, an additional (mandetory) argument tells the module
> for which run levels is should print the message to stderr.
>
> This method is introduced to have consistent output from modules.
> Module authors are incouraged to go through thier code and
> substitute code like
>
> if (Verbose() > n)
> cout << "<message>" << ...
>
> with the simpler:
>
> Info(n+1, "<method>", "<message formt>" ...);
>
> Note that this method forces the removal of obsulete method
> BrModule::Info(void). This will cause no problem in BRAT, but may
> in user code. The solution is simple: exchange Info() with Print().
>
> I don't think the last change will affect a lot of people, since the
> old Info method has been obsulted by Print for a long time. Anyway,
> that method will disappear (assmuing noone barks ASAP). I'll remind
> you when I do the actual commit.
>
> Yours,
>
> Christian Holm Christensen -------------------------------------------
> Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
> DK-2200 Copenhagen N Cell: (+45) 28 82 16 23
> Denmark Office: (+45) 353 25 305
> Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
>
>
This archive was generated by hypermail 2b30 : Wed Dec 12 2001 - 12:57:22 EST