ConwayLife.com - A community for Conway's Game of Life and related cellular automata
Home  •  LifeWiki  •  Forums  •  Download Golly

Golly 2.5 has been released

For general discussion about Conway's Game of Life.

Golly 2.5 has been released

Postby Andrew » April 24th, 2013, 12:42 am

EDIT: I've removed the links to my site because 2.5 is now available from Sourceforge:

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

As always, see Help > Changes for the full list of changes. The most important changes are given below.

  • This version introduces a new rule format. A file in the new format has a .rule extension and contains all the information about the rule: its name, description, table/tree data, and any color/icon information. All the details, along with some examples, can be found here:
    http://code.google.com/p/ruletablerepos ... RuleFormat

  • The RuleTable and RuleTree algorithms have been merged into a new algorithm called RuleLoader. When asked to load a rule called "Foo", RuleLoader will look for Foo.rule first, then Foo.table, then Foo.tree.

  • To help the transition to the new rule format, the Control menu has a new command called Convert Old Rules that can be used to convert all your old .table/tree/colors/icons files into new .rule files. After the conversion finishes you're given the option of deleting all the old files. (Before using Convert Old Rules it would be a good idea to backup your current rules folder -- the one set in Preferences > Control -- just in case something goes wrong. Please let me know if that happens!)

  • The .rule format makes it much easier to publish new rules in these forums. Consider this example:
    @RULE SlowLife

    A variant of Life that shows births (green cells) and deaths (red cells)
    in every 2nd generation.  SlowLife patterns work the same as in Life,
    but twice as slow.  Author: Andrew Trevorrow (andrew@trevorrow.com).

    The @TREE data was created by copying the following Python code to the
    clipboard and running Golly's make-ruletree.py script.

    name = "SlowLife"
    n_states = 4
    n_neighbors = 8
    def transition_function(s):
        # NW, NE, SW, SE, N, W, E, S, C = s
        C = s[8]
       
        # live states:
        normal = 1
        birth = 2
        death = 3
       
        if C == birth: return normal
        if C == death: return 0
       
        # count the number of normal neighbors
        ncount = 0
        for i in xrange(8):
            if s[i] == normal: ncount += 1
            # no change if there are any birth/death neighbors
            if s[i] > normal: return C
       
        if C == 0 and ncount == 3: return birth
        if C == normal and (ncount < 2 or ncount > 3): return death
       
        return C

    @TREE

    num_states=4
    num_neighbors=8
    num_nodes=39
    1 0 3 1 0
    1 0 1 1 0
    2 0 0 1 1
    2 0 1 1 1
    2 1 1 1 1
    3 2 3 4 4
    1 2 1 1 0
    2 1 6 1 1
    3 3 7 4 4
    3 4 4 4 4
    4 5 8 9 9
    2 6 0 1 1
    3 7 11 4 4
    4 8 12 9 9
    4 9 9 9 9
    5 10 13 14 14
    3 11 2 4 4
    4 12 16 9 9
    5 13 17 14 14
    5 14 14 14 14
    6 15 18 19 19
    3 2 2 4 4
    4 16 21 9 9
    5 17 22 14 14
    6 18 23 19 19
    6 19 19 19 19
    7 20 24 25 25
    4 21 21 9 9
    5 22 27 14 14
    6 23 28 19 19
    7 24 29 25 25
    7 25 25 25 25
    8 26 30 31 31
    5 27 27 14 14
    6 28 33 19 19
    7 29 34 25 25
    8 30 35 31 31
    8 31 31 31 31
    9 32 36 37 37

    @COLORS

    0  48  48  48   background is dark gray
    1 255 255 255   normal is white
    2   0 255   0   birth is green
    3 255   0   0   death is red

    @ICONS

    XPM
    /* width height num_colors chars_per_pixel */
    "31 93 10 1"
    /* colors */
    ". c #303030"
    "B c #404040"
    "C c #808080"
    "D c #C0C0C0"
    "E c #FFFFFF"
    "F c #004000"
    "G c #007F00"
    "H c #00C000"
    "I c #00FF00"
    "J c #FF0000"
    /* icon for state 1 */
    "..............................."
    "..............................."
    "..........BCDEEEEEDCB.........."
    ".........CEEEEEEEEEEEC........."
    ".......BEEEEEEEEEEEEEEEB......."
    "......DEEEEEEEEEEEEEEEEED......"
    ".....DEEEEEEEEEEEEEEEEEEED....."
    "....BEEEEEEEEEEEEEEEEEEEEEB...."
    "....EEEEEEEEEEEEEEEEEEEEEEE...."
    "...CEEEEEEEEEEEEEEEEEEEEEEEC..."
    "..BEEEEEEEEEEEEEEEEEEEEEEEEEB.."
    "..CEEEEEEEEEEEEEEEEEEEEEEEEEC.."
    "..DEEEEEEEEEEEEEEEEEEEEEEEEED.."
    "..EEEEEEEEEEEEEEEEEEEEEEEEEEE.."
    "..EEEEEEEEEEEEEEEEEEEEEEEEEEE.."
    "..EEEEEEEEEEEEEEEEEEEEEEEEEEE.."
    "..EEEEEEEEEEEEEEEEEEEEEEEEEEE.."
    "..EEEEEEEEEEEEEEEEEEEEEEEEEEE.."
    "..DEEEEEEEEEEEEEEEEEEEEEEEEED.."
    "..CEEEEEEEEEEEEEEEEEEEEEEEEEC.."
    "..BEEEEEEEEEEEEEEEEEEEEEEEEEB.."
    "...CEEEEEEEEEEEEEEEEEEEEEEEC..."
    "....EEEEEEEEEEEEEEEEEEEEEEE...."
    "....BEEEEEEEEEEEEEEEEEEEEEB...."
    ".....DEEEEEEEEEEEEEEEEEEED....."
    "......DEEEEEEEEEEEEEEEEED......"
    ".......BEEEEEEEEEEEEEEEB......."
    ".........CEEEEEEEEEEEC........."
    "..........BCDEEEEEDCB.........."
    "..............................."
    "..............................."
    /* icon for state 2 */
    "..............................."
    "..............................."
    "..........FGHIIIIIHGF.........."
    ".........GIIIIIIIIIIIG........."
    ".......FIIIIIIIIIIIIIIIF......."
    "......HIIIIIIIIIIIIIIIIIH......"
    ".....HIIIIIIIIIIIIIIIIIIIH....."
    "....FIIIIIIIIIIIIIIIIIIIIIF...."
    "....IIIIIIIIHGF.FGHIIIIIIII...."
    "...GIIIIIIIH.......HIIIIIIIG..."
    "..FIIIIIIIG.........GIIIIIIIF.."
    "..GIIIIIIH...........HIIIIIIG.."
    "..HIIIIIH.............HIIIIIH.."
    "..IIIIIIG.............GIIIIII.."
    "..IIIIIIF.............FIIIIII.."
    "..IIIIII...............IIIIII.."
    "..IIIIIIF.............FIIIIII.."
    "..IIIIIIG.............GIIIIII.."
    "..HIIIIIH.............HIIIIIH.."
    "..GIIIIIIH...........HIIIIIIG.."
    "..FIIIIIIIG.........GIIIIIIIF.."
    "...GIIIIIIIH.......HIIIIIIIG..."
    "....IIIIIIIIHGF.FGHIIIIIIII...."
    "....FIIIIIIIIIIIIIIIIIIIIIF...."
    ".....HIIIIIIIIIIIIIIIIIIIH....."
    "......HIIIIIIIIIIIIIIIIIH......"
    ".......FIIIIIIIIIIIIIIIF......."
    ".........GIIIIIIIIIIIG........."
    "..........FGHIIIIIHGF.........."
    "..............................."
    "..............................."
    /* icon for state 3 */
    "..............................."
    "..............................."
    "..JJJJ....BCDEEEEEDCB....JJJJ.."
    "..JJJJJ..CEEEEEEEEEEEC..JJJJJ.."
    "..JJJJJJEEEEEEEEEEEEEEEJJJJJJ.."
    "..JJJJJJJEEEEEEEEEEEEEJJJJJJJ.."
    "...JJJJJJJEEEEEEEEEEEJJJJJJJ..."
    "....JJJJJJJEEEEEEEEEJJJJJJJ...."
    "....EJJJJJJJEEEEEEEJJJJJJJE...."
    "...CEEJJJJJJJEEEEEJJJJJJJEEC..."
    "..BEEEEJJJJJJJEEEJJJJJJJEEEEB.."
    "..CEEEEEJJJJJJJEJJJJJJJEEEEEC.."
    "..DEEEEEEJJJJJJJJJJJJJEEEEEED.."
    "..EEEEEEEEJJJJJJJJJJJEEEEEEEE.."
    "..EEEEEEEEEJJJJJJJJJEEEEEEEEE.."
    "..EEEEEEEEEEJJJJJJJEEEEEEEEEE.."
    "..EEEEEEEEEJJJJJJJJJEEEEEEEEE.."
    "..EEEEEEEEJJJJJJJJJJJEEEEEEEE.."
    "..DEEEEEEJJJJJJJJJJJJJEEEEEED.."
    "..CEEEEEJJJJJJJEJJJJJJJEEEEEC.."
    "..BEEEEJJJJJJJEEEJJJJJJJEEEEB.."
    "...CEEJJJJJJJEEEEEJJJJJJJEEC..."
    "....EJJJJJJJEEEEEEEJJJJJJJE...."
    "....JJJJJJJEEEEEEEEEJJJJJJJ...."
    "...JJJJJJJEEEEEEEEEEEJJJJJJJ..."
    "..JJJJJJJEEEEEEEEEEEEEJJJJJJJ.."
    "..JJJJJJEEEEEEEEEEEEEEEJJJJJJ.."
    "..JJJJJ..CEEEEEEEEEEEC..JJJJJ.."
    "..JJJJ....BCDEEEEEDCB....JJJJ.."
    "..............................."
    "..............................."

    XPM
    /* width height num_colors chars_per_pixel */
    "15 45 10 1"
    /* colors */
    ". c #303030"
    "B c #404040"
    "C c #808080"
    "D c #C0C0C0"
    "E c #FFFFFF"
    "F c #004000"
    "G c #007F00"
    "H c #00C000"
    "I c #00FF00"
    "J c #FF0000"
    /* icon for state 1 */
    "..............."
    "....BDEEEDB...."
    "...DEEEEEEED..."
    "..DEEEEEEEEED.."
    ".BEEEEEEEEEEEB."
    ".DEEEEEEEEEEED."
    ".EEEEEEEEEEEEE."
    ".EEEEEEEEEEEEE."
    ".EEEEEEEEEEEEE."
    ".DEEEEEEEEEEED."
    ".BEEEEEEEEEEEB."
    "..DEEEEEEEEED.."
    "...DEEEEEEED..."
    "....BDEEEDB...."
    "..............."
    /* icon for state 2 */
    "..............."
    "....FHIIIHF...."
    "...HIIIIIIIH..."
    "..HIIIIIIIIIH.."
    ".FIIIHF.FHIIIF."
    ".HIIH.....HIIH."
    ".IIIF.....FIII."
    ".III.......III."
    ".IIIF.....FIII."
    ".HIIH.....HIIH."
    ".FIIIHF.FHIIIF."
    "..HIIIIIIIIIH.."
    "...HIIIIIIIH..."
    "....FHIIIHF...."
    "..............."
    /* icon for state 3 */
    "..............."
    ".JJ.BDEEEDB.JJ."
    ".JJJEEEEEEEJJJ."
    "..JJJEEEEEJJJ.."
    ".BEJJJEEEJJJEB."
    ".DEEJJJEJJJEED."
    ".EEEEJJJJJEEEE."
    ".EEEEEJJJEEEEE."
    ".EEEEJJJJJEEEE."
    ".DEEJJJEJJJEED."
    ".BEJJJEEEJJJEB."
    "..JJJEEEEEJJJ.."
    ".JJJEEEEEEEJJJ."
    ".JJ.BDEEEDB.JJ."
    "..............."

    XPM
    /* width height num_colors chars_per_pixel */
    "7 21 11 1"
    /* colors */
    ". c #303030"
    "B c #404040"
    "C c #808080"
    "D c #C0C0C0"
    "E c #FFFFFF"
    "F c #004000"
    "G c #007F00"
    "H c #00C000"
    "I c #00FF00"
    "J c #FF0000"
    "K c #E0E0E0"
    /* icon for state 1 */
    ".BKEKB."
    "BEEEEEB"
    "KEEEEEK"
    "EEEEEEE"
    "KEEEEEK"
    "BEEEEEB"
    ".BKEKB."
    /* icon for state 2 */
    ".FHIHF."
    "FIIIIIF"
    "HIH.HIH"
    "II...II"
    "HIH.HIH"
    "FIIIIIF"
    ".FHIHF."
    /* icon for state 3 */
    "JBKEKBJ"
    "BJEEEJB"
    "KEJEJEK"
    "EEEJEEE"
    "KEJEJEK"
    "BJEEEJB"
    "JBKEKBJ"

    To install this rule in the correct place, simply select all, copy it to the clipboard, then switch to Golly and select File > Open Clipboard (or Edit > Paste). When Golly sees that the clipboard text begins with "@RULE rulename" it will save the text as rulename.rule in your rules folder and then switch to that rule.

  • Two new scripts (in Scripts/Python/Rule-Generators) allow Golly to be used as an icon editor. Run icon-importer.py first to import any icons for the current rule and display their bitmaps in a new layer for you to edit. When you've finished editing, run icon-exporter.py to extract the icon images and create or update the @ICONS section in the appropriate .rule file, then display the icons in a separate test layer.

  • Support for monochrome icons has been extended to allow grayscale icons, where shades of gray can be used to do anti-aliasing. Most of the default icons are now grayscale bitmaps.

  • Patterns can now be displayed at scale 1:32. If you want to use that scale when creating a new pattern then choose the appropriate pop-up menu option in Preferences > File.
