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

RLE grammar

For scripts to aid with computation or simulation in cellular automata.

RLE grammar

Postby tomdunn » March 6th, 2019, 1:29 am

Hi all,

In case this is useful to anyone... I'm about to write an RLE parser and I wrote up this grammar based on the page from LifeWiki:

Run Length Encoded (RLE) File Format Grammar
============================================

See http://www.conwaylife.com/wiki/Run_Length_Encoded

For description of this Augmented BNF Style Grammar, see https://tools.ietf.org/html/rfc2616/#section-2.1

rle-file        = *(hash-line)
                  header-line
                  1*(run-item [LWS]) "!" [comment]      ; Lines in the RLE file MUST NOT
                                                        ; exceed 70 characters
hash-line       = "#" line-type LWS (comment | rule-set | *TEXT) CRLF
line-type       = "C" | "c"  ; comment
                | "N"        ; pattern name
                | "O"        ; file creator
                | "P" | "R"  ; top-left corner coordinates
                | "r"        ; rule-set
comment         = *TEXT
rule-set        = birth-counts "/" survival-counts
birth-counts    = *(DIGIT)   ; numbers of live neighbors for dead cell to be born
survival-counts = *(DIGIT)   ; number of live neighbors for live cell to survive
header-line     = "x = " pattern-width ", y = " pattern-height
                  [", rule = " bs-rule-set] CRLF
pattern-width   = *DIGIT     ; the width, in cells, of the pattern
pattern-height  = *DIGIT     ; the height, in cells, of the pattern
bs-rule-set     = ("b" | "B") birth-counts "/" ("s" | "S") survival-counts
run-item        = run-count tag
run-count       = *(DIGIT)   ; run-count can be omitted if it is 1
tag             = "b" | "B"  ; dead cell
                | "o" | "O"  ; alive cell
                | "$"        ; end of line

Also at:
https://gist.github.com/thomasdunn/d70b ... 07e7e9c067
tomdunn
 
Posts: 8
Joined: March 5th, 2019, 4:57 pm

Re: RLE grammar

Postby wildmyron » March 6th, 2019, 4:21 am

Thanks for sharing this. Whenever I've done anything with RLE I've generally ignored everything except the actual pattern so I haven't bothered with trying to maintain a complete representation.

I don't know the syntax particularly well, but the grammar looks good to me except for one detail. There are many RLE encoded patterns which are for cellular automata which don't conform to the semi-totalistic Bxx/Syy notation. Additionally some simulators give CA rules nicknames which can also be used as the rule name in RLE. You can see many examples of such patterns on the Other Cellular Automata board. I don't know if a pattern reader using your grammar would fail gracefully in this case or if it would choke on the non B/S form for the rule, but perhaps something to consider accommodating.

It's also worth noting that the format has been extended to CA with >2 states. This format is described in Golly's help.
The latest version of the 5S Project contains over 47,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1110
Joined: August 9th, 2013, 12:45 am

Re: RLE grammar

Postby dvgrn » March 6th, 2019, 8:21 am

A couple of other things maybe worth mentioning:

1) Almost every RLE parser is more forgiving than the RLE spec would imply. I don't think any of the standard Life editors enforce the 70-character width limit, for example, and it's quite common to store databases of patterns as "headerless RLE" -- one line per pattern no matter how long the line is, and no header. 70 characters is definitely standard for Life editors writing RLE, though.

2) Another very common variant is also mentioned vaguely in the LifeWiki RLE article: comments very often follow the RLE-terminating !, starting on a new line. They usually but not invariably have the #C prefix. Comments either before or after the RLE section are relatively likely to go over the 70-character width limit.

An extremely nitpicky detail is that the grammar currently seems to allow RLE like bo$00000000002bo!0000000003o! for a glider.

EDIT: This line of the grammar isn't quite correct:

rule-set        = birth-counts "/" survival-counts

Due to the inability of humans anywhere to agree on any kind of consistent standards, it should actually be

