Golly suggestions

[dvgrn]

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!

Yup, no objection to supporting headerless RLE, for sure -- the lack of that support keeps causing various minor problems.

No need to allow Spaces in Weird Places, because the lack of that support hasn't ever caused any actual problems. The Leading Space Due To Copy/Paste certainly has caused some mystifying troubles on occasion, though.

[hkoenig]

There's nothing wrong with requiring there to not be whitespace in a parseable token. In the case of RLE runs, that means that the count and the bit-type are a single token, and not split by whitespace or line breaks. In the header, is x=10 a single token, or three tokens? (I prefer three.)

Then again, is there even still a reason to require a header? The dimensions can be derived from the pattern, and should not be needed to generate that pattern. Knowing the dimensions in advance can be useful to a person, but how does it help in decoding. (Another check for the validation suite: seeing if the dimensions in the header match the dimensions in the pattern. And does the parser even care?)

At some point supporting flexibility, or backwards compatibility, enters the realm of absurdity and diminishing returns. Some of the requirements made sense when RLE was first defined. For example, the header made sense when programs may need to allocate a fixed array. The 70 character line length is another obsolete requirement. We aren't using memory measured in kilobytes any more, or Hollerith cards. (My first Life program fixed the width of the universe at 132 because that was the line length produced by the chain printers I used for output.)

[rowett]

Chris, if you want to make the changes, that would be great!

Sure, no problem.

The only one I'm a little unhappy with is supporting whitespace between counts and verbs (and within counts).

Agreed.

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.

Golly's current implementation doesn't flag issues with illegal multistate values as an error. The code says:

Code: Select all

	// return "Illegal multi-char state";
	// be more forgiving so we can read non-standard rle files like
	// those at http://home.interserv.com/~mniemiec/lifepage.htm
	state = 1;

It clearly used to but now just sets illegal multistate definitions to state 1. How would you like this handled?

[rowett]

In the header, is x=10 a single token, or three tokens? (I prefer three.)

Three.

In fact Golly's RLE parser handles the header line as follows:

• In order for a line to be recognized as a header line it must start with x followed by = or any ASCII character from code 1 to code 32 (space). I expect this is a quick way of matching whitespace since TAB is code 9 and it's unlikely the input will contain other control characters. New line (either CR 13 or LF 10) won't be here since the line reader removes them.
• To read the x value the reader starts at the beginning of the line and skips any characters that are not =. It then uses sscanf() to decode an integer from the character after the =.
• To read the y value the reader continues skipping characters until it finds the next = character. It then uses sscanf() to decode an integer from the character after this second =.
• To read the rule it skips characters until it finds r. If then checks if the string rule is at this position. If so then it skips any number of = or ASCII characters from code 1 to code 32. FInally it searches for any trailing , character and removes it if present.

Then again, is there even still a reason to require a header? The dimensions can be derived from the pattern, and should not be needed to generate that pattern. Knowing the dimensions in advance can be useful to a person, but how does it help in decoding. (Another check for the validation suite: seeing if the dimensions in the header match the dimensions in the pattern. And does the parser even care?)

The Golly documentation says (Help>File Formats):

The line starting with "x" gives the dimensions of the pattern and usually the rule, and has the following format:
x = width, y = height, rule = rule
where width and height are the dimensions of the pattern and rule is the rule to be applied. The dimension data is ignored when Golly loads a pattern, so it need not be accurate, but it is not ignored when Golly pastes a pattern; it is used as the boundary of what to paste, so it may be larger or smaller than the smallest rectangle enclosing all live cells.

It also impacts where the pattern is placed on the grid (especially noticable in bounded grids). For example:

Code: Select all

x = 3, y = 3, rule = B3/S23:T6,6
3o$o$bo!

Code: Select all

x = 6, y = 3, rule = B3/S23:T6,6
3o$o$bo!

However, I don't know how often this is used or how helpful it is.

EDIT: More details in the answer to the first question.

[dvgrn]

It also impacts where the pattern is placed on the grid (especially noticable in bounded grids). For example:

Code: Select all

x = 3, y = 3, rule = B3/S23:T6,6
3o$o$bo!

Code: Select all

x = 6, y = 3, rule = B3/S23:T6,6
3o$o$bo!

However, I don't know how often this is used or how helpful it is.

So... LifeViewer and Golly both automatically center the pattern within the bounds, if the bounds are larger than the pattern? That seems reasonable.

If I wanted to be sure the glider was placed starting at (+2, +2) I'd just give the full 6x6 pattern:

Code: Select all

x = 6, y = 6, rule = B3/S23:T6,6
2$2b3ob$2bo3b$3bo2b$6b!

[confocaloid]

