-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#119 - specify runahead limit as a duration #983
Comments
This needs to work via CLI and GUI, which currently still expect integer hours. |
@benfitzpatrick - I was about to start working on this, and had got as far as revising the documentation when I thought I'd better check that you hadn't also started on it, since it is closely related to #1007... and it seems you have done, in a branch "119.restore-runahead-limit". So, I'll stop where I'm at, but could you take my documentation, which is a slightly more general rewrite than strictly necessary for this issue, and merge with your branch as appropriate: bbdef52 One question, I was going to go for a default runahead limit of twice the smallest interval specified in the graph section headings, without accounting for tasks that have a smaller cycling interval than that because they appear in multiple sections. A quick look at your code suggests you're going for the full solution ... but I think we should at least consider whether the simpler version might be better because it would be easier for users to see at a glance where the default comes from. |
The multiple section problem is really because when a user writes:
they mean:
which is:
and the actual cycling interval isn't easy to get out. This may have been true in |
Closed by #1011 |
Currently on the ISO8601 feature branch (see #119) the runahead limit is specified as a multiple of the smallest cycling interval in the suite, which defaults to 2. However, it would probably be better for users who want to override this default to be able to specify a duration (in ISO8601 format, or an integer for integer cycling).
The default value can still be computed as twice the smallest cycling interval. Note that the "smallest cycling interval" is as determined by the recurrence expressions used, it does not get adjusted for tasks that appear in multiple recurrences, which can make the interval between successive task instances smaller than this. However, this probably doesn't matter much so long as how the default is determined is clearly documented.
The text was updated successfully, but these errors were encountered: