[QUOTE=kracker;302635]It's a bat script... (only windows)... and the script is rough.... give me...a...few... :help::unsure:

:missingteeth:

How many "workers" should I make it support? (max)[/QUOTE]
It should be possible to write the whole thing in perl, avoiding the use of bat scripts altogether. I've given it a go. Do you want me to post what I've managed so far?

[QUOTE=mognuts;307739]It should be possible to write the whole thing in perl, avoiding the use of bat scripts altogether. I've given it a go. Do you want me to post what I've managed so far?[/QUOTE]

Sure! :smile:

I second that ;)

Consolidation of worker results for submit_spider
 

[COLOR=black][FONT=Verdana]Here goes ...[/FONT][/COLOR]

[COLOR=black][FONT=Verdana]I've managed to cobble together some code that appears to do the job on my computer (Windows 7 64bit/ActivePerl/mfaktc).[/FONT][/COLOR]

[COLOR=black][FONT=Verdana]Please note that since I started writing this, (all of 5 days ago), PrimeNet no longer gives inflated credit for factors found when submitted manually, so the variable [/FONT][/COLOR][COLOR=black][FONT=Verdana]$RemFact needs to be set at 0, unless you fancy having a play.[/FONT][/COLOR]

[COLOR=black][FONT=Verdana]It was written assuming that multiple instances of mfakt* are run in subdirectories/folders and not in the same directory/folder as the script itself. It should still work, however not much in the way of results consolidation will be going on.[/FONT][/COLOR]

[COLOR=black][FONT=Verdana]The usual rules apply. No guarantees, for research purposes only, I can't safeguard against data loss, and if I've upset anybody for any reason whatsoever then I'm very very sorry etc.[/FONT][/COLOR]

mognuts

Consolidation of worker results for submit_spider
 

I've modified the code to make it a little more robust and added a couple of extra features. I've also removed the typos that crept in the previous version.

If anybody wants to try this and evaulate it then I'll be very greatful.

mog

I found a bug in the script. If you have mfakt* (mfaktc at least; I'd guess mfakto has this option as well) set to include the UID prefix using the V5UserID and ComputerID options, the regex used to detect results no longer finds a match, since it only looks at the start of the line:
[CODE] if ($Line =~ /^no factor for (M\d*)/ || $Line =~ /^(M\d*) has a factor/
|| $Line =~ /^(M\d*) no factor from/) {[/CODE]
I was able to fix this for me by removing the ^, thus allowing the string to be found anywhere in the line:
[CODE] if ($Line =~ /no factor for (M\d*)/ || $Line =~ /(M\d*) has a factor/
|| $Line =~ /(M\d*) no factor from/) {[/CODE]
As long as this won't break anything else, feel free to include this in the next release of the script. :smile:

[QUOTE=Mini-Geek;323558]I found a bug in the script.

[snip]

As long as this won't break anything else, feel free to include this in the next release of the script. :smile:[/QUOTE]

Thanks!

The script was written before there was an option for a UN/CN to be included in the results.

And I'm long overdue to release my Fetching/Submitting spider, which subsumes the previous code. But I'll be sure to take this into account (with appropriate credit, of course... :smile:).

What is the status of the spider?

[url]http://www.gpu72.com/spider/[/url]

Does it still have issues with returning factors?

Thanks!

:mike:

[QUOTE=Xyzzy;365890]Does it still have issues with returning factors?[/QUOTE]

Only when Primenet isn't accepting them; it is at the moment.

Unfortunately the Spider was a quick and dirty hack (not nearly as sophisticated as MISFIT), and doesn't handle failed communications very well. In the case of an error, it simply renames the file as "not_completely_submitted_${Now}.txt".

What I do is every few days check the directory mfaktc and the spider are running in, and if I see any such files execute the command "cat not_completely_submitted_* >> results.txt; rm not_completely_submitted_*".

What happens if work is reported "out of order"?

Example: Say you are trial factoring from 71 to 74, and when the spider tries to communicate that 71-72 is done, it fails, and then a while later it reports, successfully, that 72-73 and 73-74 is done. Later you want to report the 71-72 part. What happens?

[QUOTE=Xyzzy;365936]Example: Say you are trial factoring from 71 to 74, and when the spider tries to communicate that 71-72 is done, it fails, and then a while later it reports, successfully, that 72-73 and 73-74 is done. Later you want to report the 71-72 part. What happens?[/QUOTE]

Excellent point!

Although I have never encountered this myself, in such a case additional human interaction is required, since a "not required" message from Primenet is not considered a communications error and so the results.txt file is not moved to "not_completely_submitted_${now}.txt".

The commands:

[code]cat not_completely_submitted_* > temp.txt
grep [EXPONENT_IN_QUESTION] sent/*.txt >> temp.txt
sort temp.txt >> results.txt
rm not_completely_submitted_* temp.txt[/CODE]

Should work.