Pattern viewer for forum threads

[dvgrn]

Just finished an experiment with the Extended Life thread. LifeViewer is now enabled for most of the rule variants posted there. A few of the never-got-used-much rules like ExtendedLife^2 haven't been added.

However, it's possible for anyone with a LifeWiki trusted flag to add a rule with a @TREE section to the Rules: namespace. After a refresh, LifeViewer will start working on patterns with that rule name in the header. I'm not absolutely sure that there won't be some weird effect with cases like the ^ character in "ExtendedLife^2", but I think it will work fine -- might be worth trying.

Here's how it works in detail:

1) Save the following RuleTableToTree-hacked.py to the same subfolder in Golly as the regular RuleTableToTree (/Scripts/Python/RuleGenerators/).

EDIT: altered line 23 in a way that hopefully will be more tolerant of different OSes:

Code: Select all

# RuleTableToTree-hacked.py, version 1.1
# modified version of RuleTableToTree.py,
#   intended to create a version of any @TABLE .rule file that can be copied
#   directly into the LifeWiki Rule: namespace for LifeViewer to use
# This involves adding a @TREE section that contains an equivalent encoding of the @TABLE section

# TODO:  add warning message if the @TREE section is so big that LifeViewer won't be able to handle it?

import golly
import os
from glife.ReadRuleTable import *
from glife.RuleTree import *
from glife.EmulateTriangular import *
from glife.EmulateMargolus import *
from glife.EmulateOneDimensional import *
from glife.EmulateHexagonal import *

rulesource="The selected rule"
s = golly.getclipstr()
if s[:5]=="@RULE":
  # create a temporary file and set rulefilename to that
  firstline = s.split("\n")[0]
  rulefilename = golly.getdir("temp") + firstline.split(" ")[1].replace("\r","").replace("\n","") + ".rule"
  with open(rulefilename, "w") as f0:
    f0.write(s)
  rulesource = "The rule in the clipboard"
else:
  # ask user to select .rule file
  rulefilename = golly.opendialog('Open a rule table file, to add a @TREE section:', 'Rule files (*.rule)|*.rule')

if len(rulefilename) == 0: golly.exit()    # user hit Cancel

with open(rulefilename,"r") as f:
  rulelines = f.readlines()

# golly.note(str(rulelines))

filename = rulefilename.replace(".rule",".table")
if rulefilename == filename:
  g.note("This script only works with saved files called *.rule\n-- otherwise things get too confusing.")
  g.exit()

with open(filename,"w") as f1:
  export = 0
  for line in rulelines:
    if line[:5] == "@TREE":
      golly.note(rulesource + " already has a @TREE section.  Nothing to do here.")
      golly.exit()
    if export != 1:
      if line[:6] == "@TABLE":
        export = 1
    else:
      if line[:1] == "@":
        export = 2
      else:
        f1.write(line)

# DMG: now the .table section (only) has been written to a separate file in the same folder,
#      and this hacked script can proceed in the same way as the original RuleTableToTree.py 

# add new converters here as they become available:
Converters = {
    "vonNeumann":ConvertRuleTableTransitionsToRuleTree,
    "Moore":ConvertRuleTableTransitionsToRuleTree,
    "triangularVonNeumann":EmulateTriangular,
    "triangularMoore":EmulateTriangular,
    "Margolus":EmulateMargolus,
    "square4_figure8v":EmulateMargolus,
    "square4_figure8h":EmulateMargolus,
    "square4_cyclic":EmulateMargolus,
    "oneDimensional":EmulateOneDimensional,
    "hexagonal":EmulateHexagonal,
}

golly.show("Reading from rule table file...")
n_states, neighborhood, transitions = ReadRuleTable(filename)

if not neighborhood in Converters:
    golly.warn("Unsupported neighborhood: "+neighborhood)
    golly.show('')
    golly.exit()

# all converters now create a .rule file
golly.show("Building rule...")
rule_name = Converters[neighborhood]( neighborhood,
                                      n_states,
                                      transitions,
                                      filename )

golly.new(rule_name+'-demo.rle')
golly.setalgo('RuleLoader')
golly.show("Created rule " + rule_name + ".")

# now go find the rule just created
newrulefilename = golly.getdir('rules')+rule_name+".rule"
with open(newrulefilename,"r") as f2:
  treelines = f2.readlines()

# rewrite the rule file to include a @TABLE as well as a @TREE section 
with open(newrulefilename,"w") as f3:
  wrotetree = 0
  for line in rulelines:
    if wrotetree == 0 and (line[:7] == "@COLORS" or line[:6] == "@ICONS"):
      foundtree = 0
      for treeline in treelines:
        if treeline[:5] == "@TREE":
          foundtree=1
        if foundtree==1:
          f3.write(treeline)
      wrotetree = 1
    if wrotetree == 0: # @TREE version of file will include @COLORS and @ICONS if they're there,
      f3.write(line)   #   so no reason to write that out twice

with open(newrulefilename,"r") as f4:
  golly.setclipstr(f4.read())

golly.setrule(rule_name)
golly.show('Created '+rule_name+'.rule and selected that rule.')

2) Copy the rule text to the clipboard. (Or save it to a file called {something}.rule -- if you don't have text starting with @RULE in the clipboard, the script will ask you to point to a file. But it seems like working through the clipboard will often be simpler.)

3) Run the RuleTableToTree-hacked.py script. You'll end up with a copy of the rule with both @TABLE and @TREE sections installed in Golly's Rules folder, and also copied to your clipboard.

4) Navigate to https:/​/conwaylife.com/wiki/Rule:{your_rulename_here}. Be careful to get the capitalization right. If different variations of capitalization are used after the first letter in the rule name, you'll have to add redirects to get LifeViewer to find the right article.

5) Create the article, paste the contents of the clipboard into it, and save.

After a refresh, LifeViewer should pick up the new @TREE definition and will be able to simulate the rule in-browser.

Handle with Care
Quite possibly some interesting problems or exceptions will show up as this feature gets more use. I wouldn't necessarily advise trying this on a rule table with a huge number of states or transitions, like QuadrupleB3S23 or 1x2Life. When permute symmetry is set as it often is, the @TREE text can end up being much much longer than the @TABLE text, and eventually the LifeWiki server might start having trouble serving up such huge volumes of text -- caching or no caching.

For example, it might be worth keeping an eye out for threads where it takes a very long time for the "Show in Viewer" links to appear, the first time the page is loaded. (?)

EDIT: An interesting detail showed up when I tried converting Foodshapeloop to @TREE form. First, it took fifteen or twenty minutes to complete the conversion, and the resulting file was 119MB. So this is an example of a rule that might be beyond what can reasonably be stored in the Rule: namespace on the LifeWiki: my impression is that you start to get some strange partial-load results when articles get too long. There's a new feature of LifeViewer as of build 453 where you don't have to get rule-tree information from the LifeWiki --

Build 453 is now available... Enhancements in this build:

• the location of the rule Repository can be overriden with the <meta> tag on the web page hosting the Viewer
  • <meta name="LifeViewer" content="/myrepository/rules/">
  • an entry beginning with a "/" is used to define the location

-- so maybe a next step would be to experiment with foodshapeloop locally and see just how painful it is for LifeViewer to load a 119MB rule tree.

Second, a couple of the variable definition lines were written as "Var ..." instead of "var ..." Until I changed those V's to lowercase, the script gave a mysterious "wrong number" error: it was trying to read it as a regular rule table line, and therefore expected to see ten items (start state, neighbors, end state).

EDIT2: Another oddity I haven't tracked down is that the output foodshapeloop rule file (119MB) or the output shapeloop3 rule file (10MB) for some reason don't get a @COLORS section at the end. They should. So I'm not sure if the input rule file is actually getting processed completely, or if there's a bug in my hacked version. It's possible that the complete @TREE isn't actually getting created -- have to check against the output of the original RuleTableToTree.py.

[Ian07]

3) Run the RuleTableToTree-hacked.py script. You'll end up with a copy of the rule with both @TABLE and @TREE sections installed in Golly's Rules folder, and also copied to your clipboard.

I'm getting an "ImportError: No module named ReadRuleTable" from line 11 when I try to run the script.

[dvgrn]

3) Run the RuleTableToTree-hacked.py script. You'll end up with a copy of the rule with both @TABLE and @TREE sections installed in Golly's Rules folder, and also copied to your clipboard.

I'm getting an "ImportError: No module named ReadRuleTable" from line 11 when I try to run the script.

Does the original RuleTableToTree.py script work? Are you running a copy of RuleTableToTree-hacked.py saved in that same folder?

