Hi Yury et all, On Mon, 13 Nov 2000 12:26:16 -0500 Yury Blyakhman <Yury_B@physics.nyu.edu> wrote concerning ": Re: BrRdoModuleBB": > The reason for not checking file existence before reading is to decrease > number of "if" and "else" 's in the code! An if ... else if ... else statement isn't that slow that you need to do away with it at all cost. What Claus prosped is almost the right way to read from files. IO is notoriously know for being error-prone (someone pulls out a cord, the disk is bsy swapping, and so on), and one should never EVER really on IO to work. Here's the way to do it: //____________________________________________________________________ void BrRdoModuleBB::Init() { // // Get Calibration Numbers // ifstream readNumbers("BrCalibrBB.dat",ios::in); if(readNumbers) { for(int i=1; i<45; i++) { ReadNumbers >> DtLeft[i] >> DtRight[i] >> LPedMean[i] >> LPedRMS[i] >> RPedMean[i] >> RPedRMS[i] >> LAdcGain0[i] >> RAdcGain0[i] >> kL[i] >> kR[i] >> DtTdcLSlew[i] >> DtTdcRSlew[i] >> LGapSt[i] >> LGap[i] >> RGapSt[i] >> RGap[i]; if (readNumbers.eof() || readNumbers.fail()) { Error("Init", "Bad read or premature end of file \"BrCalibrBB.dat\"); // fStatus = kFatalModuleError; // Not implemented yet return; } } } else { readNumbers.open(Form("%s/params/bb/BrCalibrBB.dat", gSystem->Getenv("BRATSYS")),ios::in) if (!readNumbers) { Error("Init", "Couldn't open file \"BrCalibrBB.dat\"); return; // fStatus = kFatalModuleError; // Not implemented yet } for(int i=1; i<45; i++) { ReadNumbers >> DtLeft[i] >> DtRight[i] >> LPedMean[i] >> LPedRMS[i] >> RPedMean[i] >> RPedRMS[i] >> LAdcGain0[i] >> RAdcGain0[i] >> kL[i] >> kR[i] >> DtTdcLSlew[i] >> DtTdcRSlew[i] >> LGapSt[i] >> LGap[i] >> RGapSt[i] >> RGap[i]; if (readNumbers.eof() || readNumbers.fail()) { Error("Init", "Bad read or premature end of file \"BrCalibrBB.dat\"); return; // fStatus = kFatalModuleError; // Not implemented yet } } } } //____________________________________________________________________ > As for the "exit", $BRATSYS/params/bb/BrCalibrBB.dat is always there!!! > There's now way you can't find it, if your $BRATSYS is set correctly! As Ian pointed out, missing files is something one should be prepared for. It happens more often then you think. Also, permissions may not allow one to open the file and so on. It's a very common mistake by both experienced and novice programmers, not to check IO. I hope that is clear that you really need to do that. Any good book on programming - in whatever programming (or spoken) language - will tell you so; if yours doesn't, throw it on the fire! I agree, however, that an "exit()" statement here is not appropiate. Rather, one should set a status flag (as suggested above) and the surronding container should take appropiate action. This falls under the UNRESOLVED issue of error handling and module intercomunication in BRAT. On Wed, 15 Nov 2000 09:20:51 -0500 Yury Blyakhman <Yury_B@physics.nyu.edu> wrote concerning ": Re: BB Vertex.": > Hello, everybody. > > "I. G. Bearden" wrote: > > > > Yury Blyakhman wrote: > > > Hello, everybody. > > > I've committed next version of BrRdoModule with refined vertex > > > calculation by BB. I'll skip all the details, but it uses more > > > calibration numbers now, hence, new version of BrCalibrBB.dat. > > > > And the BRAT version is? > > I'll tag the BRAT version next time. It's just when I receive messages > from smbd, about some major changes, I always checkout a fresh version > (or update, if no new classes/files were introduced), deleting the old > one. I thought everybody else are doing the same... Nope, and don't expect us to, 'cause then we'd do nothing but update BRAT. Here at NBI, we like to have a common BRAT version used for production (in sync with the AFS version more or less) and individual BRAT versions for development. The common version is updated via scripts, and that means that CVS tags are very VERY helpfull. So please, everyone, bump the revision number when you change more then the spelling of a variable. > > This is not a negligible change, if I have understood correctly. You have > > changed the calibration procedure (how? why 'more numbers?'), > > There're two major changes in BrCalibrBB.dat : > 1. Old values are refined and retuned, based on runs 2484 and 2235 > 2. Individual values for ADC gaps starting point and width are > added for Big tubes. > > > and so I suppose this will give problems if one, for example, just took > > the new RdoModule or calibration file. > > Yes, all calibration process will go wrong if one uses old version of > BrCalibrBB.dat. That's why one should update his/her BRAT. In general, I > guess, it'll be fixed by making database stuff to work for everybody. I'd like to take this oppertunity to push for using the MySQL database for calibration data. Experience with a test database here at NBI show good result (I should say test were done by Djamel and not me, so it's not that I'm advocating what I did - in fact Flemming did most of the user-level interface, and bloody nicely too), and he'll probably soon commit code that'll read from and write to a production database. Really good examples of IO (thanks to Flemming) for the DBs can be found in brat/dbapps. 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 Nov 20 2000 - 14:11:06 EST