RE: New release of Debian ROOT packages - Development Snapshot

Hi Fons,
> Hi Valeri,
>
> yes I can expose the content of config.h via TROOT. But if you have
a
> quick fix for TGQt that would be fine.

 Ilka had committed the Christian's corrections.

> See for example TGResourcePool.cxx.

Yes, I know about TGResourcePool. This is what the Qt piece was originally "derived" from by the "error prone mouse copy/paste" technique ;) ".

Cheers, Valeri

>
> Cheers, Fons.
>
>
> Fine, Valeri wrote:
> > Hello Fons,
> >
> > Don't you think one has to add some extra methods to TApplication /
> > TSystem to get the name of those directories from one single place
to
> > eliminate such sort of the problem in future?
> >
> > Something like:
> >

http://root.cern.ch/root/htmldoc/TApplication.html#TApplication:Applicat
> > ionName
> >
> > const char *TApplication::ApplicationBinRoot() const
> > const char *TApplication::ApplicationFontRoot() const
> >
> > etc
> >
> > Thank you, Valeri
> >
> > Best Regards
> > Valeri Fine
> > ---------------
> > Brookhaven National Laboratory
> > Upton, NY 11973, USA
> > Phone: +1 631 344 7806
> > Fax: +1 631 344 4206
> > E-mail: fine_at_bnl.gov
> >
> >> -----Original Message-----
> >> From: owner-roottalk_at_pcroot.cern.ch
> > [mailto:owner-roottalk_at_pcroot.cern.ch]
> >> On Behalf Of Fons Rademakers
> >> Sent: Monday, October 30, 2006 9:28 AM
> >> To: Roland Kuhn
> >> Cc: Christian Holm Christensen; ROOT Talk; Debian Science Mailing
List
> >> Subject: Re: [ROOT] New release of Debian ROOT packages -
Development
> >> Snapshot
> >>
> >> There is some ROOTSYS badness in TGQt which has to be fixed. I'll
also
> >> take
> >> care of the test program problems using the attached patches.
> >>
> >> Cheers, Fons.
> >>
> >>
> >> Roland Kuhn wrote:
> >>> Hi Christian!
> >>>
> >>> On 30 Oct 2006, at 12:20, Christian Holm Christensen wrote:
> >>>
> >>>>>> Try unsetting the ROOTSYS environment variable (and
> > LD_LIBRARY_PATH
> >>>>>> for
> >>>>>> that matter). These variables are _not_ needed.
> >>>>>>
> >>>>> Without the Qt plugin it gave no errors, but with it I got
> >>>> So, if you unset ROOTSYS, it works? Is that correctly
understood?
> >>>>
> >>> Sorry for not being crystal clear: without Qt I did not observe
any
> >>> error messages or problems when running with unset ROOTSYS.
> >>>
> >>>>> rkuhn_at_rk:~$ root
> >>>>> Error in <TUnixSystem::ExpandFileName>: input:
> > $ROOTSYS/bin/root.exe,
> >>>>> output: $ROOTSYS/bin/root.exe
> >>>>> Xlib: extension "XInputExtension" missing on display
> >> "localhost:10.0".
> >>>> I guess this has to do with the remote X server set-up. It's
> > probably
> >>>> harmless.
> >>>>
> >>> I figured.
> >>>
> >>>>> Failed to get list of devices\
> >>>> Does the pointer and keyboard work?
> >>>>
> >>> Yes.
> >>>
> >>>>> ** $Id: TGQt.cxx,v 1.33 2006/10/04 16:08:48 antcheva Exp $
> >> this=0xb12a70
> >>>>> The font "symbol.ttf" was not installed yet
> >>>>> Substitute it with "Arial"
> >>>>> Make sure your local "~/.fonts.conf" or "/etc/fonts/fonts.conf"
> > file
> >>>>> points to "$ROOOTSYS/fonts" directory to get the proper support
> > for
> >>>>> ROOT TLatex class
> >>>>> Error in <TUnixSystem::ExpandFileName>: input:
> > $ROOTSYS/cint/include/
> >>>> ... <bla bla bla>
> >>>>
> >>>> All these warnings has to do with some bugs in the Qt code. The
> >> problem
> >>>> is, that the Qt code does not take into account that one might
> > install
> >>>> ROOT without the use of the ROOTSYS environment variable (sigh!).
> > I'll
> >>>> open a bug report on savannah.cern.ch and add a fix.
> >>>>
> >>> Okay, thanks.
> >>>
> >>>>> To check e.g. library loading I tried
> > 'gSystem.Load("libPhysics.so")'
> >>>>> and got again two Errors with qt and none without. The library
> > seems
> >>>>> to work, though.
> >>>> That's because the Qt backend adds wrong stuff to the library
path.
> >>>>
> >>> Yup.
> >>>
> >>>>> I'm doing some stress tests now.
> >>>> Great. As far as I can tell, they all work, right?
> >>>>
> >>> Yes.
> >>>
> >>>>> I've not noticed any failures (stressGraphics seems to require
the
> >>>>> creation of a file which I cannot write as non-root,
> >>>> Probably since you're executing in a directory where you have no
> > write
> >>>> access. I'd suggest copying the `test' directory somewhere else
> > (as a
> >>>> normal user) and compile and run it there.
> >>>>
> >>> Well, it complains that $ROOTSYS/tutorials/hsimple.root does not
> > exist,
> >>> which is not a location I'd have write access for. Something like
> > below
> >>> might help:
> >>>
> >>> --- /usr/share/doc/root/test/stressGraphics.cxx 2006-09-12
> >>> 13:24:40.000000000 +0000
> >>> +++ stressGraphics.cxx 2006-10-30 13:13:49.000000000 +0000
> >>> @@ -143,10 +143,21 @@
> >>>
> >>> // Check if $ROOTSYS/tutorials/hsimple.root exists
> >>> gErrorIgnoreLevel = 9999;
> >>> + if (verbose) printf("searching hsimple.root\n");
> >>> gFile = new TFile("$ROOTSYS/tutorials/hsimple.root");
> >>> if (gFile->IsZombie()) {
> >>> - printf("File $ROOTSYS/tutorials/hsimple.root does not
exist.
> > Run
> >>> tutorial hsimple.C first\n");
> >>> - return;
> >>> + if (verbose) printf(" not found in $ROOTSYS/tutorials\n");
> >>> + delete gFile;
> >>> + gFile = new TFile("hsimple.root");
> >>> + if (gFile->IsZombie()) {
> >>> + if (verbose) printf(" not found in current
directory\n");
> >>> + printf("File hsimple.root does not exist. Run tutorial
> >>> hsimple.C first\n");
> >>> + return;
> >>> + } else {
> >>> + if (verbose) printf(" found in current directory\n");
> >>> + }
> >>> + } else {
> >>> + if (verbose) printf(" found in $ROOTSYS/tutorials\n");
> >>> }
> >>> gErrorIgnoreLevel = 0;
> >>>
> >>> =====
> >>>
> >>> Side note: the options parsing of stressGraphics.cxx is a bit
weird,
> >> right?
> >>>>> stressHepix
> >>>>> seems to want to call only the other stress tests, which fails
> >>>>> because I don't have '.' in my PATH, and I shouldn't be forced
> > to).
> >>>> No you shouldn't. This is a mistake in the stressHepix program
to
> >>>> assume that.
> >>>>
> >>>> Having `.' in ones path is very _very_ bad and is frowned upon by
> > any
> >>>> serious administrator. Suppose you have `.' in your PATH, and
you
> > cd
> >>>> to some other users directory. There you execute `ls'. Now,
what
> > you
> >>>> don't know, is that the other user has put a malicious version of
> > `ls'
> >>>> in her directory, say something that forks and runs some bad
stuff
> > in
> >>>> the background, while executing `/bin/ls' in the foreground.
> >>>>
> >>> Yep, that's why I said I shouldn't be forced to ;-)
> >>>
> >>>> Someone please correct the function `runTest' in
`stressHepix.cxx'
> > to
> >>>> read
> >>>>
> >>>> void runTest(const char *atest, int estimate) {
> >>>> printf("Running : %s, (takes %d RT seconds on the ref
> >>>> machine)\n",atest,estimate);
> >>>> gSystem->Exec(Form("./%s >>stressHepix.log",atest));
> >>>> }
> >>>>
> >>> Looks reasonable. But it might be even better to use the dirname
of
> >>> argv[0], unless that's the empty string. The following Works For
> > Me(tm)
> >>> and also fixes a linker problem with libEvent.so (had to set
> >>> LD_LIBRARY_PATH before):
> >>>
> >>> diff -ur /usr/share/doc/root/test/Makefile test/Makefile
> >>> --- /usr/share/doc/root/test/Makefile 2006-09-30
> > 18:17:14.000000000
> >> +0000
> >>> +++ test/Makefile 2006-10-30 12:58:35.000000000 +0000
> >>> @@ -17,7 +17,7 @@
> >>> ifeq ($(PLATFORM),win32)
> >>> EVENTLIB = libEvent.lib
> >>> else
> >>> -EVENTLIB = $(EVENTSO)
> >>> +EVENTLIB = $(shell pwd)/$(EVENTSO)
> >>> endif
> >>>
> >>> MAINEVENTO = MainEvent.$(ObjSuf)
> >>> diff -ur /usr/share/doc/root/test/stressHepix.cxx
> > test/stressHepix.cxx
> >>> --- /usr/share/doc/root/test/stressHepix.cxx 2006-09-15
> >>> 10:05:30.000000000 +0000
> >>> +++ test/stressHepix.cxx 2006-10-30 12:47:33.000000000
+0000
> >>> @@ -71,7 +71,14 @@
> >>>
> >>> void runTest(const char *atest, int estimate) {
> >>> printf("Running : %s, (takes %d RT seconds on the ref
> >>> machine)\n",atest,estimate);
> >>> - gSystem->Exec(Form("%s >>stressHepix.log",atest));
> >>> + TString cmdname(gROOT->GetApplication()->Argv(0));
> >>> + TString prefix(".");
> >>> + Ssiz_t offset;
> >>> + if ((offset = cmdname.Last('/')) != kNPOS) {
> >>> + cmdname.Resize(offset);
> >>> + prefix = cmdname;
> >>> + }
> >>> + gSystem->Exec(Form("%s/%s
> >>> stressHepix.log",prefix.Data(),atest));
> >>> }
> >>>
> >>> int main(int argc, char **argv)
> >>> =====
> >>>
> >>> This patch is badly whitespace-mangled, I don't know how to make
> > Apple
> >>> Mail behave in this respect, so please accept my apologies and if
> > you
> >>> want to actually apply this, use the attached version.
> >>>
> >>> Ciao,
> >>> Roland
> >>>
> >>> --
> >>> TU Muenchen, Physik-Department E18, James-Franck-Str., 85748
> > Garching
> >>> Telefon 089/289-12575; Telefax 089/289-12570
> >>> --
> >>> CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487
4482
> >>> --
> >>> Any society that would give up a little liberty to gain a little
> >>> security will deserve neither and lose both. - Benjamin Franklin
> >>> -----BEGIN GEEK CODE BLOCK-----
> >>> Version: 3.12
> >>> GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w---
> > M+ !V
> >> Y+
> >>> PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
> >>> ------END GEEK CODE BLOCK------
> >>>
> >>>
> >> --
> >> Org: CERN, European Laboratory for Particle Physics.
> >> Mail: 1211 Geneve 23, Switzerland
> >> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
> >> WWW: http://fons.rademakers.org Fax: +41 22 7669640
> >
>
> --
> Org: CERN, European Laboratory for Particle Physics.
> Mail: 1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
> WWW: http://fons.rademakers.org Fax: +41 22 7669640
Received on Mon Oct 30 2006 - 19:22:17 MET