From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Mon Aug 25 2003 - 12:56:17 EDT
Hi all, Kris Hagel <hagel@comp.tamu.edu> wrote concerning Re: BRAT does not compile anymore. [Mon, 25 Aug 2003 10:18:04 -0500] ---------------------------------------------------------------------- > A short comment about BrRecoPackage. I started on that very > enthusiastically to try to take some of the "mystery" (at least for > me) out of reduction. You're not alone! > The intent was to have it consistent with ProductionReduction.C and > thereby simplifying ProductionReduction.C and making the results of > a reduction less dependent on which ProductionReduction.C one is > using. (ie the one in djam_app or the one in kh_app or any other > place where one might find one (I am fairly sure there are more to > be found; perhaps they are not even called > ProductionReduction.C!!!) I'm surprised that none of these scripts have made it into BRAT yet. Or something like your `BrRecoPackage'. > I also must say that I did not know about the ProductionReduction.C > in ~bramreco/reduce, but now that I look at it I see that it is a > link to djam_app. Will it remain the "official" script after Djamel > finishes? If it's official, shouldn't it be in BRAT (hint hint). > And for my part, as long as we continue to have "official" passes > coming out of macros in peoples private directories where the > collaboration as a whole does not have control over what the > individual person is doing, I will remain confused. > On the other hand, if it would be felt that something like > BrRecoPackage would be an appropriate approach, perhaps I could > notch that up on my priority list if there would broad consensus > that it would be used once completed and accepted. Why not? I think it's a good idea, as long as it's not doing too complicated stuff. Heck, then you could run your jobs via the interactive prompt (on a PROOF server?), like: > bratroot brat[0] BrMainModule* main = BrMainModule::Instance(); brat[1] main->Add(new BrRecoPackage); brat[2] main->Main(); starting job on node `rcas0000.rcf.bnl.gov' ... starting job on node `rcas0001.rcf.bnl.gov' ... starting job on node `rcas0002.rcf.bnl.gov' ... ... Be warned: This is not complete, just a hint at what _might_ be possible, should Kris' idea be implemented. > In the short term, I will check it out and make sure it compiles. Well, I think it's safe to say, that when you do changes in one directory, to one set of modules, then you should may damn sure that _all_ of the directories build nicely. Meaning, if I do a change in class `BrFooModule', and `BrBarPackage' uses that module, then I should make sure that `BrBarPackage' compiles _before_ submitting to CVS - otherwise people will slam me on the head, saying `BRAT does not compile anymore!' A suggestion for Kris: Why not leave the various `Set'ters out of the `BrRecoPackage', and just have `Get'ters to get a reference (or pointer) to the various contained modules - much like in the BrMultPackage for example. In that way, BrRecoPackage is thin, but still allows for user customisation. > > I made a look into BrRecoPackage and, at least concerning the DC > > setup, is it absolutely not up-to date. > > I don't know whether any one uses it, if not, it should be removed, if > > yes, it should be modified > > according to ~/bramreco/reduce/ProductionReduction.C - but in my > > opinion keeping the same > > software in two different places is a potential source of confusion. It definitely is - however, having `official' scripts outside BRAT is even more confusing. In that respect, Kris' approach is sound - it keeps the `official' stuff were it's supposed to be - in BRAT. Yours, ___ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 305 ____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm | |
This archive was generated by hypermail 2.1.5 : Mon Aug 25 2003 - 12:57:10 EDT