Hello, Jonathan
On Saturday, April 03, 1999 12:48 PM you wrote:
>
> It is a help to know that the bug seems to be dependent on the
> configuration of the specific machine.
Do you mean the same version of ROOT works just fine within another box ?
> I am a bit frustrated that there is no way for me to build root on my system, or else
> I could run it under a debugger and see where the problem comes in.
ROOT is always compiled with /Zi option ON and *.pdb files for all ROOT DLLs are
created. They are not part of the "tar" file to keep it smaller. Anyway I can provide it
somehow.
> Do you know if Rene and
> friends plan ever to release a makefile for NT?).
As far as I know even the most UNIX makefiles are the ROOT user's contributions rather
the "product" of the ROOT team itself. So this question to ROOT talk. From another hand
ROOT is supported with CMZ utility and it takes 1 command and 10-20 min of the wallclock
time to do everything from the scratch (the debug information will be included as well).
> Do you know if there is a debugging facility within Root/CInt that would allow me to
> debug the initialization process?
I think there is no such powerful facility within Root/Cint itself
> For what it's worth, if I give the command-line
I think it doesn't worth to try. Much more simpler either get my *.pdb files
or re-install ROOT from the scratch via CMZ utility.
> "root h.C", I can inspect the command line with
> gROOT.GetApplication()->Argc(1), which returns "h.C". However, I don't know
> what Root is doing with this argument.
It is slightly more complicate that one can expect.
Look up:
"void TApplication::ProcessFile(const Text_t *name)"
and you will see that any input file is preprocessed by that ProcessFile first then
it is transferred to Cint and the last performs the second circle of the "pre-processing"
For example the real syntax of the ROOT command (I've discovered from the
void TApplication::GetOptions(int *argc, char **argv) ))
looks as follows:
root [-l] [-b] [-n] [-q] [-p] [+/-] [dir] [file1.C ... fileN.C]
The most interesting piece here is
} else if (argv[i][0] != '-' && argv[i][0] != '+') {
Long_t id, size, flags, modtime;
char *dir = gSystem->ExpandPathName(argv[i]);
if (!gSystem->GetPathInfo(dir, &id, &size, &flags, &modtime) &&
(flags & 2)) { // if directory make it working directory
gSystem->ChangeDirectory(dir);
TSystemDirectory *workdir = new TSystemDirectory("workdir", gSystem->WorkingDirectory());
TObject *w = gROOT->GetListOfBrowsables()->FindObject("workdir");
TObjLink *lnk = gROOT->GetListOfBrowsables()->FirstLink();
while (lnk) {
if (lnk->GetObject() == w) {
lnk->SetObject(workdir);
lnk->SetOption(gSystem->WorkingDirectory());
break;
}
lnk = lnk->Next();
}
It shows the ROOT may CHANGE YOUR WORKING CURRENT DIRECTORY
if you by your "Windows" habit (;-)) "forgot" to mention an extension of your file
at start up time.
This may lead to many unexpected side effect. (For example the "original" working
directory is not restored by the end of the ROOT session and this may lead
to many surprises). It is not custom of any UNIX since he/she must point the file
extensions always. Or under the current directory there is no macro file you pointed
but some directory with the same name instead.
I wonder Fons may enlight us on this issue as well.
With my regards,
Valery
PS. For example on Sun the "man chdir" says:
Certain FORTRAN file operations reopen files by name.
Using chdir while doing I/O may cause the runtime system
to lose track of files created with relative path names,
including those files that are created by open statements
without file names.
>
> Thanks for your attention,
> Jonathan
>
> At 11:16 AM 4/1/99 , you wrote:
> > Hello Jonathan
> > I paid my attention on your "cat" command.
> > Does this means your are running some Posix/Unix layer over
> > WIN32 subsystem.
> >
> > Did you switch to this this recently. Did the previous version of ROOT
> >worked in this environment and what is that: Cygwin, MKS, MS Posix,
> >Hamilton shell, UWin ........, home made GNU.
> >
> > I can repeat, I did find some problem with ROOT but still can not
> > reproduce yours.
> >
> > Valery
>
> ===========================================================================
> Jonathan M. Gilligan <jonathan.gilligan@vanderbilt.edu>
> Research Assistant Professor of Physics (615) 343-6252
> Dept. of Physics and Astronomy, Box 1807-B Fax: 343-7263
> 6823 Stevenson Center
> Vanderbilt University, Nashville, TN 37235 Dep't Office: 322-2828
>
>
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:31 MET