Golly suggestions

[confocaloid]

Apart from the "SuperToHistory" part, there are other unnecessary inconsistencies between toHistory.lua and toSuper.lua. Suggested changes:
(trimmed)

Are there other significant changes in how the scripts work, other than g.setstep(step) and the changed message in toSuper?

[dvgrn]

Apart from the "SuperToHistory" part, there are other unnecessary inconsistencies between toHistory.lua and toSuper.lua. Suggested changes...

Thanks! Can you just post your "new" versions of the scripts? -- or else let me know what I'm doing wrong with git apply, if it's something obvious?

Code: Select all

C:\repos\golly-code\Scripts\Lua>git apply toHistory.patch
error: corrupt patch at line 17

C:\repos\golly-code\Scripts\Lua>git apply toSuper.patch

I'm working on Windows. I know enough to save the patch files with Unix-style line endings and a newline at the end, so it must be ... some other silly thing. But I've already wasted half an hour on this, and really I just want the actual files -- I can do my own diffs perfectly well, after all.

My "toSuper.patch" doesn't throw any errors, but it also doesn't actually apply any changes to toSuper.lua. Seems very odd.

[GUYTU6J]

Are there other significant changes in how the scripts work, other than g.setstep(step) and the changed message in toSuper?

No.

Apart from the "SuperToHistory" part, there are other unnecessary inconsistencies between toHistory.lua and toSuper.lua. Suggested changes...

Thanks! Can you just post your "new" versions of the scripts? ...

toHistory.lua (without updating comment)

Code: Select all

-- Fast [Rule] or [Rule]Super to [Rule]History converter,
--   intended to be mapped to a keyboard shortcut, e.g., Alt+H
-- Sanity checks and Lua translation by Dave Greene, May 2017
-- Creates special rule and runs it for one generation, then switches to Life 
-- Replace 2k + 1-> 1 and 2k -> 0
-- Preserves step and generation count
-- v1.1: skip the SuperToHistory conversion unless the current name has a "Super" suffix

local g = golly()

local rule = g.getrule()
local algo = g.getalgo()

ruletext = [[@RULE SuperToHistory
@TABLE
n_states:26
neighborhood:oneDimensional
symmetries:none
var a={0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25}
var b={a}
var withtrailON ={9,11}
var withtrailOFF={10,12}
var notrailON   ={13,15,17,19,21,23,25}
var notrailOFF  ={14,16,18,20,22,24}
var markedON    ={7}
var markedOFF   ={8}

notrailOFF  ,a,b,0
withtrailON ,a,b,1
notrailON   ,a,b,1
withtrailOFF,a,b,2
markedON    ,a,b,3
markedOFF   ,a,b,4]]

local function CreateRule()
    local fname = g.getdir("rules").."SuperToHistory.rule"
    local f=io.open(fname,"r")
    if f~=nil then
        io.close(f)  -- rule already exists
    else 
        local f = io.open(fname, "w")
        if f then
            f:write(ruletext)
            f:close()
        else
            g.warn("Can't save SuperToHistory rule in filename:\n"..filename)
        end
    end
end

-- deal with bounded-universe syntax appropriately
suffix = ""
baserule = rule
ind = string.find(rule, ":")
if ind then
    suffix = rule:sub(ind)
    baserule = rule:sub(1,ind-1)
end

-- No effect if the current rule ends with "History"
if algo == "Super" and baserule:sub(-7) == "History" then
    g.exit("The current rule is already a [Rule]History rule.")
end

