Macro reloads and achieving ROOT5 workflows in ROOT6

During analysis development, my standard work pattern in ROOT5 is as follows:

  1. edit unnamed macro with lots of commands, etc.
  2. run in root, producing results
  3. play with calculated variables from the command line
  4. edit macro
  5. repeat

A key part of step #3 is that the variables generated in the unnamed macro are available in memory to manipulate quickly at the command line, which helps determine what needs to be done in step #4. Named macros don’t work in this workflow because the variables aren’t global.

At the moment, this cannot be done in ROOT6 because variables are not reset when re-running a macro. This has been discussed before:




https://sft.its.cern.ch/jira/browse/ROOT-8689

It doesn’t seem like fixing this is a high priority, which I find quite remarkable, since it has prevented most of the people I work with from upgrading to ROOT6. Perhaps there is a better/different workflow we should be using in ROOT6? We tried exiting root after step 3 every time, but the startup delay of root is large enough to make this unacceptable.

Thoughts?

Hi,

what do you mean by slow startup (1s, 10s)? ROOT 6.10/04 boots and quits in 150ms on a machine with SSD drive.
What is the reason of the slow startup? Some code you are running perhaps?

Cheers,
D

And yes, we feel the pain. It’s terrible, and I’m keeping all the bug reports related to reloading open, to signal how important this is to the world. I am not the one managing resources, so all I can do is work as hard as I can…

1 Like

A (ugly) workaround that I use sometimes on very simple unnamed macros is to always define variables in the following way:

{
  n = int{5};
  s = string("test");
  gDirectory->Delete("myhisto");
  myhisto = TH1D("myhisto","",10,0,10);
} 

The first time that the macro is executed, cling intends these lines as the “command-line-only shortcut” allowing to skip auto.
Any subsequent time, it will be intended as assignment.

Of course I do not suggest it as a “production code” approach, as you could have surprises (something constructor can be different than assignment) and could include dangerous side-effects that are not immediately visible (e.g. I am not sure if the second time the previous TH1D object is not leaking… I do not know what gDirectory->Delete() is exactly doing behind the curtains…), but for some short trial&error test maybe you can survive…

I hope this can help,
Matteo

1 Like

On my machine (w/ SSD), 6.10/02 completes a start/stop cycle in about 400ms, which is fine for normal startup, but becomes untenable for rapid iterations on the macro. There is some startup code I use which probably accounts for half of the delay.

Hi,

is the unsatisfactory judgement you formulate linked to your workflow which needs to run at a higher rate than the present one or to the latency you experience when restarting ROOT?

Cheers,
Danilo

Not sure I parse the question properly. Basically, I want to be able to achieve the same fast cycle times that I can in root5. For instance, with 2 windows open, I can perform the following loop quickly and with a bare minimum of keystroks to iterate on the contents of macro: edit, switch window, up-arrow-enter, switch window, repeat.

The focus on loop time is probably not productive anyway. Consider that in the root5 case, I am allowed to build up any number of other (outside of macro) variables in the session (perhaps from other macros), which I can use and refer to, etc. and which don’t get lost when I rerun the macro. This obviously cannot be done if you have to exit the session each time to restart.

Anyway, thanks to the team and to Axel, who I can tell feels the pain. Hopefully the decision makers can be convinced that core functionality should trump bells and whistles like docker containers…

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.