(I haven't tried running the hacked script from the clipboard, but my superstitious theory was that annoying errors like this one might happen.)

[Ian07]

Does the original RuleTableToTree.py script work? Are you running a copy of RuleTableToTree-hacked.py saved in that same folder?

1. Nope, same issue.
2. Yes.

EDIT: Just moved RuleTableToTree-hacked.py outside of Rule-Generators and now I'm getting this error instead: (note: can't select the message so I'm posting an image instead)

[dvgrn]

Does the original RuleTableToTree.py script work? Are you running a copy of RuleTableToTree-hacked.py saved in that same folder?

1. Nope, same issue.
2. Yes.

Interesting... Well, what version of Golly, and what OS? I don't really have much experience with RuleTableToTree.py -- just tried it out on my Windows system yesterday, and found that it was capable of generating the @TREE section that LifeViewer currently needs, so I hoped it would turn out to be reasonably reliable for other people too.

So... the odds are good that you have the relevant glife Python file defining ReadRuleTable(), in the right place --

golly-3.3-win-64bit\Scripts\Python\glife\ReadRuleTable.py(146): def ReadRuleTable(filename):

-- so what else might be going wrong?

I wonder if it could be a similar problem to the occasional mysterious inability of some scripts to load glife's make_text module? Maybe try running another script that imports glife, or just run

Code: Select all

import glife

or

Code: Select all

from glife.ReadRuleTable import *

and, if you can avoid getting an error with those, try running the RuleTableToTree-hacked.py script again.

(?)

EDIT: Altered the posted RuleTableToTree-hacked.py script slightly, as per discussion on Discord. Hopefully at least we'll be able to move on to a different error...

[Ian07]

EDIT: Altered the posted RuleTableToTree-hacked.py script slightly, as per discussion on Discord. Hopefully at least we'll be able to move on to a different error...

I didn't get an error this time, but at first it didn't look like it actually generated the @TREE section of the file when I tried it with Brew. I thought this might've been because the Brew.rule file was already in my Rules folder without the @TREE, so I renamed it to Brew3 and tried again and got this:

Code: Select all

@RULE Brew



@TABLE

n_states:4

neighborhood:Moore

symmetries:permute

var a={0,1,2,3}

var b=a

var c=a

var d=a

var e=a

var f=a

var g=a

var h=a

var i={0,2,3}

var j=i

var k=i

var l=i

var m=i

var n=i

var o={0,1,3}

var p=o

var q=o

var r=o

var s=o

var t=o

var u={0,1,2}

var v=u

var w=u

var x=u

var y=u

var z=u



i,1,1,1,j,k,l,m,n,1

1,1,1,1,i,j,k,l,m,1

1,1,1,i,j,k,l,m,n,1

o,2,2,2,p,q,r,s,t,2

2,2,2,2,p,q,r,s,t,2

2,2,2,o,p,q,r,s,t,2

u,3,3,3,v,w,x,y,z,3

3,3,3,3,u,v,w,x,y,3

3,3,3,u,v,w,x,y,z,3



1,a,b,c,d,e,f,g,h,2

2,a,b,c,d,e,f,g,h,3

3,a,b,c,d,e,f,g,h,0



@TREE

num_states=4
num_neighbors=8
num_nodes=260
1 0 2 3 0
2 0 0 0 0
1 0 1 3 0
2 0 2 0 0
1 0 2 2 0
2 0 0 4 0
1 0 2 3 3
2 0 0 0 6
3 1 3 5 7
1 1 1 1 1
2 2 9 2 2
2 0 2 4 0
2 0 2 0 6
3 3 10 11 12
1 2 2 2 2
2 4 4 14 4
2 0 0 4 6
3 5 11 15 16
1 3 3 3 3
2 6 6 6 18
3 7 12 16 19
4 8 13 17 20
2 9 0 9 9
1 0 1 2 0
2 2 9 23 2
1 0 1 3 3
2 2 9 2 25
3 10 22 24 26
2 4 23 14 4
2 0 2 4 6
3 11 24 28 29
2 6 25 6 18
3 12 26 29 31
4 13 27 30 32
2 14 14 0 14
1 0 2 2 3
2 4 4 14 35
3 15 28 34 36
2 6 6 35 18
3 16 29 36 38
4 17 30 37 39
2 18 18 18 0
3 19 31 38 41
4 20 32 39 42
5 21 33 40 43
3 22 1 22 22
1 2 1 2 2
2 23 9 46 23
2 2 9 23 25
3 24 22 47 48
1 3 1 3 3
2 25 9 25 50
3 26 22 48 51
4 27 45 49 52
2 14 46 0 14
2 4 23 14 35
3 28 47 54 55
2 6 25 35 18
3 29 48 55 57
4 30 49 56 58
2 18 50 18 0
3 31 51 57 60
4 32 52 58 61
5 33 53 59 62
3 34 54 1 34
1 3 3 2 3
2 35 35 14 65
3 36 55 34 66
4 37 56 64 67
2 18 18 65 0
3 38 57 66 69
4 39 58 67 70
5 40 59 68 71
3 41 60 69 1
4 42 61 70 73
5 43 62 71 74
6 44 63 72 75
3 1 1 5 7
2 9 4 9 9
3 22 5 78 22
2 9 6 9 9
3 22 7 22 80
4 45 77 79 81
2 46 9 2 46
1 0 1 2 3
2 23 9 46 84
3 47 78 83 85
2 25 9 84 50
3 48 22 85 87
4 49 79 86 88
2 50 9 50 2
3 51 80 87 90
4 52 81 88 91
5 53 82 89 92
3 54 83 3 54
2 35 84 14 65
3 55 85 54 95
4 56 86 94 96
2 18 50 65 0
3 57 87 95 98
4 58 88 96 99
5 59 89 97 100
3 60 90 98 3
4 61 91 99 102
5 62 92 100 103
6 63 93 101 104
3 1 3 1 7
2 14 14 6 14
3 34 54 7 107
4 64 94 106 108
2 65 65 14 4
3 66 95 107 110
4 67 96 108 111
5 68 97 109 112
3 69 98 110 5
4 70 99 111 114
5 71 100 112 115
6 72 101 113 116
3 1 3 5 1
4 73 102 114 118
5 74 103 115 119
6 75 104 116 120
7 76 105 117 121
3 5 5 15 16
3 7 7 16 19
4 77 77 123 124
2 9 14 9 9
3 78 15 126 78
3 22 16 78 80
4 79 123 127 128
2 9 18 9 9
3 80 19 80 130
4 81 124 128 131
5 82 125 129 132
3 83 126 10 83
1 3 1 2 3
2 84 9 46 135
3 85 78 83 136
4 86 127 134 137
2 50 9 135 2
3 87 80 136 139
4 88 128 137 140
5 89 129 138 141
3 90 130 139 10
4 91 131 140 143
5 92 132 141 144
6 93 133 142 145
3 3 10 3 12
2 14 46 6 14
3 54 83 12 148
4 94 134 147 149
2 65 135 14 4
3 95 136 148 151
4 96 137 149 152
5 97 138 150 153
3 98 139 151 11
4 99 140 152 155
5 100 141 153 156
6 101 142 154 157
3 3 10 11 3
4 102 143 155 159
5 103 144 156 160
6 104 145 157 161
7 105 146 158 162
3 7 12 7 19
4 106 147 106 164
2 14 14 18 14
3 107 148 19 166
4 108 149 164 167
5 109 150 165 168
3 110 151 166 15
4 111 152 167 170
5 112 153 168 171
6 113 154 169 172
3 5 11 15 5
4 114 155 170 174
5 115 156 171 175
6 116 157 172 176
7 117 158 173 177
4 118 159 174 118
5 119 160 175 179
6 120 161 176 180
7 121 162 177 181
8 122 163 178 182
3 15 15 34 36
3 16 16 36 38
4 123 123 184 185
3 19 19 38 41
4 124 124 185 187
5 125 125 186 188
3 126 34 22 126
2 9 35 9 9
3 78 36 126 191
4 127 184 190 192
3 80 38 191 130
4 128 185 192 194
5 129 186 193 195
3 130 41 130 22
4 131 187 194 197
5 132 188 195 198
6 133 189 196 199
3 10 22 10 26
2 46 9 25 46
3 83 126 26 202
4 134 190 201 203
2 135 9 46 23
3 136 191 202 205
4 137 192 203 206
5 138 193 204 207
3 139 130 205 24
4 140 194 206 209
5 141 195 207 210
6 142 196 208 211
3 10 22 24 10
4 143 197 209 213
5 144 198 210 214
6 145 199 211 215
7 146 200 212 216
3 12 26 12 31
4 147 201 147 218
2 14 46 18 14
3 148 202 31 220
4 149 203 218 221
5 150 204 219 222
3 151 205 220 28
4 152 206 221 224
5 153 207 222 225
6 154 208 223 226
3 11 24 28 11
4 155 209 224 228
5 156 210 225 229
6 157 211 226 230
7 158 212 227 231
4 159 213 228 159
5 160 214 229 233
6 161 215 230 234
7 162 216 231 235
8 163 217 232 236
3 19 31 19 41
4 164 218 164 238
5 165 219 165 239
3 166 220 41 34
4 167 221 238 241
5 168 222 239 242
6 169 223 240 243
3 15 28 34 15
4 170 224 241 245
5 171 225 242 246
6 172 226 243 247
7 173 227 244 248
4 174 228 245 174
5 175 229 246 250
6 176 230 247 251
7 177 231 248 252
8 178 232 249 253
5 179 233 250 179
6 180 234 251 255
7 181 235 252 256
8 182 236 253 257
9 183 237 254 258

Unfortunately looking at the forum thread it doesn't seem to have added "show in viewer" options to any of the RLEs:

Code: Select all

x = 10, y = 1, rule = Brew
10B!

Trying to use it inside a viewer in the Sandbox also didn't work with Brew (error says "Missing digit prefix") even though it does with the ExtendedLife .rule file that's already in the Rule namespace:

Code: Select all

x = 10, y = 1, rule = Extendedlife
10B!

Code: Select all

x = 10, y = 1, rule = ExtendedLife
10B!

I also would like to note that the Brew file I received from the script wasn't copy-pasted into my clipboard, so I had to open up Brew3.rule myself.

[rowett]

Unfortunately looking at the forum thread it doesn't seem to have added "show in viewer" options to any of the RLEs

Fixed in build 458.

[rowett]

-- so maybe a next step would be to experiment with foodshapeloop locally and see just how painful it is for LifeViewer to load a 119MB rule tree.

It works but took 91 seconds to load:

• 2 seconds to fetch the foodshapeloop rule from the local Repository
• 83 seconds to tokenize the file
• 6 seconds to create the RuleTree

I'll have a look at the tokenizer...

EDIT

After a minor rewrite it now takes 6 seconds to load:

• 2 seconds to fetch the foodshapeloop rule from the local Repository
• 4 seconds to tokenize and create the RuleTree

The question now is how big files can you have in the Rule: section of the Wiki? My local Repository is just a web server.

[rowett]

Build 459 is now live on the Forums and LifeWiki

Please note: you will need to refresh your browser to use the new build (Ctrl-F5 on Chrome)

Enhancements since the last released build:

• RuleTable support
  • only supports @TREE and @COLORS sections from the LifeWiki Rule: Repository
  • the location of the rule Repository can be overriden with the <meta> tag on the web page hosting the Viewer
    • <meta name="LifeViewer" content="/myrepository/rules/">
    • an entry beginning with a "/" is used to define the location
• size and timing information is in Help->Info->Rule Cache

The updated hotkey map detailing the LifeViewer keyboard controls is here.

Comments, feedback, suggestions and bug reports welcome!

[dvgrn]

After a minor rewrite it now takes 6 seconds to load:

• 2 seconds to fetch the foodshapeloop rule from the local Repository
• 4 seconds to tokenize and create the RuleTree

The question now is how big files can you have in the Rule: section of the Wiki? My local Repository is just a web server.

Well, let's try working our way up slowly. The original shapeloop rule has a 1.5MB @TREE; shapeloop3 is more like 10MB, and foodshapeloop is 119MB.

EDIT: Well, loading the shapeloop rule activates "Show in Viewer" links in the ShapeLoop thread in just a second or so on my system -- no apparent difficulties at all.

I suspect that we won't want to put Rule:Foodshapeloop on the LifeWiki, even if it can technically be made to work, just because the average Internet connection might take a long time to finish loading a page with a foodshapeloop viewer pattern on it. But then again, maybe anyone who is actually visiting the Shapeloop threads won't mind waiting a few seconds to get browser animations of those rules.

Do I have it right, that the rule loading will only happen if there are viewer tags around a pattern, or when a "Show in Viewer" link is clicked? And then the rule loading happens once, and that information is cached and can be used by other "Show in Viewer" links on the same page?

I hope to have another slight improvement to RuleTableToTree-hacked.py later today, to at least fix the problem chris_c saw with extra newlines in the @TABLE section. With any luck I can also figure out why the @COLORS section seem to go missing sometimes when the @TREE section is very large.

[rowett]

Do I have it right, that the rule loading will only happen if there are viewer tags around a pattern, or when a "Show in Viewer" link is clicked? And then the rule loading happens once, and that information is cached and can be used by other "Show in Viewer" links on the same page?

Yes.

Lifeviewer gets notified by the browser once the (forum) page has fully loaded and become interactive.

LifeViewer then scans the page for [ code ] blocks containing patterns. If a pattern uses a natively supported rule then LifeViewer will immediately add a "Show in Viewer" link.

If the pattern does not use a natively supported rule then LifeViewer makes an asynchronous request to download the rule from the LifeWiki repository. If there are further requests for the same rule then only the first one queries the repository and the remainder get notified when the first request returns as to whether the rule is valid.

Valid rules are cached so when "Show in Viewer" is clicked the rule is local and immediately available. The cache disappears if you navigate to a different page.

Any [ viewer ] tags work pretty much the same way.

Since most of the work is asynchronous the page should stay interactive throughout. The only pauses will come if significant decoding is required for very large @TREE sections (like the foodshapeloop rule, which causes a 4 second pause on my machine once the rule has been fetched - but it is then cached and causes no further pauses). Commonly rules take a few milliseconds to decode.

Help->Info->Rule Cache will give you metrics on downloaded rules. Size tells you how large the downloaded rule file was from the Repistory (in Kb). Fetch tells you how long it took (in ms) to retrieve the file (this is aysnchronous). Decode tells you how long it took (in ms) to decode the rule (this is synchronous).

[dvgrn]

I seem to have found the limit for rule files.

Code: Select all

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20727336 bytes) in /home/njohns01home/webapps/conwaylife/w/includes/TemplateParser.php(149) : eval()'d code on line 42

