Life tag testing

[rowett]

Build 231 is now up -- sorry for the delay!

Many thanks!

[dvgrn]

Build 231 is now up -- sorry for the delay!

Thanks!

Build 231 seems to be working just fine on the forums, but I'm seeing trouble on the LifeWiki. Pattern infoboxes, examples in the Tiki Bar discussion, etc. are not showing up for me at all. Is anyone else seeing this?

Internet access here has been strangely slow sometimes today, so I don't want to hit the panic button and roll back Build 231 if it's just a temporary glitch at my end...

[rowett]

Nathaniel there appears to be an issue on the Wiki. The LifeViewers are not appearing (at least for me) and the error message from Chrome is as follows:

LifeViewer:1 Refused to execute script from 'http://conwaylife.com/w/load.php?debug= ... n=monobook&*' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

And Internet Explorer says:

SEC7112: Script from http://conwaylife.com/w/load.php?debug= ... n=monobook&* was blocked due to mime type mismatch

Any ideas?

[Nathaniel]

Not sure what's going on on the wiki yet. Does this new build of LV try to load files from another URL?

My server is being really slow right now so it's a bit tough to test things. Will contact hosting people and try to get it sorted out.

[rowett]

No it doesn't it's all self contained. I really didn't change anything exciting in this build so I don't think it's LifeViewer but I'll take a more detailed look later.

[dvgrn]

No it doesn't it's all self contained. I really didn't change anything exciting in this build so I don't think it's LifeViewer but I'll take a more detailed look later.

The [[ NOGUI ]] option seems fairly exciting to me, as a way for people to easily add illustrations without having to ask anyone to upload RLE files for them.

I sent a note to Apple Bottom yesterday, who understands a lot more about LifeWiki categories and templates and MediaWiki scripts and so on, than I do. Here's the exchange so far:

-- Also, in case you run into this problem before it gets fixed: Nathaniel is currently running into errors with Build 231 of LifeViewer, on the LifeWiki but not apparently on the forums. He's working on it with his hosting people at the moment. Don't know if we might roll back Build 231 temporarily -- it's the one that might make it easier to put images directly into articles.

-- Then again, it will presumably mean that RLE starts being added directly to articles again, instead of to the RLE:{patternname} namespace. Is that going to turn out to be a bad idea somehow?

Thanks for the heads-up re: LifeViewer build 231!

Will putting RLE snippets right into the articles themselves prove to be a bad idea down the road -- good question. It feels dirtier to me, somehow, not cleanly separating things that are conceptually separate (information on a pattern vs. encoding of a pattern), but I don't foresee any real trouble, certainly nothing that couldn't be fixed down the road.

That said -- and I haven't looked at that LifeViewer build at all -- is there a reason we couldn't somehow keep RLE snippets in their own namespace?

To echo that question: does it make sense, or is it even possible, to keep using the "RLE:{patternname}" convention somehow, for patterns that are intended as subsidiary illustrations in an article? This is pretty much what we do already for the LifeViewer in the infoboxes, I guess, but not for the

Code: Select all

[[Image:toadsucker.png|framed|center|One particular toad sucker -- the arrow indicates 30 generations of evolution<br />{{JavaRLE|toadsucker}}]]

kinds of images.

Currently making one of these illustrations requires that a contributor figure out how to crop an image to the right size and upload it as a separate step, along with probably having to get an admin's attention somehow and wait around after asking for the associated RLE to be uploaded, before the whole thing will work right...?

It's no wonder people are taking shortcuts trying to put in ASCII-art pattern images and so forth. With the [[ NOGUI ]] option, what's the shortest simplest set of steps that might be made to work?

[dvgrn]

I see LV231 got re-applied, with an extra carriage return character, at noon today with no apparent effect.

Any reason not to experimentally roll back to LV226? If LifeViewer then starts working on wiki pages again, the problem is (probably) somewhere in the LV231 update.

[Nathaniel]

Any reason not to experimentally roll back to LV226? If LifeViewer then starts working on wiki pages again, the problem is (probably) somewhere in the LV231 update.

The reason from my end is that I actually can't "undo" the change on the wiki, since there are so many changes that it causes MediaWiki's diff script to timeout. I could of course just directly upload an old version like LV226, but sadly I didn't keep a copy of old versions locally (since I didn't foresee the diff timeout problem).

Chris -- do you have an old version of LV somewhere that I could upload to the wiki for now? In fact, anyone with access to the MediaWiki:common.js page on the wiki (which should be both of you, I think) should be able to do this even.

[dvgrn]

The reason from my end is that I actually can't "undo" the change on the wiki, since there are so many changes that it causes MediaWiki's diff script to timeout. I could of course just directly upload an old version like LV226, but sadly I didn't keep a copy of old versions locally (since I didn't foresee the diff timeout problem).