step = g.getstep()
-- If rulestring contains "Super" suffix, remove it and continue
if algo == "Super" and baserule:sub(-5) == "Super" then
    baserule = baserule:sub(1,#baserule-5)
    CreateRule()
    g.setrule("SuperToHistory")
    g.run(1)
    g.setgen("-1")
end

-- attempt to set the new History rule to see if it is valid
local function tryrule()
    g.setrule(baserule.."History"..suffix)
end
local status, err = pcall(tryrule)
if err then
    g.note("Conversion failed. This '"..baserule.."' rule is not supported by the Super algo.\n"
           .. "To revert to the original rule, please click OK, then press Z to undo the rule change.")
    g.exit("Press Z to revert to the original rule.")
end

g.setstep(step)

toSuper.lua

Code: Select all

-- [Rule] or [Rule]History to [Rule]Super converter,
--   intended to be mapped to a keyboard shortcut, e.g., Alt+G

local g = golly()

local rule = g.getrule()
local algo = g.getalgo()

-- deal with bounded-universe syntax appropriately
suffix = ""
baserule = rule
ind = string.find(rule, ":")
if ind then
    suffix = rule:sub(ind)
    baserule = rule:sub(1,ind-1)
end

-- No effect if the current rule ends with "Super"
if algo == "Super" and baserule:sub(-5) == "Super" then
    g.exit("The current rule is already a [Rule]Super rule.")
end

step = g.getstep()
-- If rulestring contains "History" suffix, remove it and continue
if algo == "Super" and baserule:sub(-7) == "History" then
    baserule = baserule:sub(1, #baserule-7)
end

-- attempt to set the new Super rule to see if it is valid
local function tryrule()
    g.setrule(baserule.."Super"..suffix)
end
local status, err = pcall(tryrule)
if err then
    g.note("Conversion failed. This '"..baserule.."' rule is not supported by the Super algo.\n"
           .. "To revert to the original rule, please click OK, then press Z to undo the rule change.")
    g.exit("Press Z to revert to the original rule.")
end

g.setstep(step)

The "error: corrupt patch at line 17" was caused by an accidentally duplicated line, I think. And I just learnt that instead of copying lines on the console, the patch file should be obtained by specifying output ">name.patch" in the git diff command. Apologies

[nokangaroo]

SVG icon for Golly

The appicon.xpm that comes with Golly sucks (and xpm is deprecated). Here is an SVG icon that you can import into inkscape and modify to your liking:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
 version="1.0"
 width="128"
 height="128"
 xmlns="http://www.w3.org/2000/svg"
 xmlns:svg="http://www.w3.org/2000/svg">
 <defs>
  <radialGradient id="radialGradient1">
   <stop style="stop-color:#bbbbff;stop-opacity:1" offset="0"/>  <!--#a8a8e6-->
   <stop style="stop-color:#0000aa;stop-opacity:1" offset="1"/>  <!--#000099-->
  </radialGradient>
 </defs>
 <rect fill="#ffff00" width="128" height="128" rx="7"/> <!--#f9da22-->
 <g transform="matrix(0.24,0,0,-0.24,6.4,121.6)"
  style="fill:url(#radialGradient1);fill-opacity:1">
  <circle cx="40" cy="440" r="20"/>
  <circle cx="90" cy="440" r="20"/>
  <circle cx="140" cy="440" r="20"/>
  <circle cx="190" cy="440" r="20"/>
  <circle cx="240" cy="440" r="20"/>
  <circle cx="290" cy="440" r="20"/>
  <circle cx="390" cy="440" r="20"/>
  <circle cx="440" cy="440" r="20"/>
  <circle cx="40" cy="390" r="20"/>
  <circle cx="90" cy="390" r="20"/>
  <circle cx="140" cy="390" r="20"/>
  <circle cx="190" cy="390" r="20"/>
  <circle cx="240" cy="390" r="20"/>
  <circle cx="290" cy="390" r="20"/>
  <circle cx="390" cy="390" r="20"/>
  <circle cx="440" cy="390" r="20"/>
  <circle cx="390" cy="340" r="20"/>
  <circle cx="440" cy="340" r="20"/>
  <circle cx="40" cy="290" r="20"/>
  <circle cx="90" cy="290" r="20"/>
  <circle cx="40" cy="240" r="20"/>
  <circle cx="90" cy="240" r="20"/>
  <circle cx="390" cy="290" r="20"/>
  <circle cx="440" cy="290" r="20"/>
  <circle cx="390" cy="240" r="20"/>
  <circle cx="440" cy="240" r="20"/>
  <circle cx="40" cy="190" r="20"/>
  <circle cx="90" cy="190" r="20"/>
  <circle cx="390" cy="190" r="20"/>
  <circle cx="440" cy="190" r="20"/>
  <circle cx="40" cy="140" r="20"/>
  <circle cx="90" cy="140" r="20"/>
  <circle cx="40" cy="90" r="20"/>
  <circle cx="90" cy="90" r="20"/>
  <circle cx="190" cy="90" r="20"/>
  <circle cx="240" cy="90" r="20"/>
  <circle cx="290" cy="90" r="20"/>
  <circle cx="340" cy="90" r="20"/>
  <circle cx="390" cy="90" r="20"/>
  <circle cx="440" cy="90" r="20"/>
  <circle cx="40" cy="40" r="20"/>
  <circle cx="90" cy="40" r="20"/>
  <circle cx="190" cy="40" r="20"/>
  <circle cx="240" cy="40" r="20"/>
  <circle cx="290" cy="40" r="20"/>
  <circle cx="340" cy="40" r="20"/>
  <circle cx="390" cy="40" r="20"/>
  <circle cx="440" cy="40" r="20"/>
 </g>
</svg>

As SVGs go, this is rather bare (handwritten except for the coordinates of the circles, which are the result of tracing an existing icon). Save the code as golly.svg and import it into inkscape, which will add the missing pieces and export it as a valid PNG image about 1.5 kB in size at 96 DPI (can also be done with Gimp but the resulting PNG will be bigger). Try the commented colors for warmer tones.

[confocaloid]

What potential exists for expansion of the "Patterns/HashLife/Metacell" folder? Currently it lists eight files, four of which are patterns in Conway's Game of Life and four are patterns in a single other rule.
How likely it is that the folder will get multiple patterns in multiple rules other than Life?

[Cyclotrons]

Hello. I have a rulestring parser + transition function for range-1 multistate rules in C++, as well as an explainer for the format. What work would have to be done to get it integrated into Golly?

msint-transition-implementation.cpp

(46.56 KiB) Downloaded 21 times

(since it's not allowing me to attach the explainer file I'll put it here)

Code: Select all

<html>
    <head>
        <title>Golly Help: Multistate INT</title>
    </head>
    <body bgcolor="FFFFCE">
        <p>Multistate INT is a family of non-totalistic cellular automata that obey D8 [sic] symmetry on the range-1 moore neighborhood. Transitions from one state to any other state can be specified.</p>

        <h2>Overview</h2>
        <p>The notation used for this rulespace is a series of constraints that a neighborhood configuration must fulfill for a non-default state transition to occur. By default, every cell will transition to state 0.</p>

        <h3>Transitions</h3>
        <p>Transitions signify a cell's state will change to upon advancing the universe a generation, given a constraint is met. A transition from state <i>a</i> to state <i>n</i> is notated as <i>aTn</i>, with <i>a</i> and <i>n</i> standing in for numbers. Also note <i>Bn</i> and <i>Sn</i>, which are shorthand for <i>0Tn</i> and <i>nTn</i> respectively.</p>
        <p>Transitions may be included and omitted freely, and in any order. As conflicting transitions are possible, transitions specified earlier in the rulestring will take priority.</p>
        <p>Transitions are delimited by a '/' in front of them, except at the beginning of the rulestring, where it must be omitted.</p>

        <h3>Constraints</h3>
        <p>Constraints are the conditions under which a transition is allowed. Under a transition, only one full constraint needs to be satisfied for a state change to occur. Constraints work by specifying the a series of configurations that cells of specific states in the neighborhood must adhere to.</p>
        <p>In a constraint, configurations are listed one after another, delimited by ';'. Configurations are specified in the format <i>x+y+z:nh</i>, with <i>x</i>, <i>y</i>, and <i>z</i> representing the cell states being considered, <i>n</i> representing the number of those cells in the neighborhood, <i>h</i> representing a specific shape as defined in hensel notation, and ':' acting as a delimiter between states and configuration. <i>n</i> and <i>h</i> can be omitted if you don't want it to be considered in the configuration.</p>
        <p>States don't have to be specified explicitly: in a constraint, state 0, then 1, then 2... is assumed in configurations where states aren't explicitly specified. However, once a state is explicitly specified in a configuration, all following configurations must also be explicitly specified.</p>
        <p>Constraints are delimited on both sides by '.', but these may be replaced by either '-' or '/'. '/' may only replace the end delimiter.</p>
        <p>An example constraint: <i>.;2a;1c;1+2:3i;2+3:3i;1+2+3:5a;3:2a.</i></p>
        <p>-state 0 cells are unconstrained<br>
        -state 1 cells must occur in the 2a configuration<br>
        -state 2 cells must occur in the 1c configuration<br>
        -state 3 cells must occur in the 2a configuration<br>
        -state 1 and 2 cells must occur in the 3i configuration<br>
        -state 2 and 3 cells must occur in the 3i configuration<br>
        -state 1, 2, and 3 cells must occur in the 5a configuration<br></p>
        <p>This is the only neighborhood that satifies this constraint:<br>
        1 1 2<br>
        0 o 3<br>
        0 0 3</p>

        <h3>Subconfigurations</h3>
        <p>After a constraint, but before its delimiter, you may specify additional constrains in a series of parens ('(', ')'), which means that any neighborhood that satifies the main constraint must also have subconfigurations that would satisfy the constraints within each set of parens.</p>

        <p>As an example: <i>.(;2a;1c;1+2:3i;2+3:3i;1+2+3:5a;3:2a).</i> (note: an empty constraint means that all neighborhoods satisfy it) represents<br>
            1 1 2<br>
            x o 3<br>
            x x 3<br>
        where <i>x</i> may be any state.</p>

        <h3>Negation</h3>
        <p>Under a transition, a '-' may be used to specify that neighborhoods that satisfy the constraints after it will not cause the transition to occur. These takes priority over non-negated constrains.</p>

        <h2>Example Rules</h2>
        <p><b>B1.;3/S1.;2.;3</b> - Life</p>
        <p><b>B1.;2/1T2.</b> - Brian's Brain</p>
        <p><b>B1.;3;0/B2.;0;3/S1.;;1.;;2.;;3.;;4.;;5.;;6.;;7.;;8.;2.;3./S2.;1.;2.;3.;4.;5.;6.;7.;8.;;2.;;3</b> - Symbiosis</p>

    </body>
</html>

Edit: fixed a very stupid mistake in the code

[confocaloid]

In future versions of Golly, can it be made so that patterns with invalid rules (or headerless RLE strings) can still be pasted properly?

This is a good point, and I definitely ought to dig around in Golly's code and see if I can implement it somehow. I'm not sure I'll actually find time for this, but I'll definitely upvote the idea!
[...]

Suggestion:
o When opening a pattern in an unknown rule, fall back to the rule "//256" (or "//n" for the smallest n that suffices).
o When pasting a RLE in an unknown rule into an existing universe, either paste without changing current rule (if the current rule has enough cellstates) or attempt to switch to "//256" or "//n" (if preferences in "Preferences/Edit/When pasting a clipboard pattern" allow changing rule in this case).
o Always show a warning when opening/pasting a pattern in an unknown rule.

Code: Select all

x = 37, y = 38, rule = //7
24.2A$24.A$21.A4.A2.2A$21.5A.A2.A$7.2A16.B.2A.A.2A$8.A10.4AB3AB2.A2.A
$8.A.AB7.A2.A.A3B2A.A$9.2AB.3B4.7B2.A.2A$11.7B3.7B.A$11.16B.2A$12.15B
$11.16B$9.18B$7.19B$7.2BE15B3.2A$6.3BEBE4B.7B5.A$7.2B3E4B2.7B4.A.2A$
6.5BE4B2.8B4.A.A$5.10B4.7B5.B$4.4B10.8B2.B.3B$4.3B11.8B.7B$2.4B12.17B
$2.2C14.18B$3.C13.20B$3C15.19B$C17.19B$19.17B$20.11B$24.6B$24.7B$23.
8B$24.6B$25.5BD$25.4BDBD$25.5B2D$25.6B$26.4B$27.2B!

[otismo]

We have Golly for Android AND iPad -

lastime I checked there were over

200 Android Apps - some free and

some were also for sale as well.

Golly is the best App.

License says a distro "fee"

can be charged...

B4 I make my proposal,

I want to make this a Community Project

( just in case it leads to a great deal of $$$money$$$ ).

50/50 or what's your pleasure ?

( becuz the Little Red Hen has to be paid for doing EVERYTHING ).

[Andrew]

... License says a distro "fee"

can be charged...

What on earth are you talking about? Golly is a free app. (And why are all your posts double spaced? Quite irritating.)

[otismo]

... License says a distro "fee"

can be charged...

What on earth are you talking about? Golly is a free app. (And why are all your posts double spaced? Quite irritating.)

Golly is an open source, cross-platform application for exploring
John Conway's Game of Life and many other types of cellular automata.
Copyright (C) 2005-2021 The Golly Gang (Andrew Trevorrow, Tomas Rokicki,
Tim Hutton, Dave Greene, Jason Summers, Maks Verver, Robert Munafo,
Brenton Bostick, Chris Rowett, Dongook Lee).
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License (see below), or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Web site: https://sourceforge.net/projects/golly
Contacts: rokicki@gmail.com andrew@trevorrow.com
======================================================================
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not <---------- FROM HERE
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things. <---------- TO HERE
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether <------ also
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software <----- noteworthy
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

ETC. - copy of License.html

[Andrew]

... For example, if you distribute copies of such a program, whether <------ also
gratis or for a fee, ...

Yes, and obviously I decided to distribute the iPad/Android versions of Golly for free.

[otismo]

... For example, if you distribute copies of such a program, whether <------ also
gratis or for a fee, ...

Yes, and obviously I decided to distribute the iPad/Android versions of Golly for free.

Obviously I plan on offering my own APP

which could be an Official or un-official

version of Golly - or something different

I take it you are purists then, and don't want anyone modifying your software...

BTW

could signal code "in-pattern"

be made to control Golly ?

thru some RULE or State

to change speed, zoom

( I know, you would tell me, "We have Life Viewer for that." )

Thank You !

[dvgrn]

I take it you are purists then, and don't want anyone modifying your software...

That doesn't seem to follow at all. If the Golly Gang didn't want anyone modifying Golly, then the obvious thing to do would be to not make the source code publicly available. Anyone is free to do as much modifying as they want.

Maybe a more accurate statement would be that at least some of the Golly Gang takes a rather dim view of the idea of spending any their time trying to figure out how to charge for (an unspecified variant of) something that is currently free. If it's basically the same app, then why would people buy it when they don't have to? If the new version has such-and-such wonderful new features, then it seems like the obvious thing for the Golly Gang to do will be to take the new-feature code (since the license says the source has to remain available) and put it into the free version immediately.

Long story short, it's sometimes a very useful thing to write software and make money from it -- but other times it just doesn't look like there's any significant accessible pot of money out there that can be tapped, at least not without making a lot of unpleasant noise and annoying a lot of people.

Everyone who might try something like that is too busy having fun with CA to risk wasting any time making themselves miserable, trying and failing to make money off of CA software.

...could signal code "in-pattern" be made to control Golly ?
thru some RULE or State to change speed, zoom ( I know, you would tell me, "We have Life Viewer for that." )

It could certainly be done via a Python or Lua script. Just for example, design some computer circuitry (or whatever) that sends a glider to switch the state of a switch somewhere whenever some Golly parameter should be changed -- and then use the Golly script to run the pattern while monitoring those switches. That would be a Life pattern that controls its own display parameters in Golly.

[otismo]

@ dvgrn :

Modification begins with re-branding.
Tiny File Manager AND OneFileCMS
both understand this ( both on github )
and WANT their software to be
BUNDLED with other proprietary CMS
( usually not much more than a Theme or Template ).
And I don't even WANT to re-brand Golly,
just make it my APP-of-Choice to run my
( maybe branded, probably not )
Pattern Collections.
Yes, one such Collection will, in fact,
be called Novelty Items.
Another "Must See on your Giant Screen TV!".
ViroPet.com of course must be branded
so I can maintain control over what
I will be sending youz : a fresh
crop of 10-year-olds
EVERY YEAR.
And youz had BETTER know how to
take very good care of them -
as I am sure you will . . .
AND
if youz think for one minute
that I am doing this for $$$,
you are out of your G-D M-Fing minds !
I have much better ways of making
WAY more dough
in a LOT less time...
What I need for ViroPet is Golly WebApp
and I need total control of Patterns
and Information in Patterns.
It is a big Pain in the Butt
to have to put Text-in-Patterns -
but I believe I am getting the knack of it...

[confocaloid]

Bump a known issue. For some reason, different people over time consistently post "code" blocks with RLEs that begin with whitespace.

Although this seems to be a known issue, I wanted to post it here as a suggestion. LifeViewer seems to ignore leading spaces in RLEs. I think Golly should do the same. Right now, when trying to paste in Golly a RLE with leading spaces, the result is broken.
[...]

[...]
LifeViewer doens't care about the extra space because it strips them while parsing the RLE.

So I guess the options are:

• Have LifeViewer remove the leading space while it processes the code block generated by the viewer tag
• Adjust Golly's parser so it ignores leading whitespace for a recognized header line in an RLE

There was another question recently about Golly and leading spaces but I can't find the reference at the moment.

Thoughts?

[...]
It would probably be good in general if Golly stripped leading white space when parsing a pattern.

[otismo]

Should Golly be/become/morph-into an A. I. ?

More generally, should-there-be/can-there-be a CA-based A. I. ?

Thank You.

[azulavoir]

Should Golly be/become/morph-into an A. I. ?

Um.. no? What would this even mean?

More generally, should-there-be/can-there-be a CA-based A. I. ?

I don't see a value in it. CA are generally fairly poor emulations of things that aren't hyper specialized, and you'd get more processing power out of just running the AI directly than the layer of abstraction making it a CA.

[otismo]

Should Golly be/become/morph-into an A. I. ?

Um.. no? What would this even mean?

More generally, should-there-be/can-there-be a CA-based A. I. ?

I don't see a value in it. CA are generally fairly poor emulations of things that aren't hyper specialized, and you'd get more processing power out of just running the AI directly than the layer of abstraction making it a CA.

It would be an A. I. that has CGoL as its roots...

AND

We want MORE out of A. I. than just more processing power...

"the layer of abstraction making it a CA" would be OUR Compatability Layer...

Thank You !

[rokicki]

Bump a known issue. For some reason, different people over time consistently post "code" blocks with RLEs that begin with whitespace.

Although this seems to be a known issue, I wanted to post it here as a suggestion. LifeViewer seems to ignore leading spaces in RLEs. I think Golly should do the same. Right now, when trying to paste in Golly a RLE with leading spaces, the result is broken.
[...]

I just noticed this; sorry I don't follow this thread as often as I'd like!

I think this is reasonably important, and should be addressed in Golly or in LifeViewer. I'm not sure what
*exactly* Golly does right now with leading spaces (or leading newlines, or a combination thereof) but
certainly Golly and LifeViewer should be fully in-sync on this.

There can be arguments made towards leniency (real users use the software; copying may introduce
extra spaces or newlines, or people might assume it doesn't make a difference; in general for user
text files whitespace should never matter) and against leniency (it makes parsing harder, especially
n other code that tries to be compatible; it implicitly expands the file format definition in ways
that might not be intended). I'd love to hear some comments if anyone has any on this.

I'm okay with skipping leading spaces at the beginning of files, and also empty lines (or lines that
include only whitespace) at the beginning of files. But I'm not okay with expanded acceptance of
whitespace *after* the first nonblank token (at this point). And I don't feel strongly on this. The
main reason is there's precedence for files with leading whitespace (in the forum), and I don't want
those links to break, so I think changing LifeViewer is not a good idea.

I *do* think the parsers in LifeViewer and Golly should be 100% compatible, even to the point of
wanting to fuzz both to find nasty tiny hidden incompatibilities.

If we do decide to modify Golly's file reading and rule recognition code, I think this would be an
excellent bug fix/feature for someone who perhaps has wanted to contribute to Golly to get
started with. So if someone wants to jump on this, let us know. Or I can do it of course.

-tom

[rowett]

I *do* think the parsers in LifeViewer and Golly should be 100% compatible, even to the point of
wanting to fuzz both to find nasty tiny hidden incompatibilities.

LifeViewer takes the approach of being super lenient on read and strict on write.

On read: Leading and trailing whitespace on each line in the header is ignored and whitespace is optional in the header definition. All whitespace is ignored in the pattern body.

On write (Save or Copy to Clipboard): The header format is "x = <value>, y = <value>, rule = <rule>" (single spaces around = and after ,). The pattern data is written without whitespace and keeping each line to around 70 characters. This strict approach is to ensure compatibility with other tools.

EDIT:
Notes on Golly's RLE parser. Blue highlight indicates a difference from LifeViewer. Red highlight indicates a difference from LifeViewer that is undesirable behaviour.

• Blank lines before the header are ignored.
• Lines containing only whitespace before the header prevent the pattern being recognised as RLE.
• The header requires that there is no whitespace before the inital x or #.
• Newlines in the pattern body are ignored which means blank lines are allowed after the header or in the pattern body.
• Whitespace in the body is ignored except when it falls between a count and a symbol, in which case it resets the count to 1.
• Golly supports #r<survival>/<birth> to define the rule (from XLife).
• Comments are allowed in the pattern body (lines starting with #) but this also means it's possible to redefine the rule with #r.
• It's possible to have a second header line in the pattern body beginning "x=" or "x ".

[rowett]

If we do decide to modify Golly's file reading and rule recognition code, I think this would be an
excellent bug fix/feature for someone who perhaps has wanted to contribute to Golly to get
started with. So if someone wants to jump on this, let us know. Or I can do it of course.

It looks like it's a relatively simple change to Golly. Please let me know if the following are the requirement:

• Ignore blank lines or lines containing just whitespace (space, tab) at the beginning of an RLE pattern
• Ignore leading whitespace (space, tab) before the RLE header line e.g. " x = 3, y = 7, rule = B3/S23"
• Ignore whitespace in the pattern body
• Disallow rule definition in the pattern body (either "#r" or "x = ...")
• Make these changes specific to decoding RLE format patterns and no other format

EDIT:
Updated the requirement list.

[confocaloid]

EDIT:
Notes on Golly's RLE parser. Blue highlight indicates a difference from LifeViewer. Red highlight indicates a difference from LifeViewer that is undesirable behaviour.

• ...
• Lines containing only whitespace before the header prevent the pattern being recognised as RLE.
• The header requires that there is no whitespace before the inital x or #.
• ...

I think those are also undesirable. For example, the following text snippets seem to be parsed and processed in the expected way by LifeViewer:

Code: Select all

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

Code: Select all

 #C
x = 3, y = 3, rule = B3/S23
bo$2bo$3o!

Code: Select all

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

However, pasting them into Golly 4.2 produces this (I pasted all three in a single column), which is unexpected/undesirable:

Code: Select all

x = 28, y = 23, rule = B3/S23
bobobo2bobobo2b4obob6o$2o10b3o10b3o9$b2o$obobo2bobobo2b4obob6o$2o10b3o
10b3o9$obobo2bobobo2b4obob6o$2o10b3o10b3o!

(A different issue)
I think single-line headerless RLEs with empty leading rows and/or columns should be pasted from clipboard the same way as RLEs with a header. Right now (Golly 4.2), when I attempt to paste a headerless RLE (only the second line in the example below), it works as if it was a 3x3 RLE (i.e. empty rows/columns are ignored). I think it should instead be pasted in the same way as the "headerful" RLE is pasted (i.e. preserving leading empty rows and columns).

Code: Select all

x = 10, y = 10, rule = B3/S23
2$4bo$5bo$3b3o!

One case when this is important is when a search program/script outputs a headerless RLE with a fixed size, which can have leading empty rows/columns, and which is meant to be pasted/inserted into a specific location. Dropping leading empty rows/columns means that the search result will not be pasted correctly.

[hkoenig]

You might consider putting together a validation suite of patterns and objects that an RLE parser should be able to handle, or at least fail gracefully.

Similarly, an RLE validator webpage would be useful for testing the RLE output. It could inform a developer if the submitted RLE conforms to the strict definition, or a loose one (line lengths > 70, for example), or not at all.

Or do these exist and I'm just not aware of them?

Thet seem like useful projects for someone who wants to get involved with Life programming.

[rowett]

You might consider putting together a validation suite of patterns and objects that an RLE parser should be able to handle, or at least fail gracefully.

Similarly, an RLE validator webpage would be useful for testing the RLE output. It could inform a developer if the submitted RLE conforms to the strict definition, or a loose one (line lengths > 70, for example), or not at all.

Or do these exist and I'm just not aware of them?

Definitely needed. I have some test files but nothing that rigorous.

Before that I'd be happy with a clear specification: I noted some initial thoughts in the requirements list above.

[rokicki]

I believe your list of requirements looks good. We should also probably do the "headerless" fix; I can't think of a reason why not.

Chris, if you want to make the changes, that would be great! No one else has volunteered . . .

I think all the fixes should be pretty easy.

The only one I'm a little unhappy with is supporting whitespace between counts and verbs (and within counts). I don't think
"12 o" should be legal, much less "1 2o", where the space is any sort of whitespace (newlines, tabs, spaces). I just don't see
a reason that should be supported. Does anyone want to argue that this should be supported?

For consistency, that would seem to mean we should support header lines such as

x = 1 2 3 , y = 7 8 9

and that's just madness; next we'll allow spaces in rules so "Li Fe" needs to be parsed as ordinary life!

There is a potential similar issue with multistate RLEs, where we use a sequence of two letters to indicate some states. I
don't think we should permit spaces between those two letters.