PRPNet 3.0.0 Released

[rogue]

Originally Posted by mdettweiler

Thanks. BTW, if you remove the socket component of the message in 3.2.3, could you please make sure it goes exactly back to the 3.2.0-and-earlier format? That way I don't have to change my script again:

[2010-03-23 03:30:58 GMT] 2036*9^694880+1 received by Email: max@noprimeleftbehind.net  User: mdettweiler  Client: Quad Program: pfgw.exe  Residue: 6ED61A2F0D4852FF

Probably. I'll see what I can do.

[rogue]

Originally Posted by Mini-Geek

Windows XP SP3 (32-bit).
The requested files are attached.

I have the same system, but could not reproduce the problem.

Could you export your database and send it to me? Maybe one of the tables has a problem.

When the server stops, do you get any errors?

I typically run the server from the command prompt. How do you start it?

[Mini-Geek]

Originally Posted by rogue

I have the same system, but could not reproduce the problem.

Hm, that's odd.

Originally Posted by rogue

Could you export your database and send it to me? Maybe one of the tables has a problem.

Ok, I've emailed it to you.

Originally Posted by rogue

When the server stops, do you get any errors?

I typically run the server from the command prompt. How do you start it?

I use a shortcut that runs prpserver.exe directly. I did not see any errors when it stopped, but it triggered the Vis Studio JIT debugger (though without having built it myself, etc. I didn't bother trying to use the debugger on it).

Edit: I was making a new database to try to test on, and I got this error when running the create_tables.sql file included with 3.2.2:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near 'index
 ix_residue (CandidateName, Residue)
) ENGINE=InnoDB' at line 18

I'm not sure why it said "line 18", because the table that failed to be created wasn't UserStats, but CandidateTest. I noticed that it was caused by a missing ending comma at line 67. Fixing that lets all the tables be created correctly.
Note that this hasn't affected the bug we're discussing, because I updated my table using the UPDATE command you listed when you released 3.2.2.

[Mini-Geek]

Originally Posted by rogue

I have the same system, but could not reproduce the problem.

I attempted to reproduce the problem with a fresh database (and debug version of the server, ready to see what's wrong) and running the server from a new directory (same settings files, but on a different port) and could not reproduce the problem. ( for not knowing what the heck went wrong, for knowing that it probably isn't affecting anything except that one DB) It successfully added all of the candidates and calculated their decimal lengths.

These are the sort of commands I've been using to remove old bases from the DB (after exporting them to files, just in case). Is there anything wrong with them, specifically that might cause the sort of instability I'm seeing?

select * from candidate where b=177 into outfile 'base177-cd-out.txt';
select * from candidatetest where candidatename like '%*177^%' into outfile 'base177-cd-test-out.txt';
delete from candidatetest where candidatename like '%*177^%';
delete from candidate where b=177;

[rogue]

Originally Posted by Mini-Geek

I attempted to reproduce the problem with a fresh database (and debug version of the server, ready to see what's wrong) and running the server from a new directory (same settings files, but on a different port) and could not reproduce the problem. ( for not knowing what the heck went wrong, for knowing that it probably isn't affecting anything except that one DB) It successfully added all of the candidates and calculated their decimal lengths.

These are the sort of commands I've been using to remove old bases from the DB (after exporting them to files, just in case). Is there anything wrong with them, specifically that might cause the sort of instability I'm seeing?

select * from candidate where b=177 into outfile 'base177-cd-out.txt';
select * from candidatetest where candidatename like '%*177^%' into outfile 'base177-cd-test-out.txt';
delete from candidatetest where candidatename like '%*177^%';
delete from candidate where b=177;

I don't see anything wrong with your statements. I'll look at the export you sent and see if the problem lies there.

[henryzz]

I can't find a mention of a limit on size of k(or b, n or c for that matter). However i hit the limit while trying to add some very prime sequence candidates.
What is the limit currently and is it trivial to allow large very large ks? The k i tested was 6725754451964432990335077705(28 digits). I suspect that the limits are a long in prpserver, an int in the webpages, and a selfset limit of 20 digits in the database judging by the output and a look at the tablecreating script. There is not warning when the limit it reached.
This is low priority and possibly not worth sorting although the webpage probably needs to be the same as the program itself. If it is just a 10 minute job to fix then it would be worth it as it would save more than 10 minutes of others time not fiddling around with pfgw.

[rogue]

Originally Posted by henryzz

I can't find a mention of a limit on size of k(or b, n or c for that matter). However i hit the limit while trying to add some very prime sequence candidates.
What is the limit currently and is it trivial to allow large very large ks? The k i tested was 6725754451964432990335077705(28 digits). I suspect that the limits are a long in prpserver, an int in the webpages, and a selfset limit of 20 digits in the database judging by the output and a look at the tablecreating script. There is not warning when the limit it reached.
This is low priority and possibly not worth sorting although the webpage probably needs to be the same as the program itself. If it is just a 10 minute job to fix then it would be worth it as it would save more than 10 minutes of others time not fiddling around with pfgw.

Yes, there is a limit because some of the programs used by the client have limits for k. I could add some code to ensure that k is kept small.

[rogue]

Originally Posted by rogue

I don't see anything wrong with your statements. I'll look at the export you sent and see if the problem lies there.

It seems to be something with the optimization level Visual Studio is using. I had some problems connecting to the server with the default optimization. I modified the optimization settings and the problems went away. Although I couldn't reproduce your issue, I suspect that Visual Studio introduced the problem during optimization. I will use different settings for the next release.

If anyone else has problems with 3.2.2 servers that are inexplicable (odd crashes, inability to connect, etc.), let me know.

Correction to this post. Apparently my PC had to be rebooted due to a software update. After I rebooted, the release build worked correctly.

[henryzz]

Originally Posted by rogue

Yes, there is a limit because some of the programs used by the client have limits for k. I could add some code to ensure that k is kept small.

Maybe rather than adding limits you could just pass the numbers with too high ks to pfgw which will test virtually anything.

[rogue]

Originally Posted by henryzz

Maybe rather than adding limits you could just pass the numbers with too high ks to pfgw which will test virtually anything.

In theory that sounds simple, but in reality it isn't quite so simple. Both the client and server would be affected. I would have to create a new server type that supports generic forms. With a generic form I wouldn't parse k, b, n, or c from the candidate.

[Mini-Geek]

I made this mod to SierpinskiRieselHTML.cpp lines 124 and 125: (new code bold)

      theSocket->Send("<tr %s><td align=center  colspan=10>%d of %d have primes/PRPs (%d remaining)</tr>",
                      (kCount == primeCount ? "bgcolor=\"red\"" : ""),  primeCount, kCount, kCount-primeCount);

Just putting it here to see if you think it'd be a good permanent addition. (I know that it's only marginally useful for things like large Sierp/Riesel work, since the number of primes there are usually 0 or 1, but it's not at a high readability cost or anything; and if that was really a big problem, you could make it only appear when there are at least 5 primes, or something like that; it is useful for smaller work, where there are usually many k's and primes)

Originally Posted by rogue

If anyone else has problems with 3.2.2 servers that are inexplicable (odd crashes, inability to connect, etc.), let me know.

Sometimes the server will just stop working. I didn't have detailed logging at the time, so nothing significant appeared (I turned full logging on a while ago, but of course since then it's stopped doing it ), but here are the symptoms:
no clients can connect,
using Ctrl+C to try to end it prints the message saying it's trying to close, but it doesn't (at least not for how long I've waited).
Killing the process with Task Manager works, and when I start it again, it all works just fine.