rule-set        = survival-counts "/" birth-counts
User avatar
dvgrn
Moderator
 
Posts: 5624
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI

Re: RLE grammar

Postby tomdunn » March 6th, 2019, 1:08 pm

Thank you both very much for the input!

wildmyron: thanks for pointing out the existence of non- semi-totalistic rules and also the nicknames. I can look into those more and update the grammar. For my parser, I don't actually plan on using the grammar past as a reference for the code implementation, but it would be nice to have it more complete. Maybe another grammar for Extended BLE could be in store for later.

dvgrn: I'll change that note on the 70 character limit to a SHOULD NOT. I'll have to make sure I write my parser to support the headerless RLE as well. I'll look closer at your comment of "!" in the grammar. And thanks! for picking up on the birth-counts and survival-counts being swapped. I didn't notice that difference between the "#r" and "rule =".
tomdunn
 
Posts: 8
Joined: March 5th, 2019, 4:57 pm

Re: RLE grammar

Postby tomdunn » March 7th, 2019, 1:14 am

Thanks again for the help. I've made the following updates:

* Allow for rules that are not semi-totalistic format or are nicknames
* Add note on 70 character limit for generators vs. parsers
* Made header-line optional
* Allow for "#C" hash-line comments after !
* Fixed run-count to not allow numbers starting with 0
* Fixed rule-set so survial-counts comes before birth-counts
* Added descriptions for each section of the file format

Run Length Encoded (RLE) File Format Grammar
============================================

See http://www.conwaylife.com/wiki/Run_Length_Encoded

For description of this Augmented BNF Style Grammar,
see https://tools.ietf.org/html/rfc2616/#section-2.1

RLE files general structure:

    - Zero or more comment lines that can specify metadata
    - Optional header line that specifies height, width, and rule
    - The pattern itself encoded with run lengths

RLE generators SHOULD NOT create lines that exceed 70 characters.
RLE parsers SHOULD allow parsing of lines that exceed 70 characters.
DOS, Unix, and Mac newline conventions are all acceptable.
The final "!" should be present but its best to treat it as optional.

    rle-file        = *(hash-line)
                      [header-line]                           
                      1*(run-item [LWS]) ["!"] [end-matter]

"# Lines" allow for comments and metadata.  These lines appear before the header.
For the rule set, semi-totalistic format is common, but should allow for
formats for other types of cellular automata, as well as rule nicknames.

    hash-line       = "#" line-type LWS (comment | hash-rule-set | *TEXT) CRLF
    line-type       = "C" | "c"  ; comment
                    | "N"        ; pattern name
                    | "O"        ; file creator
                    | "P" | "R"  ; top-left corner coordinates
                    | "r"        ; rule-set
    comment         = *TEXT
    hash-rule-set   = (hash-semi-totalistic-rule-set | *TEXT)
    hash-semi-totalistic-rule-set   = survival-counts "/" birth-counts
    birth-counts                    = *(DIGIT)  ; # of live neighbors for cell birth
    survival-counts                 = *(DIGIT)  ; # of live neighbors for cell survival

Header lines are optional.  If "#r" is omitted and a header line with a specified "rule"
is omitted the rule set S23/B3 MAY be assumed, or use simulator rule settings.

    header-line     = "x = " pattern-width ", y = " pattern-height
                      [", rule = " rule-set] CRLF
    pattern-width   = *DIGIT     ; the width, in cells, of the pattern
    pattern-height  = *DIGIT     ; the height, in cells, of the pattern
    rule-set        = (semi-totalistic-rule-set | *TEXT)
    semi-totalistic-rule-set  = ("b" | "B") birth-counts "/" ("s" | "S") survival-counts