Questions, comments, suggestions, bug reports, are all welcome.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » April 24th, 2013, 4:10 am

This is great! I love the 1:32 scale for icons.

Regarding the colors of the icons:
I see what is either a bug or an inconvenience in the "Convert Old Rules" function. Given a .ruletree file, a .colors file, and a .icons file, I end up with a .rule which has the correct colors at scale 1:4 or more zoomed out than that, but when I zoom in to 1:8 or more, the colors are inherited from the .icons file rather than from the .colors file.

For example, given a .colors file that says that state 1 is yellow and state 2 is green, and given a .icons file which has a black background and red icon shapes, when I zoom out I get a yellow-and-green rule as expected, but when I zoom in to 1:8, 1:16, or 1:32, all the cells, regardless of their state, are red, whereas previous versions of Golly have colored the cells yellow or green.

For whatever it is worth: I create my .icons files by drawing 15x15 cell shapes using Golly and then I convert the icons to a .bmp with the save-bmp.py script, and then I change the file extension from .bmp to .icons. I don't know if this is the standard way to do it. If I've been doing it wrong, a fix on my end would be for me to edit each converted .rule file, but I wonder if you think "Convert Old Rules" is doing the right thing.

I'm using a Mac running OS X version 10.6.8.
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » April 24th, 2013, 9:35 am

