In case anyone did not see [URL="https://www.mersenneforum.org/showthread.php?t=27648"]this thread[/URL], @Prime95 updated the PrimeNet API to return 1.3 instead of 2 for the [C]ll_tests_saved_if_factor_found[/C] parameter of P-1 assignments. This unfortunately broke our PrimeNet script, as it uses a regular expression to parse the assignment lines, which was expecting an integer. However, I just pushed a simple update to fix it. See [URL="https://github.com/tdulcet/Distributed-Computing-Scripts/commit/606956261ba97573ea280f6c3d86a977c5a06002#diff-1557cc1ac12b10f59513e25db23a4c33b47f9348943ab2f4ead78b46282c54c4"]here[/URL] for the full changes.

Anyone who is using our PrimeNet script to get P-1 assignments (worktype 4) will need to update as soon as possible. The PrimeNet script ignores lines in the worktodo file that it cannot parse, so this issue will cause it to get a new assignment for every run/worker every 6 hours by default...

Linux users could just run this from their [C]mlucas_v20.1.1[/C] directory to update:
[CODE]killall python3
rm primenet.py
wget https://raw.github.com/tdulcet/Distributed-Computing-Scripts/master/primenet.py -nv[/CODE]@ewmayer - This may cause problems for Mlucas as well, as from looking at your code, it is expecting an unsigned integer.

Indeed. Only 3 tests_saved values are supported; 0, 1, 2.
In Mlucas.c, dated 2021-10-18, starting line 561, following fragment assumes the PRP worktodo line will contain tests_saved value 0, 1, or 2 only;
[CODE] tests_saved = strtoul(++char_addr, (char**)NULL, 10);
if(tests_saved > 2) {
sprintf(cbuf, "ERROR: the specified tests_saved field [%u] should be 0,1 or 2!\n",tests_saved); fprintf(stderr,"%s",cbuf);
[/CODE]line 377, types as uint32 and initializes, tests_saved = 0

starting line 580, splitting nonzero tests_saved assignment to separate P-1 and PRP will fail because it assumes tests_saved occupies a single character, not 3 as in "1.3" or "0.9" or "1.1" or 4 as in "1.05";
[CODE] // Copy up to the final (tests_saved) char of the assignment into cstr and append tests_saved = 0;
// A properly formatted tests_saved field is 1 char wide and begins at the current value of char_addr:
i = char_addr - in_line; strncpy(cstr,in_line, i); cstr[i] = '0'; cstr[i+1] = '\0';
// Append the rest of the original assignment. If original lacked a linefeed, add one to the edited copy:
strcat(cstr,in_line + (i + 1));
if(cstr[strlen(cstr)-1] != '\n') {
strcat(cstr,"\n");
}[/CODE]

@tdulcet: I saw the thread in question and had a look at what happens with such fractional-test-saved assignment. Long story short - there should be no problem for Mlucas users.

Step-through debug of George's example Pfactor assignment did, however, turn up a bug in the parsing code for that assignment type, which leads to nonsense values for the TF_BITS and tests_saved variables. For instance for the example assignment
[i]
PFactor=9A0F34B929B282C41C75682C9496D92B,1,2,109343671,-1,76,1.3
[/i]
after the k,b,n,c data quartet - '1,2,109343671,-1' here - used to encode the modulus as k*b^n+c is (correctly) processed, instead of the char* used as a placeholder for where-to-resume-parsing advancing to the ',76', it gets reset to the '=9A0F...'. That results in both TF_BITS and tests_saved getting assigned the largest parseable decimal-int following the '=', which is 9 in this case. Again not an issue since the ensuing p-1 bounds-setting currently ignores those values, but fixed in my dev-branch version of the code, obviously.

I also tried swapping the leading '9' in the above AID from the left to right end, yielding A0F34B929B282C41C75682C9496D92B9, to see what happens when the first char after the '=' is not a decimal integer, that causes TF_BITS and tests_saved to retain their default init values of 0, again not a problem.

Ken's code-snips which check that tests_saved <= 2 are for PRP-assignment parsing, which are not being changed to support such fractional values, at least as yet. But just to see what would happen with the current v20.1.1 release were such to occur, I modified the assignment type in the above example from PFactor to PRP:
[i]
PRP=A0F34B929B282C41C75682C9496D92B9,1,2,109343671,-1,76,1.3
[/i]
The parsing code again ignored the '.3' fractional part, yielding tests_saved = 1 and the original assignment was overwritten by the following split form:
[i]
Pminus1=A0F34B929B282C41C75682C9496D92B9,1,2,109343671,-1,1200000,0
PRP=A0F34B929B282C41C75682C9496D92B9,1,2,109343671,-1,76,0.3
[/i]
That is still potentially problematic, since the split-off PRP assignment gets set not to the intended 0, but to 0 followed by the unmodified .3 fraction from the original 1.3. But, once the p-1 assignment completes, assuming no factor is found, we move on the PRP assignment, and now the same parsing code again ignores the .3, yielding tests_saved = 0 and proceeding to the PRP test. For PRP assignments, the only problematic tests_saved values would be ones >= 3, with or without a nonzero fractional part.

If anyone does encounter any crash or untowardness-in-practice resulting from such fractional test-saved values, please post details here, as usual.

Small patch uploaded - The bug only manifests for users doing PRP tests and who have set CheckInterval = 1000, the minimal allowable value, in their mlucas.ini file. (Such a low value is not generally recommended since on all but the slowest systems it wastes 1-2% runtime doing excessively frequent savefile writes.)

As always, post #1 in this thread has updated MD5 value for the release tarball, and the README linked there has details about the issue addressed.

Hey, I just finished a PRP on 113091931. For whatever reason, my primenet.py has stopped working so I have had to upload the result manually. Do I need to upload a proof file anywhere? Sorry if I am mistaken somehow.

[QUOTE=christian_;602818]Do I need to upload a proof file anywhere?[/QUOTE]Mlucas proof file generation has not been released yet, AFAIK, so, no, not if it was an Mlucas PRP result. A PRPDC will be necessary someday.

Small patch which fixes an infrequent (but run-killing when it occurs) issue with multithreaded runs of p-1 stage 2.

As always, post #1 in this thread has updated MD5 value for the release tarball, and the README linked there has details about the issue addressed, and download links.

[QUOTE=ewmayer;592258]Those of you using tdulcet's mlucas.sh install script will want to grab the [URL="https://github.com/tdulcet/Distributed-Computing-Scripts/blob/master/mlucas.sh"]latest version[/URL], but check the SUM-field value and if it differs from the one (8d8851f5e383d8a74cf067192474256a) for the current-download of v20.1.1, manually change it to the md5 checksum listed for the latter at the README.[/QUOTE]

I just pushed the new md5sum to my repository. See [URL="https://github.com/tdulcet/Distributed-Computing-Scripts/commit/f33127b5b5496bd1e4a6217692439ad97cf5f60e"]here[/URL] for the change.

[QUOTE=christian_;602818]Hey, I just finished a PRP on [M]113091931[/M].[/QUOTE]Result was confirmed via gpuowl PRP DC & proof gen & CERT.