Patterns are encoded with a number that describes how many times to repeat the following
character.  Dead cells at the end of a pattern line do not need to be encoded, nor
does the end of the last line of the pattern.  RLE writers should adhere to the status
spacing shown, but RLE readers are best not to assume it.  Letters other than b and o
may be used for the <tag>s to represent extra states. Unless the cellular automaton has
more than 26 states it is a good idea to stick to lowercase letters. RLE readers that
cannot handle more than two states should treat all letters other than b (and perhaps B)
as equivalent to o.

    run-item        = [run-count] tag ; run-count can be omitted if it is 1
    run-count       = ("1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9") *(DIGIT)   
    tag             = "b" | "B"  ; dead cell
                    | "o" | "O"  ; alive cell
                    | "$"        ; end of line
                    | CHAR       ; for additional states; if not understood, treat as o

End matter follows the final "!".  It is mainly used for comments.  # Lines here would
likely be the "#C" comment type.

    end-matter       = *(CRLF) *(end-file-comment)
    end-file-comment = (hash-line | comment *(CRLF))


Also at https://gist.github.com/thomasdunn/d70b ... 07e7e9c067
tomdunn
 
Posts: 8
Joined: March 5th, 2019, 4:57 pm

Re: RLE grammar

Postby hkoenig » March 7th, 2019, 1:39 am

For the header line, I also allow "h=nnn" and "v=nnn" to specify absolute positioning. Useful when you need to coordinate multiple layers (for example, Glider constructions starting vs. ending bit patterns).

I gave up trying to enforce the 70 character limit on output, and on input just ignore whitespace characters until '!'. I'm assuming that the limit was originally there for static buffer allocation. (I sure hope it wasn't to keep each line in the punch card data area...) Enforcing an arbitrary line length limit makes the code unnecessarily complicated, and wasn't worth the effort. Also, unescaped line terminator characters make a mess of SQLite import, export and table display.

For some reason, my 25+ year old parser routine also allows 'X', 'x', 'Y', 'y', 'A', 'a', 'Z', 'z', '*', and '@" as alternatives to 'o', and '.' in addition to 'b'. Which means that at some point I had to hack it to work with somebody's RLE properly. (And, I think maybe to allow parsing of the old XLIFE format?) So you might want to have the option of "strict" or "loose" modes. In the latter, you want to treat any undefined ASCII character >= '@', <= 'z' as "on".
hkoenig
 
Posts: 92
Joined: June 20th, 2009, 11:40 am

Re: RLE grammar

Postby tomdunn » March 7th, 2019, 11:27 am

hkoenig - thanks a lot for the input, its very helpful.

The "h" and "v" values seem very useful. I'll follow your advice on the whitespace. The loose and strict modes are a good idea. I'll definitely stick with writing for the loose mode at first for my parser.

The RLE wiki page had this:
RLE readers that cannot handle more than two states should treat all letters other than b (and perhaps B) as equivalent to o.


I'll probably follow that, but also accept '.' for 'b' as you suggest.
tomdunn
 
Posts: 8
Joined: March 5th, 2019, 4:57 pm

Re: RLE grammar

Postby dvgrn » March 7th, 2019, 2:51 pm

tomdunn wrote:hkoenig - thanks a lot for the input, its very helpful.

The "h" and "v" values seem very useful.

They definitely are very useful. Unfortunately that syntax has never gotten widely adopted: the only place I know of where it gets used regularly is the Game of Life News weblog on pentadecathlon.com. Here's an example multi-layer RLE file, from this weblog posting:

