PRPNet 5.5 Released - Page 7

rogue · 2013-08-05, 01:59

I've considered modifying pfgw so that you could run one copy of the exe, but specify a directory where it would perform all other I/O. For example, "pfgw64 -D c1" would run pfgw64 from the current directory, but put pfgw.ini, pfgw.log, etc into the subdirectory c1. I don't think that would be too hard. Is that how the -w option works for llr?

mdettweiler · 2013-08-05, 05:43

Yes, that is how -w works on LLR. Actually, PFGW already can be run quite well as-is in a similar manner to that - you can do something similar to what I've been doing with my PRPnet clients, where you have one copy of PFGW, but cd into another directory and launch PFGW with an appropriate path (either an absolute path, such as "/usr/local/bin/pfgw", or a relative path such as "../pfgw"). That will keep all the files for this run in the directory your terminal window is in when you start it, and you can do this simultaneously for multiple instances (started from separate directories of course) from one exe. It's basically the same way you can run multiple copies of, say, Firefox on a multi-user system - everyone's accessing the same binary in Program Files or wherever, but each of their instances are reading and writing to a separate profile record somewhere under their home directory.

Interestingly enough, it's LLR that has a problem with this on Linux due to the issue I've been describing in the last few posts--it does this fine on Windows, but on Linux it always reads/writes to the directory where the LLR binary is stored (unless overridden with -w), instead of the current working directory where it should. PFGW has worked fine when I've done this on both Windows and Linux, and I seem to recall Genefer and WWWW handling it as well on Windows (I haven't tried it with them on Linux). In general, most programs that read-write from the "current directory" can do this without any problems; LLR seems to be the exception in this regard.

Edit: I was just thinking, a good example of this is when you go into the right-click Properties menu for a shortcut in Windows. There's two boxes with properties you can edit: one for the path to the program you want to run (with command line arguments), and another for the working directory to run the program from. On Windows, the default is for this to be the directory the executable is in, which is why Windows programs traditionally saved log files and such under C:\Program Files\ProgramName\; this was the cause of a lot of troubles for legacy programs when Microsoft introduced UAC with Vista and made Program Files a "privileged-only write" folder. On Linux and Mac, which had a stricter user/superuser model from the start, programs traditionally started in the context of the user's home folder, and this is usually the default when you create a desktop shortcut in one of those operating systems. This is also why many Linux/Unix programs ported to Windows (such as GIMP) tend to junk up your C:\Users\me folder with random files, since it's seen as the home folder on Windows.

chris2be8 · 2013-08-05, 15:49

You could try putting a symlink to llr64's real location into the 1 and 2 dirs. That avoids having multiple copies of llr64 on the system (sooner or later one will be forgotten when you upgrade llr64). Or a hard link if that does not work. See the man page for ln for details.

I've not tested either option though.

Chris

mdettweiler · 2013-08-05, 18:59

Quote:

Originally Posted by chris2be8

You could try putting a symlink to llr64's real location into the 1 and 2 dirs. That avoids having multiple copies of llr64 on the system (sooner or later one will be forgotten when you upgrade llr64). Or a hard link if that does not work. See the man page for ln for details.

I've not tested either option though.

Chris

Hmm, right...I hadn't thought of that, though it should work. I think I'll try that...

rogue · 2013-09-04, 18:54

I have released 5.2.8.

Changes include:
all: Fixed a logging issue that prevented debug logging from working as intended.
client: Add support for OpenCL based genefer. It will be treated as an equivalent to the CUDA version of genefer.
server: Fix log issue where prpserver.log would sometimes duplicate a line written to it.
server: Ensure database transaction is using REPEATABLE READ option.
server: Check return codes when setting connection attributes in database.
server: Add support for OpenCL based genefer. It will be treated as if it is equivalent to the CUDA version of genefer.
server: Fixed an issue with loading Cullen-Woodall candidates that prevented loading of multiple bases.

The Cullen/Woodall change was supplied by one of my faithful users. I have not tested the OpenCL genefer change, but the other items have been tested.

You can d/l 5.2.8 from here.

mdettweiler · 2013-09-05, 03:06

Just as a heads-up - Avast antivirus is currently flagging the 5.2.8 release package as a virus. I've reported it to them as a false positive (with a brief description of the program's purpose and source - seeing as how the source code is included it should be pretty obvious that it's benign).

