Results set processing shouldn't be in the progress bar

[marcharper]

No description provided.

[drvinceknight]

I don't believe it is?

The bar increments to 100% as each chunk output is written. It will (or at least should if I've done things as I intended) sit on 100% until the result are processed. Am I missing something?

[marcharper]

It sort of is -- tournament.play returns a results set now if build_results=True. For larger tournaments, this can make the progress bar seem to hang for a long time.

We could make the result set load lazily, perhaps with a property. I think it's a low priority in any case.

[drvinceknight]

It sort of is -- tournament.play returns a results set now if build_results=True. For larger tournaments, this can make the progress bar seem to hang for a long time.

Do you mean when it's sat on 100% whilst the result set is building it looks like it's hanging? Still not fully seeing it.

We could make the result set load lazily, perhaps with a property. I think it's a low priority in any case.

Would another option be to include a second progress bar for the result set perhaps?

[marcharper]

That's what I mean, yes. A seconds progress bar might be good, the trick will be estimating the work time.

[drvinceknight]

A seconds progress bar might be good, the trick will be estimating the work time.

I've got a couple of ideas. tqdm has some nested progress bar functionality that could help.

I'll knock up a couple of possibilities and post gifs here for us to figure out a way to go :)

[drvinceknight]

How does this look @marcharper:

That's actually relatively basic. The progress is across the 19 calculations that the results set does (self.build_ranking(), self.build_payoffs(),...) so it's not terribly granular. No matter the size of the tournament the result set progress bar will always have 19 steps. FYI, my current implementation just uses a decorator that tries to increment the progress bar by 1 for the result set for each of the 19 methods so it's not actually increasing code complexity very much at all.

I've got some other ideas for nested progress bars (for each of the sub methods like build_ranking() etc...) but I think that might be overkill. I feel this current implementation gives enough of an indicator that something is happening.

Note that this approach is not incrementing a thing whilst reading in the results from file, so while that is happening the progress bar should be sitting on an empty Analysing Results: .... This gets away from the issue of having to know the size of the results set file.

Let me know what you think, I can tidy this up and get tests in there as necessary pretty straightforwardly.

[marcharper]

Definitely better. I know it's hard to make the bar accurate for the results calculations, nevertheless it's much better than just sitting there with no user feedback at all.

[drvinceknight]

Have opened #603, coveralls doesn't seem to be plugged in quite right though.