#C smaller highway-robber device: Calcyman, 27 February 2009
x = 113, y = 117, rule = B3/S23
64bo$62b3o$38bo22bo$26bo11b3o20b2o$24b3o14bo$8bo14bo16b2o39b2o$8b3o12b
2o56b2o5b2o$11bo76b2o$10b2o2$67b2o17b2o$11b2o55bo17b2o$11b2o17b2o36bob
o21b2o$30b2o37b2o21b2o6$27b2o32b2o$27bo20b2o11b2o$29bo19bo$28b2o16b3o$
24b2o20bo$24bo$25b3o68bo$27bo66b3o$93bo$93b2o2$8b2o$7bobo$7bo25b2o$6b
2o25bo$14b2o15bobo$14b2o15b2o65b2o$98bo$96bobo$96b2o3$82b2o$81bobo$81b
o$80b2o3$13b2o83b2obo$12bobo83bob2o$12bo$11b2o78b2o$91b2o7$81b2o$23b2o
57bo$23b2o57bobo$35b2o46b2o$35bobo$37bo$37b2o2$12b2o$13bo19b2o$13bobo
17bo71b2o$14b2o15bobo71bo$26bo4b2o70bobo$25bobo75b2ob2o$25bobo78bo$14b
2o10bo79bobo$13bobo67b2o20b2ob3o$13bo70bo26bo$7bo4b2o70bobo18b2ob2o2bo
$7b3o17b2o56b2o18b2obob2o$10bo16bo82bo$o8b2o17b3o79bo$3o27bo77bob2o$3b
o104b2o2bo$2b2o15b2o65b2o23b2o$19b2o66bo$84b3o$47bo36bo$45b3o$44bo$44b
2o62b2o$50b2o56bo$9b2o39b2o7bo49b3o$8bo2bo45b3o51bo$8bobo45bo26bo$9bo
46b2o25b3o$86bo$64b2o19b2o$64bo16b2o$62bobo16bo$62b2o19bo$82b2o6$79b2o
$79b2o17b2o$98b2o$40b2o$40bo$41b3o6b2o47b2o$43bo2b2o2b2o47bo$43bobobo
38b2o12b3o$24b3o15b2obo23b2o16bo14bo$24bo17bo2bo23bo14b3o$25bo17b2o25b
3o11bo$72bo!
#C envelope layer
x = 110, y = 111, h=0, v=4,  color=(0,0,0), alpha=48
59b4o$58b3o$40b4o14b4o18bo2b2o$19b2ob3o3b7obo5b3o12b5o19b4o2bo2bo$18b
5o5b13ob4o11b6o14bob6o3b2o$10b5o2b36o2b8o12b10o2b2o$12b52o11b11o2b2o$
13b50o11b12o2b3obo$13b17o2b22ob7o9bo2b18o$12bob16o2b31o8bo3b15obo$14b
23o3b2o2b19o8b18o3bo$15b9o2b10o11b17o7b18o$16b8o3b6o16b15ob2o2b19o$17b
7o4b3o19b38o$14b11o3bo21b8ob20ob7o$13b12o23b8o3b2o2b16o2b6o$13b12o28bo
5b2o2b17ob7o$13b11o36b21ob6o$13b8ob4o35bob3ob4o7b9o$13b7o46b4o9b8o$13b
7o45b4o11b8o$13b6o45b4o13b7o$12b7o44b4o15b6o$11b8o43b4o16b7o$10b8o43b
4o17b7o$10b8o42b4o18b8ob4o$10bo2b6o40b4o19b11o$10bob7o39b4o20b12o$12b
6o39b4o21b12o$12b8o4bo31b4o23b11o$13bo2b6ob4o3bo24b4o27b7o$12b2o2b13ob
o23b4o27b8o$13b18o22b4o27b8o$14b17o21b4o29b8o2bo$17b13o21b4o29b10obo$
16b12o22b4o30b12o$16b10o23b4o31b12o$15b11o22b4o32bo2b9o$15b7ob2o22b4o
33bo2b8o$14b11o21b4o38b6o$15b11o19b4o38b6o$15b11o18b4o40b5o$15b11o17b
4o41b7o$15bo2b8o16b4o42b8o$15bo3b7o15b4o41b12o$19b7o14b4o42b11o$20b6o
13b4o43b5o2b4o$20b7o11b4o44b5o2b3o$20b8o9b4o45b10o$21b8o7b4o46b9o$21b
9o5b4o47b9o$20b6ob4o3b4o49b8o$20b7ob4ob4o49b8o$21b6o2b7o51b6o$21b6o3b
5o52b6o$21b2o2bo4b5o52b6o$20b3o2b2o2b6o50bob7o$20b7ob4o2bo50b2ob6o$21b
5ob4o3bo50b8o$21b9o55b8o$21b8o57b8o$21b7o59b7o$21b6o61b6o$21b7o60b7o$
16bo3b7o61b7o$16bob11obo57b8ob2o$16b10ob2obo57b13obo$15b10obob3o57b13o
bo$16b9obob3o57b16o$16bob8ob2o60b14o$16bo2b8o65b11o$18b4o2b3o64b11o4bo
$17b4o3b5o58bo2b13obo2bo$16b4o6bo60bob16o$15b4o68b20o$14b4o69b18o$9b8o
71b18obo$11b5o70b20obo$11b4o75b18o$2b5o3b6o2bo2bo69b17o$4b4ob8o2b2o73b
13o$3b9o2b4o2b2o72b14o$2b10o2b4ob4o5b2o6bo57b14o$ob10ob11ob6o4b3o57b
10ob4o$32o3b3o57b10o$32o2b5o3b4o46b11o$9o2b29ob3o5bo2bo38b12o$b7ob2ob
32o5b3o39b12o$2b6obob33o6bobo38b13o$3b6ob34o4b6o38b12o$4b42o2b10o33b
12o$5b51o35b12o$6b4o2b44o29b4ob12o$7b4ob43o6bo25b11ob2o$8b4o2b41o2b3ob
o24b12o$9b4ob48o24b12o$10b52o20bo3b11o$11b50o19b3o4b7o$12b50o16b6o3b8o
$13b8ob42o11b10o2b9o$14b5o8b17o3b20o2b2o3b23o$15b4o10bo3b10o5b31o2b16o
bo$16b4o14b8o7b7ob22o2b17o$17b4o14b7o7b6o2b41o$18b4o26b6o3b42o$19b4o
25b4o6b36o2b5o$20b4o24b2o2bo12b4ob13o5b5o$21b4o23bo17b3o5bob7o3b3ob2o$
22b4o22bo18b4o$23bo$25b2o!
CB 1,1,1,1
GP F NW x=24, y=113, len=30, color=(255,0,0)
GP F NW x=44, y=9, len=20, color=(0,255,0)