EricG wrote:For example, given a .colors file that says that state 1 is yellow and state 2 is green, and given a .icons file which has a black background and red icon shapes...

The old Golly treats icons with 2 colors (or less) as monochrome, regardless of what they are. I sort of assumed that people would use black and white for such icons. The new Golly sees the red color and assumes it is a multi-colored icon (ie. not grayscale) and so uses those colors in the .rule file's XPM data.

For whatever it is worth: I create my .icons files by drawing 15x15 cell shapes using Golly and then I convert the icons to a .bmp with the save-bmp.py script, and then I change the file extension from .bmp to .icons. I don't know if this is the standard way to do it.

A perfectly fine way to create a .icons file. My only quibble would be that it's strange to use red-on-black rather than white-on-black if you wanted to specify monochrome icons.

To fix the problem I think you can just edit the .rule file and change the XPM lines that specify red (FF0000) to white (FFFFFF). If a lot of people have created .icons files like yours then I'll have to rethink what to do. Maybe if Convert Old Colors sees a .colors file *and* a .icons file with only 2 colors, one of which is black, then the .rule file should probably force the other XPM color to white.

Thanks for the report!
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » April 24th, 2013, 10:09 pm

I tried out icon-importer/exporter (which constitutes a very nice idea!). One of my goals was to see if I could fix my color problem from within Golly 2.5, by editing the monochrome-but-nonwhite icons I created, rather than editing the .rule file directly. It looks like that works! Here are some first reactions:

