Life tag testing

[dvgrn]

Alternatively if the golly gang are open to contributions I may download the Golly source and see how hard it will be to add the isotropic code. The implementation in LifeViewer was fairly trivial.

The Golly Gang is definitely a gang-of-whoever-will-do-the-work, with Andrew kind of holding it all together (and doing the great majority of the coding for the GUI and scripting components of Golly).

Obviously Golly is perfectly capable of handling isotropic rules, since we have a working rule generator script. It hasn't been on my priority list to try to dig into the code that handles parsing and algorithms... so I'm not even sure if isotropic rules would be best supported by adding a new algo to the list, or by modifying the RuleLoader (?) algo so that it understands Hensel's neighbors2.html notation when it sees it.

It's a good question for the golly-test list -- might also get Tom Rokicki's attention again. Back in late January he thought that once the notation issues were sorted out, "...change to the code should be fairly minimal and completely constrained to liferules.cpp."

[Andrew]

I did think about adding limited rule table support into LifeViewer but it's unpleasant in the forum since the rule definitions are either in separate posts or not posted. Plus at some stage I suspect Andrew will release Molly - the LifeViewer integration is done but disabled until he's ready.

Hmm, there seems to have been a major misunderstanding (mostly on my part I suspect!). I've really got no idea what you mean by me "releasing Molly". I thought my involvement had finished and it was up to you and Nathaniel to decide on how and when to release LifeViewer+Molly. The main reason I wrote Molly was to show how it's quite easy to integrate Golly's core rule-loading code into a web app. This includes loading rules stored in external .rule files. I thought we'd decided that the best way to support this latter feature would be if the .rule files are stored somewhere on conwaylife.com so that LifeViewer+Molly could download them when needed. If you're waiting for me to do something then what exactly is it?!

Alternatively if the golly gang are open to contributions I may download the Golly source and see how hard it will be to add the isotropic code. The implementation in LifeViewer was fairly trivial.

We are definitely open to contributions! Tom seems busy on other stuff at the moment so if you wanted to have a go at adding support for isotropic rules, that would be much appreciated. I'm pretty sure all the changes should be limited to the liferules::setrule routine in gollybase/liferules.cpp. That routine defines all the rules recognized by the QuickLife and HashLife algorithms.

If you get to the point of wanting to commit your changes then just let me know a sourceforge account name and I'll give you the necessary permissions. Or just email me the changes if you prefer to do that.

For starters, I recommend getting the latest git repository code via:

Code: Select all

git clone git://git.code.sf.net/p/golly/code golly-code

Then build Golly by following the instructions in docs/Build.html. If you have any questions or problems, I'm happy to help (best to send email to andrew@trevorrow.com).

[rowett]

Hmm, there seems to have been a major misunderstanding (mostly on my part I suspect!). I've really got no idea what you mean by me "releasing Molly". I thought my involvement had finished and it was up to you and Nathaniel to decide on how and when to release LifeViewer+Molly. The main reason I wrote Molly was to show how it's quite easy to integrate Golly's core rule-loading code into a web app. This includes loading rules stored in external .rule files. I thought we'd decided that the best way to support this latter feature would be if the .rule files are stored somewhere on conwaylife.com so that LifeViewer+Molly could download them when needed. If you're waiting for me to do something then what exactly is it?!

Quite possibly on my part too! Back in December I posted a bunch of source changes for Molly to complete the Molly side of the LifeViewer integration along with a bug fix that was causing a crash in Molly in Linux. I guess I was expecting you'd incorporate them in your build, complete the testing of the fix and then let Nathianel and me know when you were ready. Apologies if I wasn't clear. My final post in the merging a minimal Golly into LifeViewer thread was:

I believe my LifeViewer -> Forum -> Molly integration work is complete (pending further testing). I'll disable the "Open in Molly" functionality in builds of LifeViewer until you're ready to release Molly on the forum. Just let me know.

[Andrew]

Back in December I posted a bunch of source changes for Molly to complete the Molly side of the LifeViewer integration along with a bug fix that was causing a crash in Molly in Linux.

I think that must have been around the time my Mac's hard drive crashed and I was offline for a couple of weeks. Or else I saw it and it just didn't sink in (I turned 60 in November so the old brain is starting to deteriorate!).

Anyway, I've incorporated your changes and tested them on trevorrow.com/molly. All seemed to work fine. Just one minor puzzle: your Makefile lists molly.html.mem as one of the install targets, but I don't get any .mem file when I run emmake. Is that file important?