It seems that it's catching on the prpadmin.exe program - it's identifying it as "Threat: Win32:Evo-gen [Susp]". Given the "Suspicious" labeling, it's likely the heuristic detector being overly aggressive. The rest of the package (including both prpclient.exe and prpserver.exe) didn't cause any problems, so this shouldn't cause any trouble with the main distribution packages at PrimeGrid.

rogue · 2013-10-03, 23:02

I have put PRPNet into sourceforge. What is in sourceforge is version 5.3.0, which is stable, but I'm still testing. The following changes are in 5.3.0:

Cleaned up compiler warnings with sockets.
Use PRId64/PRIu64 where needed.
Convert to using the string datatype for most function parameters.
Added notifylowwork= option to the prpserver.ini. When set to a non-zero value, the server will send an e-mail once a day notifying the distribution list that the server is running low on work. This change triggered the refactoring of some server code, specifically the moving of logic from prpserver.cpp to helper classes specific to the server type.

When it is ready to release I will build executables and post them, but those of you with Visual Studio have the option to d/l and build on your own.

Cruelty · 2014-03-18, 22:19

Is there a chance to post here 5.3.0 executables?

pinhodecarlos · 2014-03-18, 22:45

Quote:

Originally Posted by Cruelty

Is there a chance to post here 5.3.0 executables?

http://www.bc-team.org/downloads.php?cat=7

rogue · 2014-05-03, 00:53

I have updated PRPNet to 5.3.1. Here are the changes:

prpclient:
Fix crash when processing wwww work units.
Fix issue where last character of LLR residue was truncated before it was reported.
Fix uninitialized variable in the client.

prpserver:
Fix an issue with length calculation of candidates.

brilong · 2014-05-14, 20:44

Quote:

Originally Posted by rogue

I have updated PRPNet to 5.3.1. Here are the changes:

prpclient:
Fix crash when processing wwww work units.
Fix issue where last character of LLR residue was truncated before it was reported.
Fix uninitialized variable in the client.

prpserver:
Fix an issue with length calculation of candidates.

Where are the official downloads for Linux 64-bit clients? I downloaded 5.3.0 from http://uwin.mine.nu/PRPNet/, but I don't see 5.3.1 available. I also looked at http://www.bc-team.org/downloads.php?cat=7.

Thanks for helping a newbie. :)

