BT 0.60

[fred]

Also, that reminds me, when I move the computer name to the left where I really want it, all I get is the following (Note the names)

EDIT:  I figured this one out.  I had added "Computer" to be displayed early but also had left it at the end.  When it is listed twice, you display "initializing" for every data element as shown below.  As soon as I changed the second instance to "HIDE" it worked fine. 

I added this to the to-do list, check for double entries.

[John C]

More than anything else, I really am hoping next beta will include ability to call external script when rule is triggered so that I will be able to automate reboots.  That's my number 1 need in terms of actions off the rules.

One more thought... while designing, it might be nice to consider eventual support for 2 actions from the same trigger.  I can envision instances where I would want to kill the task and then reboot the machine.  I'm thinking that's likely not especially difficult as long as you plan for it from the start.

Thanks.

2 identical rules would do this, one with a suspends a tasks and one that starts a bat file. I don't want to add a kill, too dangerous for the moment and a bit permanent.

I suppose it depends on how you evaluate the rules. Rules can't be applied to suspended tasks or else they will fire off repeatedly against the task that was suspended.  Rules really only make sense against active tasks.  So, if the first rule is the suspend rule, then the second rule wouldn't fire unless you cache the state and run through all rules against the cached rather than the actual state.  Likewise if the first rule caused the reboot, then potentially the program wouldn't receive the instruction to suspend (unless someone build a slight delay into the batch file that triggered the reboot).

Anyway, using 2 rules is possible, it just creates a little more complexity.  I've already been thinking though that the same multi-rule approach could be used if we don't have batch parameters.  A different rule would just need to be setup for each server with each triggering a different batch file that was specific to that server.

As for kill (technically task abort), I'd prefer to have it.  The goal of this is to have automation and suspend just time-shifts the clean-up rather than truly automating it.  Suspend is the smart way to go initially as the user test his or her rules, but after they are tested it would be better to be able to convert to an abort - better for the user and better for the projects so that they would be notified of the abort and didn't have to wait for those suspended jobs to time out by users who got lazy and just allowed the deadlines to take care of their cleanup for them.  Of course, all of this impacts the "use 2 rules" approach and potentially further complicates that.  For my needs, I'll just put a delay in the reboot script and that will solve my known need.  I'm just wondering about the 2 rule scenario that we haven't yet considered because surely there are some.

Good stuff.  Thanks again for all you are doing on this.

[fred]

More than anything else, I really am hoping next beta will include ability to call external script when rule is triggered so that I will be able to automate reboots.  That's my number 1 need in terms of actions off the rules.

One more thought... while designing, it might be nice to consider eventual support for 2 actions from the same trigger.  I can envision instances where I would want to kill the task and then reboot the machine.  I'm thinking that's likely not especially difficult as long as you plan for it from the start.

Thanks.

2 identical rules would do this, one with a suspends a tasks and one that starts a bat file. I don't want to add a kill, too dangerous for the moment and a bit permanent.

I suppose it depends on how you evaluate the rules. Rules can't be applied to suspended tasks or else they will fire off repeatedly against the task that was suspended.  Rules really only make sense against active tasks.  So, if the first rule is the suspend rule, then the second rule wouldn't fire unless you cache the state and run through all rules against the cached rather than the actual state.  Likewise if the first rule caused the reboot, then potentially the program wouldn't receive the instruction to suspend (unless someone build a slight delay into the batch file that triggered the reboot).

Anyway, using 2 rules is possible, it just creates a little more complexity.  I've already been thinking though that the same multi-rule approach could be used if we don't have batch parameters.  A different rule would just need to be setup for each server with each triggering a different batch file that was specific to that server.

As for kill (technically task abort), I'd prefer to have it.  The goal of this is to have automation and suspend just time-shifts the clean-up rather than truly automating it.  Suspend is the smart way to go initially as the user test his or her rules, but after they are tested it would be better to be able to convert to an abort - better for the user and better for the projects so that they would be notified of the abort and didn't have to wait for those suspended jobs to time out by users who got lazy and just allowed the deadlines to take care of their cleanup for them.  Of course, all of this impacts the "use 2 rules" approach and potentially further complicates that.  For my needs, I'll just put a delay in the reboot script and that will solve my known need.  I'm just wondering about the 2 rule scenario that we haven't yet considered because surely there are some.

Good stuff.  Thanks again for all you are doing on this.

Rules are only applied on running tasks. But they are captured at the same time. So they will execute at the same time (sequentially but close).

