Re: BROP-1-0-1 and something must be wrong here.......

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Fri Jul 13 2001 - 08:04:17 EDT

  • Next message: Pawel Staszel: "new version on BrOnlineMonitorDC"

    Hi Jens, 
    
    On Thu, 12 Jul 2001 22:54:05 -0100 (GMT+1)
    Jens Ivar Jordre <jens@tellus.fi.uib.no> wrote
    concerning ": Re: BROP-1-0-1 and something must be wrong here.......":
    > On Thu, 12 Jul 2001, Christian Holm Christensen wrote:
    > > I think Kris has some views on this (I tried to find them in my
    > > backcatalog of emails, but - alas - failed).  As far as I remember,
    > > the idea was to have a seperate application for such computing heavy
    > > stuff as the TPC tracking, so that the normal monitor is fairly free
    > > to do what ever.
    > 
    > Well, that is the thing. The new BrOnlineMonitorTPC does not include
    > clustering, tracking or any heavy calculation algorithms. These parts of
    > the TPC monitoring will be part of a TPC Event Display program that I am
    > about to develop. Therefore the TPC parts of supermonitor will not slow it
    > down.
    
    However, we might still want a seperate program that does the full
    tracking.  
     
    
    > The dialog, PrintDialogBox, inherits from TGTransientFrame and is
    > constructed with "new PrintDialogBox(<arguments>)".
    
    Hmm.  Odd.  How is the window unmapped?  Does the "Ok", "Cancel",
    ladida button delete the object it self?  I believe it should (see
    also guitest.C in the ROOT source tree). 
     
    > > By the way, does the monitor GUI's use the Signal/Slot mechanism or
    > > the ProcessEvent mechanism?
    > 
    > It is the ProcessEvent mechanism being used here.
    
    I really REALLY recoomend using the signal/slot thing instead, since
    it is soooo much nicer and easier to understand. 
     
    > > Try running the application in the debugger, and see where it fails.
    > 
    > This leads to file format problems, 
    
    Uh? 
    
    > at least using gdb 19991004 and gdb 5.0. Looking at the output of
    > the compilation the appropriate flags for debugging seem to have
    > been set. But that's just as far as I can see.
    
    Take a look in for example util/Makefile, and you'll see 
    
      CXXFLAGS = -g -O2
    
    That is, debug symbols and 2nd level optimisation.  The 2nd level
    optimisation may make things look a bit odd in the debugger, since
    some instructions are optimised away. 
    
    If you want to avoid this optimisation, configure the source tree as 
    
      CXXFLAGS="-g" ./configure <options> 
    
    > Using BRAT 2 and other module (in the CVS meaning of the word) 
    
    Let's call that a software package to minimize confusion. 
    
    > with the same building structure, how can one change the compiler
    > flags say for the entire module and in any given directory where a
    > Makefile is generated? 
    
    As above. 
    
    
    I may at some point write a M4 macro that lets you choose this via the
    configure script directly, like 
    
      ./configure --disable-optimisation 
    
    and 
    
      ./configure --disable-debug 
    
    It should be fairly simple to do. 
    
    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 2b30 : Fri Jul 13 2001 - 08:05:48 EDT