From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Mon Dec 16 2002 - 14:36:06 EST
Hi Djam, Bjorn, Flemming, Eun-Joo, et al [Sigh. Apparently the list-servers at BNL are defunct - again - so a direct copy to the above people, sorry about the duplicates. AFS is pretty slow today too.] Djamel Ouerdane <ouerdane@nbi.dk> wrote concerning Re: calibration module problem [Mon, 16 Dec 2002 00:48:37 +0100 (MET)] ---------------------------------------------------------------------- > Ciao, > > Let me comment on a couple of things : > > 1- if you, Christian, keep on hitting people's heads with wet or dry > papers or whatever comes into your hand, you might watch out for some > feedback. I suggest you get a more quiet temper. Other people than me > might care that you use more and more violence in your emails just because > you're more and more pissed off by bad coding habits from the rest of the > collaboration... So, behave man! :) The point of the paper-thingy is to fold - first it's a reference to a saying in Danish (`Faa bank med en vaad Sondagsberlinger') - second, if you think back to one of our Giessen adventures, you'll remember what happened each time David started to read out loud in German! All in all, it was a joke, but with a grain of sincerity that said: `Please don't do this'. > 3- I'm not for aborting systematically in SaveAscii. The reason is that > the histogram module finishes after all analysis or calibration modules. > Therefore, if you abort in SaveAscii, you lose the histogram file since it > won't be closed properly. I want to have the possibility to have at least > the histograms and optionally make some calibrations without reprocessing > all the data sample if the ascii stuff failed for some reasons. If you did > some calibrations, you can understand. This said, proper checks and > warnings should be in place if they're not yet. I wasn't suggesting a `systematic' abort in that member function - that would indeed be counter productive. Rather, I was suggesting that one checked the file name in the `Init' member function of the module, and if not set _either_ abort immediately, _or_ set it to some default value. I hope I was clear on that in my previous email. Oh, and I have made calibrations you know! Bjorn H Samset <bjornhs@rcf2.rhic.bnl.gov> wrote concerning Re: calibration module problem [Mon, 16 Dec 2002 04:09:54 -0500 (EST)] ---------------------------------------------------------------------- > On Sat, 14 Dec 2002, Flemming Videbaek wrote: > > I don't know about insight, but I was able to reproduce your problem on my > laptop. Or rather, when I ran a BbSlewCal script to test, with some > outputs and stuff, I saw that it ran SaveAscii but didn't give me any > files in my current dir (I also added an extra test file, to check...). > > But then I did a > find . -name 'BbrRun5840.slew' > and got this: > ./install/share/brat/params/mult/BbrRun5840.slew > which really is the new file. My test file is also in this dir. Aha, that's the clue I wanted to get. This is due to an error(?), or assumption in `TSystemDirectory' (i.e., in ROOT - not BRAT). Basically, it goes like this: * First you create an object of class `TSystemDirectory' * Then, when you do `TSystemDirectory::GetListOfFiles()' the directory is opened via `TSystem::OpenDirectory', and later closed via `TSystemDirectory::FreeDirectory'. * `TSystem::OpenDirectory' is a virtual member function, so the real member function executed is `TUnixSystem::OpenDirectory' which dispatches to `TUnixSystem::UnixOpendir'. * Likewise, `TSystemDirectory::FreeDirectory' is virtual, and the real member function called is `TUnixSystem::FreeDirectory' which dispatches to `TUnixSystem::UnixClosedir'. * `TUnixSystem::UnixOpendir' calls `opendir' (from the C library), which sets the working directory to the directory you're scanning. * `TUnixSystem::UnixClosedir' calls `closedir' (from the C library), but the working directory _isn't_restored_ to the old working directory. Now, what does all this have to do with the problem at hand, I hear you say? Well, the changes from BRAT version 2.6.0 to 2.6.1 is in BrMultTmpCalibration. Here' we scan the files in the directory <prefix>/share/brat/params/mult and based on the current run number, we read in the appropriate calibration file. As you may have guessed by now, that scanning is done using `TSystemDirectory'. But, I didn't put in the code to `cd' back to the old directory - though I probably envisioned to do so, judging from the fact that I obtain the old working directory name. It must have slipped my mind - sorry. Anyway, I've put in the code that fixes this problem, and it's commited to CVS. BRAT has been tagged and the micro-version updated. BRAT Version: 2.6.4 BRAT CVS tag: BRAT-2-6-4 "Flemming Videbaek" <videbaek@rcf.rhic.bnl.gov> wrote concerning Re: calibration module problem [Mon, 16 Dec 2002 08:31:51 -0500 (EST)] ---------------------------------------------------------------------- > Hi Bjoern and other > Thiis sounds like a usefull clue > Could it be that someone in a brat module has changed default directory > with system calls an not setting it back ? (inserted since Oct-26) Indeed that was the case, as explained above. When I saw Bjorn's email, I immediately realised this. I'm not sure if the above behaviour of `TSystemDirectory' is really what it wanted. It affects the way the TBrowser works in ROOT too. I'll get in contact with the ROOT people about this - look out for more on this on roottalk. 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 Dec 16 2002 - 14:47:25 EST