Here is an example, when it was desirable to choose a specific location for a pattern in a torus (from OCA:Iceballs). The three-cell seed is positioned so that the iceball starts forming near the center.

Code: Select all

#C A 3-cell pattern on the 20x20 torus runs chaotically, with average density about 25%,
#C until about gen 435175. Then an iceball forms, which slowly grows, filling the torus
#C completely in gen 435374. The same pattern, run on a 100x100 torus, forms an iceball
#C about gen 31300, which fills the torus at gen 31951.
x = 20, y = 20, rule = B25678/S5678:T20,20
$8b2o$10bo!

[rowett]

I've committed changes to Golly's RLE parser and headerless paste. All the changes are in gollybase/readpattern.cpp.

Changes made:

• Ignore blank lines containing only whitespace
• Ignore leading whitespace on any line
• Ignore rule definition with #r if a rule is already defined
• Throw an error if there is whitespace between a count and symbol in pattern body
• Throw an error if the count has a leading zero
• Respect initial blank rows or columns when pasting headerless RLE

Note:
Currently the parser ignores some illegal states (converts them to state 1). LifeVewer doesn't. Which is preferred?

For those that can please review and test the new code and let me know any issues.

[rokicki]

Thanks for the changes! I've looked at the code diffs and it all looks good so far. I'll try to get some testing in soon.

I don't think these changes justify rushing a release out but I'm grateful to have them underway.

[hkoenig]

Some of this is only obliquely related to Golly...

I've always written RLE parsers assuming that the lines are left-justified, and are padded on the right if shorter than the header dimensions. Similarly, rows are top-justified, with blank lines at the bottom. So, I would argue that centering should be considered non-standard or an extension of the definition. (But it does seem to work nicely for bounded arrays.)

It seems that Golly adds whitespace on the left and top with runs of blanks ("nnnb") or multiple blank lines ("nnn$"). This works, except you end up multiple RLE strings that are different but encode the same object, making string matching more complicated.

Here's a Glider, for example:

Code: Select all

x = 58, y = 50, rule = B3/S23
22$31b3o$31bo$32bo!

Long ago when I needed to define multiple RLE bit-patterns that would overlay, I added two parameters to the header, "h=" and "v=", to specify the horizontal and vertical offset relative to the first pattern in the array. That pattern didn't need these additions, and was assumed to have its upper-left corner at the origin, unless there was a specific offset. So the above Glider would be:

Code: Select all

x=3, y=3, h=31, v=22 3o$o$bo!

