Re: New release of Debian ROOT packages - Development Snapshot

From: Roland Kuhn <rkuhn_at_e18.physik.tu-muenchen.de>
Date: Mon, 30 Oct 2006 14:17:30 +0100


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:

     // 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------




  • application/octet-stream attachment: patch
Received on Mon Oct 30 2006 - 14:17:48 MET

This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:01 MET