This was while trying to load rule text with just about half that number of characters -- 10,500,000 bytes. Not sure what's going on with the extra bytes -- maybe it tries doubling its allocation if it runs out of room, and 10363668 bytes wasn't big enough... or something like that.

The ZIP version of the rule file is easily small enough to attach, just for the record:

shapeloop3.zip

(2.07 MiB) Downloaded 166 times

So for the moment, this is a good test cases for the limitations of @TREE format. The @TABLE-only form of the rule is only 8K:

Code: Select all

@RULE shapeloop3

https://www.conwaylife.com/forums/viewtopic.php?f=11&t=1440

version 1.08.1
1 wire
2 left signal
3 right signal
4 forward signal
5 trigger/right signal
6 idle/right signal
7 6 to 5 converter
8 signal lead
9 arm edge 1
10 arm edge 2
11 arm starter
12 arm delete
13 delete all
14 boundary
15 checker
#/ shows where edits/additions were made
#* shows where movements were made

@TABLE
n_states:16
neighborhood:Moore
symmetries:rotate4
var a={0,1,2,3,4,5,6,7,8,9,10,11,12,13,15}
var b={1,2,3,4,5,6,15}
var c={9,10}
var d={1,2,3,4,5,6,7,11,12,15}
var e={1,2,3,4,5,6,11,15}
var f={0,7,8,9,10,12,13}
var g={8,9,10}
var h={0,8}
var i={0,11,12}
var j={3,5,6,15}
var k={1,2,3,4,5,6,7,8,9,10,11,15}
var l={0,7,8,9,10,12,13}
var m={0}
var n={9}
var o={10}
var p={9,10}
var q={0,1,2,3,4,5,6,8,9,10,12,15}
var r={0,8,12,13}
#var s={16,17}
var t={8}
var u={8,9,10}
var v={1,2,3,4,5,6,8,9,10,15}
var w={0,12,13}
var x={1,4}
var y={2,4}
var z={0,12}
var A={0,12}
var B={0,13}
#var C={15,15}
var D={8,9,10,12}
var E={0,1,2,3,4,5,6,7,8,9,10,11,12,15}
var F={0,13}
var G={0,7,8,9,10,11,12}
var H={0,7,12}
var I={0,8}
var J={1,2,3,4,5,6,15}
var K={0,7,8,9,10,12,13}
var L={12}
#var M={15,16}
var N={0,8,9,10,11,12}
var O={0,7,8,11,12,13}
var P={0,12,13}
var Q={0,1,2,3,4,5,6,7,10,12,13,15}
var R={0,8,9,10}
var S={1,2,3,4,5,6,7,11,12,13,15}
var T={0,1,2,3,4,5,6,7,11,12,13,15}
var U={0,7,11,12,13}
var V={1,2,3,4,5,6,8,9,10,15}
var W={0,12}
var X={1,2,3,4,6,7,8,9,15}
var Y={0,1,2,3,4,5,6,12,15}
var Z={15}
var AA={8,10}
var AB={11}
var AC={12}
var AD={0,7,8,9,10,13}
var AE={12}
var AF={7,11}
var AI={0,8,9,10}
var AAA={6,15}
var AAB={1,2,3,4,5,6,11,15}
var aa={a}
var ab={a}
var ac={a}
var ad={a}
var ae={a}
var af={a}
var ag={a}
var ba={b}
var bb={b}
var bc={b}
var bd={b}
var bd={b}
var ca={c}
var cb={c}
var cc={c}
var da={d}
var db={d}
var dc={d}
var dd={d}
var fa={f}
var fb={f}
var ga={g}
var gb={g}
var gc={g}
var ha={h}
var la={l}
var lb={l}
var lc={l}
var ld={l}
var le={l}
var lf={l}
var lg={l}
var na={n}
var ma={m}
var mb={m}
var mc={m}
var md={m}
var me={m}
var pa={p}
var pb={p}
var pc={p}
var ta={t}
var tb={t}
var ua={u}
var ub={u}
var uc={u}
var ud={u}
var ue={u}
var Aa={A}
var Ab={A}
var Ac={A}
var Ad={A}
var Ae={A}
var Ba={B}
var Da={D}
var Ea={E}
var Eb={E}
var Ec={E}
var Fa={F}
var Ga={G}
var Ha={H}
var Hb={H}
var Hc={H}
var Hd={H}
var Ia={I}
var Ja={J}
var Pa={P}
var Ta={T}
var Tb={T}
var Tc={T}
var Ua={U}
#state 11
0,b,5,0,0,0,0,0,m,11
b,ba,g,5,0,0,0,0,0,6
#
11,8,m,Z,a,aa,ab,x,t,6
#
8,0,0,0,b,11,ba,12,0,12
#/
#
AAB,D,0,b,ba,0,0,12,R,7
AAB,D,0,ba,bb,0,0,12,z,7
8,a,aa,0,b,7,0,R,ab,0
#
11,12,a,0,0,b,g,ga,A,13
11,12,a,0,9,b,g,ga,A,13
#
11,l,la,lb,lc,ld,le,lf,lg,0
#completed reproducton
8,0,a,aa,ab,ac,ad,12,b,0
#special delete immunity
p,l,la,1,e,A,a,aa,ab,p
f,12,b,ba,bb,A,a,p,bc,f
#/
#special arm destruction
9,A,Aa,u,b,ba,bb,bc,bd,0
10,A,Aa,u,b,ba,bb,bc,bd,12
#special bended arm destruction
g,a,aa,u,b,ba,bb,bc,12,12
#special state 7
12,L,D,ba,A,Aa,Ab,bb,bc,7
12,L,D,ba,A,Aa,bd,bb,bc,7
b,ba,bb,12,12,bc,bd,A,Aa,7
#special arm destruction
b,g,ga,ba,A,Aa,Ab,12,12,ba
g,a,aa,u,b,ba,bb,12,ab,12
12,12,u,ba,A,Aa,a,aa,ab,12
#special state 8/lead transiton
g,a,aa,u,b,ba,bb,S,ab,8
g,u,a,p,3,ua,b,ba,bb,8
#arm collision recovery
##starter arm
A,Aa,b,ba,11,g,4,p,Ab,A
g,A,b,11,ba,u,p,4,pa,g
u,g,11,b,ba,ua,a,p,4,u
#
g,A,b,11,ba,ga,4,p,Aa,8
u,g,11,b,ba,ua,p,4,pa,u
##broken arm exeption
b,A,p,0,pa,u,ua,ba,Aa,ba
b,A,p,0,pa,u,ua,ba,bb,ba
b,A,p,0,pa,ba,Aa,Ab,Ac,ba
##broken arm
b,8,u,ba,E,G,Ea,Ga,Eb,12
b,u,ua,ba,E,O,Ea,G,Eb,12
b,A,u,ba,Aa,ua,G,Ga,lb,12
b,A,u,ba,Aa,Ab,ua,G,Ga,12
b,u,A,Ab,ua,ba,Ac,bb,Ad,12
#
b,u,ua,ba,ub,uc,ud,bb,ue,12
b,p,u,12,ua,p,l,la,lb,12
#
b,A,u,ba,Ab,l,la,lb,lc,12
#/
##boundary
b,l,p,u,ba,bb,lb,lc,ld,12
##2 arms (both facing eachother)
B,A,p,4,pa,Aa,pb,b,pc,12
B,A,p,b,pa,Aa,pb,4,pc,12
A,a,aa,p,b,B,4,pa,ab,A
A,a,aa,p,4,B,b,pa,ab,A
#
B,P,b,p,A,Aa,pa,4,pb,12
B,A,p,b,pa,Ba,4,pa,a,0
P,A,p,b,pa,Ba,ba,pa,a,P
#special construct
l,la,3,p,4,pa,a,aa,ab,l
l,b,ba,a,aa,p,4,pa,3,l
#
c,3,b,l,p,1,pa,la,lb,13
l,la,4,p,1,pa,a,aa,ab,l
#construct left
c,l,a,t,b,2,la,lb,lc,8
c,2,b,l,la,lb,lc,ld,le,4
f,l,2,c,la,lb,a,aa,ab,10
f,b,ba,l,a,aa,la,c,2,c
f,l,p,2,ca,la,a,aa,ab,8
#construct right
c,l,la,t,b,j,P,Pa,lb,4
c,j,b,h,a,aa,ab,P,Pa,h
8,a,aa,t,b,ba,j,c,ab,c
c,l,la,t,b,ba,bb,4,lb,8
f,l,la,p,j,lb,a,aa,ab,10
f,a,aa,fa,8,4,p,fb,ab,1
#construct forward
c,r,a,t,e,4,l,la,aa,8
c,4,e,q,a,aa,ab,la,lb,0
f,l,p,4,pa,la,a,aa,ab,1
f,a,r,c,4,l,aa,ab,ac,c
f,l,4,c,a,aa,ab,ac,ad,c
#special instable signal remover
1,4,A,p,u,ua,ub,pa,uc,4
1,b,A,p,u,ua,ub,pa,uc,1
#delete immunity
p,b,P,Pa,a,aa,ab,V,e,p
b,p,a,aa,ab,pa,V,ba,A,ba
1,p,a,aa,ab,pa,V,11,A,4
4,p,a,aa,ab,pa,V,11,A,1
b,ba,bb,p,a,13,aa,pa,V,ba
#
u,b,ba,ua,13,P,Pa,ub,e,u
u,b,ba,ua,P,13,Pa,ub,e,u
u,b,ba,ua,P,Pa,13,ub,e,u
u,b,ba,ua,13,P,Pa,0,t,u
u,b,ba,ua,P,13,Pa,0,t,u
u,b,ba,ua,P,Pa,13,0,t,u
u,b,ba,ua,13,P,t,ta,bb,u
u,13,m,ma,b,11,bb,ua,mb,u
u,m,ma,mb,b,11,bb,ua,13,u
#arm destruction
b,i,u,ba,A,Aa,Ab,bb,bc,12
b,i,u,ba,A,Aa,bd,bb,bc,12
12,A,Aa,u,b,ba,bb,bc,bd,12
#
b,u,ua,ba,A,Aa,Ab,12,N,12
g,a,aa,u,b,ba,12,N,ab,12
#
g,a,aa,ab,ac,ba,bb,12,ad,12
b,12,u,ba,A,Aa,Ab,12,N,12
#bended arm destruction
#g,A,Aa,u,b,ba,bb,bc,12,12
b,12,u,ba,bb,H,Ha,12,Hb,12
#
g,H,Ha,Hb,ga,b,12,12,Hc,12
#
b,12,u,ba,H,Ha,Hb,Hc,Hd,12
g,12,H,Ha,Hb,ga,b,ba,bb,12
#8,12,H,E,Ha,8,b,ba,bb,12
#
g,12,H,Ha,u,ua,b,ba,12,12
b,12,u,ba,H,Ha,Hb,bb,12,12
#forward arm obstruction
b,A,ba,p,Aa,bb,u,bc,Ab,13
b,A,p,Aa,m,ba,u,bb,Ab,13
#special arm obstruction
8,Q,b,11,ba,t,a,p,1,13
#arm obstruction
Q,P,d,a,aa,Pa,p,1,pa,13
Q,P,a,d,aa,Pa,p,1,pa,13
Q,P,a,aa,d,Pa,p,1,pa,13
Q,P,a,aa,d,Pa,Ab,p,1,13
Q,P,d,a,aa,Pa,1,p,Ab,13
Q,P,a,d,aa,Pa,p,1,pa,13
#state 7
7,5,a,aa,ab,ac,ad,ae,af,0
#special turning arm obstruction
12,p,A,Aa,b,ba,Y,Ab,9,13
#state 12
12,a,aa,ab,ac,ad,ae,af,ag,0
#square loop destruction
#b,ba,bb,9,8,bc,0,10,bd,13
#state 8 transition
g,a,aa,u,b,ba,bb,ua,ab,8
g,a,aa,u,b,ba,ua,S,ab,8
g,a,aa,S,u,ba,bb,ua,ab,8
g,b,ba,u,a,ua,bb,bc,bd,8
#turning arm obstruction
w,o,A,Aa,Y,b,ba,Ab,Ac,13
w,p,A,Aa,b,ba,Y,Ab,t,13
b,ba,u,bb,A,p,bc,Aa,Ab,13
#delete
k,13,a,aa,ab,ac,ad,ae,af,13
k,a,13,aa,ab,ac,ad,ae,af,13
k,a,aa,13,ab,ac,ad,ae,af,13
13,a,aa,ab,ac,ad,ae,af,ag,0
#state 5/6/19
b,ba,u,AAA,m,7,a,A,ma,5
b,u,ua,AAA,A,7,Aa,ba,ub,5
#starter growth
1,A,Aa,Ab,Ac,na,8,11,Ad,1
1,n,A,Aa,Ab,na,g,11,Ac,4
1,A,a,b,aa,u,ua,11,Aa,4
4,A,a,b,aa,u,ua,11,Aa,1
#
1,A,a,b,aa,u,ua,11,aa,13
#instable signal remover
1,1,p,u,b,j,A,Aa,pa,4
1,2,ba,A,p,1,pa,u,ua,4
b,f,A,p,ba,j,Aa,pa,Ab,4
b,2,ba,p,A,f,Aa,pa,u,4
c,b,ba,A,Aa,Ab,p,Ac,bb,0
#checker
b,u,l,ua,ub,6,A,ba,uc,15
#special signal movement
b,ba,n,bb,A,Aa,Ab,bc,o,1
b,ba,o,bb,A,Aa,Ab,bc,n,1
b,p,ba,bb,t,ta,tb,bc,m,bc
b,ba,m,t,bb,bc,bd,ta,tb,ba
b,t,ta,ba,p,bb,pa,tb,a,ba
b,p,ba,bb,A,pa,l,la,lb,bb
b,A,p,ba,pa,pb,t,bb,Aa,bb
#b,A,Aa,ba,u,5,Ab,bb,g,6
#merge
b,ba,t,1,0,1,0,bb,ta,ba
b,1,t,ba,0,1,0,bb,ta,ba
b,ba,t,ba,0,1,0,bb,ta,ba
#nand gate
b,ba,t,1,0,bb,0,bc,ta,bb
b,1,t,ba,0,bb,0,bc,ta,bb
b,ba,t,bb,0,bc,0,bd,ta,1
#special junk wire remover
b,AI,l,la,lb,lc,A,ba,ua,13
#signal movement
b,U,a,T,Ta,ba,ab,ua,ac,1
b,U,a,T,Ta,ba,ua,Ua,ac,1
#
b,U,a,T,aa,ba,u,ua,ab,1
b,U,a,aa,T,ba,u,ua,ab,1
#
b,ba,T,Ta,a,aa,ab,ac,ua,ba
b,ba,T,Ta,a,aa,ab,ua,ac,ba
#
b,ba,ad,T,a,aa,ab,ac,ua,ba
b,ba,T,ad,a,aa,ab,ua,ac,ba
#starter
f,A,b,11,l,la,a,aa,ab,8
#
f,8,11,fa,l,la,a,aa,ab,9
#
f,11,A,l,a,la,lb,lc,8,1
#
f,A,a,aa,ab,l,AD,b,11,9
#junk state 8
g,l,la,lb,lc,ld,le,lf,lg,0
g,A,b,ba,bb,Aa,Ab,u,12,0
g,A,b,ba,bb,Aa,a,aa,ab,0
#unnecessary wire remover
b,a,aa,ab,ac,ad,ae,af,ag,12

