On Thu, 12 Jul 2001, Christian Holm Christensen wrote: > Hi Jens, > > Jens Ivar Jordre <jens@fi.uib.no> wrote > > Hello y all. > > Uh, take look at > > http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0045.html > http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0046.html > http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0047.html > http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0048.html > > to see what a greeting like the above can spawn - funny stuff by the > way. Yes, I guess that if you do something that makes you look Texan then people are bound do react. E.g. I also frequently use "howdy" which have lead people to ask me if I'm from Texas. Maybe I'm a Texan deep down. I that dangerous, doctor Hagel? > > First some update info. I have made a lighter BrOnlineMonitorTPC > > than the one that was there previously. This new class does not do > > clustering nor tracking. I have also updated SuperMon.cxx to include > > the four TPCs. In my view SuperMonTPC.cxx is obsolete, but I have > > chosen to keep it so far. New tag: BROP-1-0-1. > > 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. > > Then the fun stuff. I had some compilation problems earlier today using > > BRAT 2.0.4 and ROOT 3.01/05. When going back to ROOT 3.00/06 everthing > > seems to work fine. Both ROOT "packages" I used are from the BRAHMS AFS > > area. This lead me to "investigate" > > /afs/rhic/opt/brahms/root/root_v3.01.05 to some small extent. I believe > > there is something odd about it. How about this: > > > > bergen@pii4<1>:/afs/rhic/opt/brahms/root/root_v3.01.05/bin/root-config > > --version > > 3.00/06 > > bergen@pii4<2>: > > Ehr ... that is odd. Hmm. Anyway, if you want to use ROOT 3.01/05, > just include in your path > > /afs/rhic/opt/brahms/new/bin:/afs/rhic/opt/brahms/pro/bin > > unset ROOTSYS and set your LD_LIBRARY_PATH to exactly > > /afs/rhic/opt/brahms/pro/lib > > See also rcf:~brahmlib/.login > > In the future, when BRAT 2.0 becomes the production version, which I > think it's almost ready for, you'll not need to unset the ROOTSYS > environment, since it will not be set in the first place. > > > Where does this fit in. > > > > Well, next thing concerns SuperMonitor. We, i.e. Flemming and I, > > want to print the histograms/pictures drawn on the screen. To do > > this one would typically use the print button on the > > BrMonitorCanvas. > > > > The first time one hits the print button, the print dialog shows up > > without any problems. Then if one wants to print other > > histograms/pictures, one typically runs into segmentation violation > > when hitting the print button on the new instance of > > BrMonitorCanvas. The seg. violation does not necessarily occur when > > printing the second BrMonitorCanvas. It can occur on the 5th, 14th, > > Nth....... > > Sounds like you do not properly unmap and destroy the popup window. > How is that defined? Does it inherit from TGTransientFrame, of from > TGMainFrame? How is it constructed? As > > new <pop-up class>; > > or as > > if (!fPopup) > fPopup = new <pop-up class>; > else { > fPopup->Update(); > fPopup->MapWindow(); > } The dialog, PrintDialogBox, inherits from TGTransientFrame and is constructed with "new PrintDialogBox(<arguments>)". > > However, this error has the same feature as an error you, Kris, > > corrected earlier. I.e. if you hit the print button several times > > after the seg. violation you finally (usually) end up with the print > > dialog window. > > Interresting. It does sound like a map/unmap window problem. > > 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. > Try running the application in the debugger, and see where it fails. This leads to file format problems, 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. Using BRAT 2 and other module (in the CVS meaning of the word) 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? Best wishes from Jens Ivar -- Jens Ivar Jřrdre e-mail: JensIvar.Jordre@fi.uib.no usually: Dep. of Phys., Allégt. 55, N-5007 BERGEN, NORWAY currently: Bldg 510D, P.O.Box 5000, Upton, NY 11973-5000, USA phone: +1-631-344-4223
This archive was generated by hypermail 2b30 : Thu Jul 12 2001 - 18:03:15 EDT