Notice that the current grammar doesn't allow this as valid RLE, but Golly, LifeViewer and so on have no problem with this as input. The rule is that anything at all can follow the exclamation point at the end of the RLE section, with no need for #C tags or any other annotations at the beginnings of lines. So the usual behavior is that all layers following the first one are silently ignored. Or they get reported as comments, right along with any comments before the header line.

So far, I think the pentadecathlon.com server has the only code anywhere that can process the h={X}, v={Y} and other special commands and produce a correct stacked view for this kind of multilayer RLE -- to say nothing of the other annotations such as GP ("glider path"), CB (something to do with padding around images, but now I forget what it stands for... aha, "cell border")... and so on.

It would be easy to write a Golly script to process the clipboard and produce a reasonably good equivalent stacked-layers view with the correct offsets -- up to ten layers, anyway! But nobody has actually written such a script, probably because there are only a few RLE files out there that use that convention, and they're all on pentadecathlon.com and are already getting rendered perfectly well.

There's an alternate syntax supported by Golly and LifeViewer for the h=, v= offset:

#CXRLE Pos={x},{y}

Could also be something like

#CXRLE Pos={x},{y} Gen={t}

or only the Gen= keyword might be defined, if you want to set a non-zero generation number.

There's also the #P syntax -- "P" | "R" ; top-left corner coordinates -- but that also hasn't seen much of any use except maybe in Xlife. I don't think it's even supported in LifeViewer or Golly:

#P -10000,5000
x = 3, y = 3, rule = B3/S23
bo$2bo$3o!