It would be very nice if users could update the shared icon for families of rules. If I'm not mistaken, it looks like icon-exporter.py only updates the current rule, rather than its family of rules. This is a significant change from how .icons files work. From the help section of Golly 2.4: " If rule.icons is not found but rule contains one or more hyphens then Golly will look for prefix.icons, where prefix consists of all the characters before the final hyphen. This allows related rules to share a single .icons file. " This is a big deal, for me at least - I have thousands of rules (created by ruletree-generating scripts) which share perhaps 30 .icons files. There are reasons beyond the color issue to update these 30 icons, particularly when each new family of rules was being developed, but at other times too. I think .icons files shouldn't be considered obsolete unless icon-exporter.py (or some similar function) can update all the .rule files that a .icons file would have addressed. Does that make sense?

[Baby is crying, but I do have more reactions that will have to wait until later - I'm very enthusiastic about this update!]
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » April 25th, 2013, 12:31 am

EricG wrote:It would be very nice if users could update the shared icon for families of rules. If I'm not mistaken, it looks like icon-exporter.py only updates the current rule, rather than its family of rules.

Correct, but that's an excellent idea -- it would be much nicer if icon-exporter.py gave you the option of updating the icons in all .rule files that share the same prefix as the current rule. I'll look into that.

(We did consider having some sort of @INCLUDE syntax that would allow a .rule file to import the colors and/or icons from another specified .rule file, but that conflicted with one of our main goals; ie. a .rule file should contain everything about the rule.)

I've thought some more about your black-and-red .icons problem. Golly 2.5 should really treat those icons the same way 2.4 does (ie. as monochrome rather than multi-color), so I'll also look into fixing that. I'll try to get you a new Mac build to test in a few days.

Thanks again for the excellent feedback.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » April 25th, 2013, 12:55 am

Here's a bug report, unrelated to my comment above, on an example of icon-importer.py failing to import icons and, seemingly, acting inconsistently within a rule family. To allow you to try it for yourself, I've attached a zip archive with two folders: 1) Excerpt from my Rules folder 2) Converted rules.

"Excerpt from my Rules folder" contains three ruletrees, a .icons file, and a .colors file. I was planning to share these rules on this forum, but the icons for the rules are a bit goofed up, so I thought I'd see if I could fix them with the icon-importer/exporter scripts. Since the icons are just little squares, this should be a very easy case, and it is a realistic (non-contrived) use of the icon-importer/exporter scripts.

For one of the rules,the LTL-R2-B4_S4.rule, icon-importer.py fails to import the icons. For the other two rules, it does import the icons. Note that all three converted .rule files have icon information, and all three correctly show their icons when the rule is run. Is this a bug with icon-importer.py?

Also: in the "it would be nice" department, it would be nice if the icon-importer created a 7x7 version of the icons if they aren't already present, just as a 31x31 version of the icons is created. When the rule is run, Golly does create 7x7 versions, and it would be nice if icon-importer could do it too -- that way, they could be edited. (This seems like a very low priority item.)

Well, regardless of whether the 7x7 icons are created automatically or not, I can see that the icon-importer/exporter is going to be very useful! -- Eric Goldstein


PS: Whoops. The rules are too big to be uploaded here. Please grab them, for the time being, at http://www.gohover.com/For-Andrew/
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » April 25th, 2013, 4:10 am

EricG wrote:For one of the rules,the LTL-R2-B4_S4.rule, icon-importer.py fails to import the icons.

This is happening because the file uses CR as the end-of-line character (I assume you must have edited the file at some stage). This is easy to fix by changing the open call in icon-importer.py to use "rU" mode. Ditto in icon-exporter.py. Good catch!

Also: in the "it would be nice" department, it would be nice if the icon-importer created a 7x7 version of the icons if they aren't already present, just as a 31x31 version of the icons is created.

I'll see what I can do, assuming I can come up with a method that scales down the 15x15 icons to produce reasonable looking results (this is easy to do using PIL but I don't want any of the supplied scripts to require PIL).
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby Andrew » April 27th, 2013, 11:00 pm

Andrew wrote:... it would be much nicer if icon-exporter.py gave you the option of updating the icons in all .rule files that share the same prefix as the current rule.

I've had 2nd thoughts about this. It would be quite messy to do, especially if some of the related rules have their own colors/icons.

I'm now looking at implementing a scheme where a related set of .rule files can share colors/icons specified in another special .rule file. In Eric's example, his LTL-R2-*.rule files can use the colors and icons in LTL-R2-shared.rule. More details when 2.5b4 is ready to test.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 3rd, 2013, 3:50 am

