PRPNet 4.0.0 Released

[rogue]

I have finally released PRPNet 4.0.0. Note that announcements for PRPNet are now in the Software forum instead of Conjectures 'R Us. This is a major upgrade from 3.x due to many changes in table structures in the database.

Here is a list of changes:

Changes to both client and server:

• Added support for Sophie/Germain prime searches.
• Fixed many compiler warnings on *nix.
• Stripped "<candidate> is a Factor of" from GFN divisors.

Changes to the client only:

• Much of this has been rewritten to support Sophie/Germain and other prime searches, such as Cunningham chains and Arithmethic Progressions (which has yet to be written). One result of this is that the client will log more messages for certain server types.
• Always check for GFN divisiblity when b = 2 and c = 1. This could happen for Twin and Sophie-Germain prime searches.
• Return version of helper program used by the client.
• Fixed an issue where the client would think that the server accepted a workunit when it didn't.
• Added support for usellroverpfgw setting from server. When set, the client will use LLR instead of PFGW for primality tests.

Changes to the server only:

• As part of the Sophie-Germain prime search, the server will now log additional messages for that server type.
• Fixed a stats issue with "Completed Thru" on the GFN server stats webpage.
• Reworked e-mail messages to be a little more readable.
• Added user_gfns.html webpage for GFN divisors by user.
• Added projectname= to prpserver.ini for the Prime Pages project name.
• Added usellroverpfgw= option to prpserver.ini.
• Modified sortoption= in prpserver.ini to provide maximum flexibility. Show if candidate was prime or PRP on user_primes.html.
• Significantly improved speed loading of Candidates via prpadmin.
• On Sierpinski/Riesel stats page, do not include k with a PRP/prime when determining the "Completed Thru" column.
• Added new columns for tracking the version the helper programs used by the client.

With the changes for this release, you will need to run the upgrade_3.3_to_3.4.sql script in the source directory to bring the database up to date. Because there are signficant changes in this release, it is HIGHLY recommend to do a backup before executing that script.

The 4.0 server is compatible with 3.x clients, except for Twin and GFN searches. The 3.x server is compatible with the 4.0 client.

Although I am highly confident in its stability for most server types, I have not spent as much time on some as I have on others. This is being released as an alpha, so I recommend that smaller projects work with it first to help me work out any bugs. Hopefully I can change this over to a beta in the next week or so.

You can d/l it from here.

[rogue]

I missed one line in the upgrade script. If you have upgraded, please execute this in mysql:

alter table UserPrimes add TestResult int default 1;

[rogue]

I am releasing PRPNet 4.0.1. This will address all known issues with 4.0.0. The changes are:

In the client: fixed an issue with handling primorials/factorials (introduced in 4.0.0).
In the server: Add time zone to date of mail so that time shows up in the correct time zone in mail in-boxes.
In the server: Populate new TestResult column on UserPrimes and fix SQL behind the view to use it.
In the server: Do not send e-mail if SMTP authentication needed and password not supplied.

Apparently some users have had difficulty upgrading to 4.0.0. As far as I can tell it is a problem with MySQL itself and only occurs on some versions of MySQL. As stated in the readme, I highly recommend backing up before doing the upgrade. If doing an upgrade, execute the upgrade script line by line, ensuring that no errors occurred and stopping when one is found so that it can be addressed before continuing.

You can d/l it from here.

[amphoria]

I have just finsihed upgrading a server from 3.3.6 to 4.0.1. The upgrade script ran without any errors.

prpadmin 3.3.6 inserted 0's into table Candidate, columns CompletedTest, HasPendingTest and DoubleChecked. prpadmin 4.0.1 no longer does this, but create_tables.sql sets these columns to a default value of 0. However, the upgrade script does not make these changes to the Candidate table.

[rogue]

Originally Posted by amphoria

I have just finsihed upgrading a server from 3.3.6 to 4.0.1. The upgrade script ran without any errors.

prpadmin 3.3.6 inserted 0's into table Candidate, columns CompletedTest, HasPendingTest and DoubleChecked. prpadmin 4.0.1 no longer does this, but create_tables.sql sets these columns to a default value of 0. However, the upgrade script does not make these changes to the Candidate table.