@COLORS
0 0 0 0
1 255 128 0
2 255 0 0
3 0 255 0
4 0 0 255
5 0 180 0
6 0 100 0
7 255 255 255
8 80 80 80
9 95 95 95
10 128 128 128
11 0 64 0
12 255 165 0
13 255 255 0
14 180 180 90
15 0 80 40

[rowett]

So for the moment, this is a good test cases for the limitations of @TREE format.

True, but it's equally showing the file size limitations of the Wiki as a repository. Served from my local repository (apache server over the Windows file system) the shapeloop3 rule (10.5Mb) is fetched in 253ms and decoded in 379ms.

[muzik]

If lifeviewer isn't going to use the golly default palette for custom rules with unspecified rule colours (which I really think it should, for aesthetic and accessibility reasons, and I don't see why it shouldn't if the none rule and invalid rules already use it) can it use the reversed generations palette that LtL multistate or LifeViewer Generations uses instead?

[rowett]

... and I don't see why it shouldn't

Because there may be people who have created RuleTable rules without @COLOR sections deliberately since they wanted Golly's default colour ramp. If I change LifeViewer's behaviour then those rules will look wrong. There needs to be a good reason to break backwards compatibility.

[rowett]

Build 463 is now live on the Forums and LifeWiki

Please note: you will need to refresh your browser to use the new build (Ctrl-F5 on Chrome)