Mostly to EricG -- please try this build of Golly 2.5b4 and let me know how it goes:

http://www.trevorrow.com/golly/golly-2.5b4-mac.zip

It should fix all the problems you reported, plus it has the changes you requested. In particular, please run "Convert Old Rules" on your original .tree/table/colors/icons files. It should now correctly handle your black-and-non-white icons, plus it will create Foo-shared.rule files containing colors and/or icons shared by all other Foo-*.rule files.

The icon-importer.py script is also smarter: it handles any line endings (LF, CR, CR+LF) and creates missing 7x7 icons by scaling down the 31x31 or 15x15 icons.

Once I hear you're happy with this version I'll do the other builds and announce them here. Barring any new bugs, I'm pretty confident this version is very close to the final 2.5 release.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » May 4th, 2013, 7:06 pm

Andrew,

I have no bugs to report, and I didn't have any real problems either. I liked the automatic scale down to 7x7 icons in icon-importer.py. Thanks, very useful! And yes, the monochrome icon problem seems to be completely fixed - thanks for that too. Sorry the following is so long, but "I didn't have time to make it shorter".

--

I suggest changing the position of "Convert Old Rules" on the "Control" menu to the spot above "Set Algorithm". I don't know about other users, but I use "Set Rule" much more often than any other option on the "Control" menu. In contrast, I expect we will use "Convert Old Rules" infrequently right from the start, and we'll use it increasingly less frequently as .rule is adopted by users. For previous versions of Golly, set-rule's position as the very last item on the control menu made it easier to quickly select it, without the need to be as precise as one would have to be otherwise. I'm finding the new position to be awkward.

(It only now occurs to me that I use "Set Rule" so much, I ought to create a keyboard shortcut. I've long felt that "Set Rule" is in an surprisingly obscure position compared to many other CA programs, but I've just been putting up with it. I forgot all about keyboard shortcuts. For that matter, I suppose a script could serve a shortcut too. But I wonder if many other users have felt the position was awkward, and have just been putting up with it)

--

I especially liked how "convert old rules" creates a prefix-shared.rule, when appropriate. I was worried that at least two .tree files and an .icon file would be needed to trigger the creation of a prefix-shared.rule, but a .icon file and one .tree file with a dash in its name suffices, and that's also very helpful.

In the future, after people have adopted the .rule format, how will new prefix-shared.rule files get generated? It looks to me like prefix-shared.rule files will have be created manually in the OS. I wonder if, when it is appropriate, you'd like the icon-importer.py script to prompt Golly users with the option of creating a prefix-shared.rule file. The same filename criteria that "Convert Old Rules" uses to figure out when to create a prefix-shared rule could be used by icon-importer.py to offer the option of creating a prefix-shared rule. The default could be to create icons for the current rule, but the option would be there to create a prefix-shared rule from within Golly.
--

I like the built-in icons option! It would be nice if icon-importer.py could import built-in icons like circles and hexagons. These might be useful to users. As an example, for my most recent project (to be posted soon) I used partitioned hexagons. Rather than design a hexagon icon from scratch, I went into the EmulateHexagonal code in glife, and copied the icon there, and then modified it -- just the sort of thing icon-importer.py will now be helpful with.

--

This rest of my comments below are really very trivial, but I guess this is the place to mention them:

--

It would be really cool if, in set-rule, the file extension .rule didn't invalidate the rule name. I can never remember what I call my rules (or which rules I've already made, in the case of a family of rules), so I look in my rules folder, and then copy and past the filename into Golly's set-rule dialog box. Of course, the file extension comes along with the filename and invalidates the name, so I have to backspace to erase the .table, or .tree file extension. Now that there is simply .rule, perhaps it could be allowed?
--

I've noticed that for some rules, the suggested 31x31 icon isn't as smooth as what Golly provides by default if there are no 31x31 icons in the exporter at all. I suppose this is related to the issue with PIL (?) you mentioned above. Not a big deal, but leaving the 31x31 icons blank might be a mentioned in a tips and tricks section.


--------
I wish the default for "Convert Old Rules" was to not delete .tree, .table, .icon, and .color files. I noticed on the forum that I'm not the only user who has the bad habit of using older versions of Golly alongside newer versions.

(And again, it only now occurs to me to find a better solution. I just learned about the open -n solution on the mac by googling "running multiple copies of a program on the mac". If it is equally easy for PC users, then nevermind.)
-------------


I wonder if it would be helpful to provide users with an upgrade path for their script folder, if they've created their own. For rules, the user's personal rules folder overrides the rules folder provided with the latest release, but both folders are a valid source of rules, so upgrading versions of golly is no hassle. For scripts, users need to know that they'll have to copy anything new (like a new version of glife, and new rule-generators) into their personal script file. Maybe they should be told. Maybe scripts could be organized into user-added-scripts and required-scripts, and then required-scripts could update automatically...

---

I see a lot of work was put into the help section regarding rules. Nice job. I wish the ease of using make-ruletree.py (and the ease of creating scripts which prompt for rule specifications, like Trilife.py) was emphasized in the help section. I'm surprised by how much more popular tables are than trees among forum users, when for many types of rules, trees would be much easier to use.

Thanks for continuing to update Golly.
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 4th, 2013, 11:38 pm

EricG wrote:... Sorry the following is so long, but "I didn't have time to make it shorter".

No problem -- I'm always happy to get good quality feedback, no matter how long! (BTW, in case you didn't notice, you've made it into the exalted list of beta testers in Help > Credits.)