I just tried going back to LV226. No apparent difference -- LifeViewer didn't reappear on the Tiki Bar page, even after a hard refresh. I probably should have taken the time to check the Javascript console to make sure the error message was the same, but I just rolled back the change, so now we're back to LV231 again. Anyone else is welcome to try similar experiments, I guess -- I'm off to work for the day soon.

@Nathaniel, to work around the diff script problem, you can go to page history and open the version of the page where you added LV226. No diff is attempted in that case. Then just save that page. As it says in the header, any later changes will be overwritten.

I found that "undo" didn't work because of the diff problem, but even though the "roll back 1 change with one click" link gave me the same diff error, it actually did complete the rollback operation before attempting the diff.

[rowett]

Chris -- do you have an old version of LV somewhere that I could upload to the wiki for now? In fact, anyone with access to the MediaWiki:common.js page on the wiki (which should be both of you, I think) should be able to do this even.

Most the old published versions are kept here.

Also it doesn't look like I have permission to change MediaWiki:Common.js. When I click "view source" it says:

Code: Select all

You do not have permission to edit this page, for the following reason:
This page provides interface text for the software on this wiki, and is protected to prevent abuse. To add or change translations for all wikis, please use translatewiki.net, the MediaWiki localisation project.

Or is there something else I should be doing?

[rowett]

Nathaniel,
I don't know if it's a red herring but when I looked at the Chrome error message:

Code: Select all

Refused to execute script from 'http://conwaylife.com/w/load.php?debug=false&lang=en&modules=site&only=scripts&skin=monobook&*' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

If you navigate to the URL directly referenced in the error message above:
http://conwaylife.com/w/load.php?debug=false&lang=en&modules=site&only=scripts&skin=monobook&*
you get the following additional error message:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 212341 bytes) in /home/njohns01home/webapps/conwaylife/w/includes/libs/jsminplus.php on line 1772

[rowett]

Nathaniel,
It looks like php might be hitting a memory cap and failing. My working theory is that rather than returning a minified JavaScript page it's returning an error message (which is an HTML page) and triggering the Chrome mismatched mime type error above.

See https://www.mediawiki.org/wiki/Topic:Pzvhg52keabfbt3l for a similar issue and instructions to modify the memory limit.

[rowett]

Further research shows that Media Wiki uses ResourceLoader to manage resources like JavaScript and CSS files. One of the first things it does is concatenate and then minify JavaScript files.
I suspect what's happening is that the new LifeViewer 231 being slightly larger than the previous build has just breached a size threshold that's causing the minification process to run out of memory.

Suggested resolution is to increase PHP memory on the server.

[Nathaniel]

Hi Chris and Dave,

