Golly bugs

[confocaloid]

I got the following steps, when trying to reproduce this:
...

Would you like to repeat this with 10^30?

No, I was just trying to get a specific way of reproducing the bug (i.e. specific generation, specific coordinates to add a cell, where exactly to look, etc.) Hopefully the above suffices for that purpose.

[pzq_alex]

* Turn "View -> Show Exact Numbers" on.
* Open the pattern via "Open Clipboard". The top-left cell should get coordinates (0,0).
* Use goto.lua to go to the generation 1000000000000000 (10^15).
* The displayed population is 1,042,324,103,587,982.
* Add a single state-1 cell at X = 56, Y = 43 (inside the tub).
* Now the displayed population is 1,042,324,158,506,313. (Addition of one cell changed the population by more than 1.)
* Press F to zoom out. Instead of the expected single diagonal line, there are two intersecting diagonal lines.

[/quote]

Using these steps I found that this is a bug with the Super algorithm, not with HashLife (Edit: I mean the HashLife algorithm, as in Control -> Set Algorithm -> HashLife). Exact steps to reproduce:

* Turn "View -> Show Exact Numbers" on (Ctrl-E).
* Open the pattern via "Open Clipboard".
* Press Alt-J to convert the pattern to two-state Life.
* Use goto.lua to go to generation 10^15.
* Observe that adding a cell or deleting one only changes the population by one. Also, pressing F shows that there is no extraneous diagonal line.

[rowett]

Using these steps I found that this is a bug with the Super algorithm, not with HashLife.

It's to do with HashLife. The RuleLoader version of LifeHistory also shows the same issue. Both RuleLoader and Super algos use HashLife.

[rokicki]

(is it a bug or it has to do with HashLife?) ...

This is my bug, and it's fixed in the repository. Thanks for the report, and I'm sorry for the error.

-tom

[Andrew]

It seems like underscores in filenames can trigger bugs.

Fixed for the next release. I've also fixed some problems (on all platforms) with filenames containing ampersands, so thanks for the report.

We've probably got enough changes and bug fixes to justify releasing Golly 4.3b1 some time in the next few weeks.

[muzik]

oscar.lua incorrectly concluded that "This pattern is stable." after 563939073 generations and several hours of running it:

Code: Select all

x = 54, y = 2, rule = MarBlocks-5-rep
o49bobo$bo48bo2bo!

[rowett]

oscar.lua incorrectly concluded that "This pattern is stable." after 563939073 generations and several hours of running it:

Code: Select all

x = 54, y = 2, rule = MarBlocks-5-rep
o49bobo$bo48bo2bo!

It's because the pattern in the previous generation hashes to the same value. The check for hash collisions fails since it only tests if the pattern is the same size, hasn't moved, and has the same population. All three of which are true in this rare case.

[confocaloid]

When trying to paste a RLE like

Code: Select all

boooooobobbob$bbooooooobobo$bobobboooobbb$bobobooobbobo$boobbboobbooo!

into Golly, the leftmost empty columns are ignored. (It is a 13x5 pattern that is incorrectly pasted as if it was a 12x5 pattern.)

In comparison, the same pattern formatted as

Code: Select all

x = 13, y = 5, rule = B3/S23
boooooobobbob$
bbooooooobobo$
bobobboooobbb$
bobobooobbobo$
boobbboobbooo!

is pasted correctly, with leftmost column empty.

(I noticed this when my program printed the single-line headerless RLE above, I tried to paste it into Golly to double-check and got evolution that did not match what my program claimed, because the pattern was pasted one cell left from the correct position.)

(Added later:) this also applies to empty rows, e.g.

Code: Select all

bbbbbbbbb$bbbbbobbb$bbobbbbbb$bbbobbbbb$bbbbobbob$bbbobbboo!

is 9x6 but it is pasted as if it was 7x5.

[iNoMed]

Golly 1.3 for iOS freezes when trying to overwrite an already-saved file (Even those created before the data transfer) with a newer copy. This issue started happening after I had transferred data from an iPad Pro 12.9" (2018) to an iPad Pro 12.9" (2022) and is possibly the main cause of this problem. This isn't an issue with saving files as a whole - the RLE shown in the image was created after the aforementioned data transfer.