PS. Re support for isotropic rules: I just realized that it would be lot simpler for you to test your changes in Molly, given that they should be limited to gollybase/liferules.cpp. No need to download and build wxWidgets, etc.

[rowett]

Anyway, I've incorporated your changes and tested them on trevorrow.com/molly. All seemed to work fine. Just one minor puzzle: your Makefile lists molly.html.mem as one of the install targets, but I don't get any .mem file when I run emmake. Is that file important?

It gets generated depending on the optimization flags. See here for more information.

PS. Re support for isotropic rules: I just realized that it would be lot simpler for you to test your changes in Molly, given that they should be limited to gollybase/liferules.cpp. No need to download and build wxWidgets, etc.

Excellent idea! Seems like your brain isn't deteriorating as much as you feared

[rowett]

I had a quick look at the Molly source and have a few questions and comments:

1. What is the canonical string representation of a hensel2 format rule? LifeViewer doesn't care. [GM]olly does since there is an API to return it.
2. What's the magic for dealing with B0 in hensel2 format rules?
3. LifeViewer also supports hensel2 format Generations rules with both Moore and Hex neighbourhoods. This would mean changes to (at least) generationsalgo.cpp including a rewrite of the algorithm.
4. We should probably standardize on parsing rules since LifeViewer is more restricted in some ways and more flexible in other ways than [GM]olly. Some examples:
   • LifeViewer insists that totalistic counts respect the neighbourhood. (e.g. rule = B8/S24H would be invalid since Hex neighbourhoods only have 6 neighbours)
   • LifeViewer insists that the "h" for hex neighbourhood is at end of the rule name.
   • [GM]olly allows the neighbourhood to be anywhere in the string (e.g. rule = B3/S2H3 is valid for Hex)
   • [GM]olly allows you to put multiple different neighbourhood characters in the rule name and uses the last one it sees (e.g. B2V/S12VH - ends up in Hex).
   • LifeViewer supports "History" postfix, [GM]olly doesn't.
   • LifeViewer allows "_" (in addition to "/") as a Birth/Survival(/Generation) divider.
5. There's also a ton of stuff that [GM]olly supports that LifeViewer doesn't and probably won't support (Wolfram, Rule Tables, Wireworlds etc.). My view is that LifeViewer should be a subset of Golly. No Venn diagrams!

Comments and thoughts welcome

[Andrew]

Good questions! Rather than answer them here, I think it would be better if you subscribe to the golly-test mailing list and ask the questions there (for all I know Tom might have been working on these issues):

http://lists.sourceforge.net/lists/listinfo/golly-test

