[quote=rlangley;205216]If you have root access on this RHEL 5 machine, you might try to do a stock "./configure; make; make test; make install" of python 2.6 from source, which would install python 2.6 into /usr/local.

I don't believe (but cannot guarantee) that it would have any negative effect on other parts of your system which depend on /usr/bin/python.[/quote]
Well, I went ahead and did the install step for mine, since this is an experimental CD/USB project anyway, and the new python became the default one; probably because you have to do it as root (or superuser). This was not intended and probably wouldn't be acceptable for the Red Hat machine.

BTW, I tried the freeze procedure and that failed as well, although it at least seemed to try, now that 2.6 is installed. It came back with missing module messages and then an error during the make.

My current thoughts on the best non-invasive method is to compile the 2.6 version without intalling and let that (or more accurately, its complete directory) reside in the same directory as the factmsieve.py script. I will be pursuing something similar for my CD/USB project. However, at ~100MB, I'd like to find out what I can trim out.

As to wine, well then you may have to install that, and how much overhead comes with it? The addition of a configuration file would probably be trivial, but it would be some added work with each upgrade, since every new version would have to include another change to those lines in the new script (which could be done by a conversion script), and then a new compiling run. And, all this would have to be done by someone who really doesn't need it for themselves, since the person with the ability to compile, etc. already has all the applications to work with the original.

I suppose in the "bigger picture" a one-time run that nets a working version for someone with a limited OS, would allow them to at least work with that script, even it was dated.

Take Care,
Ed

[QUOTE=Mini-Geek;205233]Couldn't they just use Wine?
But then there's still the problem of the config values, that EdH just mentioned.[/QUOTE]The Perl script works just fine on my Linux box. Not tried it on a Windows installation but Brian appears to be the only one reporting problems. Maybe I'll give it a whirl.

Paul

I'm not sure if you are still gathering data for MINRELS but using the latest version it seemed to greatly underestimate a C127:

Factor base limits: 6100000/6100000
Large primes per side: 3
Large prime bits: 28/28

Wed Feb 10 08:12:39 2010 Found 18994963 relations, [B]151.7%[/B] of the estimated minimum (12518750).

That was the last run before the post-processing succeeded.

Jeff.

[QUOTE=Jeff Gilchrist;205267]I'm not sure if you are still gathering data for MINRELS but using the latest version it seemed to greatly underestimate a C127:

Factor base limits: 6100000/6100000
Large primes per side: 3
Large prime bits: 28/28

Wed Feb 10 08:12:39 2010 Found 18994963 relations, [B]151.7%[/B] of the estimated minimum (12518750).

That was the last run before the post-processing succeeded.

Jeff.[/QUOTE]

lpb 28 for a c127 seems quite high.

Try 27, or as newly stated in the [URL="http://www.mersenneforum.org/showthread.php?t=11615&page=8"]alq4788-thread[/URL], even 26. (scroll down to post #775 and the following ones.)

Lots of people who have problems with the Perl script on WIndows do so because it relies on a number of *nix tools that do not normally exist in a native Windows environment (grep, nice, ...). It hence requires either cygwin or quite an effort to acquire several *nix tools for native Windows. In contrast the Python script is entirely self contained on Windows so it works pretty well 'out of the box'. Apaart from personal interest and a desire drop Perl, this was a significant motivation for the development of my Python version.

Brian

The script has only been modified for new minrels estimates for lpbr/a values of 25, 26 and 27. I did not have enough valuess for 28 up to obtain reliable estimates. So, yes, we do need values for lpbr/a 28 and above and an assessment of the the effectiveness of the values for 25, 26 and 27

Brian

[QUOTE=Brian Gladman;205322]Lots of people who have problems with the Perl script on WIndows do so because it relies on a number of *nix tools that do not normally exist in a native Windows environment (grep, nice, ...). It hence requires either cygwin or quite an effort to acquire several *nix tools for native Windows. In contrast the Python script is entirely self contained on Windows so it works pretty well 'out of the box'. Apaart from personal interest and a desire drop Perl, this was a significant motivation for the development of my Python version.

Brian[/QUOTE]I don't doubt that people have problems with it. My statement was that you were the only one I'd heard complaining about it.

There's no good reason I can see why it needs grep at all. There must be a portable Perl module which sets process priority in a portable manner. I'll look into it. Writing portable Perl is pretty straightfoward in my experience.

My experience is that Python does not work pretty well out of the box, except on my WinXP installation. Perhaps the best approach would be for the Perl script and your Python script be developed in tandem so that either can be used where appropriate.

Paul

[quote=xilman;205327]I don't doubt that people have problems with it. My statement was that you were the only one I'd heard complaining about it.[/quote]
And I don't doubt that. But a lot of people know that I work on Windows and I have had quite a lot of emails about the various failings of this script.

[quote]There's no good reason I can see why it needs grep at all. There must be a portable Perl module which sets process priority in a portable manner. I'll look into it. Writing portable Perl is pretty straightfoward in my experience.[/quote]
Maybe - but it DOES use these tools. And it also requires external support from Perl modules for large integer arithmetic that many users did not have loaded. Moreover, the script has been little changed in years and nobody has done anything about these issues. And I am very confident that nobody would even be thinking about any of this had I not actually done something about it.

[quote]My experience is that Python does not work pretty well out of the box, except on my WinXP installation.[/quote]

I have had no problems at all with Python on Windows but it is clear from what people have said here that Linux is years behind Windows in respect of Python (2.4 is ancient in Python terms).

I could say a lot about Perl but in the interests of avoiding a flame war, I will resist the temptation :smile:

[quote]Perhaps the best approach would be for the Perl script and your Python script be developed in tandem so that either can be used where appropriate.[/quote]

That depends on someone actively maintaining the Perl script. If someone does, I will be happy to keep the two scripts in reasonable alignment.

[message by mazuki deleted - please resubmit]

I'm among those whose computers are not running Python >= 2.6 (no such packages in my distro's repositories), so I'd also be interested in an updated Perl script.

[QUOTE=Andi47;205311]lpb 28 for a c127 seems quite high.

Try 27, or as newly stated in the [URL="http://www.mersenneforum.org/showthread.php?t=11615&page=8"]alq4788-thread[/URL], even 26. (scroll down to post #775 and the following ones.)[/QUOTE]

That was automatically selected when running factmsieve.py so maybe those parameters need tweaking as well.

Jeff.