Tracking in nested functions of functions.

[gijsbertwerner]

When nesting the 'single' functions, I have for now set the tracker to 'style =3' which I think works slightly better for this. The problem is that in the main loop we silently call the 'single' function, so then everytime the tracker increases in rather large increments. With style 3 I think it still looks ok, but when people are dealing with a large number of species (or trees) it will still take a while before they see anything happening.

Another option is to actually call the single function and not set Track=FALSE. Then you essentially get two trackers simultaneously, a sort of meta-tracker that goes slowly and the one for each individual single function call. Visually it looks terrible, but you can sort of figure out what is going on. Unless we rewrite the underlying single functions (which I don't think we should), I don't think we have any option other than either of these two. I would favour the former.

[paternogbc]

Hey Gijsbert!

Many thanks for that! I am also trying to find a solution. I will test your ideas!

[paternogbc]

Found a solution for this problem. The problem was: the single functions were creating an object that start the progress bar even when track = FALSE:

 pb <- utils::txtProgressBar(min = 0, max = N, style = 1)

This code starts the bar even if we were not printing the progress bar (only activated inside of the loop when track = TRUE):

if (track == TRUE) setTxtProgressBar(pb, i)

Thus, when we used the same code in the nested loops, even when we include a track = FALSE inside the single function but want to print the progress of the nested loop we have a problem. Because each iteration creates a new "pb" object (in the single function) that will will interact with the new "pb" objected created in the nested loop.

Solution:

1. Include a if (track == TRUE) before the code pb <- utils::txtProgressBar(min = 0, max = N, style = 1) inside the single functions.

Then we can use the traditional approach for the nested loops and it should work since it will be only one "pb" objetct created inside the function. This will require us to set track = FALSE in the single functions.

Let me know what you think. But after we finish other problems we can easily fix this issue. I find the tracking bar quite important for the user, specially for the interaction functions which take much more time to run.

[caterinap]

I like this solution, I think I set if (track == TRUE) in some of the single for another reason but did not think about it :).

[paternogbc]

But you got the idea right?

if (track == TRUE) pb <- utils::txtProgressBar(min = 0, max = N, style = 1)

to avoid any activity from the progressbar when track = F in the function call.

[caterinap]

Yep, sure, we can at the same time do this + add again the progressbars in the interactions (I removed them all).

[gijsbertwerner]

Yes, great, Gustavo, this is an excellent solution, I think!

[paternogbc]

Nice guys! This is solved then! I will do this later this week in a specific branch! I am glad we are going to have progress bars again because it is annoying to wait without any idea how long it is going to take.