Updating restRoot behaviour

[jgalan]

Updates brought by this PR:

Now restRoot will be able to open 2 different ROOT files on-the-fly: TRestRun based files, TRestDataSet based files and standard ROOT files.

When it is a TRestRun it will create instances for all metadata objects accessible to TRestRun together with the analysisTree and the eventTree if available.

When it is a TRestDataSet it will call to TRestDataSet::Import to make the dataset readily accessible.

When we open a dataset we get:

@lobis @juanangp @nkx111 I would prefer to remove the last line about attaching _file0 but not idea how or if it is possible.

It seems that when doing it using a TRestRun file it does not prompt this _file0 line.

Main changes are happening in restRoot. Remains are just re-factoring.

[juanangp]

@lobis @juanangp @nkx111 I would prefer to remove the last line about attaching _file0 but not idea how or if it is possible.

It seems that when doing it using a TRestRun file it does not prompt this _file0 line.

I think that _file0 is created by root, so I don't understand why you don't have it while opening a TRestRun, I guess it should be done here TRint theApp("App", &argc, argv);
I found restRoot rather complicated. I would suggest to create a TRestRun *_run0=nullptr; pointer and a TRestDataSet *_dS0 = nullptr; then you can avoid complicated stuff like this:

   string evcmd = Form("TRestAnalysisTree* ana_tree%i = (TRestAnalysisTree*)%s;", nFile,
                         (PTR_ADDR_PREFIX + ToString(runTmp->GetAnalysisTree())).c_str());
                if (debug) printf("%s\n", evcmd.c_str());
                gROOT->ProcessLine(evcmd.c_str());

I guess this should work:

TRestRun *_run0=nullptr;
TRestDataSet *_dS0 = nullptr;
...
if (TRestTools::isTRestRun(opt)){
_run0 = new TRestRun (opt);
std::cout <<"Attaching TRestRun " << opt <<" as _run0"<<std::endl;
} if (TRestTools::isDataSet(opt)) {
_dS0 = new TRestDataSet();
_dS0->Import(opt);
std::cout <<"Attaching TRestDataSet " << opt <<" as _dS0"<<std::endl;
} else ...

[jgalan]

@lobis @juanangp @nkx111 I would prefer to remove the last line about attaching _file0 but not idea how or if it is possible.
It seems that when doing it using a TRestRun file it does not prompt this _file0 line.

I think that _file0 is created by root, so I don't understand why you don't have it while opening a TRestRun, I guess it should be done here TRint theApp("App", &argc, argv); I found restRoot rather complicated. I would suggest to create a TRestRun *_run0=nullptr; pointer and a TRestDataSet *_dS0 = nullptr; then you can avoid complicated stuff like this:

   string evcmd = Form("TRestAnalysisTree* ana_tree%i = (TRestAnalysisTree*)%s;", nFile,
                         (PTR_ADDR_PREFIX + ToString(runTmp->GetAnalysisTree())).c_str());
                if (debug) printf("%s\n", evcmd.c_str());
                gROOT->ProcessLine(evcmd.c_str());

I guess this should work:

TRestRun *_run0=nullptr;
TRestDataSet *_dS0 = nullptr;
...
if (TRestTools::isTRestRun(opt)){
_run0 = new TRestRun (opt);
std::cout <<"Attaching TRestRun " << opt <<" as _run0"<<std::endl;
} if (TRestTools::isDataSet(opt)) {
_dS0 = new TRestDataSet();
_dS0->Import(opt);
std::cout <<"Attaching TRestDataSet " << opt <<" as _dS0"<<std::endl;
} else ...

However we need to call ProcessLine at some point so that the instance is available inside the ROOT interactive shell.

So I don't really see how to solve this. We need to provide the C-command to the ROOT shell.

We could avoid using the instance of analysisTree since we can always access it using run0->GetAnalysisTree().

Also there was some issues while using std::cout for some reason I am not aware of, but @nkx111 knows more about.

[nkx111]

I think the line is shown when you propagate the file name argument to TRint. TRint will just handle those arguments as the command line root does. You need to remove the corresponding item in the arguments.

[nkx111]

I found restRoot rather complicated. I would suggest to create a TRestRun *_run0=nullptr; pointer and a TRestDataSet *_dS0 = nullptr; then you can avoid complicated stuff like this

Constructing such complicated command and calling it through gROOT is because we can therefore use those objects in ROOT prompt. I don't know if it is possible to initialize objects outside ROOT environment but still accessible through its prompt. Perhaps by adding it to some global list?

[jgalan]

I found restRoot rather complicated. I would suggest to create a TRestRun *_run0=nullptr; pointer and a TRestDataSet *_dS0 = nullptr; then you can avoid complicated stuff like this

Constructing such complicated command and calling it through gROOT is because we can therefore use those objects in ROOT prompt. I don't know if it is possible to initialize objects outside ROOT environment but still accessible through its prompt. Perhaps by adding it to some global list?

Ah, right! I see it now that is done for the TRestRun case!

[juanangp]

I found restRoot rather complicated. I would suggest to create a TRestRun *_run0=nullptr; pointer and a TRestDataSet *_dS0 = nullptr; then you can avoid complicated stuff like this
Constructing such complicated command and calling it through gROOT is because we can therefore use those objects in ROOT prompt. I don't know if it is possible to initialize objects outside ROOT environment but still accessible through its prompt. Perhaps by adding it to some global list?

Ah, right! I see it now that is done for the TRestRun case!

I have simplified the opening of TRestRun and TRestDataSet in this PR #447 to this branch, please merge into this branch if you think is a better approach.

I think is possible to add global variables by defining them between the declaration of TRint theApp... and theApp.Run();. However, it would be not possible to add multiple files as it is done now, in fact the generation of the _file0 in root is done in a similar way using the interpreter.

[jgalan]

I found restRoot rather complicated. I would suggest to create a TRestRun *_run0=nullptr; pointer and a TRestDataSet *_dS0 = nullptr; then you can avoid complicated stuff like this
Constructing such complicated command and calling it through gROOT is because we can therefore use those objects in ROOT prompt. I don't know if it is possible to initialize objects outside ROOT environment but still accessible through its prompt. Perhaps by adding it to some global list?

Ah, right! I see it now that is done for the TRestRun case!

I have simplified the opening of TRestRun and TRestDataSet in this PR #447 to this branch, please merge into this branch if you think is a better approach.

I think is possible to add global variables by defining them between the declaration of TRint theApp... and theApp.Run();. However, it would be not possible to add multiple files as it is done now, in fact the generation of the _file0 in root is done in a similar way using the interpreter.

I never used the function opening multi files. I use it for quick inspection of the input file. So, perhaps the multi can be removed