I suggest changing the position of "Convert Old Rules" on the "Control" menu to the spot above "Set Algorithm".

Good idea -- will do.

It only now occurs to me that I use "Set Rule" so much, I ought to create a keyboard shortcut.

Absolutely -- I just type "r".

In the future, after people have adopted the .rule format, how will new prefix-shared.rule files get generated? It looks to me like prefix-shared.rule files will have be created manually in the OS.

Yes, I think that's best. I don't think we should try to make icon-importer.py too clever -- it will just end up too confusing and put people off using it (I'm a bit worried it's already much more complicated than I originally planned).

I like the built-in icons option! It would be nice if icon-importer.py could import built-in icons like circles and hexagons.

Hmm, maybe. The danger is that people will run icon-exporter.py without changing the icons and end up with a proliferation of duplicated icon bitmaps, which is what the built-in icons are meant to avoid. I'll have to think about this a bit more. Maybe it would be better to publish the XPM data for the built-in icons in a new .html file and link to that from the appropriate section in Help > File Formats. Or provide special .rule files in the Rules folder called Default_circles.rule, Default_diamonds.rule, etc., so you can switch to one of those rules, then run icon-importer.py and copy the bitmaps from that layer to new icons in another layer.

It would be really cool if, in set-rule, the file extension .rule didn't invalidate the rule name. I can never remember what I call my rules (or which rules I've already made, in the case of a family of rules), so I look in my rules folder, and then copy and past the filename into Golly's set-rule dialog box.

That's a really clumsy way of switching to a .rule file! Far easier to organise your folders so you can simply click on a .rule file in the Patterns panel. The contents of my Golly folder looks like this (with some extraneous stuff omitted):

Downloads (orange, contains my downloaded files, set in Prefs > File)
Golly.app
GollyPrefs (orange)
Help
Patterns
Rules
Scripts
Test-files (orange, contains all my test patterns)
Test-rules (orange, contains all my .rule files, set in Prefs > Control)
Test-scripts (orange, contains all my .py/.pl scripts)

I use an orange label for files/folders I've added to the Golly distribution, so when I update to a new release I can just drag that stuff into the new Golly folder. I've used File > Set Pattern Folder to point to the parent folder, so now everything is easily available. Note that there's also no need to switch to the Scripts panel because the Scripts folder is now available in the Patterns panel.

I've noticed that for some rules, the suggested 31x31 icon isn't as smooth as what Golly provides by default if there are no 31x31 icons in the exporter at all. I suppose this is related to the issue with PIL (?) you mentioned above. Not a big deal, but leaving the 31x31 icons blank might be a mentioned in a tips and tricks section.

Not sure there's any need to mention that. Presumably people are using icon-importer.py because they want to improve the icons and make them look better than the scaled icons created by Golly.

I wish the default for "Convert Old Rules" was to not delete .tree, .table, .icon, and .color files. I noticed on the forum that I'm not the only user who has the bad habit of using older versions of Golly alongside newer versions.

All I can say is that's a very bad habit. You should really throw away those old versions of Golly (or at least zip them up so they are readily available if you ever need to test something). But you should definitely not keep your old .tree, .table, .icon, and .color files alongside the new .rule files for any length of time. They will eventually get out of sync and just cause confusion. Plus future versions of Golly may well stop supporting those files, so now is the time to wean yourself off them!

I wonder if it would be helpful to provide users with an upgrade path for their script folder, if they've created their own.

I think the above folder arrangement solves that problem. I can easily run a supplied script (in Scripts) or one of my own scripts (in Test-scripts) with just a few clicks.

I wish the ease of using make-ruletree.py (and the ease of creating scripts which prompt for rule specifications, like Trilife.py) was emphasized in the help section. I'm surprised by how much more popular tables are than trees among forum users, when for many types of rules, trees would be much easier to use.

Me too. That's the main reason I gave the above SlowLife.rule example -- it shows how simple the Python transition function is, and how it can be included in the documentation section. As an aside, I was impressed that my text editor (TextWrangler) was smart enough to automatically detect when make-ruletree.py updated the @TREE section in SlowLife.rule which I had open while creating and testing the transition function.

Excellent feedback, as usual -- thanks!
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » May 5th, 2013, 4:12 pm

Re: the credits, whoo hoo!

Re: the default icons, if the concern is that users will export unmodified default icons, I wonder if it would be too much of a hassle for icon-exporter.py to check whether the icons match the four patterns for the default icons, and if so, just export a single default word, eg "circles". (So, icon-importer.py would translate "circles" into an RLE, and icon-exporter.py could check if an RLE should be translated back into "circles".)

Re: setting the pattern folder to the overall Golly folder, Head-smack! That's brilliant! Everyone should know this is an option. It is incredibly simple, yet it greatly improves the overall experience of using Golly. Fantastic.
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 5th, 2013, 6:57 pm

EricG wrote:Re: the default icons, if the concern is that users will export unmodified default icons, I wonder if it would be too much of a hassle for icon-exporter.py to check whether the icons match the four patterns for the default icons, and if so, just export a single default word, eg "circles".

Yep, that should work. I'll probably put the XPM data for the default icons into strings in a new glife module so the importer and exporter scripts can use them.

Re: setting the pattern folder to the overall Golly folder, Head-smack! That's brilliant! Everyone should know this is an option.

