ConwayLife.com

Posted: **October 16th, 2017, 7:40 pm**

Golly 3.1 is now available from sourceforge:

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

Changes since 3.0:

- Fixed bugs in the Larger than Life algorithm that caused Golly to crash.

- Scripts can call g.setoption("showprogress",0) to prevent the progress dialog from appearing (useful for scripts that you want to run in the background).

- Updated the Life Lexicon to release 27.

Posted: **November 17th, 2017, 12:27 am**

There seem to be several bugs with unicode strings in Golly. I've only tested this with Golly 3.0 (on Win7 x64) but I don't believe any relevant code changed in 3.1. I believe all of the tests I've done have used UTF-8, but I'm not 100% certain of that.

The main issue for me is that g.getclipstr() returns an empty string when the text on the clipboard contains a unicode character. The behaviour is identical using Python and Lua. While investigating the issue I found the same thing happens with g.getstring(). Here's a simple way to reproduce:

Code: Select all

-- Test unicode strings

local g = golly()
local ustring = g.getstring("Enter string", "")
g.note(ustring)

Run this script in Golly and paste the following string in (from A for Awesome's signature)

A for Awesome wrote:x₁=ηx

The result is a blank Note window (same thing in Python).

Including unicode characters in a script (run from the clipboard) causes the language detection to fail:

Code: Select all

local g = golly()
g.note("x₁=ηx")

Run from the clipboard, this causes a Syntax error in the Python interpreter.

This sort of works when saved as a file:

Code: Select all

-- Test unicode strings
local g = golly()
g.note("x"..utf8.char(0x2081).."="..utf8.char(0x3B7).."x")
g.note("x₁=ηx")

both resulting Note windows contain

Code: Select all

xâ‚=Î·x

Trying to get at least something with UTF-8 to work in Python I found the following: (all run from clipboard)

Code: Select all

import golly as g
g.note(u"x₁=ηx")

gives a syntax error:

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\ariep\AppData\Roaming\Golly\golly_clip.py", line 2
SyntaxError: Non-ASCII character '\xe2' in file C:\Users\ariep\AppData\Roaming\Golly\golly_clip.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

... probably not surprising.

Code: Select all

# -*- coding: utf-8 -*-
import golly as g
g.note(u"x₁=ηx")

raises an exception

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\ariep\AppData\Roaming\Golly\golly_clip.py", line 3, in <module>
    g.note(u"xâ‚=Î·x")
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2081' in position 1: ordinal not in range(128)

Code: Select all

import golly as g
g.note(u"x\u2081=\u03B7x")

raises the same exception:

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\ariep\AppData\Roaming\Golly\golly_clip.py", line 2, in <module>
    g.note(u"x\u2081=\u03B7x")
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2081' in position 1: ordinal not in range(128)

Code: Select all

import golly as g
g.note(u"x\u2081=\u03B7x".encode('utf-8'))

and

Code: Select all

# -*- coding: utf-8 -*-
import golly as g
g.note(u"x₁=ηx".encode('utf-8'))

both give the same result as the corresponding lua script above

Code: Select all

xâ‚=Î·x

I readily admit that I have no idea what I'm doing here. To be honest - all I care about is g.getclipstr() giving me something, even if it doesn't preserve the unicode characters. The current behaviour breaks scripts like importRLE.py when there are some unicode characters interspersed amongst the rle patterns to be imported.

Posted: **January 1st, 2018, 3:57 am**

Enter this pattern (can be anything really):

Code: Select all

x = 3, y = 3, rule = B3/S23-a
2o$b2o$bo!

Add 3 to the rule string, run it, undo, and run it again.

Posted: **January 1st, 2018, 8:12 am**

danny wrote:Enter this pattern (can be anything really):
Code: Select all
x = 3, y = 3, rule = B3/S23-a
2o$b2o$bo!
Add 3 to the rule string, run it, undo, and run it again.

Thanks for reporting! The extra 3 is incorrectly overwriting the 3-a in the rule decoder. I'll fix it for the next release.

Posted: **January 6th, 2018, 5:43 am**

When will be the mobile version updated to include non-totalistic CA and LTL CA?

Posted: **January 6th, 2018, 10:09 am**

KittyTac wrote:When will be the mobile version updated to include non-totalistic CA and LTL CA?

It has been on iOS.

Posted: **January 6th, 2018, 10:25 am**

AforAmpere wrote:
KittyTac wrote:When will be the mobile version updated to include non-totalistic CA and LTL CA?
It has been on iOS.

I'm on Android. When will the Android version be updated?

Posted: **January 8th, 2018, 11:41 pm**

I noticed a bug that occurs when on cells have x-coordinates out of the range [-2^32, 2^32 - 1] or y-coordinates out of the range [-2^32 + 1, 2^32].

When one tries to add new cells, either by drawing or copy-pasting, to a canvas where the above conditions are fulfilled by at least one currently on cell, the new cells get placed 2^32*(2^n - 1) cells farther out in the x and y directions than their intended location, where n is the largest integer such that every cell has an x-coordinate in the range [-2^(32 + n), 2^(32 + n) - 1] or a y-coordinate in the range [-2^(32 + n) + 1, 2^(32 + n)].

The intended coordinates of the added cells are transformed into the resulting coordinates as follows:

If a coordinate is not zero, 2^32*(2^n - 1) is added to its absolute value and its sign is unchanged.
If an x-coordinate is zero, it becomes 2^32*(2^n - 1).
If a y-coordinate is zero, it becomes -2^32*(2^n - 1).

This bug does not affect any of the cells that were on before the placing of new cells. Also note how the bug causes every new cell to be misplaced, even when its coordinates are within the range [-2^32, 2^32].

The bug occurs in HashLife and RuleLoader, and probably every hashing algorithm.

Also, I still have Golly 3.0 so the bug might have been fixed already in Golly 3.1.

Posted: **January 10th, 2018, 2:31 pm**

Ughh. I thought I had these fixed (as of July 2016). Please post a script that exhibits the problem
(or a detailed set of instructions for reproduction). Also please try it with Golly 3.1.

-tom

Posted: **January 11th, 2018, 12:58 am**

This seems to exhibit the bug as described:

Code: Select all

-- Draw cell bug when On cells outside x-coord range [-2^32, 2^32-1]
local g = golly()
g.new("")
g.setalgo("HashLife")
g.setrule("B2/S")
g.setbase(2)
g.setstep(32)
moon = g.parse("o$bo$bo$o")
g.putcells(moon)
g.step()
g.setcell(0, 0, 1)
g.fit()

Tested with Golly 3.1 on Win64. When the script runs there will be a moon at (2^32, 0) and a dot at (2^32, -2^32).
I included a g.new() at the beginning of the script only because otherwise Golly does not behave nicely if the script is run multiple times.

Posted: **January 11th, 2018, 2:51 am**

I just downloaded Golly 3.1 and can confirm that the bug still exists.

For example, if you run this pattern to 10^10 generations in HashLife:

Code: Select all

x = 178, y = 218, rule = B3/S23
125b3o$125bobo$125b3o6bo$125b3o5b3o$125b3o$125b3o$125bobo5b3o$125b3o$
133bobo$133bobo2$133b3o$111b2o6b2o$110bo2bo4bo2bo$110bo2bo4bo2bo11b3o$
110bo2bo4bo2bo12bo$111b2o6b2o2$137bo2b2o4b2o2bo$136bo3b3o2b3o3bo$137bo
2b2o4b2o2bo7$139bo$139b3o4bobo2bobo$138bob4obo2bo2bo2bob2o$120bobo23bo
bo2bobo$120b2o$121bo$139b3o$139b3o$44b3o93bo$45bo94bo$45bo94bo$44b3o
92bobo2$44b3o$44b3o92bobo$140bo$44b3o93bo$45bo94bo$45bo93b3o$44b3o92b
3o2$51b2o6b2o$49bo4bo2bo4bo$49bo4bo2bo4bo$49bo4bo2bo4bo4bo$51b2o6b2o5b
3o8bo$65bobobo6b3o$65bobobo5bobobo$66b3o6bobobo$67bo8b3o$77bo2$67bo$
66b3o8bo$17bo47bobobo6b3o$16b3o46bobobo5bobobo$15bobobo46b3o6bobobo$
15bobobo47bo8b3o$16b3o12bo45bo$17bo11b2o$30b2o2$17bo79b3o$16b3o80bo$
15bobobo59bo18bo$15bobobo59bobo$16b3o49bo10b2o$17bo49b2o$67bobo$78b3o$
2bo2bo4bo2bo64bo$3o2b6o2b3o63bo$2bo2bo4bo2bo2$81b2o$82b2o$81bo2$48bo$
46b2o$47b2o$58bobo2bobo$54b2obo2bo2bo2bob2o$58bobo2bobo2$22b3o52b3o2$
21bo3bo50bo3bo$21bo3bo50bo3bo2$22b3o52b3o$88b3o$88b3o$22b3o52b3o9bo$
89bo$21bo3bo50bo3bo8bo$21bo3bo17bobo30bo3bo7bobo$44b2o$22b3o19bo32b3o$
88bobo$89bo$8bo2bob2obo2bo69bo$8b4ob2ob4o69bo$8bo2bob2obo2bo68b3o$37b
2o6b2o41b3o$35bo4bo2bo4bo$35bo4bo2bo4bo$35bo4bo2bo4bo$37b2o6b2o2$51b3o
66b2o$52bo66b2o$52bo68bo$51b3o2$51b3o$38bobo10b3o$39b2o$39bo11b3o$52bo
$52bo$51b3o26$159bo$159b3o4bobo2bobo$158bob4obo2bo2bo2bob2o$166bobo2bo
bo3$159b3o$159b3o$160bo$160bo$81bo78bo$79bobo77bobo$80b2o2$159bobo$
160bo$160bo$160bo$159b3o$159b3o23$117b3o$119bo$118bo$100b2o6b2o$99bo2b
o4bo2bo$99bo2bo4bo2bo$99bo2bo4bo2bo$100b2o6b2o$114b3o2$113bo3bo$113bo
3bo2$114b3o3$114b3o2$113bo3bo$113bo3bo2$114b3o!

and then draw two cells at (-1,0) and (0,0), they will appear at positions (-2^32-1,-2^32) and (2^32,-2^32).

Posted: **January 11th, 2018, 1:53 pm**

Thanks; I will fix this.

Posted: **January 11th, 2018, 10:54 pm**

Okay, based on your script I wrote a random tester that randomizes the
various coordinates/generation count/etc. and easily reproduced the
bug for a variety of values. I fixed the code, and am running thousands
of test cases with no failures yet. Change is checked in.

Unless someone tells me otherwise we'll hold this until the next release;
I don't think anyone's doing anything that's actually going to bump into
this, right? Or am I wrong?

Posted: **January 17th, 2018, 9:31 pm**

Recently Golly started acting up and generated weird rendering glitches. (I actually experienced this on an earlier version but it's happening on 3.1 too)
Here are screanshots:

: what1.tiff (106.56 KiB) Viewed 16672 times

: what2.tiff (108.79 KiB) Viewed 16672 times

: what3.tiff (105.75 KiB) Viewed 16672 times

(The pattern evolves and is selected and copied like normal. For the first 2 It's the first ship in this post and the 3rd one is a random soup.)
When evolving the pattern it generates a ton of similar frames but appears to evolve normally. This only happens when zoomed out.

Posted: **January 19th, 2018, 1:28 am**

toroidalet wrote: When evolving the pattern it generates a ton of similar frames but appears to evolve normally. This only happens when zoomed out.

OK I'll need more details since I can't reproduce it. Please let me know:

Golly version
Operating system version
Hardware you are running on
A copy of your GollyPrefs file
Pattern file
Steps to reproduce

Thanks!

Posted: **January 19th, 2018, 10:12 am**

rowett wrote:OK I'll need more details since I can't reproduce it.

I can't reproduce the problem either. toroidalet is clearly using a Mac but I see no such display problems on my iMac (using 10.6) nor on my Macbook Pro (using 10.12). Perhaps it's a glitch in the graphics card.

Posted: **January 25th, 2018, 7:22 am**

Is there a way of adding a rule to a plaintext pattern? I'm writing a search program and I want the output to be immediately understandable (so RLE won't do) but also to be pasteable into Golly and loadable into Golly from a file. So it would be good if the rule could be embedded in the pattern's header somehow.

EDIT: I guess I could do something like:

Code: Select all

x = 4, y = 2, rule = B2/S
.oo.$
o..o!

Is there a better way?

Posted: **January 25th, 2018, 12:27 pm**

Macbi wrote:EDIT: I guess I could do something like:
Code: Select all
x = 4, y = 2, rule = B2/S
.oo.$
o..o!
Is there a better way?

Better how? This appears to be doing everything you want it to.

Posted: **January 25th, 2018, 12:39 pm**

Apple Bottom wrote:Better how? This appears to be doing everything you want it to.

Yeah, but it's not official RLE format (where the "."s would be "b"s), so I can't expect every program or even every future version of Golly to support it. So I was wondering if there was some "official" way of incorporating a rule into the plaintext format.

Posted: **January 25th, 2018, 12:49 pm**

Macbi wrote:Is there a way of adding a rule to a plaintext pattern?

The old standard way of doing that is Life 1.05 format:

Code: Select all

#Life 1.05
#R B2/S
.**.
*..*

You need the "#Life 1.05" header for Golly to be able to recognize this, and the ON cells need to be asterisks rather than o's.

You might also consider just using b's instead of periods for the OFF cells in your example. That gets you back to canonical RLE, or close enough. Catagolue does this for soup patterns, and at least to my eye it seems as if the characters are different enough that it's not too hard to sort out the pattern from the background.

Posted: **January 27th, 2018, 11:01 am**

dvgrn wrote:
Code: Select all
#Life 1.05
#R B2/S
.**.
*..*
Strictly speaking, Life 1.05 format only supports Survival/Birth format rule definition:
Rules are encoded as Survival/Birth, each list being a string of digits representing neighbor counts. Since there are exactly eight possible neighbors in a Conway-like rule, there is no need to separate the digits, and "9" is prohibited in both lists.

However, Golly supports any valid rule definition and so the next build of LifeViewer will also.

Posted: **February 20th, 2018, 6:34 am**

Very impressed with quality, performance, and design. Only a couple natural editing features I found missing or difficult to accomplish (filling a region and moving a region), so only -1 on features.

Posted: **February 20th, 2018, 6:36 am**

BitGid wrote:Very impressed with quality, performance, and design. Only a couple natural editing features I found missing or difficult to accomplish (filling a region and moving a region), so only -1 on features.

Both of those things can be accomplished with scripts in the Scripts folder: flood-fill.lua or flood-fill.py for the former, and move-selection.lua or move-selection.py for the latter.

Posted: **March 1st, 2018, 4:11 am**

I wish we could use toolbar buttons for those things. The scripts are always replied when the lack of floodfill and lines is mentioned, but they are still awkward to use:

-the loical place to find these two simple, expected, operations, is together with the operations to draw single pixels. You are painting a 2D world like a painting program.

-requires opening the scripts panel to use unless using shortcuts

-the only lines script is unintuitive due to being multiline and requiring esc to stop

-can assign shortcuts to scripts which is good (kind of hidden feature) but cannot make toolbar button for them

-the database accessible through the help menu allows you to access some online scripts (I found one to create langton's ant like rules there for example), but you cannot easily get that script in your offline golly from there, all it mentions it a .gz file without link to download or anything

Posted: **March 1st, 2018, 10:53 am**

I think I already suggested this but it would be cool to have scripts that can be added to Golly that run constantly.
This could make it possible to draw while running a script or have it update live or run multiple scripts

ConwayLife.com

Golly 3.1

Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1

Re: Golly 3.1