(Note how that's not considered displayable because of the missing linebreak.)

Here's another example, using the stages of an monlithic construction pattern I got from Catagolue, compared to one partitioned into multiple patterns.

Code: Select all

x = 150, y = 50, rule = B3/S23
2bo$obo$b2o7$36bo$35bo$35b3o$29bo$29bobo$29b2o$33b3o$33bo$34bo$96b
2o2bo34b2o2bo$96bo2bobo33bo2bobo$97bobobo34bobobo$98bo2b2o34bo2b2o
$99b2o2bo34b2o2bo$102b2o37b2o$87b2o56bobo$86bo2bo55b2o$87bobo45bo
10bo$88bo46b2o$134bobo3b2o$90b3o46b2o$90bo50bo5b2o$91bo55bobo$147b
o$143b2o$142bobo$144bo5$19b2o$13b2o5b2o31b3o$4b3o5bobo4bo33bo$6bo
7bo39bo$5bo3$53bo$52b2o$52bobo!

Code: Select all

#C partitioned into stages
x=56, y=50
2bo$obo$b2o7$36bo$35bo$35b3o$29bo$29bobo$29b2o$33b3o$33bo$34bo23$19b2o$13b
2o5b2o31b3o$4b3o5bobo4bo33bo$6bo7bo39bo$5bo3$53bo$52b2o$52bobo!
x=18, y=14, h=86, v=18
10b2o2bo$10bo2bobo$11bobobo$12bo2b2o$13b2o2bo$16b2o$b2o$o2bo$bobo$2bo2$4b
3o$4bo$5bo!
x=16, y=18, h=134, v=18
b2o2bo$bo2bobo$2bobobo$3bo2b2o$4b2o2bo$7b2o$11bobo$11b2o$bo10bo$b2o$obo3b
2o$5b2o$7bo5b2o$13bobo$13bo$9b2o$8bobo$10bo!

(Note that I still try to respect the line length limit, although if I didn't, this could be formatted as three long lines.)

The partitioned version is a little larger than the solitary version, but I think it's worth it. This is the way stamp collections should be organized. It should be relatively easy to compare the encoded bitpatterns to find the changed objects or new objects. There could also be comment lines and blank lines annotating the pattern, too. Viewer programs like Golly could even have a "Paste as stamp collection" which would determine a nice layout based on the sizes of the sub-patterns.

[muzik]

Would it be possible to allow cells of the same state to use different icons depending on their position within the grid? Alternating triangle icons would make editing triangular grid patterns far more intuitive in Golly.

[squareroot12621]

I'm not sure if that would work, considering that square icons in @ICONS sections would have to somehow fit a triangle.
(Oops, 600ᵗʰ post.)

[Andrew]

I've committed changes to Golly's RLE parser and headerless paste. All the changes are in gollybase/readpattern.cpp.

Thanks Chris. I've documented those changes so feel free to make any corrections or additions to what I've written.

I think we've got enough changes to justify releasing Golly 4.3b1 so I'll do the builds in a few days.

[hotdogPi]

Immediately before 4.3 gets released, one or both of two things should happen:

1. I update b3s23osc to add the new oscillators found during that time. (I've already added them to my personal .txt file; I just need to upload them to Github.)

2. The mid-2023 https://github.com/carson-cheng/newjslife/tree/main collection should be added, which is more comprehensive than b3s23osc. Note that this has not been updated for several months, and updating it would require doing another forum scrape and manually removing duplicates.

[dvgrn]

2. The mid-2023 https://github.com/carson-cheng/newjslife/tree/main collection should be added, which is more comprehensive than b3s23osc.

What exactly do you think should be added from "newjslife" (or whatever it might get called instead, like "newosc-{date}")?

That looks to me like a lot of big RLEs, and a big addition to the ongoing maintenance task for the Golly pattern collection. Big comprehensive collections like that haven't really ever been prioritized for inclusion in the pattern collection that's bundled with Golly; Golly's download size would quickly get annoyingly large. This looks more like the kind of case where we put a link to the newjslife collection into one of the Online Archives HTML docs, and/or into the comments of the b3s23osc collection.

Another good option might be hosting a LifeViewer-enabled set of pages on conwaylife.com/ref/newosc/ -- using PatMan or something similar -- and have links in Golly point to that location. That would make the patterns a lot more accessible than they are in the current GitHub-repo text file format, but it would de-couple the update process from Golly's release schedule.

There are some stamp collections like b3s23osc that it seems important to include in the patterns bundled with Golly. But for most stamp collections -- like the "h-to-h" Herschel conduit collection, for example -- it's actually more important to have the links available to where the latest information can actually be found ... because the patterns bundled with Golly will almost inevitably be out of date, sooner rather than later.

That's why the h-to-h collection has that automatic pop-up HTML page with all of the relevant links. Hopefully on average it's not too annoying, or at least it's more useful than annoying. (If not, people can always save an .mc or .rle copy and delete the original zip file.)

[Antonin Duda]

update android

[confocaloid]

From my testing, the old issues with leading whitespace appear to be resolved in 4.3b1.
However, when opening each of the following two patterns via "Open Clipboard",

• the pattern comment is lost for the first pattern (View Pattern Info shows "No comments found.")
• the pattern comment is preserved for second pattern

Comments should be preserved in both cases.

[...]

Code: Select all

 #C The leading space breaks things
x = 10, y = 5, rule = B3/S23
2b6o$bo6bo$o8bo$bo6bo$2b6o!

Code: Select all

#C The leading space breaks things
 x = 10, y = 5, rule = B3/S23
2b6o$bo6bo$o8bo$bo6bo$2b6o!

[rowett]

Comments should be preserved in both cases.

This should be fixed now. Thanks for reporting!

[muzik]

Are there any plans for a dedicated script for viewing triangular patterns on a triangular grid like there is for hexagonal rules, or is this just entirely dedicated to LifeViewer at this point?

[rowett]

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?

An issue was reported here (and see my reply immediately below that post for triage) relating to the use of a 3rd party tool that is creating RLE with new lines between counts and verbs.

I'm not sure how many other tools out there will be creating now invalid RLE and if it is worth allowing newline as a break between counts and verbs to support them.

Thoughts?

[dvgrn]

An issue was reported here (and see my reply immediately below that post for triage) relating to the use of a 3rd party tool that is creating RLE with new lines between counts and verbs.

I'm not sure how many other tools out there will be creating now invalid RLE and if it is worth allowing newline as a break between counts and verbs to support them.

I guess I'll cast a very mild vote in favor of keeping things as they are: whitespace in inappropriate places means a chunk of text shouldn't be read as an RLE pattern, even if it would be valid RLE with the whitespace removed.

It's only a very mild vote, because the only reason I can think of for that limitation is to keep RLE a little bit more human-readable. That doesn't seem like a particularly important consideration most of the time, but maybe it's just enough of a reason to stick with tradition in this case.

[rowett]

As a side note the issue in the 3rd party tool has been fixed by the author.