I'll add a note to Help > Hints and Tips.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » May 8th, 2013, 5:31 pm

Andrew,

I've continued to use version 2.5b, and I've found that the @Rule rulename feature makes it inconvenient to do a batch rename for a large family of rules. In my case, the quickest solution was to throw out the .rule files, go back to my collection of .tree files, do a normal batch rename, and then call "convert old rules" again. One more reason to keep around those old rule files....

To some extent, this is the family-of-rules vs single-rule issue again. But even for single rules, including the rulename in the .rule file can be undesirable -- for example, when an inexperienced conwaylife.com forum member posts a rule named "GreatRule", we won't want to install it without editing the name first.

But being able to install rules from "Open Clipboard" was a good idea!

What if @Rule stood alone, as an indicator to "Open Clipboard" that it should prompt the user for a filename and then install the rule?

Hmmm, I just noticed something else: If you've already installed a rule called, say, "slowlife", and then "open clipboard" on the slowlife rule you offered above, the original slowlife gets erased, without any warning. What if I had annotated slowlife after the first time I installed it? Or, worse yet: did you know that you're not the first person to post a rule that runs life at half speed? Troplium wrote about "B3_S23+B_S012345678" here: viewtopic.php?f=11&t=719#p5126 If I had called that rule "slowlife", installing your "slowlife" would have quietly overwritten it.

On the other hand, if Golly had prompted me for a name, I think I would have called your more useful rule "ShowLife"!

I really like the icon-importer/exporter, and the explicit representation of icons as ascii text, but I'm not so sure about abandoning .table, .tree,.colors, and .icons. I think I would have been happier to see various scripts and built-in functions which make it easier to use the old format. (But somehow I'll manage.)

One more idea: working with the icon-importer/exporter made me also want a way to create or update .color info from within Golly, using the nice pallets that Golly offers.)
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 8th, 2013, 8:30 pm

EricG wrote:I've continued to use version 2.5b, and I've found that the @Rule rulename feature makes it inconvenient to do a batch rename for a large family of rules.

A couple of thoughts: I don't think it's all that hard to do such a rename, either by writing a simple little script, or by using a smart text editor (TextWrangler, which is free, has a Multi-File Search command that would do the job). But I'd think very carefully about doing such a rename. If you rename .tree/table file names then you also need to edit any .rle/.mc files that specify those rule names, so the renaming problem is not restricted to .rule files.

To some extent, this is the family-of-rules vs single-rule issue again. But even for single rules, including the rulename in the .rule file can be undesirable -- for example, when an inexperienced conwaylife.com forum member posts a rule named "GreatRule", we won't want to install it without editing the name first.

I have to disagree. The creator of a rule has the right to name it, as long as it doesn't conflict with an existing rule. If it's a silly name then that's too bad, but if everybody called rules whatever they liked then chaos would reign! (Actually, you can assign any rule a different name by using the Set Rule dialog to add a new name for a given rule string, but those names are only seen by you; ie. they are never stored in a .rle/.mc file.)

What if @Rule stood alone, as an indicator to "Open Clipboard" that it should prompt the user for a filename and then install the rule?

The naming of .rule files is very important, which is why the name is stored in the file. It avoids the problem we see in the forums where somebody publishes table/tree data without saying what the file should be called. It also gives Golly a chance to detect and prevent the problem of Mac/Win users forgetting that rule names are case sensitive (ie. the rule name must match the case of the .rule file name, otherwise problems will occur on Linux).

If you've already installed a rule called, say, "slowlife", and then "open clipboard" on the slowlife rule you offered above, the original slowlife gets erased, without any warning.

Good point. I'll add code to check if rulename.rule already exists and then ask if you want to replace the existing file. That will give you the chance to compare the two rules and see which one you want to keep.

I really like the icon-importer/exporter, and the explicit representation of icons as ascii text, but I'm not so sure about abandoning .table, .tree,.colors, and .icons.

Sorry, but I'm absolutely convinced that the .rule format is the right way forward. It avoids the proliferation of all those different file extensions, and it will allow us to add new features while remaining backward compatible. (In particular, the clumsy .icons format did not allow support for 31x31 icons in a backward compatible way.)

One more idea: working with the icon-importer/exporter made me also want a way to create or update .color info from within Golly, using the nice pallets that Golly offers.)

Maybe in 2.6. :)
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 19th, 2013, 6:42 pm

I've updated the above links to version 2.5b4. Barring any major bugs, this should be the final beta version.

(Eric, throw away your current Mac 2.5b4 version and grab the latest. It has most of the changes you suggested.)
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby bprentice » May 21st, 2013, 2:38 pm

Andrew

In Golly 2.5, please support neighborhoods with any 8 neighbors selected from the 24 nearest neighbor set?

Brian Prentice
bprentice
 
Posts: 407
Joined: September 10th, 2009, 6:20 pm
Location: Coos Bay, Oregon

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 21st, 2013, 7:18 pm

bprentice wrote:In Golly 2.5, please support neighborhoods with any 8 neighbors selected from the 24 nearest neighbor set?

Definitely won't happen in 2.5 (only fixing bugs at this stage) and I can't see it happening in the near future either, for a couple of reasons:

1. The QuickLife and HashLife algorithms are highly optimized for the 8 nearest neighbors so I'm guessing that some significant changes would be needed to support larger neighborhoods. Tom Rokicki would have a more accurate answer. Possibly easier to write a completely new LargerThanLife algorithm.