-- Nope, Golly doesn't seem to like the #P line at all, and LifeViewer just ignores it. #P is also used in some ASCII formats, which might be confusing the parser I suppose.

So: pentadecathlon.com format for that second layer quoted in the multilayer RLE above, looks like this:
#C envelope layer
x = 110, y = 111, h=0, v=4,  color=(0,0,0), alpha=48
59b4o$58b3o$40b4o14b4o18bo2b2o$19b2ob3o3b7obo5b3o12b5o19b4o2bo2bo$18b
5o5b13ob4o11b6o14bob6o3b2o$10b5o2b36o2b8o12b10o2b2o$12b52o11b11o2b2o$
13b50o11b12o2b3obo$13b17o2b22ob7o9bo2b18o$12bob16o2b31o8bo3b15obo$14b
23o3b2o2b19o8b18o3bo$15b9o2b10o11b17o7b18o$16b8o3b6o16b15ob2o2b19o$17b
7o4b3o19b38o$14b11o3bo21b8ob20ob7o$13b12o23b8o3b2o2b16o2b6o$13b12o28bo
5b2o2b17ob7o$13b11o36b21ob6o$13b8ob4o35bob3ob4o7b9o$13b7o46b4o9b8o$13b
7o45b4o11b8o$13b6o45b4o13b7o$12b7o44b4o15b6o$11b8o43b4o16b7o$10b8o43b
4o17b7o$10b8o42b4o18b8ob4o$10bo2b6o40b4o19b11o$10bob7o39b4o20b12o$12b
6o39b4o21b12o$12b8o4bo31b4o23b11o$13bo2b6ob4o3bo24b4o27b7o$12b2o2b13ob
o23b4o27b8o$13b18o22b4o27b8o$14b17o21b4o29b8o2bo$17b13o21b4o29b10obo$
16b12o22b4o30b12o$16b10o23b4o31b12o$15b11o22b4o32bo2b9o$15b7ob2o22b4o
33bo2b8o$14b11o21b4o38b6o$15b11o19b4o38b6o$15b11o18b4o40b5o$15b11o17b
4o41b7o$15bo2b8o16b4o42b8o$15bo3b7o15b4o41b12o$19b7o14b4o42b11o$20b6o
13b4o43b5o2b4o$20b7o11b4o44b5o2b3o$20b8o9b4o45b10o$21b8o7b4o46b9o$21b
9o5b4o47b9o$20b6ob4o3b4o49b8o$20b7ob4ob4o49b8o$21b6o2b7o51b6o$21b6o3b
5o52b6o$21b2o2bo4b5o52b6o$20b3o2b2o2b6o50bob7o$20b7ob4o2bo50b2ob6o$21b
5ob4o3bo50b8o$21b9o55b8o$21b8o57b8o$21b7o59b7o$21b6o61b6o$21b7o60b7o$
16bo3b7o61b7o$16bob11obo57b8ob2o$16b10ob2obo57b13obo$15b10obob3o57b13o
bo$16b9obob3o57b16o$16bob8ob2o60b14o$16bo2b8o65b11o$18b4o2b3o64b11o4bo
$17b4o3b5o58bo2b13obo2bo$16b4o6bo60bob16o$15b4o68b20o$14b4o69b18o$9b8o
71b18obo$11b5o70b20obo$11b4o75b18o$2b5o3b6o2bo2bo69b17o$4b4ob8o2b2o73b
13o$3b9o2b4o2b2o72b14o$2b10o2b4ob4o5b2o6bo57b14o$ob10ob11ob6o4b3o57b
10ob4o$32o3b3o57b10o$32o2b5o3b4o46b11o$9o2b29ob3o5bo2bo38b12o$b7ob2ob
32o5b3o39b12o$2b6obob33o6bobo38b13o$3b6ob34o4b6o38b12o$4b42o2b10o33b
12o$5b51o35b12o$6b4o2b44o29b4ob12o$7b4ob43o6bo25b11ob2o$8b4o2b41o2b3ob
o24b12o$9b4ob48o24b12o$10b52o20bo3b11o$11b50o19b3o4b7o$12b50o16b6o3b8o
$13b8ob42o11b10o2b9o$14b5o8b17o3b20o2b2o3b23o$15b4o10bo3b10o5b31o2b16o
bo$16b4o14b8o7b7ob22o2b17o$17b4o14b7o7b6o2b41o$18b4o26b6o3b42o$19b4o
25b4o6b36o2b5o$20b4o24b2o2bo12b4ob13o5b5o$21b4o23bo17b3o5bob7o3b3ob2o$
22b4o22bo18b4o$23bo$25b2o!
CB 1,1,1,1
GP F NW x=24, y=113, len=30, color=(255,0,0)
GP F NW x=44, y=9, len=20, color=(0,255,0)