Before you post your questions in golly-test, wait for me to post some background info about Molly (I haven't yet mentioned Molly in golly-test). Let me know when you've subscribed.

[rowett]

Before you post your questions in golly-test, wait for me to post some background info about Molly (I haven't yet mentioned Molly in golly-test). Let me know when you've subscribed.

I have subscribed.

[Andrew]

I have subscribed.

Eagerly awaiting those questions...

[rowett]

I have subscribed.

Eagerly awaiting those questions...

Now eagerly awaiting the answers

[rowett]

Build 187 is now available on the lazyslug server

Enhancements in this build:

• Von Neumann neighbourhoods are now suported for totalistic and Generations rules - test
• Wolfram 1D rules are supported - test
• you can now specify just one dimension for bounded grids and it is used for both width and height - test
• neighbourhood is now displayed in help information
• display mode (hex or square) is now displayed in help information
• shift and hotkey "/" now sets display mode to pattern default (hex or square)
• shift and hotkey "1" sets zoom to the nearest integer zoom

Fixes in this build:

• state 1 of Generations patterns with only 2 states was being drawn in black
• patterns with an odd height and a bounded grid were being drawn one line too high

The updated hotkey map is here.

[dvgrn]

Build 187 is now available on the lazyslug server...

Finished a random round of regression -- reviewed a baker's dozen of my sample saved pages from the forums using the new Build 187, and saw only good behavior. Guess I'll check the remaining thirteen for the next release, just for variety.

Nathaniel, Build 187 is ready to release whenever you get a moment.

[Nathaniel]

Nathaniel, Build 187 is ready to release whenever you get a moment.

Done.

[rowett]

Build 188 is now available on the lazyslug server

Enhancements in this build:

• added B0 emulation support for totalistic rules with Hex or Von Neumann neighbourhoods - test
• if the STEP size is too large to allow frequent updates then it will by dynamically reduced to keep the UI responsive

Fixes in this build:

• fixed a visual glitch caused by a previous optimization - test
• [[ TITLE ]] string was ignoring text after last variable substitution - test
• & symbols in script strings were being converted to html friendly versions - test
• snapshots were not working with patterns containing no live cells
• Wolfram rule number must be even - test
• when all cells died the STEP size was ignored
• partial fix for embedding <code> tags inside <viewer> tags

Nathaniel - Please upload this build once Dave is happy since it fixes a visual glitch that's been reported by a few members here.

[dvgrn]

Build 188 is now available on the lazyslug server...
Nathaniel - Please upload this build once Dave is happy since it fixes a visual glitch that's been reported by a few members here.

I'm happy with it already.

Have only done a cursory inspection of anything besides the new features so far. But people keep noticing and reporting the glitch, so I think it will work fine to have them test this next version instead...!

EDIT: I successfully embedded Build 188 into my Blogger weblog template. The Select All link doesn't work yet, but no doubt that's some obvious silly thing that I did, or didn't do.

Any advice on how to do this better, and/or to make the viewer show up in the news feed on the conwaylife.com home page?

[rowett]

EDIT: I successfully embedded Build 188 into my Blogger weblog template. The Select All link doesn't work yet, but no doubt that's some obvious silly thing that I did, or didn't do.

Any advice on how to do this better, and/or to make the viewer show up in the news feed on the conwaylife.com home page?

The "Select All" code is not part of LifeViewer. It's a forum function defined in forum_fn.js. The one used by this forum contains a bug that means it won't work in the new Microsoft Edge browser. I submitted a fix here that I don't remember Nathaniel incorporating but feel free to use the one from that post.

The conwaylife.com home page needs to include both lv-plugin.js and forum_fn.js files. Both files should only be included once. Also it needs a <code></code> block just before the <canvas> element containing the pattern rle.

For forum-like pages (with the Select All) the structure should look something like this:

Code: Select all

<!DOCTYPE html>
<html>
	<head>
		<script src="js/lv-plugin.js"></script>
		<script src="js/forum-fn.js"></script>
		<title>My page containing LifeViewer</title>
	</head>
	<body>
		<h1>My article containing a viewer</h1>
		<div class="rle">
			<div class="codebox">
				<div class="selall">Code: <a href="" onclick="selectCode(this); return false;">Select all</a></div>
				<code>
x = 23, y = 23, rule = B1/S01234V
5bo$6bo$5b4o$4b3ob3o$3b3o4b3o$2b3o7b3obo$4o10b3o$2bo13bo$2b2o12b2o$3bo
13bo$3b2o12b2o$4bo13bo$4b2o12b2o$5bo13bo$5b2o4bo2bo4b2o$6bo6bo6bo$6b3o
10b4o$6bob3o3bo3b3o$10b3o4b3o$12b3ob3o$14b4o$16bo$17bo!
				</code>
			</div>
			<canvas width="480" height="480"></canvas>
		</div>
	</body>
</html>

[Nathaniel]

Build 188 is now up on the forums.

I submitted a fix here that I don't remember Nathaniel incorporating but feel free to use the one from that post.

Sorry about that! It's up on the forums now.

The conwaylife.com home page needs to include both lv-plugin.js and forum_fn.js files. Both files should only be included once. Also it needs a <code></code> block just before the <canvas> element containing the pattern rle.

Done. I had to tweak the code that strips the HTML in blog entries a bit, so let me know if you see anything completely broken (but I think it's OK). The code block still doesn't quite format very pretty, but I'll fix that with some CSS later.

IMPORTANT EDIT:

LifeViewer is now, at least in some limited capacity, also live on the wiki. Here is an example of how you would use it on a page:

{{LV:Viewer|3o$o$bo}}

You should be able to enter anything after the "|" that you can enter in the

Code: Select all

tags on the forum (so it can be multi-line, have comments starting with #C and waypoints, etc). Please test and let me know of any weirdness or ways you think that I should change how it behaves.

Note that, unlike on the forums, it does *not* display the RLE codebox above the pattern. This is intentional (people can view the source of a wiki page if they want the code), but if you feel this should be changed then I can probably be convinced.

[rowett]

LifeViewer is now, at least in some limited capacity, also live on the wiki.

Wow, LifeViewer truly has escaped from the confines of this forum!

Based on my limited testing it looks good so far.

[rowett]

Build 189 is now available on the lazyslug server

Enhancements in this build:

• added support for #CXRLE Gen - test
  • generations >= 1,000,000,000 are shown as "1B+" in the UI
  • shift and hotkey "g" toggles generation display between absolute generation and offset from start
  • waypoints still use offset from start
• added partial support for #CXRLE Pos (it's read and validated but doesn't move the pattern yet)
• added #CXRLE Gen and Pos to the help information
• hotkey "Esc" will now close the standalone viewer - test
• standalone viewer grabs keyboard focus when opened

Fixes in this build:

• fixed a display issue with Generations algorithm when only decaying cells remain

The updated hotkey map is here.

[dvgrn]

LifeViewer is now, at least in some limited capacity, also live on the wiki.

Wow, LifeViewer truly has escaped from the confines of this forum!

Based on my limited testing it looks good so far.

Have you found the LifeWiki Tiki bar page yet? I tried a few options there yesterday, with good results -- thumbnail, autostart, different themes, etc.

There's a sample viewer added to the Copperhead wiki page. I just made a few experimental changes, dropping the initial size to THUMBNAIL, switching to THEME 6 which seems to match standard wiki images better, etc.

Looking forward to setting up a waypoint animation to illustrate something moderately complicated... but haven't decided yet what needs illustrating the most.

EDIT: Hmm, the Reset button seems to be acting up again. It's hard to get control of the Copperhead on the Tiki-bar page, for example. To keep the viewer from looping, it seems like you have to hit Play, then Pause -- hitting Reset twice in a row doesn't do what I expect any more.

[rowett]

Hmm, the Reset button seems to be acting up again. It's hard to get control of the Copperhead on the Tiki-bar page, for example. To keep the viewer from looping, it seems like you have to hit Play, then Pause -- hitting Reset twice in a row doesn't do what I expect any more.

It's working as designed (tm)

For patterns with a LOOP clicking Pause disables the LOOP (so you can then Play past the LOOP point).

Single Reset:

1. returns the pattern to T=0
2. disables waypoints (if defined)
3. enables looping (if LOOP defined and no waypoints defined)
4. does not reset camera or colours

Second Reset (while at T=0)

1. resets the camera and colours to load state
2. enables waypoints (if defined)
3. enables looping (if LOOP defined)
4. starts playback (if AUTOSTART defined)

Perhaps point 3 of the Single Reset list should be changed?

[rowett]

There's a sample viewer added to the Copperhead wiki page. I just made a few experimental changes, dropping the initial size to THUMBNAIL, switching to THEME 6 which seems to match standard wiki images better, etc.

How about this one with moving grid lines (uses the new LINEAR command with a waypoint and LOOP, and doesn't suffer from the Reset issue):

Code: Select all

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o!
#C [[ COLOR GRIDMAJOR 209 209 209 COLOR GRID 229 229 229 GRID THEME 6 AUTOSTART GPS 5 ZOOM 28 THUMBNAIL T 98 LINEAR Y Y 10 LOOP 99 ]]

[dvgrn]

For some reason I was thinking that the way it was supposed to work was for a single click to restart the waypoint animation/loop/whatever, and it would take two clicks on Reset to cancel animations entirely and let users do whatever they want from T=0.

[rowett]

For some reason I was thinking that the way it was supposed to work was for a single click to restart the waypoint animation/loop/whatever, and it would take two clicks on Reset to cancel animations entirely and let users do whatever they want from T=0.

Yes it's the other way around and the reason is AUTOSTART. You'd have no chance to do the second reset at T=0 if it had already started playing automatically on the first reset.

[rowett]

Build 190 is now available on the lazyslug server

Enhancements in this build:

• added [[ THUMBSIZE ]] script command to define thumbnail size divisor (2, 3 or 4)
• added [[ THUMBLAUNCH ]] script commmand which changes thumbnail behaviour so when clicked on launches the standalone viewer - test
• default grid line colours are now based on brightness of the background colour
  • no longer need to define custom grid line colours when using Theme 6
• when a thumbnail is expanded briefly display hotkey to shrink

Fixes in this build:

• saving (hotkey "v") and restoring (shift and hotkey "v") camera position now works correctly with thumbnail view