Golly 2.6 has been released

[Andrew]

Golly 2.6 is now available from SourceForge:

https://sourceforge.net/projects/golly/ ... golly-2.6/

This version fixes some important bugs, so it is highly recommended you upgrade. The changes are listed here:

http://golly.sourceforge.net/Help/changes.html

[Andrew]

We've had a report that the 64-bit Golly fails to start up on Windows 8 (8.1 to be precise). Can anybody here confirm or refute that?

[rowett]

Hi,
I can confirm that Golly 2.6 64bit version fails to start on Windows 8.1. Event Viewer shows the following error:

Faulting application name: Golly.exe, version: 0.0.0.0, time stamp: 0x52a52b9e
Faulting module name: Golly.exe, version: 0.0.0.0, time stamp: 0x52a52b9e
Exception code: 0xc0000005
Fault offset: 0x000000000017c0b2
Faulting process ID: 0x108c
Faulting application start time: 0x01cef7e3804255d6
Faulting application path: C:\Users\Chris\Downloads\golly-2.6-win\Golly.exe
Faulting module path: C:\Users\Chris\Downloads\golly-2.6-win\Golly.exe
Report ID: bdfb771a-63d6-11e3-80cf-bcaec576f1da
Faulting package full name:
Faulting package-relative application ID:

Best regards,
Chris

[Andrew]

I can confirm that Golly 2.6 64bit version fails to start on Windows 8.1.

Thanks for that. We've uploaded a new build (same name -- ie. golly-2.6-win64.zip) that seems to fix the problem so please give it a try.

[flipper77]

I'm using Windows 7, and there's a minor bug where anything assigned to the "." key won't be executed at all when I try to use it. Assigning the any action to a different key other than "." seems to works fine.

[rowett]

Yes the new version of Golly 2.6 64bit works for me on Windows 8.1.

Best regards,
Chris

[Andrew]

I'm using Windows 7, and there's a minor bug where anything assigned to the "." key won't be executed at all when I try to use it.

Yep, I see the same bug on my Win XP system. Very odd -- looks like some sort of wxWidgets bug. I've made a note to investigate the problem when I next work on Golly (which could be many months away, unless a more serious bug is discovered in the meantime). Thanks for the report.

[Sphenocorona]

On Windows 8 64-bt, Golly 2.6 crashes every time I try to change the current rule through the "Set Rule" dialog.

[Andrew]

On Windows 8 64-bt, Golly 2.6 crashes every time I try to change the current rule through the "Set Rule" dialog.

Does the crash occur before the dialog appears, or immediately after it appears, or when you select OK, or only when you do something specific while the dialog is open?

I don't have a Win 8 system and I don't see any problems with that dialog using 32-bit Golly on Win XP, so it will be hard for me to fix that bug. Until the bug is fixed you can use the following script as a (poor) replacement for the Set Rule dialog:

Code: Select all

import golly as g

def changerule(r):
    try:
        g.setrule(r)
        return         # success
    except:
        g.warn("Given rule ("+r+") is not valid in any algorithm!")

oldrule = g.getrule()
newrule = g.getstring("Enter the new rule:", oldrule, "Set Rule")
if len(newrule) == 0: g.exit()      # user hit Cancel
if newrule != oldrule: changerule(newrule)

[Sphenocorona]

Does the crash occur before the dialog appears, or immediately after it appears, or when you select OK, or only when you do something specific while the dialog is open?

It crashes before the dialog opens, but I get two messages saying that golly has crashed (presumably one for the main window and one for the set rule windows which failed to open)

[rokicki]

You say "64-bit Win8"; are you running a 64-bit version of Golly, or a 32-bit?
Can you try the other one and let us know if the same problem shows up?

Thanks!

-tom

[NickGotts]

This is not strictly about version 2.6, which I haven't yet downloaded, but about command-line use of bgolly, on a 64-bit windows 7 platform. I am running patterns where each power of 2 generally step takes longer than the last, as novelty keeps arising, so I just run them until the time taken is too long, or I need the machine to concentrate on something else! So for this purpose, I use the "-2" flag and a "-o" argument, and Golly creates a file for every power of 2 it reaches. But occasionally, the pattern "resolves", and Golly starts churning out large files at speed. If I combine the "-2" flag and "-o" argument with a "-m" argument as a backstop in case this happens, then the power-of-2 files don't get created. Is there away I can get the behaviour I want - i.e. files created for each power of 2 up to a limit (which I would set some way beyond where I expect Golly to run to if no resolution occurs), at which limit it halts?

[David]

I spotted another problem:
When I try using any python script on Golly, the following error message pops out:
"The Python library does not have this symbol: Py_initialize"

EDIT: this problem occurs whether I use 32bit or 64bit.

[David]