Golly/LifeViewer format -- notice the coordinate change gets picked up by LifeViewer in this case. I've left off the color and alpha commands. LifeViewer has equivalents for color but can't do multi-layer displays; Golly can do layers and colors, but the alpha is adjusted automatically if I remember right.
#CXRLE Pos=-4 0
#C envelope layer
x = 110, y = 111, rule = B3/S23
59b4o$58b3o$40b4o14b4o18bo2b2o$19b2ob3o3b7obo5b3o12b5o19b4o2bo2bo$18b
5o5b13ob4o11b6o14bob6o3b2o$10b5o2b36o2b8o12b10o2b2o$12b52o11b11o2b2o$
13b50o11b12o2b3obo$13b17o2b22ob7o9bo2b18o$12bob16o2b31o8bo3b15obo$14b
23o3b2o2b19o8b18o3bo$15b9o2b10o11b17o7b18o$16b8o3b6o16b15ob2o2b19o$17b
7o4b3o19b38o$14b11o3bo21b8ob20ob7o$13b12o23b8o3b2o2b16o2b6o$13b12o28bo
5b2o2b17ob7o$13b11o36b21ob6o$13b8ob4o35bob3ob4o7b9o$13b7o46b4o9b8o$13b
7o45b4o11b8o$13b6o45b4o13b7o$12b7o44b4o15b6o$11b8o43b4o16b7o$10b8o43b
4o17b7o$10b8o42b4o18b8ob4o$10bo2b6o40b4o19b11o$10bob7o39b4o20b12o$12b
6o39b4o21b12o$12b8o4bo31b4o23b11o$13bo2b6ob4o3bo24b4o27b7o$12b2o2b13ob
o23b4o27b8o$13b18o22b4o27b8o$14b17o21b4o29b8o2bo$17b13o21b4o29b10obo$
16b12o22b4o30b12o$16b10o23b4o31b12o$15b11o22b4o32bo2b9o$15b7ob2o22b4o
33bo2b8o$14b11o21b4o38b6o$15b11o19b4o38b6o$15b11o18b4o40b5o$15b11o17b
4o41b7o$15bo2b8o16b4o42b8o$15bo3b7o15b4o41b12o$19b7o14b4o42b11o$20b6o
13b4o43b5o2b4o$20b7o11b4o44b5o2b3o$20b8o9b4o45b10o$21b8o7b4o46b9o$21b
9o5b4o47b9o$20b6ob4o3b4o49b8o$20b7ob4ob4o49b8o$21b6o2b7o51b6o$21b6o3b
5o52b6o$21b2o2bo4b5o52b6o$20b3o2b2o2b6o50bob7o$20b7ob4o2bo50b2ob6o$21b
5ob4o3bo50b8o$21b9o55b8o$21b8o57b8o$21b7o59b7o$21b6o61b6o$21b7o60b7o$
16bo3b7o61b7o$16bob11obo57b8ob2o$16b10ob2obo57b13obo$15b10obob3o57b13o
bo$16b9obob3o57b16o$16bob8ob2o60b14o$16bo2b8o65b11o$18b4o2b3o64b11o4bo
$17b4o3b5o58bo2b13obo2bo$16b4o6bo60bob16o$15b4o68b20o$14b4o69b18o$9b8o
71b18obo$11b5o70b20obo$11b4o75b18o$2b5o3b6o2bo2bo69b17o$4b4ob8o2b2o73b
13o$3b9o2b4o2b2o72b14o$2b10o2b4ob4o5b2o6bo57b14o$ob10ob11ob6o4b3o57b
10ob4o$32o3b3o57b10o$32o2b5o3b4o46b11o$9o2b29ob3o5bo2bo38b12o$b7ob2ob
32o5b3o39b12o$2b6obob33o6bobo38b13o$3b6ob34o4b6o38b12o$4b42o2b10o33b
12o$5b51o35b12o$6b4o2b44o29b4ob12o$7b4ob43o6bo25b11ob2o$8b4o2b41o2b3ob
o24b12o$9b4ob48o24b12o$10b52o20bo3b11o$11b50o19b3o4b7o$12b50o16b6o3b8o
$13b8ob42o11b10o2b9o$14b5o8b17o3b20o2b2o3b23o$15b4o10bo3b10o5b31o2b16o
bo$16b4o14b8o7b7ob22o2b17o$17b4o14b7o7b6o2b41o$18b4o26b6o3b42o$19b4o
25b4o6b36o2b5o$20b4o24b2o2bo12b4ob13o5b5o$21b4o23bo17b3o5bob7o3b3ob2o$
22b4o22bo18b4o$23bo$25b2o!

