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