And I noticed that the problem that Golly 64bit fails to run in Windows 8/8.1 64bit has been occured in older versions of Golly too.

[Andrew]

"The Python library does not have this symbol: Py_initialize"

Which version of Python have you installed? Sounds like you might be using Python 3.x, but Golly will only work with Python 2.x (2.7 seems to be safest).

[David]

"The Python library does not have this symbol: Py_initialize"

Which version of Python have you installed? Sounds like you might be using Python 3.x, but Golly will only work with Python 2.x (2.7 seems to be safest).

I've installed 2.7.8.

[Andrew]

I've installed 2.7.8.

In your GollyPrefs file, what is the python_lib setting? It should be something like this:

python_lib=python27.dll

If it is, and you're getting an error about Py_Initialize then I can only think of 2 possible causes:

1. python27.dll is somehow corrupted. Try downloading Python 2.7 again and re-installing.

2. (More likely.) You are trying to use a 32-bit Python with a 64-bit Golly, or vice versa. The bit size of Golly and Python MUST match.

TIP: If you want to run both a 32-bit Golly and a 64-bit Golly on the one machine, put a copy of GollyPrefs in the same folder as Golly.exe and make sure the python_lib line points to the right .dll file for each. You'll probably need to specify the full paths to the .dll files for the 32-bit and 64-bit Python libs.

[David]

I've installed 2.7.8.

In your GollyPrefs file, what is the python_lib setting? It should be something like this:

python_lib=python27.dll

If it is, and you're getting an error about Py_Initialize then I can only think of 2 possible causes:

1. python27.dll is somehow corrupted. Try downloading Python 2.7 again and re-installing.

2. (More likely.) You are trying to use a 32-bit Python with a 64-bit Golly, or vice versa. The bit size of Golly and Python MUST match.

TIP: If you want to run both a 32-bit Golly and a 64-bit Golly on the one machine, put a copy of GollyPrefs in the same folder as Golly.exe and make sure the python_lib line points to the right .dll file for each. You'll probably need to specify the full paths to the .dll files for the 32-bit and 64-bit Python libs.

Both Golly and Python are 32bit. And the problem isn't fixed after re-installation.

[Lewis]

When using the g.randfill(x) command, is there any chance of the grids generated repeating themselves after a large enough number of them have been generated at the same size and density?

In Winlife32 I generated a fairly large census in 2x2 a while back, and noticed that I'd get times where there'd be no new reported objects for a long time, and various objects that had been seen one time only previously would show up together again in the same order as they'd been spotted the first time. This was due to the fact that I'd kept the same density/grid size for a while and the random generator looped after however many million cells generated.

Now I've mostly moved on from Winlife32 in favour of Golly scripts, so I'm just checking that something like this won't happen again here. So far I've noticed a few odd goings-on (certain objects appearing a lot for certain edge lengths, then not appearing after I change it, etc.) but nothing that couldn't just be down to sheer fluke.

[apg]

I had a brief look at the source code, and Selection::RandomFill() uses the C++ rand() function. This is implementation-specific, although glibc's PRNG repeats with period 2^32. Hence, it doesn't surprise me if your results repeat themselves.

[Lewis]

I had a brief look at the source code, and Selection::RandomFill() uses the C++ rand() function. This is implementation-specific, although glibc's PRNG repeats with period 2^32. Hence, it doesn't surprise me if your results repeat themselves.

How far will randomising the density and grid size each game go towards preventing the results from repeating? Looking at the python documentation for the random.randint(a, b) function, it says that it repeats with period 2^19937 - 1, so even if the on/off cells generated by Golly are repeating over and over, the size of the board constantly changing might mean that the soups themselves are different. Will that work?

[Andrew]

If you think Golly's randfill command might be a problem, just write your own equivalent using Python's random.randint. The random-fill.py script at http://www.conwaylife.com/scripts/ should have everything you need.

[Lewis]

If you think Golly's randfill command might be a problem, just write your own equivalent using Python's random.randint. The random-fill.py script at http://www.conwaylife.com/scripts/ should have everything you need.

I think I've got it to work OK just by varying the size of the board generated. That way even when the cells generated start to repeat, the boards will still be different.

Also, running the script for a while turned up a small puffer in B35/S23 (posted in this thread), which I think is the first known infinite growth mechanism in this rule.

[Andrew]

On Windows 8 64-bt, Golly 2.6 crashes every time I try to change the current rule through the "Set Rule" dialog.

That bug has now been fixed. You need to download golly-2.7b2-win64.zip from here:

http://sourceforge.net/projects/golly/f ... golly-2.6/

Version 2.7b2 has very little functional difference to 2.6 (which is why we haven't bothered doing a full 2.7 release). Just wanted to get a fixed version out ASAP.