Enhancements since the last released build:

• added support for @TABLE section of RuleTable rules
  • the runtime is normally faster for @TREE sections so please include both in the Repository if possible
  • LifeViewer will favour the @TREE section if both are specified in the rule

  Code: Select all

  x = 25, y = 11, rule = shapeloop3
  7D11.7D$D5HD11.D5HD$D3H.HB11.D3H.HB$DC2D2HD11.DC2D2HD$3.D2HD14.D2HD$
  3.D2HO14.D2HO$3.C2HD14.C2HD$BDCD2HB11.BDCD2HB$D3H.HD11.D3H.HD$D5HD11.
  D5HD$BDCADED11.BDCADED!
  

• an optional rule name postfix may be specified with the <meta> tag on the web page hosting the Viewer
  • <meta name="LifeViewer" content=".rule /myrepository/rules/">
  • an entry beginning with a "." is used to define the postfix
• performance improvements to the @TREE decoder
• performance improvements to the tokenizer
• improved error reporting for invalid RuleTable rules

Fixes since the last released build:

• fixed colours for RuleTable rules with only 2 states
• fixed Identify misbehaving with LOOP
• fixed an issue with Identify calculating incorrect spaceship speeds after grid growth
• handle HTML entities
• ensure RuleTable sections are only matched at the beginning of the line