That should be okay, but I'll modify the upgrade script to change the column defaults to 0.

[amphoria]

Originally Posted by rogue

That should be okay, but I'll modify the upgrade script to change the column defaults to 0.

Unfortunately it wasn't as I got insert errors on every candidate. Initially I tried just allowing NULL values, but this caused the code in the server to assume that all the candidates I had just uploaded had already been tested.

[rogue]

I have fixed a number of bugs in 4.0.

Here is a list of changes:

Changes to the client only:

• Verify that INFO message from server is for the specific candidate before treating it as accepted by the server.
• Do not sent sub-workunits that have not had a test done.
• The client will remove a workunit from its list only if the server responds with an INFO message for that workunit.
• If the client gets an error when reporting a workunit to a server, it will close the socket and try again later rather than trying to send any additional workunits.
• Fix parsing of GFN factors as client excluded first character of string sent back to the server..

Changes to the server only:

• Fix problems with loading candidates for Sophie-Germain servers.
• On pending_tests.html, add CandidateName to the sorting.
• Fixed a memory leak when sending mail.
• Made a change to eliminate the "Error in my_thread_global_end(): 1 threads didn't exit" message from MySQL. In doing so, the server will always have at least one active connection to the MySQL server.
• Return "test accepted" message if the test has already been marked as completed. This can occur if the client didn't receive the INFO message the first time it sent the test and eliminates potential confusion that the test was rejected.

You can d/l it from here.

Although not included at this time, you can use these alter commands to modify the default values on the Candidate tables:

alter table Candidate modify CompletedTests int default 0 not null;
alter table Candidate modify HasPendingTest int default 0 not null;
alter table Candidate modify DoubleChecked int default 0 not null;

I have discovered a more insidious memory leak in the server. For a while I thought it was in my code, but none of the tools I have used have shown that to be the case. Apparently the problem lies somewhere in the MySQL library. It doesn't seem to like multi-threaded applications too much. I'm still investigating potential solutions, but am having little luck.

[Shaopu Lin]

When I used prpclient v4.0.2 to search for GFNs on 64-bit linux, there appeared following messages:

[2010-11-02 01:49:19 CST] PRPNet Client application v4.0.2 started
[2010-11-02 01:49:19 CST] User name acer at email address is sp65536@yahoo.com.tw
[2010-11-02 01:49:20 CST] a: Getting work from server prime2u.com at port 11001
[2010-11-02 01:49:22 CST] a: PRPNet server is version 3.3.0
gfn524288
[2010-11-02 01:49:22 CST] Total Time:  0:00:03  Total Tests: 0  Total PRPs Found: 0
[2010-11-02 01:49:23 CST] a: Returning work to server prime2u.com at port 11001
[2010-11-02 01:49:23 CST] a: INFO: Test for candidate 1186^524288+1 abandoned
[2010-11-02 01:49:24 CST] a: INFO: Test for 1186^524288+1 was accepted
[2010-11-02 01:49:24 CST] a: INFO: All 1 test results were accepted

Prpclient v4.0.2 can`t be used to search for GFNs but prpclient v3.3.5 can.

[rogue]

I fixed the aforementioned issue with GFN searches in the client.

You can d/l it from here.

[Shaopu Lin]

Originally Posted by rogue

I fixed the aforementioned issue with GFN searches in the client.

You can d/l it from here.

When I used prpclient v4.0.3 to search for GFNs, it worked fine.

[Mini-Geek]

There is a small problem in the create_tables.sql script. Because of the order that it drops tables, it leaves the Candidate and CandidateTest tables (at least, it did for me; there was information in the tables left over from a few CRUS projects with many primes found, if that makes a difference). This order seems to work correctly:

drop table CandidateTestResult;
drop table GeneferROE;
drop table CandidateGFNDivisor;
drop table CandidateGroupStats;
drop table UserStats;
drop table UserPrimes;
drop table CandidateTest;
drop table Candidate;