From: Flemming Videbaek (videbaek@sgs1.hirg.bnl.gov)
Date: Sun Dec 15 2002 - 14:19:36 EST
Hi Christian,
thank for taking a look at this; I do though think due to the working 2.6.0 and non-working 2.6.1 that this has anything
to do with the actual code in either BrTd1 or any other Tofcalibration modules code. Let me respond to a few things you
mention/propose given as inline, since I/EJK did in fact look at some of these.
I should encourage other coders to read Christian's mail carefully it contains several useful hints
on good coding practices.
Flemming
|
| > a) I checked this with my current brat on rcas (brat 2.6.3 0 on gcc
| > 2.96 with root opt/brahms/pro and an earlier adcgain script for
| > td1 did also not produce a ascii file.
|
| In `BrTofCalModule' there's a line going
|
| cin >> fCalibFile;
|
| That's really ugly, as it basically prevents you from using this
| module in a batch environment. Who ever is responsible for this
| module should take out that line. Instead, assign some default value
| to the `fCalibFile' data-member, possibly based on the module name and
| other information, and warn the user that that has happened.
| A better approach is to check in `Init' wether `fCalibFile.IsNull()'
| and in that case, fail immediately - then you will not be wasting CPU
| cycles on something that may not be completed properly.
>> I agree with your comment, though it has nothing to do with the problem.
|
| In general: In the BRAT libraries, one can not assume interactive
| input at all - anyone that does so, should be hit hard on the head
| with a very big, wet, paper! The point is, that BRAT is used _a_lot_
| in batch environments, and therefor _must_not_ assume interactive
| access.
|
| > b) I checked the same command + script on my local desktop version
| > i.e. gcc 3.04, a version of brallibs/main from Oct 28 (I lost
| > the version info) and root 3.03/09 and here the script (reading
| > the same data file) did work.
| >
| > Updating with brat as of today - It does not work any longer - Thus,
| > has anyone else observed a similar behaviour recently? Are there
| > any obvious clues ? (An examination of the change-log does not point
| > to any obvious piece of code that could cause this problem) it is
| > not restricted to tof like cal it also happens for BB, TPC etc...
| >
| > Any clues would be appriciated. (The 10/28 version on my local
| > machine was with all the 'use namespace std' included.)
|
| Couldn't you please submit that to CVS? Thanks.
>
That is the version 2.6.0 that was committed on 10/26 .
|
| ----------------------------------------------------------------------
| > brat-2-6-0 (10/26) works in the normal manner saving the acsii file
| > in the local directory
| >
| > brat-2-6-1 (10/31) does NOT work. You might think this gives a clue,
| > but the very few modules checked in for this version update by
| > Christian has to do with the BrMultcalibration data class At least,
| > I fail to see a connection here. Of course as reported the current
| > version also fails.
|
| > This is all with 2.96 and root 3/03.09 on the rcas machines.
| >
| > Well we are baffled; I hope someone else have some insight into
| > this.
|
| I know this is a really silly thing, but did you check if there's
| enough access permissions to the file you're trying to write to?
Well it work for the version 2.6.0 but not for 2.6.1 running at the same place. It also creates
the histogram root files
| Whether there's any disk space available?
|
| Also, in `BrTd1AdcGainCalModule::SaveAscii()' you have
|
| ofstream file(fCalibFile.Data(), ios::out);
|
| file << ...
|
| That is, you assume that the open thing works. You should really test
| if it does, an emit appropriate error messages if not:
|
| ofstream file(fCalibFile.Data(), ios::out);
| if (!file || file.bad())
| Abort("SaveAscii", "failed to open output file '%s' - aborting",
| fCalibFile.Data());
|
| file << ...
|
I aggree in this and we should put it in whenever we come across stuff like this.
- in fact in a testversion I checked that the file << in fact returned a
rdstate() of good as it should do.
| If you want a bit more diagnostics, include the header files `cerrno'
| and `cstring', and then code it as
|
| ofstream file(fCalibFile.Data(), ios::out);
| if (!file || file.bad())
| Abort("SaveAscii", "failed to open output file '%s': %s",
| fCalibFile.Data(), strerror(errno));
|
| file << ...
|
| It should work in GNU/Linux, but on other systems (especially where
| the IOStream library isn't in sync with the C I/O library - ISO C++
| does not make that guaranty) it will give you nothing of any value.
| Hence, this is not a way I'd recommend in general and should only be
| used for debugging. I've attached a program that shows how this
| works. Compile it:
|
| > g++ foo.cc -o foo
|
| and try to run it with an existing file as the first argument:
|
| > ./foo foo.cc
|
| That should number the lines in the file (a la `cat -n'). Now try to
| run it with a non-existing file as input:
|
| > ./foo bar # assuming `bar' doesn't exis - otherwise another filename
| Failed to open file bar: No such file or directory
|
| I hope that gives you a bit of a clue as to what is going on.
|
| One should _always_ check ones I/O operations, as it depends on
| external things not necessarily under your control (i.e., the medium
| you're writing to).
--------------------------------------------------------------------------------
| #ifndef __IOSTREAM__
| #include <iostream>
| #endif
| #ifndef __FSTREAM__
| #include <fstream>
| #endif
| #ifndef __IOMANIP__
| #include <iomanip>
| #endif
| #ifndef __CERRNO__
| #include <cerrno>
| #endif
| #ifndef __CSTRING__
| #include <cstring>
| #endif
|
|
| using namespace std;
|
|
| int main(int argc, char** argv)
| {
| if (argc < 2) {
| cerr << "I need a file name as sole argument" << endl;
| return 1;
| }
|
| ifstream infile(argv[1], ios::in);
| if (!infile || infile.bad()) {
| cerr << "Failed to open file " << argv[1] << ": "
| << strerror(errno) << endl;
| return 2;
| }
| char c = 0;
| int line = 0;
| cout << setw(8) << line++ << " ";
| while ((c = infile.get()) != EOF) {
| switch(c) {
| case '\n':
| cout << endl << setw(8) << line++ << " ";
| break;
| default:
| cout << c;
| break;
| }
| }
| cout << endl;
| return 0;
| }
|
|
|
This archive was generated by hypermail 2.1.5 : Sun Dec 15 2002 - 14:21:08 EST