The updated hotkey map detailing the LifeViewer keyboard controls is here.

Comments, feedback, suggestions and bug reports welcome!

[Ian07]

What's with the script errors here? https://www.conwaylife.com/wiki/Bumper_ ... er_gallery

[rowett]

What's with the script errors here? https://www.conwaylife.com/wiki/Bumper_ ... er_gallery

Should be fixed now. Thanks for reporting!

[pcallahan]

This isn't a feature request unless it's super-easy, but what would it take to have Margolus rules with more than 2 states? I was thinking about how to embed the 1D rule 110 in a 4-state reversible Margolus neighborhood*. It would not be that interesting since it effectively just stores all history, but it suggests that there could be some interesting CAs out there with reversible >2-state rules whereas the 2-state ones are limited to a few like Critters and BBM. Naturally, it would not be as concise as it is now to write out the permutation of 16 values, but maybe there is some reasonable format.

(It would be nice to have native Margolus rules in Golly as well, but that's a different thread.)

------------ footnote and not part of main post -------------

*The construction (let me know if I've made a mistake) is like this. For a rule 110 row like

Code: Select all

.... a b c d e f g h .... 

where each variable is a single bit, encode the Margolus CA as four states represented as 2-bit strings. The encoding starts with some duplication, so it would be

Code: Select all

.... ab ab cd cd ef ef gh gh .... 

The rule is applied to ab-cd, ef-gh, etc. The transition function g is:

Code: Select all

ab cd → b'c' b'c'

where b' = f(a, b, c) c' = f(b, c, d) and f is the original rule 110 encoding.
So each generation preserves the 3-cell neighborhood in Margolus cells through duplication (not a new idea I'm sure).

To make it reversible (in an uninteresting way), extend it to this 2D Margolus rule:

Code: Select all

⎡ab cd⎤  → ⎡   ab             cd      ⎤
⎣xy zw⎦    ⎣xy⊕g(ab, cd) zw⊕g(ab, cd)⎦

Staring with all 0s except for the original row, the effect is to copy the next generation into the row below. The bottom row will always have the current generation. Rows above may get XOR'd in strange ways, but the history is ultimately recoverable just by running the rule in reverse.

[muzik]

Now that we have rule table support is bsfkl, genext, ... support still planned?

[rowett]

This isn't a feature request unless it's super-easy, but what would it take to have Margolus rules with more than 2 states? I was thinking about how to embed the 1D rule 110 in a 4-state reversible Margolus neighborhood*. It would not be that interesting since it effectively just stores all history, but it suggests that there could be some interesting CAs out there with reversible >2-state rules whereas the 2-state ones are limited to a few like Critters and BBM. Naturally, it would not be as concise as it is now to write out the permutation of 16 values, but maybe there is some reasonable format.

In principle it should be "fairly straightforward" to add multi-state support to Margolus in LifeViewer. I'll take a proper look in the new year and keep you posted.

[rowett]

Now that we have rule table support is bsfkl, genext, ... support still planned?

Yes still on the backlog. RuleTable was higher priority. I always prefer native rule support if possible since it typically makes performance a bit better and editing patterns more straightforward.

[rowett]

Announcement

Code: Select all

x = 77, y = 48, rule = B/S012345678
5o67b5o$4b5o59b5o$8b5o51b5o16$23bo3bo3b3o3b4o3b4o3bo3bo$23bo3bo2bo3bo
2bo3bo2bo3bo2bo3bo$23bo3bo2bo3bo2bo3bo2bo3bo2bo3bo$23b5o2b5o2b4o3b4o4b
obo$23bo3bo2bo3bo2bo6bo8bo$23bo3bo2bo3bo2bo6bo8bo$23bo3bo2bo3bo2bo6bo
8bo5$13bo3bo3b3o3bo6b3o2b4o4b3o3bo3bo3b4o$13bo3bo2bo3bo2bo7bo3bo3bo2b
o3bo2bo3bo2bo$13bo3bo2bo3bo2bo7bo3bo3bo2bo3bo2bo3bo2bo$13b5o2bo3bo2bo
7bo3bo3bo2b5o3b3o4b3o$13bo3bo2bo3bo2bo7bo3bo3bo2bo3bo4bo8bo$13bo3bo2b
o3bo2bo7bo3bo3bo2bo3bo4bo8bo$13bo3bo3b3o3b5o2b3o2b4o3bo3bo4bo4b4o12$6b
4ob5ob4ob13ob6ob9ob8ob4ob5o!
[[
AUTOSTART GPS 1
COLOR ALIVE 32 200 32 COLOR DEAD 0 0 64
ZOOM 8 Y 5
RLE blank b!
PASTEMODE COPY
PASTET 75 PASTE blank 64 2
PASTET 90 PASTE blank 12 2
PASTET 105 PASTE blank 65 2
PASTET 120 PASTE blank 11 2
PASTET 135 PASTE blank 66 2
PASTET 150 PASTE blank 10 2
PASTET 165 PASTE blank 67 2
PASTET 180 PASTE blank 9 2
]]

[muzik]

Looks like I've been giving you hell for just about a year now:

Will this also be able to support the range-extended outer-totalistic rules apgsearch can search?

Also, will non-totalistic hexagonal rulestrings be supported?

Will it ever be possible to draw using dead states of different ages (or, indeed, live states of different ages)? Only freshly created and never alive are available for usage.

Code: Select all

 x = 7, y = 5, rule = B3/S23
b2o$obo$obo3bo$obo2bo$2b3o!

[toroidalet]

For me (I use Safari 9.1.3) the viewer will fail to render patterns whenever the edge or gridlines are in view.