Probably later I will include the abort for advanced users. Because this is potentially very dangerous, you could delete all tasks with a wrong rule.
And there are always things we didn't consider in advance.

And to be sure, every rule has it's own event and can start it's own external program, you don't need the parameters, only if you want to know the exact cause of the rule.

[fred]

I will add  the possibility of 1 internal and 1 external event. So starting a program and suspending a task.

[John C]

I will add  the possibility of 1 internal and 1 external event. So starting a program and suspending a task.

Like it.  Thanks.

[jjwhalen]

- Fixed: History: Should be fixed, but it wasn't: Einstein@Home/3.02 Global Correlations S5 search #1 (S5GCESSE2) still showed as GPU task.

Solved in 0.60 hopefully. 

OK, entries already in History are now displaying correctly   I've reattached 1 host to Einstein and will test with a new (S5GCESSE2) task also.

1) Confirming that newly completed (S5GCESSE2) WUs are displaying correctly in History; this issue looks to be resolved
2) I'm following the discussion in this thread of the first implementation of Rules.  I agree with John C that the new functionality is very promising

[idahofisherman]

Love the new rules area.

I have a problem with the minute field (Middle field) of the timer field.  What ever I place in the second field ends up in the third field.  Therefore I am  unable to specify minutes.

[fred]

Love the new rules area.

I have a problem with the minute field (Middle field) of the timer field.  What ever I place in the second field ends up in the third field.  Therefore I am  unable to specify minutes.

A problem that I can't reproduce for some reason.
Try something like 0d,00:30:00 or 30:00

[jjwhalen]

Love the new rules area.

I have a problem with the minute field (Middle field) of the timer field.  What ever I place in the second field ends up in the third field.  Therefore I am  unable to specify minutes.

A problem that I can't reproduce for some reason.
Try something like 0d,00:30:00 or 30:00

I also am not seeing this problem, either in the Time or the Value field of the Rule Editor dialog

[Corsair]

Love the new rules area.

I have a problem with the minute field (Middle field) of the timer field.  What ever I place in the second field ends up in the third field.  Therefore I am  unable to specify minutes.

the same happens to me too, any value inserted in "minutes" appears in the "seconds" field and as you state I've tried:
xd,xx:xx:00
xx:00
xx:xx:00.

that's what I posted in the initial message.

[John C]

Love the new rules area.

I have a problem with the minute field (Middle field) of the timer field.  What ever I place in the second field ends up in the third field.  Therefore I am  unable to specify minutes.

A problem that I can't reproduce for some reason.
Try something like 0d,00:30:00 or 30:00

I also am not seeing this problem, either in the Time or the Value field of the Rule Editor dialog

Odd.  Like you (but unlike the others) I am not having this problem.  For whatever it is worth, I am running Win 7 x64 bit.

[fred]

Love the new rules area.

I have a problem with the minute field (Middle field) of the timer field.  What ever I place in the second field ends up in the third field.  Therefore I am  unable to specify minutes.

A problem that I can't reproduce for some reason.
Try something like 0d,00:30:00 or 30:00

I also am not seeing this problem, either in the Time or the Value field of the Rule Editor dialog

Odd.  Like you (but unlike the others) I am not having this problem.  For whatever it is worth, I am running Win 7 x64 bit.

Yep found something, X64 fine X32 problem.
Something with data types no doubt, should be easy to find now I can reproduce it.

[fred]

Yep found something, X64 fine X32 problem.
Something with data types no doubt, should be easy to find now I can reproduce it.

The problem was in the output, so the number entered in the rule is correct.
It's only shown incorrect.
Not sure why though.. I used __int64, changed that into int and that works fine. The Format function doesn't seem to like 64 integers on a 32 bit system.

[wicked]

1 - after exit from BT, size and position of the window when restarted BT not saved.

1 - Works with me, use File -> exit to store these settings.

This has never worked for me..  not even using File -> Exit that I tried. BoincTasks always starts with default size and on my primary monitor. Could it be that it gets confused because I always place it on my second monitor? This is also on Win 7 x64, which may be relevant..

[fred]

1 - after exit from BT, size and position of the window when restarted BT not saved.

1 - Works with me, use File -> exit to store these settings.

This has never worked for me..  not even using File -> Exit that I tried. BoincTasks always starts with default size and on my primary monitor. Could it be that it gets confused because I always place it on my second monitor? This is also on Win 7 x64, which may be relevant..

Don't know why, I've seen it myself, something between versions.
I use a second monitor as well and haven't seen any problems.
And.... Windows treats the whole screen, of the 2 monitors as one virtual screen, so the program doesn't see the difference.