There really doesn't seem to have been much of a market for stacking multiple layers. For example, envelope.lua does it, but it just makes a mess if you already have multiple layers open in not-stacked not-tiled mode (which I usually do).

More commonly layers of information are handled LifeHistory-style: keep everything in the same layer for editing and copy/paste convenience, and just add extra states to show different "pseudo-layers", overlaps, etc. For example, LifeViewer has an envelope/history pseudo-layer (state 2) and a "marked cell" pseudo-layer (states 3, 4, and 5). This has its own problems and trade-offs, of course, but it seems to be what people use in practice.
User avatar
dvgrn
Moderator
 
Posts: 5624
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI

Re: RLE grammar

Postby tomdunn » March 8th, 2019, 4:51 am

Thanks again, Dave. You've given me a lot to chew on. I'll try playing around with the offset parameters and some of the layering methods you've mentioned. If I ever end up working on a grammar for Extended RLE I'll try to include any of this that makes sense.

I'll update the end-matter section so that its a little more general and describe that pretty much anything can live there.

The project I have in mind right now may require some other custom metadata with an arbitrary number of instances of the metadata. The # lines seem like the best way to that.
tomdunn
 
Posts: 8
Joined: March 5th, 2019, 4:57 pm

Re: RLE grammar

Postby MikeP » March 8th, 2019, 10:27 pm

dvgrn wrote:There's also the #P syntax -- "P" | "R" ; top-left corner coordinates -- but that also hasn't seen much of any use except maybe in Xlife.


Bellman's input files use the #P syntax. The format has its roots in the "Life 1.05" format that Xlife used; I just ended up adding more and more to it over the years.
MikeP
 
Posts: 81
Joined: February 7th, 2010, 9:51 am
Location: Cambridge, UK

Re: RLE grammar

Postby rowett » March 9th, 2019, 4:53 am

I've seen RLE patterns with a newline between the run-count and the tag.
User avatar
rowett
Moderator
 
Posts: 1376
Joined: January 31st, 2013, 2:34 am
Location: UK

Re: RLE grammar

Postby tomdunn » March 12th, 2019, 3:56 am

Thank you for the notes MikeP and rowett!
tomdunn
 
Posts: 8
Joined: March 5th, 2019, 4:57 pm


Return to Scripts

Who is online

Users browsing this forum: No registered users and 2 guests