2013-08-05, 05:43	#68
mdettweiler A Sunny Moo Aug 2007 USA 6298₁₀ Posts	Yes, that is how -w works on LLR. Actually, PFGW already can be run quite well as-is in a similar manner to that - you can do something similar to what I've been doing with my PRPnet clients, where you have one copy of PFGW, but cd into another directory and launch PFGW with an appropriate path (either an absolute path, such as "/usr/local/bin/pfgw", or a relative path such as "../pfgw"). That will keep all the files for this run in the directory your terminal window is in when you start it, and you can do this simultaneously for multiple instances (started from separate directories of course) from one exe. It's basically the same way you can run multiple copies of, say, Firefox on a multi-user system - everyone's accessing the same binary in Program Files or wherever, but each of their instances are reading and writing to a separate profile record somewhere under their home directory. Interestingly enough, it's LLR that has a problem with this on Linux due to the issue I've been describing in the last few posts--it does this fine on Windows, but on Linux it always reads/writes to the directory where the LLR binary is stored (unless overridden with -w), instead of the current working directory where it should. PFGW has worked fine when I've done this on both Windows and Linux, and I seem to recall Genefer and WWWW handling it as well on Windows (I haven't tried it with them on Linux). In general, most programs that read-write from the "current directory" can do this without any problems; LLR seems to be the exception in this regard. Edit: I was just thinking, a good example of this is when you go into the right-click Properties menu for a shortcut in Windows. There's two boxes with properties you can edit: one for the path to the program you want to run (with command line arguments), and another for the working directory to run the program from. On Windows, the default is for this to be the directory the executable is in, which is why Windows programs traditionally saved log files and such under C:\Program Files\ProgramName\; this was the cause of a lot of troubles for legacy programs when Microsoft introduced UAC with Vista and made Program Files a "privileged-only write" folder. On Linux and Mac, which had a stricter user/superuser model from the start, programs traditionally started in the context of the user's home folder, and this is usually the default when you create a desktop shortcut in one of those operating systems. This is also why many Linux/Unix programs ported to Windows (such as GIMP) tend to junk up your C:\Users\me folder with random files, since it's seen as the home folder on Windows. Last fiddled with by mdettweiler on 2013-08-05 at 05:51

2013-10-03, 23:02	#73
rogue "Mark" Apr 2003 Between here and the 3×2,447 Posts	I have put PRPNet into sourceforge. What is in sourceforge is version 5.3.0, which is stable, but I'm still testing. The following changes are in 5.3.0: Cleaned up compiler warnings with sockets. Use PRId64/PRIu64 where needed. Convert to using the string datatype for most function parameters. Added notifylowwork= option to the prpserver.ini. When set to a non-zero value, the server will send an e-mail once a day notifying the distribution list that the server is running low on work. This change triggered the refactoring of some server code, specifically the moving of logic from prpserver.cpp to helper classes specific to the server type. When it is ready to release I will build executables and post them, but those of you with Visual Studio have the option to d/l and build on your own.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PRPNet 4.0.0 Released	rogue	Software	84	2011-11-16 21:20
PRPNet 4.0.1 Released	Joe O	Sierpinski/Riesel Base 5	1	2010-10-22 20:11
PRPNet 3.0.0 Released	rogue	Conjectures 'R Us	220	2010-10-12 20:48
PRPnet	mdettweiler	No Prime Left Behind	80	2010-02-09 21:31
PRPNet released!	rogue	Conjectures 'R Us	250	2009-12-27 21:29

2013-08-05, 01:59	#67
rogue "Mark" Apr 2003 Between here and the 7341₁₀ Posts	I've considered modifying pfgw so that you could run one copy of the exe, but specify a directory where it would perform all other I/O. For example, "pfgw64 -D c1" would run pfgw64 from the current directory, but put pfgw.ini, pfgw.log, etc into the subdirectory c1. I don't think that would be too hard. Is that how the -w option works for llr?

2013-08-05, 15:49	#69
chris2be8 Sep 2009 2⁵×7×11 Posts	You could try putting a symlink to llr64's real location into the 1 and 2 dirs. That avoids having multiple copies of llr64 on the system (sooner or later one will be forgotten when you upgrade llr64). Or a hard link if that does not work. See the man page for ln for details. I've not tested either option though. Chris

2013-09-04, 18:54	#71
rogue "Mark" Apr 2003 Between here and the 3·2,447 Posts	I have released 5.2.8. Changes include: all: Fixed a logging issue that prevented debug logging from working as intended. client: Add support for OpenCL based genefer. It will be treated as an equivalent to the CUDA version of genefer. server: Fix log issue where prpserver.log would sometimes duplicate a line written to it. server: Ensure database transaction is using REPEATABLE READ option. server: Check return codes when setting connection attributes in database. server: Add support for OpenCL based genefer. It will be treated as if it is equivalent to the CUDA version of genefer. server: Fixed an issue with loading Cullen-Woodall candidates that prevented loading of multiple bases. The Cullen/Woodall change was supplied by one of my faithful users. I have not tested the OpenCL genefer change, but the other items have been tested. You can d/l 5.2.8 from here.

2013-09-05, 03:06	#72
mdettweiler A Sunny Moo Aug 2007 USA 2·47·67 Posts	Just as a heads-up - Avast antivirus is currently flagging the 5.2.8 release package as a virus. I've reported it to them as a false positive (with a brief description of the program's purpose and source - seeing as how the source code is included it should be pretty obvious that it's benign). It seems that it's catching on the prpadmin.exe program - it's identifying it as "Threat: Win32:Evo-gen [Susp]". Given the "Suspicious" labeling, it's likely the heuristic detector being overly aggressive. The rest of the package (including both prpclient.exe and prpserver.exe) didn't cause any problems, so this shouldn't cause any trouble with the main distribution packages at PrimeGrid.

2014-03-18, 22:19	#74
Cruelty May 2005 2²×11×37 Posts	Is there a chance to post here 5.3.0 executables?

2014-05-03, 00:53	#76
rogue "Mark" Apr 2003 Between here and the 1110010101101₂ Posts	I have updated PRPNet to 5.3.1. Here are the changes: prpclient: Fix crash when processing wwww work units. Fix issue where last character of LLR residue was truncated before it was reported. Fix uninitialized variable in the client. prpserver: Fix an issue with length calculation of candidates.