[QUOTE=swl551;325391]Since I am adding Fetching directly into MISFIT here is how it will look.[/QUOTE]

Looks reasonable.

Just wondering though... What does the checkbox labeled "Replace placeholder with YYYY-MM-DD" do?

[QUOTE=chalsall;325392]Looks reasonable.

Just wondering though... What does the checkbox labeled "Replace placeholder with YYYY-MM-DD" do?[/QUOTE]

turns Factor=N/A,577757,68,69
into Factor=2013-01-21,577757,68,69

From GIMPS N/A is a GUID.

Usefull to people who fondle their assignments a lot: FLASHJH being a prime example!

[QUOTE=swl551;325393]Usefull to people who fondle their assignments a lot: FLASHJH being a prime example![/QUOTE]

Again, reasonable.

Dates given in YYYYMMDD order can be sorted using simple command-line programs. (I've never understood why almost everyone except geeks use any other, and almost every other possible, order.... :smile:)

VERSION 2.3.2
 

[QUOTE=swl551;325385]You should be seeing the non-blocking MISFIT alert panel when automation detects an error condition instead of a modal dialog box.

However a file-lock cleanup can be automated just by looking at the age of the lock file. If > 10 mins..... delete.[/QUOTE]



VERSION 2.3.2
1. Added code to release a lock from a file if the ".lck" file is > 15 mins old. This will prevent stale locks from hindering unattended operations.

****************

Still working hard on v 2.4 which puts full gpu72 fetching directly into MISFIT. Hopefully I'll be ready for beta testing by this weekend. The GPU72 fetch code is simple, refitting MISFIT to handle full configuration for two providers (GIMPS, GPU72) and streamlining the code-base is the complicated part.

[QUOTE=swl551;325385]You should be seeing the non-blocking MISFIT alert panel when automation detects an error condition instead of a modal dialog box.

However a file-lock cleanup can be automated just by looking at the age of the lock file. If > 10 mins..... delete.[/QUOTE]
I haven't been home much lately, but when something like a stalled instance occurs and I'm not there to fix it (or I don't log in and catch it), MISFIT doesn't run the fetch code nor does it distribute anything that was already there which causes all the work to run out.

I wish I could say nothing else will go wrong, but for now I'll just watch for another scenario and hopefully take some screen shots.

[QUOTE=swl551;325424]VERSION 2.3.2
1. Added code to release a lock from a file if the ".lck" file is > 15 mins old. This will prevent stale locks from hindering unattended operations.
[/QUOTE]Thanks.
[QUOTE=swl551;325388]Yes it is. Hardly anyone knows how to do Windows [B]command shell scripting[/B] anymore..... The old days are gone.[/QUOTE]
You'd love the one I put together to do what you coded for G72 fetching ;)

[QUOTE=flashjh;325426]I haven't been home much lately, but when something like a stalled instance occurs and I'm not there to fix it (or I don't log in and catch it), MISFIT doesn't run the fetch code nor does it distribute anything that was already there which causes all the work to run out.
[/QUOTE]

FLASHJH. I just did a code review to see if there is a blocking condition related to a stalled instance. There is not one. The inability to apply a lock is a blocking condition. So if a lock is applied and then a network error occurs and the lock is orphaned the next time a lock is requested there will be collision. So the 2.3.2 PURGE_STALE_LOCK will solve that.


Code snippet showing exactly how the main methods are called.
[CODE]
if (timer1UpdateStatsCounter >= globals.cfg.settingUpdateStatsInterval)
{
UpdateGridStats();
AssignWorkViaAutomation();
BalanceWorkViaAutomation();

}

[/CODE]

[QUOTE=flashjh;325426]
You'd love the one I put together to do what you coded for G72 fetching ;)[/QUOTE]

Same here. We are old school guys, and I believe the most of the members of this forum can handle very well some batch making thingies (*nix or win), or string processing toys like perl, etc. I personally do windoze stuff.
[ATTACH]9156[/ATTACH]

[QUOTE=LaurV;325432]Same here. We are old school guys, and I believe the most of the members of this forum can handle very well some batch making thingies (*nix or win), or string processing toys like perl, etc. I personally do windoze stuff.
[ATTACH]9156[/ATTACH][/QUOTE]

I'm hardly old school, and am proficient in *nix scripting... :razz:

[QUOTE=Dubslow;325433]I'm hardly old school, and am proficient in *nix scripting... :razz:[/QUOTE]

Stick near us kid. You'll do OK.... :wink:

[QUOTE=Dubslow;325433]I'm hardly old school, and am proficient in *nix scripting... :razz:[/QUOTE]


Chalsall's original assertion is that Windows user rely less on scripting than *nix users due to the Windows UI. I concur. In my old DOS days scripting was part of the job. IT departments could roll out entire Windows 3.x installations via scripting. Write menu systems like Laurv did and just about everything else. Today our IT department has to come to corporate development groups to show them how to use xcopy.

So scripting is good and no insult to anyone uses it.

[QUOTE=swl551;325435]Chalsall's original assertion is that Windows user rely less on scripting than *nix users due to the Windows UI.[/QUOTE]

That's not exactly what I asserted. But it's not too far off the mark.

Bill Gates et al got rich by enabling those who perhaps shouldn't be using computers to pretend to do so. Anyone else here find themselves employing someone who was using a spreadsheet as a desktop publishing program?

"Math class is tough!" -- Barbie