BT 0.88

[jjwhalen]

The huge random number appears if and only if the first 2 values are 0/0, which is the case for your DNETC (mine too).  Any project with no work will show a huge random number
The nci issue that we're talking about is different and doesn't show the huge number in field 3.

Thanks for the clarification, Beyond.  The point I was trying to make is that after updating to BT 0.88, DNETC correctly read "0/0/0" until the FreeHAL task on that host was aborted bringing its count to 0/0/0, after which both projects displayed the random number.  This is the strange behavior I was talking about, related to your NCI issue or otherwise.

Best wishes.

[jjwhalen]

Fred,

Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort.  Yoyo, for one, uses project abort a lot to keep the server workload down.

That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort.  Did you maybe go back to an earlier version of the code in that area?

[fred]

Fred,

Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort.  Yoyo, for one, uses project abort a lot to keep the server workload down.

That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort.  Did you maybe go back to an earlier version of the code in that area?

I have to check.

[fred]

I've tried once (twice) more - 2 minutes after the first benchmark nothing happened, but shortly after second benchmark the time was noted. 

I checked everything, nothing wrong that I can find.
It may be that the BOINC client rejected the Benchmark result, sometimes it's invalid.
it this get_host_info(HOST_INFO&) that gives the benchmark time. Looks like client problem, if there is a problem. Maybe a too frequent benchmark is rejected as well.

[fred]

Fred,

Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort.  Yoyo, for one, uses project abort a lot to keep the server workload down.

That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort.  Did you maybe go back to an earlier version of the code in that area?

You can switch off the filter for aborted.
Fixed a bug in V 0.89 to show the real status on 1 filtered task.

[jjwhalen]

Fred,

Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort.  Yoyo, for one, uses project abort a lot to keep the server workload down.

That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort.  Did you maybe go back to an earlier version of the code in that area?

You can switch off the filter for aborted.
Fixed a bug in V 0.89 to show the real status on 1 filtered task.

Great; I guess it never occurred to me that the filter acts on just a single line entry that matches the filter criteria -- but why not.

But this raises a new question: if the filter option "Aborted" is checked and the computer has multiple aborts, some user and some project, does this mean that the filter will combine them all into a single line entry?  I would expect "Aborted by project" to be treated as a completely different Status and not touched by filter criterion "Aborted"  I may user-abort 100+ tasks and want them to be filtered.  But project aborts are relatively rare and I want them to stand out

[jjwhalen]

Regarding "Set debt":

I agree with Beyond that this is a useful addition.  A few points...

1) Projects>Set debt only works if "All computers" is selected & a project is highlighted.  If a single computer is selected the menu item is active (not grayed out) but does nothing.  Either (in descending order of desirability)
    a) Let it call the dialog for that computer, or
    b) Make it inactive when a single computer is selected.

2) If the dialog is opened, a project is selected, the data entry fields are left blank, and "Apply" is clicked, this causes debts to be zeroed out for that project.  It is very easy to accidentally zero debts that you don't want/can't afford to.  Nulls in the data entry fields should not be read in as zeros, and hitting Apply on null fields should result in either no action or an error message.  To zero debts, the user should have to deliberately enter "0" "0.0" or some permutation into the data entry field(s) and then click "Apply".

3) Numbers entered into the data entry fields stay there, even after the dialog is closed, until BT is restarted.  Data entry fields should be cleared whenever
    a) Apply is clicked,
    b) A different project is highlighted on the selection list, or
    c) The dialog is closed.

Feature request: request the Set debt menu item be added to the Context Menu of the Projects tab, with the same functionality as Projects>Set debt.

Question: will you be adding capability to adjust GPU debts at a later date?

[fred]

Regarding "Set debt":

I will not improve much on the debt dialog.
The whole debt concept will be gone sooner than later.

I tested, selection a single computer and this seems to work just fine.
Usage go to the project tab, select a project on the right computer and select set debt.
The computer shown in the dialog title is the one that is used

GPU debt is not supported by the client and will never be as the whole debt concept will be gone soon.

In the next version, the apply button will only function only, when there is a number filled out, for both fields.

[Pepo]

I would also expect that just matching groups of tasks be put together, including their state. And also not that it would kick in on a single one