Add option to remove (or modify behaviour) progress bar

[scarlehoff]

The progress bar looks nice but if one is in a metered or low-bandwith connection over ssh the constant update apparently takes quite some data.

[cschwan]

I think this will be fixed with the move to Grid::evolve in PineAPPL which doesn't show any progress, because it's much faster.

[scarlehoff]

"It's so much faster that it doesn't need a progress bar", that's a good tag line :P

[alecandido]

In any case, I take the message, and we should add a --no-interaction global option.

[cschwan]

So technically this will be a non-issue when #49 will be merged.

[alecandido]

So technically this will be a non-issue when #49 will be merged.

Pineko is not only doing convolutions, but yes, #49 will solve the specific issue.

Even though, even if takes ~10s for big sets, I would show a bar the same. It is not intuitive to get a program stuck with no output, if you don't at least warn the user in advance (but maybe also big grids with big ekos are convoluted in <1s, is this the case?)

[cschwan]

For timings see NNPDF/pineappl#184 (comment); the entire theory 208 took roughly 10 mins. Personally I dislike libraries (not programs) printing to stdout if everything goes OK, and I'd like to keep it that way and I rather spend more time on optimizing the code then showing a progress bar. If the code ever gets stuck, that's a bug and it should be fixed, of course. However, that shouldn't happen - maybe we'll just have to implement #49 and see how it 'feels'.

[scarlehoff]

We can have a "evolving, could take a few minutes..." and then most of the time takes seconds which makes people using it happy because it is so fast.

[alecandido]

We can have a "evolving, could take a few minutes..." and then most of the time takes seconds which makes people using it happy because it is so fast.

Indeed, this is a possible solution.
However, consider that Pineko itself is mostly used as a program, and PineAPPL CLI is also a program. So, being programs, they have human users, and human users need UI (I agree on libraries, since they are consumed by other programs).

[felixhekhorn]

The problem is how to feed the information/progress from inside the library to the program outside ... (possible solutions might be a console argument or just a boolean argument ...)

[cschwan]

I suggest that we simply make the transition from Grid::convolute_eko to Grid::evolve and see if it's really a problem.

[felixhekhorn]

I still agree with @cschwan above - just to point out that this is (quasi) in conflict with #77

[alecandido]

Proper solution to both issues would be a mechanism to pass the information to the caller. Like exposing a pointer to a structure that will be updated with progresses.

Nothing is printed, so the library itself is not doing it, but the application calling the library can decide to print on its own.

Unfortunately, this is rather complex, since it requires async programming, otherwise the control would never return to the caller, and it would be impossible to print anything.

[scarlehoff]

The progress bar is gone as far as I can see.

[alecandido]

The progress bar is gone as far as I can see.

Yes, @cschwan speeded up PineAPPL evolution, such that we don't need it any longer, and we don't waste time deciding what to do :)