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. See for example TGResourcePool.cxx.
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
>> 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
>>>>>> 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:
>>>>> 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
>>>> 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"
>>>>> points to "$ROOOTSYS/fonts" directory to get the proper support
>>>>> ROOT TLatex class >>>>> Error in <TUnixSystem::ExpandFileName>: input:
>>>> ... <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
>>>> ROOT without the use of the ROOTSYS environment variable (sigh!).
>>>> open a bug report on savannah.cern.ch and add a fix. >>>> >>> Okay, thanks. >>> >>>>> To check e.g. library loading I tried
>>>>> and got again two Errors with qt and none without. The library
>>>>> 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
>>>> access. I'd suggest copying the `test' directory somewhere else
>>>> normal user) and compile and run it there. >>>> >>> Well, it complains that $ROOTSYS/tutorials/hsimple.root does not
>>> which is not a location I'd have write access for. Something like
>>> 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.
>>> 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
>>>> 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
>>>> serious administrator. Suppose you have `.' in your PATH, and you
>>>> to some other users directory. There you execute `ls'. Now, what
>>>> don't know, is that the other user has put a malicious version of
>>>> in her directory, say something that forks and runs some bad stuff
>>>> 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'
>>>> 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
>>> 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
>> +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
>>> --- /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
>>> Mail behave in this respect, so please accept my apologies and if
>>> want to actually apply this, use the attached version. >>> >>> Ciao, >>> Roland >>> >>> -- >>> TU Muenchen, Physik-Department E18, James-Franck-Str., 85748
>>> 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---
>> 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 7669640Received on Mon Oct 30 2006 - 17:50:44 MET
This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:01 MET