Thanks, that all sounds about right. I'll see what I can do, but I might not be able to increase PHP's memory limit. (I'm actually on roughly $5/month shared hosting that provides shockingly little server control). I'll look into other better methods of loading Javascript into MediaWiki again (common.js isn't really designed for "large" JS scripts like this, so I'm not too surprised that we've gone over some limit with it)

In the meantime, I've reverted back to 226 on the wiki again. This should fix things soon -- MediaWiki does some heavy-duty caching of stuff that even page refreshes sometimes doesn't fix though, so it might take a couple hours for the fixes to take effect.

[dvgrn]

Hi Chris and Dave,

Thanks, that all sounds about right. I'll see what I can do, but I might not be able to increase PHP's memory limit. (I'm actually on roughly $5/month shared hosting that provides shockingly little server control). I'll look into other better methods of loading Javascript into MediaWiki again (common.js isn't really designed for "large" JS scripts like this, so I'm not too surprised that we've gone over some limit with it)

In the meantime, I've reverted back to 226 on the wiki again. This should fix things soon -- MediaWiki does some heavy-duty caching of stuff that even page refreshes sometimes doesn't fix though, so it might take a couple hours for the fixes to take effect.

Yay -- LifeViewer is back and working on the wiki! Guess I just didn't wait long enough when I tried that.

Looking at the Tiki Bar again, I'm reminded of Apple Bottom's Template:EmbedViewer. Between that and a variant template yet to be created for the NOGUI image-only option -- Template:EmbedLVImage? -- it seems like we should be in good shape once Build 231+ returns.

Looks like MediaWiki:Common.js is a bit over 248K at the moment, down from 250K+ for Build 231. A quick Google search finds a mention of a relevant-looking 250K limit:

*Security and other implications*
Since UploadStash allows one to read temp files off the MediaWiki server in a new way, it has to be checked very carefully that it does not open any new security holes. Here is what is in place:

• The actual temporary path is not revealed to the user. The user only uses an opaque session key, or a related Special:UploadStash URL.
• UploadStash tries to check that the path it is reading from really is in the repository's temp area.
• Since UploadStash is using PHP to serve the file, which is inherently less efficient, it will refuse to serve files that are larger than a preset limit (currently 250K).

[rowett]

Build 232 is now available on the lazyslug server

Enhancements in this build:

• added [[ NOSOURCE ]] which hides the pattern source textbox - test
• renamed [[ NORLE ]] to [[ NOCOPY ]] and the link from "RLE" to "Copy"
  • [[ NOCOPY ]] will also disable hotkey control and "c"
• improved compatibility of copy pattern source

[rowett]

I'll look into other better methods of loading Javascript into MediaWiki again (common.js isn't really designed for "large" JS scripts like this, so I'm not too surprised that we've gone over some limit with it)

Nathaniel, this MediaWiki Extension:Javascript looks like it might help.

[dvgrn]

Helping Rhombic with some MAP-related scripts at lunch today, I happened to notice that Golly 3.0b1 allows 15 non-canonical versions of any MAP string to be set, without correcting them to canonical form:

Code: Select all

x = 96, y = 93, rule = MAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/
96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$
96o$96o$20o6b70o$20o6b70o$20o6b70o$20o6b70o$20o6b70o$20o6b70o$20o6b70o
$20o6b70o$20o6b70o$20o6b70o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$
96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$
96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$67o$67o$67o$67o$67o$
67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$
67o$67o$67o!

should really have the last four bits of padding cut off, so it turns into

Code: Select all

x = 96, y = 93, rule = MAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw
96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$
96o$96o$20o6b70o$20o6b70o$20o6b70o$20o6b70o$20o6b70o$20o6b70o$20o6b70o
$20o6b70o$20o6b70o$20o6b70o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$
96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$
96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$96o$67o$67o$67o$67o$67o$
67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$67o$
67o$67o$67o!

Mentioning it here because it's kind of hard to tell if LifeViewer is correcting the last character or not. Might it be possible to wrap the text for the Information rule line, so that the whole rule is visible?

[rowett]

I happened to notice that Golly 3.0b1 allows 15 non-canonical versions of any MAP string to be set, without correcting them to canonical form

Thanks for reporting. This has been fixed in Golly 3.0b2.

Mentioning it here because it's kind of hard to tell if LifeViewer is correcting the last character or not. Might it be possible to wrap the text for the Information rule line, so that the whole rule is visible?

LifeViewer also wasn't making the last character canonical. It's fixed and will be in the next released build. Test case is here.
This also includes multi-line MAP rule display in the help information (use hotkey 'I' to get to the help information quickly).

[rowett]

These are the things I'm working on or thinking about. Feel free to challenge or suggest new ideas.

LifeViewer backlog:

• Support for Larger than Life rules
• MAP extension for Hex (22 base 64 characters) and von Neumann (6 base 64 characters) neighborhoods Done, testing.

Golly backlog:

• MAP extension (see above) Done, testing.
• Larger than Life performance improvements Done, testing.
• Finish lifeviewer.lua

[Nathaniel]

I've implemented another way of getting LifeViewer on the wiki, and build 233 is now up. Let me know if anything looks wonky or hasn't carried over properly.

[dvgrn]

I've implemented another way of getting LifeViewer on the wiki, and build 233 is now up. Let me know if anything looks wonky or hasn't carried over properly.

Looks good to me so far. Someone probably ought to write up an introduction of [[ NOGUI ]], [[ NOSOURCE ]], and [[ NOCOPY ]] -- and any other recent improvements that are temporarily slipping my mind -- for the LifeWiki Tiki Bar, and maybe for the "Pattern viewer for forum threads" thread as well. It will be interesting to see if wiki templates can be built now to make adding illustrations a bit easier.

I'd do the writeup, but my Life Lexicon project has just recently gotten down to only a dozen TBDs and half a dozen missing definitions. I'm beginning to hope that there might be an end to that project after all... or at least a good temporary stopping place.

[rowett]

Someone probably ought to write up an introduction of [[ NOGUI ]], [[ NOSOURCE ]], and [[ NOCOPY ]] -- and any other recent improvements that are temporarily slipping my mind -- for the LifeWiki Tiki Bar, and maybe for the "Pattern viewer for forum threads" thread as well. It will be interesting to see if wiki templates can be built now to make adding illustrations a bit easier.

@Dave - I've documented it on the LifeWiki Tiki Bar. I didn't document [[ NOSOURCE ]] because the RLE text boxes are already hidden on the Wiki.
Now I've finished Golly 3.0 work I'll get back to LtL and MAP updates for LifeViewer. Which reminds me - did you get a chance to check out whether the latest OpenGL fix worked on your ancient laptop?

@Nathaniel - thanks for fixing it on the Wiki. Please could you upload the same build (233) here on the forum and then I'll document it in the "Pattern viewer for forum threads" thread.

[dvgrn]

Which reminds me - did you get a chance to check out whether the latest OpenGL fix worked on your ancient laptop?

It's on my to-do list for this evening.

@Nathaniel - thanks for fixing it on the Wiki. Please could you upload the same build (233) here on the forum and then I'll document it in the "Pattern viewer for forum threads" thread.

Looks to me like it's already there. Or do I mean "here"?

[rowett]

Looks to me like it's already there. Or do I mean "here"?

It is here and there! Thanks