Re: calibration module problem

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Sun Dec 15 2002 - 13:19:44 EST

  • Next message: Flemming Videbaek: "Re: calibration module problem"
    Hi Flemming et al, 
    
    "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote concerning
      calibration modules problem [Fri, 13 Dec 2002 17:51:09 -0500] 
    ----------------------------------------------------------------------
    > Eun-joo came to me with a problem that while running calibration the
    > calibration module did NOT output the calibration ascii file, and
    > said that it worked recently (a few weeks) back.
    >
    > We talked about this and convinced ourselves that that code in fact
    > went to the SaveAscii.. method and went into the piece of code
    > following the ofstream file(fFileName.Data(),ios::out) but NO output
    > was produced. EJK even tried to insert a simple piece of code
    > 'ofstream("test.dat",ios::out) followed by some simple formatted
    > output to this file and it did not show up.
    >
    
    > 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. 
    
    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. 
    
    "Flemming Videbaek" <videbaek@rcf.rhic.bnl.gov> wrote concerning
      calibration module problem [Sat, 14 Dec 2002 13:01:58 -0500 (EST)] 
    ----------------------------------------------------------------------
    > 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?
    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 << ...
    
    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).  
    
    BTW Flemming, is your name set properly in the user database?  I'm
    asking because in `BrTd1AdcGainCalModule::Print', it says 
    
         cout << endl 
              << "  Original author: Flemmin Videbaek" << endl
    
    I'm assuming you've used the Emacs lisp function to create the class,
    and that library gets the users name using 
    
      (user-full-name)
    
    which fetches it from the user database, so if that function gave the
    `Flemmin' (missing `g' for all you non-Danes), something is wrong.
    You can test it  by evaluating the above lisp expression in your
    `*scratch*' buffer (press `C-x C-e' with the cursor right after the
    right parenthesis). 
    
    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
     | |
    
    
    #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 - 13:23:17 EST