Automatic Submission Spider for Workers...

[mognuts]

Originally Posted by kracker

It's a bat script... (only windows)... and the script is rough.... give me...a...few...



How many "workers" should I make it support? (max)

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?

[kracker]

Originally Posted by mognuts

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?

Sure!

[flashjh]

I second that ;)

[mognuts]

Here goes ...

I've managed to cobble together some code that appears to do the job on my computer (Windows 7 64bit/ActivePerl/mfaktc).

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 $RemFact needs to be set at 0, unless you fancy having a play.

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.

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.

mognuts

[mognuts]

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

[Mini-Geek]

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:

   if ($Line =~ /^no factor for (M\d*)/ || $Line =~ /^(M\d*) has a factor/ 
      || $Line =~ /^(M\d*) no factor from/) {

I was able to fix this for me by removing the ^, thus allowing the string to be found anywhere in the line:

   if ($Line =~ /no factor for (M\d*)/ || $Line =~ /(M\d*) has a factor/ 
      || $Line =~ /(M\d*) no factor from/) {

As long as this won't break anything else, feel free to include this in the next release of the script.

[chalsall]

Originally Posted by Mini-Geek

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.

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... ).

[Xyzzy]

What is the status of the spider?

http://www.gpu72.com/spider/

Does it still have issues with returning factors?

Thanks!

[chalsall]

Originally Posted by Xyzzy

Does it still have issues with returning factors?

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_*".

[Xyzzy]

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?

[chalsall]

Originally Posted by Xyzzy

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?

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:

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

Should work.