2. Support for larger neighborhoods (and other exotic types of CA) was one of the reasons for creating Ready (http://code.google.com/p/reaction-diffusion/). See larger-than-life.vti which is included in the latest release. The kernel code in that file can be modified quite easily to support many different LtL variants.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby 137ben » May 21st, 2013, 7:21 pm

bprentice wrote:Andrew

In Golly 2.5, please support neighborhoods with any 8 neighbors selected from the 24 nearest neighbor set?

Brian Prentice

This has been requested before, and I thought it turned out to be hard to add directly without slowing down the rest of the program...it is probably too late to add it to v2.5 anyways, as that would be a fairly major change...
You can already emulate larger neighborhoods by adding more states: a radius 2 k-state CA can be modeled by radius 1 k^4 state CA (k^2 if your original CA is 1 dimensional).
137ben
 
Posts: 343
Joined: June 18th, 2010, 8:18 pm

Re: Golly 2.5b3 is available for testing

Postby Andrew » May 21st, 2013, 7:41 pm

137ben wrote:You can already emulate larger neighborhoods by adding more states...

Good point -- I forgot about that! In fact, I think EricG has a Python script that can generate files like LTL-R2-B89AB_S789ABC.tree. Those rules look to be totalistic, but I imagine it would be easy to modify the script to generate rules based on an arbitrary set of neighbors.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5b3 is available for testing

Postby EricG » May 21st, 2013, 8:54 pm

I'm a day or three away from posting a collection of rule-generating scripts which includes some simple code for Radius 2 Weighted Life, so that Radius 2 Larger-Than-Life rules, Hexagonal radius 2 rules, and more, can be run in Golly. I used Golly's RuleTreeGen code, so unfortunately, all of the radius 2 rules are restricted to emulating just two states, using 16 states as 137Ben describes. And even so, it takes about 4.5 hours to generate each 16 state rule on my mac using C code, and much much longer using Python. For rule-generation times like that, it makes sense to use a program like Ready or Brian's Square Cell to find good radius 2 rules, and only then create an equivalent Golly rule to benefit from Golly's many advantages. I'll be interested in discussing alternative solutions, and I'll also suggest one possible solution in the "What I'd like to see in Golly " thread, rather than here. (I've got sick kids who can't sleep, so it'll all have to wait just a little bit longer.)

Andrew, I'll keep looking for bugs in Golly 2.5b4, but all is working well so far!
EricG
 
Posts: 199
Joined: August 19th, 2011, 5:41 pm
Location: Chicago-area, USA

Re: Golly 2.5b3 is available for testing

Postby Andrew » June 11th, 2013, 7:17 pm

I've updated the links in the first post to the final version 2.5 files. Assuming there are no problems, I'll upload these to sourceforge in a couple of days.
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5 has been released

Postby Andrew » June 15th, 2013, 9:59 am

Golly 2.5 is now available from Sourceforge:

https://sourceforge.net/projects/golly/ ... golly-2.5/
User avatar
Andrew
Moderator
 
Posts: 621
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia

Re: Golly 2.5 has been released

Postby Rlo » June 15th, 2013, 9:48 pm

Hi there, I noticed this thread as I was checking for updates to my own thread. I thought this might be a good place to put my observations, please disregard this if I've taken an improper step.

My interactions with Golly have been as a hobby-artist. In this vein Golly (and cellular automata) has been a vast source of inspiration and material for me. I find it both visually striking and mathematically elegant.

In that vein I have a few observations about the program that I hope might be helpful.


1. The grid-spacing between cells at magnifications nearer than 1:2 is bothersome for visual capture and editing. It would be a blessing to have that option as a toggle to be turned on and off.

2. Finer control over generation speed (while generating) under 1s would also be a blessing. Say, a step counter in the preferences that would allow me to + or - at a predetermined delay amount.

3. At further distances of magnification (2^x) all cell state colors seem to revert to the State 1 color chosen in the gradient. If there was a way, instead, to calculate the color based on nearest neighbor--or a similar reduction method--I think it would greatly enhance the program's capability at large view sizes.

4. Lastly is a bit of a wish for me. Being able to use Golly's timeline to export generations as multiple files or all in one file as a gif/video would be my dying wish. It seems perfectly suited and there is a lot of control therein that would be excellent to have as exportable. Also, the speed slider in the timeline doesn't seem to display what speed it's actually running at, it would be nice to know somehow.

Thank you very much for your work on the program and making it accessible to people like me, with little training in the mathematics that power it. Thank you, also, for taking the time to read this.
Rlo
 
Posts: 6
Joined: June 12th, 2013, 11:26 pm

Re: Golly 2.5 has been released

Postby dvgrn » June 15th, 2013, 10:30 pm

Rlo wrote:1. The grid-spacing between cells at magnifications nearer than 1:2 is bothersome for visual capture and editing. It would be a blessing to have that option as a toggle to be turned on and off.

You can toggle the grid on and off with the 'L' key. There's also a setting in File > Preferences > View that lets you set how close you have to zoom in before the grid appears.

Rlo wrote:2. Finer control over generation speed (while generating) under 1s would also be a blessing. Say, a step counter in the preferences that would allow me to + or - at a predetermined delay amount.

File > Preferences > Control -- I always change the minimum delay to 10 milliseconds, since the default 250 seems much too large for what I'm usually doing.
dvgrn
Moderator
 
Posts: 3879
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests