Difference between revisions of "LifeWiki:Tiki bar"

From LifeWiki
Jump to navigation Jump to search
(80 intermediate revisions by 11 users not shown)
Line 15: Line 15:
* See [[LifeWiki:Tiki bar/Archive/2018]] for Tiki bar discussions started in 2018.
* See [[LifeWiki:Tiki bar/Archive/2018]] for Tiki bar discussions started in 2018.


== Conduits and converters ==
== The list(s) of rules investigated on Catagolue ==


I'm gradually gathering the necessary courage to tackle the new Life Lexicon items that start with "P".  Looks like one of the big things I should do is to carefully figure out how to make proper use of [[Template:Reflector]], but in this modern LifeViewer age I don't think I agree with the part about "The image in this infobox should '''NOT''' include the glider that is to be reflected...".
Short version: these have increasingly become a burden to maintain on-wiki, and with Catagolue now having [https://catagolue.appspot.com/rules its own endpoint] providing an overview over and an exhaustive list of all rules searched, they're largely irrelevant now. (The on-wiki list was only started because Catagolue didn't provide one at the time.)


Seems to me these template recommendations should be updated to say something like "The image in this infobox '''should''' include the glider that is to be reflected -- optionally, two input gliders separated by the mechanism's minimum [[recovery time]], and an output glider if that allows a smoother animation.  However, the bounding box and population count should be calculated with these gliders removed."
So I'm giving up maintainership of these. If anyone wants to take over, please do! [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 17:00, 7 January 2019 (UTC)


It would actually be pretty annoying to provide RLE of a reflector and not at least show where the input is supposed to go.  When copying and pasting one of these to use in a larger construction, it's usually pretty handy to have some kind of marker for where the the input goes and where the output comes from -- thus the [[ghost Herschels]] in recently added [[Herschel conduit]]s.
: If we are to retire the [[List of rules investigated on Catagolue]], how should we do this? Add a notice at the top saying:


[Ideally the marks are state-4 LifeHistory so you don't have to edit them out after pasting -- but we should probably stick with simple 2-state Life patterns on the LifeWiki and not open the LifeHistory can of worms.]
: "This page is no longer actively maintained in favour of the [https://catagolue.appspot.com/rules equivalent Catagolue page]."


... And we can probably get rid of [[Template:Reflector/Doc]] while we're at it, no?
: or words to that effect?


Before I start this I'll definitely undertake to review all the existing converters and reflectors and conduits -- there are a bunch with raw RLE and/or uploaded pattern files missing.  That's relatively easy to fix, once we have an official decision about whether and how to show inputs and outputs.  I'm currently puzzled by the mysterious [[Template:ConduitInput]] and [[Template:ConverterInputOutput]]. Not that that's surprising -- I'm easily confused by all this wiki template trickery. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:26, 8 May 2018 (UTC)
: It still might be a good idea to actually keep the information in the LifeWiki, because Catagolue occasionally has outages when the daily quota has been exceeded, whereas conwaylife.com tends to be permanently accessible. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 18:26, 7 January 2019 (UTC)


:I agree that reflector patterns should include the input glider.  I'm the one who originally wrote that they shouldn't, and I'm not really sure why anymore. It can't have been very good reasoning, because I completely disagree with it now.<br/>~[[User:Sokwe|Sokwe]] 07:08, 9 May 2018 (UTC)
:: The wiki page does have some advantages over the Catagolue one, such as listing the rule integers for outer-totalistic rules and being easier to edit (e.g. adding names for new rules). [[User:77topaz|77topaz]] ([[User talk:77topaz|talk]]) 23:51, 7 January 2019 (UTC)


:[[Template:Reflector/Doc]] also asks users not to put animated images on pages, instead suggesting that one should "''consider using a static image of the reflector with a caption that links to the animation''". I think this does not match the general current LifeWiki practice regarding animated images, or generally animated content. Should we reconsider? [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 05:25, 7 June 2018 (UTC)
== Time for a consensus decision on pnames? ==


:: It does seem to me that we have a developing consensus that LifeViewer-based illustrations are a good way to go.  There are quite a few Help documents and templates that were written long before the advent of LifeViewer. I'd love to have the Help actually explain to a new user how exactly to add RLE to the RLE namespace, how to get that RLE to show up in an infobox or an embedded viewer, how to adjust the LifeViewer config so that animations (if any) look good, etc. It will take a while to get all the docs updated, no doubt.  My edit yesterday was just a first attempt to start chipping away at the problem. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:48, 7 June 2018 (UTC)
I've run the RLE-scraper script to collect new RLE files for a bulk upload. The script found 321 new RLE files. Before I send them to Nathaniel, it looks like I'll be doing some more standardization, especially involving pnames.


:::Definitely agree! Unfortunately writing documentation is one of things I'm hopelessly.. well, hopeless at. ;) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 10:33, 9 June 2018 (UTC)
The [[LifeWiki:Pattern_pages|guidelines for creating pnames]] say very clearly:
<pre>pname (required) The name of the pattern being described, but converted to lowercase and with all non-alphanumeric characters and spaces removed.</pre>


== Lexicon tags ==
This has worked fine for us for the great majority of cases, but there are two related cases where blindly following that rule creates not-very-good pnames:


Many of our articles (glossary, in particular) are based on, or at least synced with, Life Lexicon content. This creates a need to update these articles when the Lexicon changes.
# '''apgcode-based names''', where removing the underscore can sometimes concatenate two strings of digits. For example, according to the rule, [[Xs15_3lkia4z32]] is theoretically supposed to have a pname of "xs153lkia4z32", which reads as if it's a 153-bit still life.  Underscores are confusing in article names because MediaWiki turns right around and renders the name without an underscore. But they do seem to work fine, and they're necessary in other article names, anyway -- raw RLE "pname_synth" synthesis files need them.
# '''patterns named after a Niemiec or pentadecathlon.com ID''', where removing a period causes similar problems with readability.  Examples:
* [[37P7.1]], created by Sokwe in 2009 with a pname of "37p7.1" -- including the period. Another similar case is [http://conwaylife.com/w/index.php?title=37P10.1&diff=13437&oldid=13432 37P10.1], where Sokwe changed the pname from Nathaniel's original "37p101" to "37p10.1", back in 2010.


Some of that has been handled in an ad-hoc manner [[User:Apple Bottom/TODO/Life Lexicon|on my userpage]], but the process is fairly involved: look at the project page, find an article to work on, make sure it needs to be worked on, make the necessary edits, make the necessary changes to the project page to reflect the fact you edited the article.
* [[38P11.1]], with a pname of "38p111". Periods in filenames are definitely annoying because the part after the period can look like a file extension... but I think "38p11.1" would really be better here.


It's also not easily found by newcomers who may want to help out. (OK, I'll admit, there likely aren't droves of eager newcomers to begin with, but that nonwithstanding, if you don't know said page exists you're not going to find it easily.)
* Several patterns with pnames created by Entity Valkyrie recently: 14p2.1, 14p2.3, 14p2.4, 28p7.3, 28p7.3bumperbouncer, 28p7.3eatingss, 31.4, 33p3.1, 33p3.1bumper, 33p3.1eatingss, 33p3.1reactions, 34P6.1.


So I was thinking, can't we improve on this? And I just had the idea of tagging articles themselves instead, indicating which version of the Lexicon they correspond to.
====Capitalization Bad====
The last pname in that list is also nonstandard due to capitalization, but that's a separate problem. The full list of capitalized pnames is 35P12, 53P13, 55P10, 113P18, BF20H, BFx59Hinjector, FMHEB, Gtolwss.rle, L112functions, L156reactions, L156variants, L200, Lightspeedcrawler, P5HWV, P58toadflipper, PT8P, PT9B, PT38P -- again all by Entity Valkyrie, I think.  I'll definitely have to go through and fix all of these, just because they're dangerous to cross-platform uses of the pattern collection:  "35P12.rle" will overwrite "35p12.rle" on a Windows operating system, but not on Linux.  And LifeViewer fails to find "RLE:35P12" when told given "pname = 35p12", because the LifeWiki's filesystem is case-sensitive.  So I think the no-capitalization part of the pname guidelines should continue to be very carefully enforced.


The Nethack wiki does something similar; for instance, take a look at their [https://nethackwiki.com/wiki/Foodless Foodless] article, and you'll find that it has an indicator at the top right saying that the page reflects Nethack 3.4.3 (rather than the current 3.6.1), generated by [https://nethackwiki.com/wiki/Template:Nethack-343 this template].
====Periods Not So Bad====
However, given the long precedent for pnames occasionally including periods, I'm not planning to change any of Entity Valkyrie's pnames if a period is the only non-standard part. Should probably do something about "31.4", but the rest seem okay.


We could use something similar. There wouldn't necessarily have to be a visible indicator (though there could be); at the very least, though, pages could be tracked in appropriate categories, and we'd know at a glance what needs to be updated (or at least reviewed) and what's current.  
-- Anyone know where the ".4" comes from in "31.4", by the way?  The problem with calling the thing just plain "Snark catalyst" is that there are several workable Snark catalysts. 31.4 is one of the two most common ones, but it's not exactly "the" Snark catalyst.  But no other common name has caught on. ('''Bellman Zero''', anyone? '''Catalyst B0'''?  '''31.4''' seems better than either of those.)


This way, all edits would be in one place: review an article and make edits as necessary, and also update the tag to indicate it now reflects a newer Lexicon version. And placing those tracking categories into an appropriate supercategory and placing that in the existing category tree in turn would allow editors interested in helping out find articles in need of review.
====Summary questions====
TL;DR:  Does anyone object if I adjust the pname guidelines to say that periods are okay, but "only where necessary", or something along those lines?  And also say that underscores are okay only in apgcode pnames and raw-RLE _synth articles?  Underscores are a minor nightmare, because MediaWiki automatically converts them into spaces, and pnames really aren't supposed to include spaces. I'm reasonably sure that that underscore-to-space conversion is bound to cause coding difficulties somewhere sometime.  But unless someone wants to recommend consistently using periods in place of underscores in apgcode pnames, I just don't see any good alternative.


There would be two downsides. a) most of the Lexicon doesn't change in each Lexicon release, so we'd have a lot of articles tagged as (say) reflecting v28 when in fact they're also current, by virtue of not having changed since v28. And b) we wouldn't easily be able to see which articles are missing from the wiki entirely.
Comments, suggestions, disagreements? Please post 'em here! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:56, 15 January 2019 (UTC)


I still feel that this would be an improvement though, and there's no reason we couldn't combine these tags with a manually-curated project page to get the best of both worlds.
: Also, not sure if anyone will find this note here, but gmc_nxtman's recent series of synthesis postings made for a good test case for reworking several pages recently updated by AwesoMan3000. It's been different changes for every article, but it tends to take a lot of fiddly adjustments to synchronize the pname, RLE, synthesis RLE, LifeViewer config, and any files already uploaded to the LifeWiki server.


Also, re: downside a) specifically, I think this could be dealt with by also having an indicator on the wiki saying which Lexicon release is current; pages that haven't been tagged as reflecting the current version would then display a gentle, unobtrusive note, and anyone viewing such a page could quickly check that it does indeed match the current Lexicon release, and update the tag if so.
: I've done half a dozen articles for starters:  [[very long snake]], [[trans-block on long hook]], [[integral with tub]], [[eater head siamese eater tail]], [[cis-block on long hook]], and [[aircraft carrier with feather]].  LifeViewer generally Just Works once there's a raw RLE article with the right pname, but the images come out too small by default, so I've been adding viewerconfig '''THUMBSIZE 2'''. This should probably be a default added to the template, with SUPPRESS, except I don't know if that will change the looks of a lot of existing articles).


Thoughts? [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:49, 18 July 2018 (UTC)
: This leaves [[boat with long tail]], [[beehive with nine]], [[broken snake]], [[cis-boat with nine]], [[eater bridge eater]], [[long boat tie ship]], [[long shillelagh]], [[ortho-loaf on table]], [[snake siamese snake]], [[snake with feather]], [[snorkel loop]], [[trans-boat on table]], [[very long shillelagh]], and [[sesquihat]] that still need editing to add the latest syntheses. I could definitely use some help with updating these:
# decide whether the pname should change to match the article name
# new synthesis copied from '''Talk:{name}''' to '''RLE:{pname}_synth''', either updating or replacing any RLE that's currently there
# fix "synthesis = {n}" in infobox
# add to infobox: <pre>viewerconfig    = [[ THUMBSIZE 2 ]]</pre>
# remove Life1.05 and Life1.06 lines (optional)
# double-check that article name matches article text and Catagolue link -- there's often something wrong there
# add '''RLE:{pname}''' if it's not there already, to make LifeViewer show up instead of an old image file


: This seems like a fine idea to me. As far as downside a) goes, I think that the last year of Life Lexicon updates is highly unusual, since it involved catching up after over a decade of no maintenance at all.
: A couple other tasks are admin-only --
# If pname has been changed, delete {old pname}*.rle from LifeWiki server to keep things in synch
# If Life1.05 and Life1.06 lines have been removed, delete corresponding files from server. (I'm leaving the "plaintext" (.cells) links, because I'm hoping to generate those automatically for all sub-64x64 patterns currently on the LifeWiki.)
# When a good break point is reached, re-run the auto-upload script and collect all the new pattern and synthesis RLE text into a ZIP file for bulk upload.


: The standard editing methodology for new Lexicon releases is to maintain a Changes section at the top of the raw Lexicon text file, carefully listing every "added" or "edited" entry since the last release, by name.  Nobody is supposed to edit a Lexicon definition without updating the change log.  This should make it trivial to find missing articles, and hopefully should also allow an easy update to the tags.  Every Lexicon entry that's not listed in the change log can be automatically bumped to the latest lexicon release.
: Here again, I'm leaving some broken links to pattern or synth files, which I'm planning to fix fairly soon (by putting the files back in place using the auto-upload script).


: That's a lot of small changes to a lot of articles with every Lexicon release, though. Does it make sense to have the default Lexicon tag be just {{LexiconLatest}} or some such, with a template to display on the page whatever the latest Lexicon release number actually is?
: This is the kind of project where I'm very unlikely to get everything exactly right. Independent reviews of all this stuff will be greatly appreciated, and just let me know what I've done wrong so far. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 12:33, 21 January 2019 (UTC)


: Then, for the next Lexicon release (30), we can just update the (relatively small) list of changed definitions to say "Release 29" -- and then after each definition is reviewed and patched, the tag is updated at the same time, back to {{LexiconLatest}}? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:15, 18 July 2018 (UTC)
==Special pages broken?==
I have noticed several oddities in a few of the maintenance pages:
* [[Special:BrokenRedirects|Broken redirects]] claims there is an existing page named [[RLE:lobster]] that redirects to a non-existent page named [[RLE:83p7h1v1]], when the opposite is actually true.
* [[RLE:Loafer]] is listed in various places (such as [[Special:ShortPages|Short pages]]) despite being in the wrong namespace.
* [[ConwayLife.com:About]] is listed as in [[Special:DoubleRedirects|Double redirects]] despite not having any redirects.
* [[Special:FewestRevisions|Pages with the fewest revisions]] isn't even close to being correct.
* [[Special:UncategorizedPages|Uncategorized pages]] is quite incomplete; I noticed the articles [[Ruler]] and [[Alternating rule]] were not listed even before I added categories to them, and these are almost certainly not the only examples.


::I suppose that would work, but it's pretty much the opposite of what I was trying to accomplish. ;) I was thinking of this as a status checkbox of sorts where editors would check off that yes, this article has been reviewed for Life Lexicon release 30 or 50 or whatever, and any articles that lacked that virtual checkmark would automatically be herded and available for review and/or updating, as necessary.
Anyone know what's up with these? [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:35, 15 January 2019 (UTC)


::Having a "LexiconLatest" tag instead would mean checkmarks that check themselves, by default, and that we'd then have to go and un-check. That's not so different from the current approach, with my TODO page.
==Rulespace info for eaters, reflectors, conduits, etc.==
So lately I've been busy adding isorule parameters to the infoboxes for various patterns. So far I've stuck with oscillators, spaceships, still lifes, and infinite growth patterns, but I'd also like to expand this to other pattern such as conduits which are a bit more ambiguous. For example, the [[sidesnagger]] works in B/S23, but obviously there are no gliders for it to eat. I'm of the opinion that for these patterns we should show the rules they're actually ''useful'' in, since that's what makes them notable in the first place, (though with the possible exception of [[eater 1]] since it's such a small pattern) but I'd like to hear others' thoughts on this. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 18:57, 19 January 2019 (UTC)


::But you raise a good point. We have a log of Life Lexicon changes, and once we're actually caught up with the Lexicon in general all we'd have to do is keep an eye on those. Hmmm.
: My main thought is that all but the very simplest and lowest-step-size conduits are very close to rule-specific -- useful only in B3/S23. Adding a B8 or an S8 might be one of the few isotropic bits where some conduits would survive the rule switch (?). Even if a particular conduit works in another rule, it's only interesting if a large enough group of conduits works in the alternate rule to make it computationally universal.  (That would probably make it construction-universal, too, but only after someone re-did all the single-channel search work to produce new recipe libraries.)


::Here's a thought, admittedly a rather complicated one. How about we do both? That is to say, how about a tag template that has ''both'' an explicit parameter ''and'' uses a default "low watermark", displaying the higher of both?
: Anyway, from my point of view the reason why B38/S23 or B3/S238 doesn't get a lot of attention is that there's nothing really new and exciting about those rules to make up for the fact that the rule spec is just that little bit more complicated... pun maybe intended. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 02:04, 20 January 2019 (UTC)


::The explicit parameter would be used by editors to indicate that a page has been reviewed/updated to reflect a certain Lexicon release; the "low watermark" (kept in a template of its own) would be updated by us whenever we're sure that ''every'' Lexicon-related entry reflects a certain Lexicon version.
==[[apgsearch]] and [[Catagolue]]==
Would anyone be opposed to a reorganization of the information on these two articles? I noticed that a lot of the information in the Catagolue article really applies more to apgsearch rather than the site itself, and therefore might be worth moving. Such a change would be particularly easy to revert if need be, but I'd rather not go through the effort if that's the case, so I'd also like some feedback about that. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:32, 19 January 2019 (UTC)


::For instance, assume that all our articles conform to Lexicon release 30. Suppose that release 31 comes out now. We then go through the changelog, edit all articles that need updating, and after that's done, we conclude that no further changes are necessary, and bump the "low watermark" to 31, thus causing ''all'' articles (that reference the Lexicon) to declare that they match release 31.
: No opposition here. I wouldn't think anyone would be likely to revert changes to those articles, just the usual quick review to see if the changes happen to serve as a reminder of anything else that should be added. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 02:04, 20 January 2019 (UTC)


::One advantage of this would be that we'd still see when an article was last ''explicitly'' reviewed. For instance, an article might say it reflects Lexicon release 31, but the "version=" parameter might still say it was last reviewed for 28. If nothing else, this would make it easier to spot articles that haven't been reviewed for a long time and where discrepancies might've crept in.
== Pattern collections ==


::Another idea: we've already got [[Template:LinkLexicon]] to link to Lexicon entries. We could repurpose this to also additionally display a tag, which would save us the need to edit 831 articles just to add a tagging template.
I just thought to check the LifeWiki pattern collection for outdated links to Mark's database. There were 165 RLE files with dead links in the comments.  I fixed two of them, one by creating an RLE:{pname}_synth page and one by editing the pattern comments and deleting and re-uploading the file by hand... and then thought, "Nope.  There has to be a better way."


::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:50, 19 July 2018 (UTC)
Now I'm just doing a search-and-replace, "http://www.conwaylife.com/ref/mniemiec" instead of "http://home.interserv.com/~mniemiec/", and will ask Nathaniel to re-upload all those files to the server along with the output of the auto-upload script.


::: This all seems reasonable to me -- especially sneaking a displayed tag into [[Template:LinkLexicon]].  Now that Golly 3.2 and Release 29 are safely out the door, I'm sorta kinda planning to get back to work on the LifeWiki ToDo list for Lexicon updates, with the intention of getting everything up to date eventually -- hopefully well before Release 30 comes along to confuse things any more. We already have some kind of a tracking system set up for Release 28 and 29, so maybe it makes sense to keep using that, and design the new template/tag system to really come into use once everything has been updated to Release 29.
Of course, if these _synth files were created when that website was available, a lot of the actual syntheses might be out of date as well. A dynamic endpoint somewhere for reporting the actual latest synthesis for each object would certainly be a step up from the current perpetually out-of-date synthesis files.


::: So in early 2019, if we end up with a list of say fifty articles that have changes for Lexicon Release 30, my thought would be to update just those fifty articles to specifically say "Release 29" (however we decide to do that exactly -- maybe with a template saying "this article is out of date, please help out by updating it"?).  Then bump up the "low watermark" to 30 right away.  As articles get updated, the "please help" template can get removed again with the same editDoes that work? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 18:49, 19 July 2018 (UTC)
-- On the other hand, there are big advantages to Mark's comprehensive collections of practically every historically known way of constructing each object.  Sometimes you might want a synthesis with a suboptimal number of gliders but better clearance than usual, or might want an incremental construction starting from one half of the still life, or whateverReporting just a single current-best synthesis would lose a lot of that useful information. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:25, 24 January 2019 (UTC)


::::OK, cool. :) Good to hear you'll have some time to devote to the Lexicon-to-LifeWiki TODO list. I'm not able to put in much effort there myself --- too much studying, too many exams. Ah well.
: The problem of deciding what to do about glider syntheses is still where it was in January. I'm still leaning toward leaving things pretty much as they are until Mark Niemiec's new synthesis database becomes available, and then figuring out how to link directly to the relevant Niemiec synthesis page, for any object that has a LifeWiki article -- and removing those _synth files from the Patterns folder. Most of the Niemiec-derived _synth files that have been uploaded will probably be subtly out of date when the new version comes out. Anyone have any better ideas?


::::Re: marking e.g. fifty articles as needing updates and everything as conforming to e.g. release 30 by default --- that would be a lot easier if we had Lua scripting available! MediaWiki's templates only go so far and aren't really meant for pushing lots of structured data around.
: In other news, [[User:Dvgrn/Plaintext_files]] documents the 695 new plaintext-format .cells files that are available on the server now. This means that a lot of articles' infoboxes could now be updated to say '''|plaintext        = true''' along with '''|rle              = true'''. If nobody wants to tackle making these several hundred edits manually, I might eventually look into setting up some kind of automated search-and-replace functionality, based on this kind of article list. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:45, 17 February 2019 (UTC)


::::Our options there would include at least the following:
:: I noticed once again that there are quite a few patterns with capitalization in their names, most of which ([http://www.conwaylife.com/w/index.php?title=RLE:P52G3to4&action=history with a few exceptions]) were created by [[User:Entity Valkyrie]]. Even [[RLE:ModelD]] is still in that list despite having been deleted and moved over a week ago, so those should probably be fixed. Something more confusing, though, is that certain small patterns (such as [[44P14]] and [[44P12.3]]) were labeled as being too large despite easily fitting within the 64&times;100 limit. What's up with that?


::::# Manually edit each of those 50 articles (e.g. by setting an extra template parameter) to override the "low watermark". Not ideal --- we might as well just edit those 50 articles to update them if we're already editing them anyway.
:: As for adding these to the infoboxes, I'll probably get to that eventually but I'm a bit too busy at the moment. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:14, 17 February 2019 (UTC)
::::# Provide a global "kill switch" for the low watermark that, when set, causes the low watermark to be ignored. Pages explicitely listing a conforming Lexicon release would then display that instead, so those 50 "release 29" articles would show up in the right category, etc. Also not ideal --- there might be many other articles that would also have the explicit "reviewed for release 29" tag, or older tags at that, which would NOT need to be updated.
::::# Keep a list of those 50 articles, and rig the template to display a notice if the title of the transcluding page happens to be on that list. '''Also''' not ideal --- we'd have to curate that list, and as I said, MediaWiki templates aren't really meant for this sort of thing.


::::Maybe there's another solution I'm not seeing, though.
::: Many thanks for the review.  I believe I've patched all the remaining instances of pnames with capital letters: 68p16.cells/.rle, 76p8.cells/.rle, 113p18.cells/.rle, 209p8.cells/.rle, p130shuttle2.cells/.rle, l156reactions.rle, p24lwss.rle, and p52g3to4.rle.  Obviously in the future the auto-upload script should check for capital letters and complain.


::::That said I also have a feeling we're trying to overengineer the solution, though, or perhaps attacking the problem from the wrong angle. After all, what do we want to do? Keep the LifeWiki current as far as Lexicon content goes. How do we achieve that? By importing Lexicon as necessary, and (once done) keeping an eye on changes made to the Lexicon and mirroring them on the wiki (again, as necessary). And how do we do ''that''? By rolling up our sleeves and working on it. Fancy templates and tagging nonwithstanding we won't get anywhere if we don't just jump in and do it.
::: I haven't yet looked into why a few small patterns didn't get .cells files created properly. Will figure it out and fix that bug along with adding the capitalization check. That one isn't too worrisome -- anything that got missed in the first round we should be able to pick up on the next auto-upload. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 19:54, 18 February 2019 (UTC)


::::<small>(And by "we", I mean whoever's willing to do that job.)</small>
:::: The missing small files that were flagged as "too big" seem to have been mostly due to patterns with no header lines in the RLE namespace. I think I've fixed all of those now.  A few such files managed to get themselves uploaded to the LifeWiki server, but the auto-upload script now reports those when it sees them, so I think those are all cleaned up now also.


::::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 18:16, 20 July 2018 (UTC)
:::: As before, if anyone wants to add "plaintext = true" to the many articles where that's missing, please go right ahead.  The latest auto-upload script report has been added to [[User:Dvgrn/Plaintext files]], so the dump of newly added .cells files there can be used as a checklist.  There's also the option of adding plaintext file links to embedded viewers as appropriate. I did a couple of samples, e.g., [[68P9]] -- it's pretty easy.  It should always be just a matter of adding this to the caption:
<pre>[http://www.conwaylife.com/patterns/{pname}.rle RLE format]
[http://www.conwaylife.com/patterns/{pname}.cells Plaintext format]<br /></pre>
:::: Maybe this is something that should be done with a template, to make things even easier?


:::::Re: overengineering... yeah, offhand I don't see a better solution than the first one:  manually edit 50 articles, copying and pasting the same "stub"-like template marker in as a header.  This is a bit tedious, but that's what multiple browser tabs are for, and it can be done pretty easily in half an hour or so.  The idea is that we can make a little bit of effort to spread the update work around.  (Here "we" means the small group of people who have done the work so far -- a small group because it's kind of tricky to do everything right, so not many people have figured out all the fiddly details.)
:::: The script now also checks for pnames with uppercase letters and complains about that. I don't think there are any of those at the moment. If anyone sees other problems or oddities that the auto-upload script should be catching but isn't, or if there are any other surveys or reports that it should do while it's running through all the articles anyway, please make suggestions here. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:09, 27 March 2019 (UTC)


:::::I can add "needs Lexicon update" headers to 50 articles in half an hour, but I sure can't do a careful comparison and repair on 50 articles, especially if it will require adding new illustrations or modifying existing ones. But it seems to me that there's a larger (and growing) population of LifeWiki users who can perfectly well review a particular Lexicon definition when they trip over a "needs Lexicon update" template header begging for help.  Often it isn't too hard to find what needs changing, make the required edits, and remove the "needs Lexicon update" tag at the same time.
::::: I just modified [[Template:EmbedViewer]] to link to the RLE and Plaintext automatically. The biggest problem with this, of course, is the larger patterns don't have a plaintext file. I'm not sure how to elegantly deal with this, unless there's a way to make it read the RLE header and find the pattern size or something. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 19:55, 27 March 2019 (UTC)


:::::Every one of these articles that someone picks up and fixes, is one that I don't have to do myself... and in the meantime, a half hour of work has already brought the LifeWiki more up to date, by specifically flagging the fact that there's newer information somewhere else that needs to be integrated into the article.  Seems like this might be a good habit to get into, for as long as the Life Lexicon is kept more or less in synch with current reality.
== Help Wanted with templates and general review ==


:::::Sound reasonable?  And could you have a look at [[Template:NeedsLexiconUpdate]] and see if it has everything in it that this plan might need? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:02, 20 July 2018 (UTC)
Here are three problems that I'd like to fix. I could probably track down the necessary template changes myself, eventually, but I'd like to have expert advice if I can get it.  Both of these items have been sorta kinda mentioned on the Tiki Bar before, fairly recently:


::::::Redirect pages don't need any markers saying they're from a Lexicon entry -- do they? I've been trying to rebuild some momentum by getting the remaining redirects done...  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:57, 26 July 2018 (UTC)
1. I think '''THUMBSIZE 2''' should be the default for all infobox LifeViewers. I keep adding '''#C [​[ THUMBSIZE 2 ]]''' to get infobox pattern frames back to the right size.  There seem to be hundreds of these '''THUMBSIZE 2''' specifications by now, but looking through a bunch of new aircraft-carrier-themed still lifes that AwesoMan3000 added recently (see links a few paragraphs up)... those all need the same addition done to them, and there are dozens or hundreds more existing articles that still have the same problemThe [http://lazyslug.no-ip.biz/lifeview/plugin/suppress.html '''SUPPRESS''' command] should follow '''THUMBSIZE 2''', so that the relatively few viewerconfigs that specify '''THUMBSIZE 3''' won't start throwing errors after the change is made.


:::::::Cool, good to see this is already progressing. Good job! :) I'm a little less swamped now, so I'll take a look at the Template'n all over the weekend.
2. As of this morning, Nathaniel has officially removed the Life 1.05 and Life 1.06 patterns from the LifeWiki patterns directory.  That means the infobox template probably ought to be adjusted to stop showing those links. We could remove "'''|life105 = true // |life106 = true'''" from all the articles that have those infobox parameters instead, but only if someone wants to get a leg up on entry into the 10,000 Club.


:::::::No, I don't think redirect pages need markers. I don't consider these "content" in the strictest sense, in either the Lexicon or the LifeWiki --- they're just tools that help people ''find'' content.
The Life 1.0x patterns are still on the server, but [http://conwaylife.com/patterns/lif_pattern_backup.zip hidden in a ZIP file].  It seems to me that going forward, the way to make patterns available in non-standard non-RLE formats will be to publish conversion scripts that work on the contents of all.zip.


:::::::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 08:31, 28 July 2018 (UTC)
Anyway, there are some places in the infobox template documentation and other docs that mention Life 1.0x, which I can track down and fix eventually if no one else gets to it first.


== Object frequency classes ==
3. Let's get rid of that dependency where you have to have '''rle = true''' or '''nofile = true''' before LifeViewer will show up -- as per [http://www.conwaylife.com/forums/viewtopic.php?f=4&t=2298&p=68135#p68135 Nathaniel's recent advice]. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:51, 25 January 2019 (UTC)


I do apologize for my somewhat extended absence. That said, I had an idea (long ago actually) about adding information on the commonness of objects to pattern infoboxes, using data from Catagolue (specifically, B3/S23/C1).  
: Okay, Nathaniel has done a bulk upload of 387 RLE files, collected by the auto-upload script for every article in the main namespace that referenced a pname and had RLE:{pname} and/or RLE:{pname}_synth articles in the RLE: namespace. That means that as of today, there should no longer be any broken RLE pattern download links (the ones that show up when you say '''rle = true''' in the infobox).


I don't think saying "this still life is the 1,691th most common object on Catagolue" is useful, of course. What I'm proposing instead is the frequency class, defined as follows: a pattern is in frequency class X if the most commonly-occurring object (the [[block]], in this case) is 2<sup>X</sup> times more common. X need not be an integer; to strike a balance I'd suggest using one decimal digit.
: There shouldn't be a lot of broken '''synthesisRLE = true''' links, either, but those might happen if somebody set that flag to true but then didn't create the RLE:{pname}_synth article.


Let me give an example. The [[twin hat]] has appeared 240,372,408 times on Catagolue (as of this morning), whereas the block has appeared 71,146,901,659,666 times. So the block is approximately 295,986 &asymp; 2<sup>18.17517</sup> times more common, and the twin hat's frequency class is 18.2, rounded to one decimal digit.
: I'd suggest that people shouldn't go too wild uploading new glider syntheses, until the next version of Mark Niemiec's database comes out -- and maybe not even then. It would be nice to come up with direct dynamic links to synthesis patterns on Catagolue and/or in Mark's database, so that we don't always have slightly antiquated information copied from those places and uploaded to the LifeWiki pattern collection, where they're kind of hard to keep up to date.


I think this is a fairly intuitive way of capturing commonness. An additional nice property is that if an object has occurred sufficiently often, its frequency class is unlikely to change much, if at all; this is true even for objects whose commonness is very similar and who might switch ranks regularly, with one or the other having occurred more often at any given moment. So once this information's added, we wouldn't need to edit it much, if at all ever.
: I guess the next item to tackle is automatic generation of the '''plaintext = true''' .cells files for every article about a pattern that's 64x64 or smaller (let's arbitrarily say). Does anyone have suggestions for other checks and auto-updates that the uploader script might be able to accomplish? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:25, 27 January 2019 (UTC)


Like I said, only sufficiently common objects should have this information added; there's too much uncertainty about the frequency class of an object that has only appeared once, say. I unfortunately lack the statistical background to suggest a good cut-off value ("objects should only have this information in their infoboxes if they have occurred at least ''n'' times"), but unless there are objections I'll add this, or at least do the necessary template work.
:: @Ian07:  Wow, that was a lot of fast Life 1.0x cleanup work. Thank you! I'll see if I can get a bulk upload done for .cells format soon, for all sufficiently small patterns (which is most of them). Then the LifeWiki will suddenly be following a standard policy on pattern formats, fairly universally across all articles. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 20:49, 28 January 2019 (UTC)


...heck, I'll just go ahead and do it, it's been a while since I've edited anything here. If anyone thinks that this is a load of bull, please just speak up and say so. :) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 17:56, 1 September 2018 (UTC)
: I've just added THUMBSIZE 2 as a [[Template:LifeViewer config/default|default option for the viewers]] to save myself some trouble. As for item #3 in your list, the solution probably in [[Template:InfoboxStart]] though I'd rather leave that to someone more experienced with templates. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 22:12, 13 February 2019 (UTC)


(P.S. --- although the block is the most common in B3/S23/C1, it isn't necessarily for other B3/S23 censuses; in some symmetries, the [[blinker]] is more common.)
:: Things are starting to look pretty good for plaintext support on LifeWiki. The latest auto-upload report is [[User:Dvgrn/Plaintext_files|here]].  There are still a few weird exceptions getting reported, but for the most part I can happily ignore them now.


:Replying to myself, I've started doing this; there is a new template parameter, <tt>fc=</tt>, currently only for [[Template:Stilllife]], [[Template:Oscillator]], [[Template:Spaceship]] and [[Template:Puffer]] (no other types of object have appeared on Catagolue anyway). I've also added a short glossary entry at [[Frequency class]], and added frequency calss data to a couple of object infoboxes, including all with FC &le; 10.0. The script used to generate the necessary data from Catagolue's [https://catagolue.appspot.com/textcensus/b3s23/C1/ textcensus] is this:
:: I'm vaguely considering making some custom plaintext files for special-case patterns like the bumpers and bouncers, where there are extra gliders added for animation purposes that happen to increase the bounding box beyond the 64x100 limit. It seems reasonable to upload plaintext versions without the extra gliders for those cases.


<pre>
:: That will give me an excuse to go through the report and make sure there aren't any other odd cases where patterns are mysteriously getting missed, even though they should be small enough for a plaintext version.  I think that's not a problem any more, but I haven't triple-checked. If anyone sees leftover stuff that the auto-upload script still isn't handling correctly, please let me know. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 23:17, 2 April 2019 (UTC)
#!/usr/bin/perl


# usage eg.:
::: I skimmed through the list, and the only problem I found was that [http://www.conwaylife.com/patterns/switchenginechannel.cells switchenginechannel.cells] didn't seem to get generated despite being smaller than the 64x100 limit, even though it has shown up in all of the "Cells files created" sections in [[User:Dvgrn/Plaintext files]]. Other than that, there doesn't seem to be any errors on the computer's part. I saw a few small patterns in the "No plaintext param in infobox" section, but that appears to be due to my own error, so I'll double-check that whenever I get the chance. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:33, 2 April 2019 (UTC)
# perl ../frequencyclasses.pl b3s23.C1.txt >frequencyclasses.txt


use Modern::Perl '2016';
:::: Huh, that's an odd one. There were a couple of nonstandard things about the uploaded RLE, so I replaced it with a more standard version.  Will re-run the script at some point and see if I get a .cells file out, and one way or another that should help me track down the bug -- can't see why the code has been skipping that pattern, but the script is getting embarrassingly messy so there could be all kinds of subtle errors hiding in there. Thanks for the review! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 02:33, 3 April 2019 (UTC)


# only patterns with more than $cutoff occurrences should be considered.
== Replacing images with animated viewers ==
# mark all other patterns with an asterisk.
our $cutoff = 10;


# throw away header line
I just started on a project to add more animated viewers in place of static images on the wiki. However, I've already started running into some problems, particularly with the [[pushalong]]s in the [[114P6H1V0]] article. I already created an [[RLE:114p6h1v0pushalong]], but I'm not sure how exactly the comments in the '''RLE:pname''' page get translated to the actual files, especially since files like [http://www.conwaylife.com/patterns/block.rle <tt>block.rle</tt>] have comments that aren't in the RLE namespace. I'm worried that I'll unintentionally remove said information from the wiki's pattern collection if I'm not careful.
<>;


my %objects = ();
I'm thinking it might be better for now to just focus on the infobox images and not worry about the rest of the article, especially considering the images in the article have colors and arrows and other things which might be lost with an animated viewer. I'd be perfectly fine with [[RLE:114p6h1v0pushalong]] being deleted for the time being so it doesn't replace [http://www.conwaylife.com/patterns/114p6h1v0pushalong.rle <tt>114p6h1v0pushalong.rle</tt>] in the next bulk upload.
my $mostcommon = -1;
my $mostcommoncode = "";
while(<>) {
    chomp;
    next unless m/^"([^"]*)","(\d+)"$/;


    my ($apgcode, $count) = ($1, $2);
Even then, though, as with the [[Block]] example above, there's still comments in the original files that may or may not be overwritten since I don't know how bulk uploads work. I'd basically just like to know what precautions to take to make sure I don't break anything with this project before I proceed. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 16:06, 2 February 2019 (UTC)
    $objects{$apgcode} = $count;


    if($count > $mostcommon) {
: All good questions.  The main answer is that the auto-upload script is designed so that it never overwrites any files that are already on the LifeWiki server, so you don't have to worry about overwriting anything.  Comments in block.rle are safe, and the addition of [[RLE:114p6h1v0pushalong]] won't damage the existing uploaded file on the server.
        $mostcommon = $count;
        $mostcommoncode = $apgcode;
    }
}


my %frequencies = ();
: Now, if we deleted 114p6h1v0pushalong.rle from the server, and added these two comment lines at the top of [[RLE:114p6h1v0pushalong]] --
foreach my $apgcode (keys %objects) {
    my $frequencyclass = sprintf("%.1f", (log($mostcommon / $objects{$apgcode})) / log(2));
    $frequencies{$frequencyclass}->{$apgcode} = $objects{$apgcode};
}


foreach my $frequency (sort { $a <=> $b } keys %frequencies) {
<pre>#O Hartmut Holzwart
    foreach my $apgcode (sort { $frequencies{$frequency}->{$a} <=> $frequencies{$frequency}->{$b} } keys %{ $frequencies{$frequency} }) {
#C A pushalong for the c/6 orthogonal period 6 spaceship 114P6H1V0.</pre>
        print "*" if($frequencies{$frequency}->{$apgcode} <= $cutoff);
        say "$frequency\t $apgcode\t $frequencies{$frequency}->{$apgcode}";
    }
}
</pre>


:(I'm sure there's better ways of doing this, but this worked for me.) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 18:52, 1 September 2018 (UTC)
: - then the auto-upload script would regenerate a fairly close copy of the file that we deleted.  The #N line would be a little different since the default is now {pname}.rle, and the script produces two URL lines instead of just one: a link to the article followed by a direct link to the (future location of the) file itself on the LifeWiki server.


::Another reply to myself --- [[User:Goldtiger997|Goldtiger997]] [http://conwaylife.com/w/index.php?title=Tumbler&curid=703&diff=46374&oldid=41650 suggested] a cut-off value of 10 (non-inclusive). This strikes me as sensible. So unless there's objections, how about we run with this, and only add frequency class information to objects having appeared more than 10 times?
: So far I've always looked through the RLE files produced by the script, and hand-edited anything that didn't come out quite right -- order of comment lines, etc. That's probably a tradition that I'll continue, so that's another line of defense against accidental damage. With any luck the next run won't be quite so much work, as long as no one goes back to uploading new headerless RLE or other nonstandard stuff that the script doesn't know how to clean up.


::Also --- right now the information is [[Catagolue]]-specific, which is sensible but still somewhat arbitrary; if we want to include more information later (e.g. from Achim's, Andrzej's and Nathaniel's censuses, or from whatever future censuses people may come up with), we can easily adjust the infoboxes to include a new "Commonness" section, and re-interpret <tt>fc=</tt> as "'''f'''requency in '''[c]'''atagolue". [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:08, 2 September 2018 (UTC)
: See also [[User_talk:AwesoMan3000#Standardization_of_comment_lines]] for a summary of what should, or could, still be included in comment lines, versus what is auto-generated. Maybe after that summary gets a good trial run, I can migrate it into the actual documentation.  It will be strange and wonderful for a new LifeWiki editor to actually have a reasonable way to learn how to add new articles with associated LifeViewer-displayed patterns... the docs have been partly stuck in 2009 ever since, well, 2009 I suppose! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:07, 3 February 2019 (UTC)


:::Sounds good. However, I already broke my "suggestion" of the 10 occurence cut-off twice; for the [[Coe ship]] and [[Achim's p8]]. Is it worth removing the <tt>fc</tt> parameter for those two articles, or should they just be left as they are? [[User:Goldtiger997|Goldtiger997]] ([[User talk:Goldtiger997|talk]]) 09:26, 2 September 2018 (UTC)
:: One more detail that isn't clear from the above:


::::I think we can grandfather those in --- would be good if you could keep an eye on them in case the information changes, of course, but it's just two articles, so that should be fine. I've also added the cutoff of &gt;10 to the script above; patterns not reaching that cutoff are marked with an asterisk. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:35, 2 September 2018 (UTC)
:: The auto-upload script will automatically generate a slightly nonstandard #O line including both the discoverer and the discoveryear from the infobox -- like


==Infobox vs. EmbedViewer==
<pre>#O Paul Tooke, 2008</pre>
All this interminable Life Lexicon import work has been leading me to believe that there are two classes of articles that can use LifeViewer animations.  There are the named patterns, where if you say "Pattern X" there's really only one likely Pattern X that you could be referring to.  These get put into an infobox category, with appropriate statistics collected and so forth.  The most recent example of this kind of imported Lexicon article is [[line crosser]].


The other class of article is for a term that might refer to a variety of different patterns, so that there are various examples but no specific example should really be considered to be the one canonical one. In these cases I've been using an embedded viewer but haven't been bothering with an infobox.  The most recent examples along these lines are [[line-cutting reaction]] and [[line-mending reaction]].  I like the way these are turning out, but am curious to hear if anyone thinks that these should also be infoboxed somehow, or if anything else should be added as standard practice. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 09:45, 12 September 2018 (UTC)
:: for the 114p6h1v0 article.  But that only works for patterns that have infoboxes.  Other patterns may also have pnames, but only show up in embedded viewers in some other article. In those cases the script can't be sure that the discoverer or discoveryear will be correct, so it will just leave that optional line out.


:I think this is eminently sensible. Off the top of my head, aren't there a few articles that have infoboxes despite being about a family of patterns rather than a specific individual one? (Or patterns with variants, anyway --- the bee shuttles come to mind there.) I've never been quite sure how to handle those, though that's not limited to LifeViewer and embedded patterns: the same goes for other infobox'ed information, such as bounding box, population etc. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:54, 13 September 2018 (UTC)
:: Theoretically we could invent some standard way to include attributes in an embedded viewer template to convey that information. But since those attributes aren't actually used by LifeViewer it seems just as easy to make a habit of adding a comment line to the RLE.


::Yup, those are the ones where I find the infoboxes to be not-helpful.  Would suggest in those cases maybe just using an embedded viewer to show one of the family, or maybe a small stamp collection would be better.  The most recent example I dealt with was [[HFx58B]] from the Life Lexicon.  Rather than pick a variant, and/or leave out perfectly good information that the Lexicon had, I just threw caution to the winds and put both patterns in the same infobox, but picked the older variant to do the infobox stats about.  Probably this will puzzle somebody sometime, but sometimes Life can be confusing... [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 11:20, 13 September 2018 (UTC)
:: For example, adding "#O Hartmut Holzwart, May 2009" to [[RLE:114p6h1v0pushalong]] would convey slightly more information (month as well as year) than the auto-upload script manages to collect for main-article patterns. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:19, 3 February 2019 (UTC)


== Semi-automated collection of raw RLE ==
::: Just looked over the first batch of patterns added to the RLE namespace for the convert-static-images-to-LifeViewer project. Everything looks pretty workable. I think I'll adjust the auto-upload script to skip the generation of an #O line if there's one in the RLE already. Usually what's in the RLE will be a more specific date than what the script can produce from the discoveryear parameter.


I now have a completed Python script -- working on my system, at least! -- that goes through all articles in the main namespace looking for pname definitions in infoboxes and embedded viewers.  If it finds any defined pnames, it checks '''www.conwaylife.com/patterns/{pname}.rle'''; if a Not Found error comes back, it creates an appropriate file using RLE from '''conwaylife.com/w/index.php?title=RLE:{pname}&action=edit''', in a reasonably standard format including pname, discoverer and discovery year if available, and links to the relevant article and the RLE file itself.
::: Maybe I should change the script to find the "name" parameter if there is one, and use that instead of '''{pname}.rle''' in the #N line?  It's kind of weird having ".rle" as part of the defined name.  The problem is, there isn't a '''name=''' line in embedded viewers, but there is a '''pname=''' line, and I wanted some information in that first line that could be collected consistently. (?)


On the last pass the script found 190 missing RLE files in the main namespace.  These have now been uploaded to the server and added to all.zip.  You can sort the contents of all.zip by date to see the new additions.  Since this was a mostly automated process, the script may have picked up a few patterns that shouldn't really be part of the collection.  If anyone wants to do a quick independent review, I'd appreciate it!
::: The only other thing I noticed offhand is that a few RLE files ended up getting comment lines with links: for example, [[RLE:151p3h1v0]] has


I think this will make the process of getting RLE uploaded to the server a lot easier for non-admins.  If raw RLE is created in the RLE: namespace, and is used in a pattern infobox or an embedded viewer, then it will make it to the all.zip collection eventually. To give time for new raw-RLE additions to be peer-reviewed, I would think this script would only be run quarterly or so, with the resulting new RLE files sent as a ZIP file to Nathaniel to do a bulk upload to the server. There shouldn't be any problem with good files getting overwritten with bad ones, since the script only generates an RLE file if no existing file is found.
<pre>#C http://www.conwaylife.com/wiki/index.php?title=233P3H1V0</pre>


It occurs to me that another semi-automated survey might be looking for articles with nofile=true, that do in fact now have raw RLE and/or uploaded RLE files.  I'll try adjusting the script to include any such files it finds in its final report.  It's a little trickier to automatically update all such "nofile = true" to say "rle = true" instead -- it's doable, but it needs a different kind of automation.
::: There's a shorter form that works just as well:


Thoughts, suggestions, worries, bug reports?  I'll add a link here to the RLE-scraper Python script when I've made it available on GitHub.  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:21, 23 October 2018 (UTC)
<pre>http://www.conwaylife.com/wiki/233P3H1V0</pre>
: [https://github.com/dvgrn/b3s23life/tree/master/lifewiki-rlescraper Link!] [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 00:58, 26 October 2018 (UTC)
:: The next item on the RLE-scraper script TODO list will be to check for raw-RLE {pname}_synth files, and upload them if they aren't already there.  Longer term, the script can make a report of any differences it finds between files already on the server and the current contents of the RLE: namespace.  Probably best not to upload changed files automatically -- it seems worth having a human review any changes, and take the time to revert any changes that aren't approved for upload to the pattern collection. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 10:46, 25 October 2018 (UTC)


== Oscillator mods ==
::: But really I don't think there's any need to add article or pattern links to the RLE namespace.  They'll get generated and added automatically by the auto-upload script.  If you're actually looking at an RLE file in the RLE namespace, and wondering which article it goes with, then it's pretty quick to click the "What links here" link in the sidebar to find that out, instead of copying and pasting part of a comment line.


I noticed that all the recently created oscillator pages from the latest Lexicon update (example: [[p29 pentadecathlon hassler]]) have their mods listed along with their periods even if they're equal. Is it agreed upon that this should be the case? Because if so I can go through the [[:Category:Oscillators with unknown mod|unknown mod]] list later and add in all the mods if no one objects to it. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 14:53, 28 October 2018 (UTC)
::: Based on experience so far, does there seem to be anything else that really ought to be adjusted for this whole conversion / auto-upload process? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:54, 3 February 2019 (UTC)


: I can't claim to have made a really deliberate decision to include the mod when it's the same as the period -- I was just blindly filling in values in the oscillator template I was using. I don't have any objection to listing both period and mod, but let's see if anyone else has a different opinion. Many thanks for all the cleanup work you've been doing recently, by the way! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:04, 1 November 2018 (UTC)
::: Oh, one more minor thing:  looking at LifeWiki articles with lots of LifeViewers on them, I'm starting to think that there might be such a thing as too much animation sometimes. If the infobox has an animated spaceship or oscillator in it, it might make sense to leave out AUTOSTART on (some?) embedded viewers in the actual article. It can be nice to have something on the page that ''isn't'' moving -- or to be able to open in LifeViewer and step through a pattern one tick at a time, without having to disable AUTOSTART first. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 23:12, 3 February 2019 (UTC)


:: Just to chime in --- I think listing both the period and the mod is valuable even if they match. Otherwise, if an infobox doesn't have mod information, a user won't know if that's because we haven't filled in the info or because it's the same as the period.  
:::: I haven't had any other problems so far, though of course I've only just started this project and have only gotten through around 1% of all the articles. As for the comment lines in RLEs, I'll try and be more consistent with them from here on out. (will double-check the ones I've already made to see if there's anything that should be added or removed) And yeah, I do agree that too many auto-started viewers looks very cluttered, so here's a rule of thumb I'm probably going to use: there should be no more than three AUTOSTART viewers in close proximity to each other. Thoughts? [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:50, 3 February 2019 (UTC)


:: And I agree, thanks are due to Ian07 for all the clean-ups and other work. MediaWiki has barn (heh) stars; do we have something similar? Maybe we should. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 21:01, 3 November 2018 (UTC)
::::: Fine by me.  I've been thinking two animated viewers at once is usually enough action, but it depends on the article. Just maybe something to keep in mind a little bit. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 01:33, 4 February 2019 (UTC)


== Conduit orientations ==
== Arbitrary adjective names ==


Quick question, y'all: is "T" a standard designation for a "turned" conduit output orientation? I'm asking because of [http://conwaylife.com/w/index.php?title=Template:Conduit&curid=11630&diff=48592&oldid=45674 this edit] to [[Template:Conduit]] --- I lack the expertise whether this is standard terminology or not.
Per [http://www.conwaylife.com/forums/viewtopic.php?p=71523#p71523 this forum post], I've removed every Arbitrary Adjective Name™ I could find on the wiki and moved it to a more easily-recognizable name (article text has also been properly updated to match title). Here's the list of files that need to be deleted as a result:
    absurdlylongboat.rle
    absurdlylongship.rle
    absurdlylongsnake.rle
    boatwithextralongtail.rle
    extralongbarge.rle
    extralongboat.rle
    extralongcanoe.rle
    extralonghookwithtail.rle
    extralongintegral.rle
    extralongshillelagh.rle
    extralongship.rle
    extralongsnake.rle
    extralongsnake_synth.rle
    extralongtubshillelagh.rle
    ludicrouslylongboat.rle
    ludicrouslylongship.rle
    remarkablylongboat.rle
    remarkablylongcanoe.rle
    remarkablylonghookwithtail.rle
    remarkablylongshillelagh.rle
    remarkablylongship.rle
    remarkablylongsnake.rle
    remarkablylongsnake_synth.rle
    ridiculouslylongboat.rle
    ridiculouslylongship.rle
    stupidlylongboat.rle
    stupidlylongship.rle
    terriblylongboat.rle
    terriblylongship.rle
    terriblylongsnake.rle


If it is, it should be documented in the template. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 21:27, 3 November 2018 (UTC)
[[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 17:12, 23 February 2019 (UTC)
 
: I think the above are all cleaned up correctly now, as far as uploaded patterns getting deleted.  There was also a file out there called "extraextralongsnake_synth.rle" which turned out to have the Niemiec synthesis file for long^4 snake rather than long^5 snake. (Yup, getting rid of the extra and very and Arbitrary adjectives in favor of a simple long count still seems like a good simplification.)
 
: The _synth files are still troublesome in general, because the files that are already out there often have generic links to the Niemiec database search page, rather than to the actual file.  And of course on that database search page, the way you'd find a long^5 snake or whatever is actually by looking up "extra extra long snake"... so there's some possibility that the cleanup of "extra" creates some new confusion while reducing some other old confusion.
 
: Anyway, I'd still recommend not starting any kind of comprehensive review of _synth files until the new version of Niemiec's database becomes available.
 
: The second half of this cleanup will require re-running the auto-upload script, to get the .rle and .cells versions of all these files back onto the server with their new longN* names. I'm planning to wait until at least the end of this week before tackling that job. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:27, 25 February 2019 (UTC)
 
:: Upload of new RLE and plaintext files should be done now.  Some of these names are still preserved as redirects, like [[Stupidly long boat]] and also as an alternate name given in the text of the article. I may eventually be inspired to track down all these leftovers and clean them up, but for now I'm kind of worn out from wrestling with the auto-upload script.  There's always another degenerate case that hasn't been handled yet... [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:45, 27 March 2019 (UTC)
 
==Non-notable isotropic rules==
Many pages on isotropic non-totalistic rules have been proposed for deletion. It seems that some users (myself included) have moved articles on such rules to their namespace, such as [http://www.conwaylife.com/wiki/User:AwesoMan3000/Goat_Flock here]. This seems to be an ongoing project and deserves discussion here.
 
Should I adopt salad or would someone else like it? I have a couple collections of ships that I’d like to move to the page should it be adopted. [[User:Moosey|Moosey]] ([[User talk:Moosey|talk]]) 17:15, 28 March 2019 (UTC)
 
: I reverted the speedy deletion tag on [[Goat Flock]] because there's a wiki link from the [https://catagolue.appspot.com/census/b2in3s123a Catagolue rule page] which originates from the [https://gitlab.com/apgoucher/catagolue/blob/master/initialise/all-rules.txt#L120 rule list].
 
: If there's still a consensus that the main namespace redirect should be deleted, then the rule list would need to be updated with 'Goat_Flock' replaced with 'User:AwesoMan3000/Goat_Flock' after the exclamation mark on line 120. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 09:53, 29 March 2019 (UTC)
 
:: I like the idea of having some space on the LifeWiki for people to document their favorite isotropic rule discoveries.  It makes sense to me that all of these could go somewhere other than the main namespace, just to keep things that are spaceships in other rules from getting mixed up with Conway's Life spaceships, and so on.  The User namespace seems like a fine place for isotropic rule pages, along the lines of Moosey's suggestion.
 
:: But sometimes it's hard to know who should "claim" a rule -- it doesn't necessarily make sense for any particular user to start a page, and yet it's clear that a page should be started.  Is there any harm in inventing a new namespace for this purpose?  Would anything be wrong with [[Isotropic:Goat Flock]], for example? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 13:59, 29 March 2019 (UTC)
 
::: @dvgrn: good idea. It would prevent too much clutter in the main namespace without making anyone frustrated about the fact that <nowiki>[insert frustration here]</nowiki> happened.
 
::: who can make new namespaces? [[User:Moosey|Moosey]] ([[User talk:Moosey|talk]]) 14:41, 29 March 2019 (UTC)
 
::: I agree with the namespace idea. Perhaps we could name it something like "OCA" so we could move existing articles such as [[HighLife]] there. As for specific patterns, I'd suggest making them subpages of their native rules, e.g. [[OCA:HighLife/Bomber]] so they don't get mistaken as rules. Of course, the notability guidelines should still apply here, or else this will become way too hard to maintain. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 14:33, 30 March 2019 (UTC)
 
:::: I agree with all of Ian07's suggestions above: using OCA for the namespace, with rule pages (except for CGoL) in that namespace, and rule-specific patterns as subpages of their rules. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 17:12, 30 March 2019 (UTC)
 
::::: @Moosey (and everyone else) -- based on a [https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces very small amount of Googling], officially adding a new namespace to the LifeWiki namespace dropdown list is a Nathaniel-only change on the server side. I tried moving the "LifeHistory" article to [[OCA:LifeHistory]] as an experiment; the move was technically successful, but I think the article is just called "OCA:LifeHistory" and it's still in the main namespace.
 
::::: I've sent a request to Nathaniel. I or somebody will post an update here if and when "OCA" becomes an official namespace. Until then there's probably no point in trying to move any more OCA pages. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 19:34, 30 March 2019 (UTC)
 
:::::: There's now an OCA namespace!  However, I've sent a follow-up question to Nathaniel, because I'm not sure what the best way would be to clean up an embarrassing problem I created.  Currently if you follow the [[LifeHistory]] link, you'll see a page called "OCA:LifeHistory", but that's still the actual name of that article, it's not in the OCA namespace. As a weird side effect, it doesn't seem to be possible to either edit or move that "OCA:LifeHistory" page, so it doesn't seem like I can fix the problem.
 
:::::: I can solve most of the problem by changing the LifeHistory redirect and creating an actual LifeHistory page in the OCA namespace. That might leave an orphaned "OCA:LifeHistory" page out there somewhere, but it doesn't seem as if there's any way to get to that article except via the current redirect. Does anyone see an easy way to move that article to where it belongs? I'm a little worried that if I don't clean it up correctly, it will be an unexpected headache sometime somehow. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:37, 4 April 2019 (UTC)
 
::::::: Stand by until further notice -- please don't try making any OCA-namespace pages just yet... hoping to get my OCA:LifeHistory mess fixed first. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:43, 4 April 2019 (UTC)
 
:::::::: Okay, it looks like Nathaniel has successfully cleaned up [[OCA:LifeHistory]], so now it's actually in the new OCA namespace. Let's try moving [[Goat Flock]] and other similar pages out of the User namespace and into OCA -- there shouldn't be any need for people to "adopt" these pages individually any more. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 01:55, 5 April 2019 (UTC)
 
(Resetting indent) All of the rule pages have now been moved to the OCA namespace, and the resulting double redirects fixed, but I have a few questions about how to continue from here:
 
# Should rule families also be moved (e.g. [[OCA:Generations]]) or should the namespace ''just'' be for individual rules/patterns?
# Should we use the same pattern categories as for Conway's Game of Life, or will that cause confusion?
# Is it possible to make [[Special:SpecialPages]] include OCA pages? This is not as important but it would be nice as a maintenance tool for these articles.
 
[[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 20:43, 5 April 2019 (UTC)
 
: For #3, I don't think there's a (reasonably easy) way to add something like that to [[Special:SpecialPages]], but a list of all pages in the OCA namespace can already be viewed [http://www.conwaylife.com/w/index.php?title=Special%3AAllPages&from=&to=&namespace=102 here]. [[User:Nathaniel|Nathaniel]] ([[User talk:Nathaniel|talk]]) 21:39, 5 April 2019 (UTC)
 
== Caterloopillar "Family Page" vs. Specific Pattern ==
 
Does anyone have any clever suggestions about how to deal with the problem that
 
1) there is a family of spaceships called Caterloopillar, with different speeds, and different bounding boxes and cell counts for each speed, and
 
2) there is a specific Caterloopillar with speed c/8 (for example) and a specific bounding box and cell count
 
?
 
It would be nice to be able to link to a specific pattern or two, in a separate section inside the generic "Caterloopillar" article. But it doesn't really make sense to have bounding box, cell count, etc. parameters in the infobox for the generic article.
 
What's the best way to make this kind of thing clearer?  Could we invent some kind of special "pattern family" infobox template where no parameters are required, and parameters are only displayed if they're defined? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:08, 5 April 2019 (UTC)
 
We have already several families of patterns. Geminoids are also family and deserve general family page. As well as very soon the 0E0P metacell will start to generate some more interesting news with special cases and other things (especially if we use turing machine to calculate the next iteration). I'm not sure exactly how to classify family. Does the helix based technology which sends *WSS upwards is considered a family of spaceships (as it contains the caterloopillar family). But I think the number of natural families of patterns is small, and it's important to think about pattern families as well. So maybe we need to start from a page where we define what does it means pattern family. I would define it as collection of designed patterns with noticeable feature which constitutes major role in the interest this pattern is arising (geminoids for example, or strange loopers, or helix based spaceships, or natural fuse based etc.).
 
I think also we in total freedom here in the sense how do we analyze the patterns and the scope of the wiki articles. I think the families ignorance might be our weak spot in how we think about CGOL in general, and new families might be found which are less intuitive to think about now, and those families might bring new discoveries and design patterns just due to someone figuring out a new family.
 
But to state it simply - it would be also nice to simply separate the two articles of caterloopillars that's all. In the banner we can simply place "-" for everything. The bounding box is the only problem as it creates -x- instead of nothing. We can insert adjustable for speed or "Less than c/4".
 
[[User:Simsim314|Simsim314]]
 
== Glider syntheses from Shinjuku with help from Catagolue ==
 
-- Okay, we can get started on the next stage of improvements for glider synthesis reporting now!  This came in from calcyman last night (links slightly edited):
 
<i><blockquote>Catagolue can now be queried for syntheses from Shinjuku. Here's the [https://catagolue.appspot.com/textsamples/xp8_gg0gba9jz11078987066zx3213/b3s23/synthesis text link] that's probably most appropriate for LifeWiki.
 
Subsequent path parts are ignored, so you can do things such as: https://catagolue.appspot.com/textsamples/xp14_j9d0d9j/b3s23/synthesis/tumbler_synth.rle
 
The syntheses are also [https://catagolue.appspot.com/object/xq5_ug1hmgc865da808ad568cgmh1guz124w6yb6w421/b3s23 embedded in a LifeViewer] on the object pages.
 
Finally, you can query the [https://catagolue.appspot.com/textcensus/b3s23/synthesis-costs best known costs (in gliders)] of all objects known to Catagolue. That's good for finding (for example) disparities between LifeWiki and Shinjuku to see whether either of them needs updating.
 
In particular, the [https://gitlab.com/apgoucher/catagolue/blob/master/initialise/diffupdate.py update script] uses this so as to only bother uploading (and indeed creating) RLEs of the objects that need to be updated.</blockquote></i>
My idea is that this should be an additional link in the "glider synthesis" section of relevant infoboxes.  If '''synthesisRLE=true''', then we can serve up both these Catagolue links and the uploaded synthesis file (which may be different from the Shinjuku/Catagolue version:  uploaded files may contain multiple syntheses with different construction envelopes, or continuous instead of incremental syntheses, sometimes two in a row for spaceships to show the repeat time, etc.)
 
When the new version of Mark Niemiec's database becomes available, maybe we can use a similar system to link directly to '''conwaylife.com/ref/mniemiec/*''', instead of uploading copies of all those patterns which will then inevitably go out of date.
 
However, it's not really ideal to use '''synthesisRLE=true''' to decide whether to show these links.  For example, we can now produce syntheses for all the 12-bit still lifes that AwesoMan3000 made articles for last year, like [https://catagolue.appspot.com/textsamples/xs12_354qic/b3s23/synthesis teardrop with claw] and so on.  Most of these don't have _synth files in the raw RLE namespace or uploaded to the server -- and now we don't need to do that. But if we had to add '''synthesisRLE=true''' to the infobox to get these new Catagolue links, then a link to the LifeWiki pattern collection would also be created.
 
If we really want all these syntheses to be part of the LifeWiki pattern collection, then we could certainly bulk-upload them all, and do a new bulk upload every year or so to catch anything that's gotten out of date. However, the total number of files on the server is already getting very unwieldy, at least with the current maintenance system, and this would only increase the pain.  Maybe it would make sense to ''remove'' all the _synth files from the pattern collection instead, and offer a separate downloadable ZIP file for glider syntheses?
 
Maybe we should just ''always'' display a Catagolue synthesis link, and then maybe have Catagolue display something slightly more edifying than [https://catagolue.appspot.com/textsamples/xs38_08e1v0v1u8zc970vg321/b3s23/synthesis "null"] if no synthesis is known. Any other ideas or suggestions?  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:24, 13 April 2019 (UTC)
 
: I think the determining factor (once the remaining small objects are in Shinjuku) is to use Catagolue if there's an apgcode provided, and to fall back on _synth.rle otherwise. The reason is because LifeWiki has Orthogonoid_synth.rle and Demonoid_synth.rle, for instance, and arguably HBK_synth.rle could also be included in LifeWiki but not in Shijuku. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 16:10, 13 April 2019 (UTC)
 
:: That sounds reasonable-ish.  Mind you, people have been adding apgcodes for a lot of things (from [[lobster]]s to [[Sir Robin]]), so unless we invent a new parameter like ''minsynthesis=true'', we'll occasionally end up making links to Catagolue when no synthesis is actually available. If the link can be created/not created based on the existence of an apgcode without adding any more custom parameters, I think I might rather do it that way and just live with the occasional link to nowhere, instead of taking the ''minsynthesis=true'' route.
 
:: It doesn't seem like there's any harm providing a Catagolue link ''and'' a _synth file link (and a Niemiec-database link, eventually).  It's often very useful to have non-record-breaking syntheses of objects, and we won't get those from Shinjuku.  When you want to construct a new object near some existing object, for example, you might need an expensive synthesis with gliders from just two directions.  Or you might want a synthesis of a two-cell edge that creates both cells simultaneously, to make a pseudo still life with an existing object with a two-cell edge.  Existing _synth uploads often have these kinds of options included along with the record-holder. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:45, 13 April 2019 (UTC)
 
::: Okay, with Ian07's incredibly helpful help, I've made a first attempt at switching over glider synthesis links to the new Shinjuku/Catagolue source.  Whenever an apgcode is supplied for an object '''and''' the 'synthesis={n}' parameter is set, a Catagolue-generated synthesis link should be provided in the Glider Synthesis section of the infobox.
 
::: I also disabled the old links to chris_c's automatically generated syntheses, since those aren't reliably up to date any more.  And I tried changing the top-level category from >=1000 glider to >100 gliders.  (Looks like I still have to work on that detail a bit more.) [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:59, 23 April 2019 (UTC)
 
:::: Here's a [http://conwaylife.com/forums/viewtopic.php?p=75407#p75407 current report] on discrepancies between LifeWiki and Shinjuku/Catagolue (I'm assuming the last two are reasonably well synchronized at the moment, since the synthesis-costs summary changed since yesterday; I used this morning's cost summary). I've gone through and cleaned up all the LifeWiki articles where a cost was reported that was larger than what's in Catagolue.
 
:::: This leaves a pile of 170 articles where LifeWiki doesn't know about any synthesis at all... but it looks like that list is being tackled already. Thanks, Ian07! (Anyone else interested, see the above link for how to get the Catagolue synthesis link to pop up in the infobox.)
 
:::: This is all a huge improvement over the old method of creating separate RLE:{pname}_synth articles or {pname}_synth.rle files and uploading them to the server. Anyone see any problems so far?
 
:::: The big remaining improvement would be not having to add "synthesis  = {cost}" to every article manually, and manually update the numbers whenever they go out of date.  This is pretty easy maintenance compared to the admin-only file upload stuff, but still it would be nice if each article magically reported the number and provided a link to Catagolue only if the synthesis actually exists on Catagolue.  At the moment, articles like [[Snake pit 2]] that have an apgcode but no known synthesis are cheerfully serving up a link to Catagolue that says [https://catagolue.appspot.com/textsamples/xp3_g8o0eh5mggz122q92t0643zy011/b3s23/synthesis/snakepit2_synth.rle "null"].
 
:::: So ... is there a clever template-y way to improve on this?  We could import the subset of apgcodes from Catagolue's synthesis-cost list that we have articles for on the LifeWiki, and set that list up as a lookup table, for starters.  Then maybe the update problem would be reduced to just updating that subset synthesis-cost list now and then. (?) [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:48, 24 April 2019 (UTC)
 
::::: Quick reply, since Dave asked me to chime in, and I'll admit I've only skimmed over the preceding discussion --- with glider syntheses being handled by Catagolue / Shinjuku now, it would obviously be ideal for the LifeWiki to simply pull in glider synthesis information from Catagolue. That is to say:
 
:::::# When a page's parser cache is updated (e.g. when a page is edited), and an apgcode is provided in the infobox template, LW should:
:::::## poll Catagolue;
:::::## perform a sanity check; and
:::::## use that information (perhaps marked in some way to indicate external data) in the infobox, as well as for categories.
:::::# When there is an apgcode, and there is a local synthesis, and Catagolue either doesn't have any synthesis or the one it has is worse than the local one, LW should:
:::::## use the local synthesis; and
:::::## add the page to a tracking category so Shinjuku's DB can be updated. (In the long run, ideally there'd be no such cases --- this'd be a temporary measure, and in fact it might not even be necessary.)
:::::# When there is no apgcode, LW should:
:::::## use a local synthesis if there is one; and
:::::## also add the page to a (different) tracking category, as I believe it already does.
 
::::: The big problem with this is the "poll Catagolue" bit. I'm not aware of a way for MW templates to programmatically make external requests and process the results.
 
::::: It could be done client-side, in Javascript, but I believe we don't want that. There's at least two big advantages to doing it server-side:
 
:::::# consistency: every user sees the same data; and
:::::# sustainability: if Catagolue is only polled when the page cache is updated, i.e. when Mediawiki re-evaluates templates etc., Catagolue will not be hit with a request every time someone views a LifeWiki page.
 
::::: That still leaves several more avenues:
 
:::::# on-wiki Lua scripting (MW supports this with an appropriate extension, though the LifeWiki doesn't);
:::::# using a bespoke Mediawiki extension; and
:::::# keeping things as they are, but using a bot that runs (un|semi)supervised to update template parameters when things change on Catagolue's / Shinjuku's side (the bot in turn could be fed by data pushed out by Catagolue, say an RSS or Atom feed of new/improved syntheses that Catagolue would generate automatically and that the bot would poll periodically).
 
::::: Unfortunately I can't help with any of these. (I couldn't help with templates either, but that's a different story.)
 
::::: I don't know if any of this is useful --- but as I said, Dave asked me to chime in, and who am I to say no to that? [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 15:14, 27 April 2019 (UTC)
 
:::::: Maybe it could be linked in with the Catagolue update process. At the moment, syntheses on Catagolue are added/updated in a very precise manner:
 
::::::# A GitLab CI runner is launched;
::::::# The entire textcensus of current synthesis costs (but not the syntheses themselves) are downloaded from Catagolue;
::::::# Shinjuku is downloaded, and minimum paths to all objects are computed;
::::::# Only the syntheses with lower cost than Catagolue are generated;
::::::# These syntheses are uploaded (as RLEs) in batches of 1000.
 
:::::: Since LifeWiki need only display the synthesis ''cost'' in the infobox, rather than the synthesis (which is available with an external link), then I guess this update process could additionally upload the entire set of synthesis costs to LifeWiki into some page which is queried by the infoboxes.
 
:::::: Of course, this raises the question: how can an external process upload to LifeWiki? That external process can contain secret environment variables (and indeed does, to securely push updates to the live Catagolue). I believe you had an [[User:Apple Bot]] which automated things -- does that run externally? [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 22:52, 27 April 2019 (UTC)

Revision as of 22:52, 27 April 2019

Taka Tiki Break

Welcome, one and all, to the Tiki bar! This page is used to discuss the technical issues, policies, and operations of the LifeWiki. Or just sit down, relax, and enjoy a cocktail.

Welcome to the Tiki bar

Wikipedia has the Village pump, Wiktionary has the Beer parlour, but the LifeWiki's lacked a central page for discussion so far other than User talk:Nathaniel. So I took the liberty to create the Tiki bar to facilitate discussion in a friendly and relaxed atmosphere. Welcome! Apple Bottom (talk) 11:09, 13 June 2016 (UTC)

Archived discussions

Note: active discussions are never archived while still active.

The list(s) of rules investigated on Catagolue

Short version: these have increasingly become a burden to maintain on-wiki, and with Catagolue now having its own endpoint providing an overview over and an exhaustive list of all rules searched, they're largely irrelevant now. (The on-wiki list was only started because Catagolue didn't provide one at the time.)

So I'm giving up maintainership of these. If anyone wants to take over, please do! Apple Bottom (talk) 17:00, 7 January 2019 (UTC)

If we are to retire the List of rules investigated on Catagolue, how should we do this? Add a notice at the top saying:
"This page is no longer actively maintained in favour of the equivalent Catagolue page."
or words to that effect?
It still might be a good idea to actually keep the information in the LifeWiki, because Catagolue occasionally has outages when the daily quota has been exceeded, whereas conwaylife.com tends to be permanently accessible. Calcyman (talk) 18:26, 7 January 2019 (UTC)
The wiki page does have some advantages over the Catagolue one, such as listing the rule integers for outer-totalistic rules and being easier to edit (e.g. adding names for new rules). 77topaz (talk) 23:51, 7 January 2019 (UTC)

Time for a consensus decision on pnames?

I've run the RLE-scraper script to collect new RLE files for a bulk upload. The script found 321 new RLE files. Before I send them to Nathaniel, it looks like I'll be doing some more standardization, especially involving pnames.

The guidelines for creating pnames say very clearly:

pname	(required) The name of the pattern being described, but converted to lowercase and with all non-alphanumeric characters and spaces removed.

This has worked fine for us for the great majority of cases, but there are two related cases where blindly following that rule creates not-very-good pnames:

  1. apgcode-based names, where removing the underscore can sometimes concatenate two strings of digits. For example, according to the rule, Xs15_3lkia4z32 is theoretically supposed to have a pname of "xs153lkia4z32", which reads as if it's a 153-bit still life. Underscores are confusing in article names because MediaWiki turns right around and renders the name without an underscore. But they do seem to work fine, and they're necessary in other article names, anyway -- raw RLE "pname_synth" synthesis files need them.
  2. patterns named after a Niemiec or pentadecathlon.com ID, where removing a period causes similar problems with readability. Examples:
  • 37P7.1, created by Sokwe in 2009 with a pname of "37p7.1" -- including the period. Another similar case is 37P10.1, where Sokwe changed the pname from Nathaniel's original "37p101" to "37p10.1", back in 2010.
  • 38P11.1, with a pname of "38p111". Periods in filenames are definitely annoying because the part after the period can look like a file extension... but I think "38p11.1" would really be better here.
  • Several patterns with pnames created by Entity Valkyrie recently: 14p2.1, 14p2.3, 14p2.4, 28p7.3, 28p7.3bumperbouncer, 28p7.3eatingss, 31.4, 33p3.1, 33p3.1bumper, 33p3.1eatingss, 33p3.1reactions, 34P6.1.

Capitalization Bad

The last pname in that list is also nonstandard due to capitalization, but that's a separate problem. The full list of capitalized pnames is 35P12, 53P13, 55P10, 113P18, BF20H, BFx59Hinjector, FMHEB, Gtolwss.rle, L112functions, L156reactions, L156variants, L200, Lightspeedcrawler, P5HWV, P58toadflipper, PT8P, PT9B, PT38P -- again all by Entity Valkyrie, I think. I'll definitely have to go through and fix all of these, just because they're dangerous to cross-platform uses of the pattern collection: "35P12.rle" will overwrite "35p12.rle" on a Windows operating system, but not on Linux. And LifeViewer fails to find "RLE:35P12" when told given "pname = 35p12", because the LifeWiki's filesystem is case-sensitive. So I think the no-capitalization part of the pname guidelines should continue to be very carefully enforced.

Periods Not So Bad

However, given the long precedent for pnames occasionally including periods, I'm not planning to change any of Entity Valkyrie's pnames if a period is the only non-standard part. Should probably do something about "31.4", but the rest seem okay.

-- Anyone know where the ".4" comes from in "31.4", by the way? The problem with calling the thing just plain "Snark catalyst" is that there are several workable Snark catalysts. 31.4 is one of the two most common ones, but it's not exactly "the" Snark catalyst. But no other common name has caught on. (Bellman Zero, anyone? Catalyst B0? 31.4 seems better than either of those.)

Summary questions

TL;DR: Does anyone object if I adjust the pname guidelines to say that periods are okay, but "only where necessary", or something along those lines? And also say that underscores are okay only in apgcode pnames and raw-RLE _synth articles? Underscores are a minor nightmare, because MediaWiki automatically converts them into spaces, and pnames really aren't supposed to include spaces. I'm reasonably sure that that underscore-to-space conversion is bound to cause coding difficulties somewhere sometime. But unless someone wants to recommend consistently using periods in place of underscores in apgcode pnames, I just don't see any good alternative.

Comments, suggestions, disagreements? Please post 'em here! Dvgrn (talk) 17:56, 15 January 2019 (UTC)

Also, not sure if anyone will find this note here, but gmc_nxtman's recent series of synthesis postings made for a good test case for reworking several pages recently updated by AwesoMan3000. It's been different changes for every article, but it tends to take a lot of fiddly adjustments to synchronize the pname, RLE, synthesis RLE, LifeViewer config, and any files already uploaded to the LifeWiki server.
I've done half a dozen articles for starters: very long snake, trans-block on long hook, integral with tub, eater head siamese eater tail, cis-block on long hook, and aircraft carrier with feather. LifeViewer generally Just Works once there's a raw RLE article with the right pname, but the images come out too small by default, so I've been adding viewerconfig THUMBSIZE 2. This should probably be a default added to the template, with SUPPRESS, except I don't know if that will change the looks of a lot of existing articles).
This leaves boat with long tail, beehive with nine, broken snake, cis-boat with nine, eater bridge eater, long boat tie ship, long shillelagh, ortho-loaf on table, snake siamese snake, snake with feather, snorkel loop, trans-boat on table, very long shillelagh, and sesquihat that still need editing to add the latest syntheses. I could definitely use some help with updating these:
  1. decide whether the pname should change to match the article name
  2. new synthesis copied from Talk:{name} to RLE:{pname}_synth, either updating or replacing any RLE that's currently there
  3. fix "synthesis = {n}" in infobox
  4. add to infobox:
    viewerconfig     = [[ THUMBSIZE 2 ]]
  5. remove Life1.05 and Life1.06 lines (optional)
  6. double-check that article name matches article text and Catagolue link -- there's often something wrong there
  7. add RLE:{pname} if it's not there already, to make LifeViewer show up instead of an old image file
A couple other tasks are admin-only --
  1. If pname has been changed, delete {old pname}*.rle from LifeWiki server to keep things in synch
  2. If Life1.05 and Life1.06 lines have been removed, delete corresponding files from server. (I'm leaving the "plaintext" (.cells) links, because I'm hoping to generate those automatically for all sub-64x64 patterns currently on the LifeWiki.)
  3. When a good break point is reached, re-run the auto-upload script and collect all the new pattern and synthesis RLE text into a ZIP file for bulk upload.
Here again, I'm leaving some broken links to pattern or synth files, which I'm planning to fix fairly soon (by putting the files back in place using the auto-upload script).
This is the kind of project where I'm very unlikely to get everything exactly right. Independent reviews of all this stuff will be greatly appreciated, and just let me know what I've done wrong so far. Dvgrn (talk) 12:33, 21 January 2019 (UTC)

Special pages broken?

I have noticed several oddities in a few of the maintenance pages:

Anyone know what's up with these? Ian07 (talk) 23:35, 15 January 2019 (UTC)

Rulespace info for eaters, reflectors, conduits, etc.

So lately I've been busy adding isorule parameters to the infoboxes for various patterns. So far I've stuck with oscillators, spaceships, still lifes, and infinite growth patterns, but I'd also like to expand this to other pattern such as conduits which are a bit more ambiguous. For example, the sidesnagger works in B/S23, but obviously there are no gliders for it to eat. I'm of the opinion that for these patterns we should show the rules they're actually useful in, since that's what makes them notable in the first place, (though with the possible exception of eater 1 since it's such a small pattern) but I'd like to hear others' thoughts on this. Ian07 (talk) 18:57, 19 January 2019 (UTC)

My main thought is that all but the very simplest and lowest-step-size conduits are very close to rule-specific -- useful only in B3/S23. Adding a B8 or an S8 might be one of the few isotropic bits where some conduits would survive the rule switch (?). Even if a particular conduit works in another rule, it's only interesting if a large enough group of conduits works in the alternate rule to make it computationally universal. (That would probably make it construction-universal, too, but only after someone re-did all the single-channel search work to produce new recipe libraries.)
Anyway, from my point of view the reason why B38/S23 or B3/S238 doesn't get a lot of attention is that there's nothing really new and exciting about those rules to make up for the fact that the rule spec is just that little bit more complicated... pun maybe intended. Dvgrn (talk) 02:04, 20 January 2019 (UTC)

apgsearch and Catagolue

Would anyone be opposed to a reorganization of the information on these two articles? I noticed that a lot of the information in the Catagolue article really applies more to apgsearch rather than the site itself, and therefore might be worth moving. Such a change would be particularly easy to revert if need be, but I'd rather not go through the effort if that's the case, so I'd also like some feedback about that. Ian07 (talk) 23:32, 19 January 2019 (UTC)

No opposition here. I wouldn't think anyone would be likely to revert changes to those articles, just the usual quick review to see if the changes happen to serve as a reminder of anything else that should be added. Dvgrn (talk) 02:04, 20 January 2019 (UTC)

Pattern collections

I just thought to check the LifeWiki pattern collection for outdated links to Mark's database. There were 165 RLE files with dead links in the comments. I fixed two of them, one by creating an RLE:{pname}_synth page and one by editing the pattern comments and deleting and re-uploading the file by hand... and then thought, "Nope. There has to be a better way."

Now I'm just doing a search-and-replace, "http://www.conwaylife.com/ref/mniemiec" instead of "http://home.interserv.com/~mniemiec/", and will ask Nathaniel to re-upload all those files to the server along with the output of the auto-upload script.

Of course, if these _synth files were created when that website was available, a lot of the actual syntheses might be out of date as well. A dynamic endpoint somewhere for reporting the actual latest synthesis for each object would certainly be a step up from the current perpetually out-of-date synthesis files.

-- On the other hand, there are big advantages to Mark's comprehensive collections of practically every historically known way of constructing each object. Sometimes you might want a synthesis with a suboptimal number of gliders but better clearance than usual, or might want an incremental construction starting from one half of the still life, or whatever. Reporting just a single current-best synthesis would lose a lot of that useful information. Dvgrn (talk) 22:25, 24 January 2019 (UTC)

The problem of deciding what to do about glider syntheses is still where it was in January. I'm still leaning toward leaving things pretty much as they are until Mark Niemiec's new synthesis database becomes available, and then figuring out how to link directly to the relevant Niemiec synthesis page, for any object that has a LifeWiki article -- and removing those _synth files from the Patterns folder. Most of the Niemiec-derived _synth files that have been uploaded will probably be subtly out of date when the new version comes out. Anyone have any better ideas?
In other news, User:Dvgrn/Plaintext_files documents the 695 new plaintext-format .cells files that are available on the server now. This means that a lot of articles' infoboxes could now be updated to say |plaintext = true along with |rle = true. If nobody wants to tackle making these several hundred edits manually, I might eventually look into setting up some kind of automated search-and-replace functionality, based on this kind of article list. Dvgrn (talk) 22:45, 17 February 2019 (UTC)
I noticed once again that there are quite a few patterns with capitalization in their names, most of which (with a few exceptions) were created by User:Entity Valkyrie. Even RLE:ModelD is still in that list despite having been deleted and moved over a week ago, so those should probably be fixed. Something more confusing, though, is that certain small patterns (such as 44P14 and 44P12.3) were labeled as being too large despite easily fitting within the 64×100 limit. What's up with that?
As for adding these to the infoboxes, I'll probably get to that eventually but I'm a bit too busy at the moment. Ian07 (talk) 23:14, 17 February 2019 (UTC)
Many thanks for the review. I believe I've patched all the remaining instances of pnames with capital letters: 68p16.cells/.rle, 76p8.cells/.rle, 113p18.cells/.rle, 209p8.cells/.rle, p130shuttle2.cells/.rle, l156reactions.rle, p24lwss.rle, and p52g3to4.rle. Obviously in the future the auto-upload script should check for capital letters and complain.
I haven't yet looked into why a few small patterns didn't get .cells files created properly. Will figure it out and fix that bug along with adding the capitalization check. That one isn't too worrisome -- anything that got missed in the first round we should be able to pick up on the next auto-upload. Dvgrn (talk) 19:54, 18 February 2019 (UTC)
The missing small files that were flagged as "too big" seem to have been mostly due to patterns with no header lines in the RLE namespace. I think I've fixed all of those now. A few such files managed to get themselves uploaded to the LifeWiki server, but the auto-upload script now reports those when it sees them, so I think those are all cleaned up now also.
As before, if anyone wants to add "plaintext = true" to the many articles where that's missing, please go right ahead. The latest auto-upload script report has been added to User:Dvgrn/Plaintext files, so the dump of newly added .cells files there can be used as a checklist. There's also the option of adding plaintext file links to embedded viewers as appropriate. I did a couple of samples, e.g., 68P9 -- it's pretty easy. It should always be just a matter of adding this to the caption:
[http://www.conwaylife.com/patterns/{pname}.rle RLE format]
[http://www.conwaylife.com/patterns/{pname}.cells Plaintext format]<br />
Maybe this is something that should be done with a template, to make things even easier?
The script now also checks for pnames with uppercase letters and complains about that. I don't think there are any of those at the moment. If anyone sees other problems or oddities that the auto-upload script should be catching but isn't, or if there are any other surveys or reports that it should do while it's running through all the articles anyway, please make suggestions here. Dvgrn (talk) 15:09, 27 March 2019 (UTC)
I just modified Template:EmbedViewer to link to the RLE and Plaintext automatically. The biggest problem with this, of course, is the larger patterns don't have a plaintext file. I'm not sure how to elegantly deal with this, unless there's a way to make it read the RLE header and find the pattern size or something. Ian07 (talk) 19:55, 27 March 2019 (UTC)

Help Wanted with templates and general review

Here are three problems that I'd like to fix. I could probably track down the necessary template changes myself, eventually, but I'd like to have expert advice if I can get it. Both of these items have been sorta kinda mentioned on the Tiki Bar before, fairly recently:

1. I think THUMBSIZE 2 should be the default for all infobox LifeViewers. I keep adding #C [​[ THUMBSIZE 2 ]] to get infobox pattern frames back to the right size. There seem to be hundreds of these THUMBSIZE 2 specifications by now, but looking through a bunch of new aircraft-carrier-themed still lifes that AwesoMan3000 added recently (see links a few paragraphs up)... those all need the same addition done to them, and there are dozens or hundreds more existing articles that still have the same problem. The SUPPRESS command should follow THUMBSIZE 2, so that the relatively few viewerconfigs that specify THUMBSIZE 3 won't start throwing errors after the change is made.

2. As of this morning, Nathaniel has officially removed the Life 1.05 and Life 1.06 patterns from the LifeWiki patterns directory. That means the infobox template probably ought to be adjusted to stop showing those links. We could remove "|life105 = true // |life106 = true" from all the articles that have those infobox parameters instead, but only if someone wants to get a leg up on entry into the 10,000 Club.

The Life 1.0x patterns are still on the server, but hidden in a ZIP file. It seems to me that going forward, the way to make patterns available in non-standard non-RLE formats will be to publish conversion scripts that work on the contents of all.zip.

Anyway, there are some places in the infobox template documentation and other docs that mention Life 1.0x, which I can track down and fix eventually if no one else gets to it first.

3. Let's get rid of that dependency where you have to have rle = true or nofile = true before LifeViewer will show up -- as per Nathaniel's recent advice. Dvgrn (talk) 15:51, 25 January 2019 (UTC)

Okay, Nathaniel has done a bulk upload of 387 RLE files, collected by the auto-upload script for every article in the main namespace that referenced a pname and had RLE:{pname} and/or RLE:{pname}_synth articles in the RLE: namespace. That means that as of today, there should no longer be any broken RLE pattern download links (the ones that show up when you say rle = true in the infobox).
There shouldn't be a lot of broken synthesisRLE = true links, either, but those might happen if somebody set that flag to true but then didn't create the RLE:{pname}_synth article.
I'd suggest that people shouldn't go too wild uploading new glider syntheses, until the next version of Mark Niemiec's database comes out -- and maybe not even then. It would be nice to come up with direct dynamic links to synthesis patterns on Catagolue and/or in Mark's database, so that we don't always have slightly antiquated information copied from those places and uploaded to the LifeWiki pattern collection, where they're kind of hard to keep up to date.
I guess the next item to tackle is automatic generation of the plaintext = true .cells files for every article about a pattern that's 64x64 or smaller (let's arbitrarily say). Does anyone have suggestions for other checks and auto-updates that the uploader script might be able to accomplish? Dvgrn (talk) 04:25, 27 January 2019 (UTC)
@Ian07: Wow, that was a lot of fast Life 1.0x cleanup work. Thank you! I'll see if I can get a bulk upload done for .cells format soon, for all sufficiently small patterns (which is most of them). Then the LifeWiki will suddenly be following a standard policy on pattern formats, fairly universally across all articles. Dvgrn (talk) 20:49, 28 January 2019 (UTC)
I've just added THUMBSIZE 2 as a default option for the viewers to save myself some trouble. As for item #3 in your list, the solution probably in Template:InfoboxStart though I'd rather leave that to someone more experienced with templates. Ian07 (talk) 22:12, 13 February 2019 (UTC)
Things are starting to look pretty good for plaintext support on LifeWiki. The latest auto-upload report is here. There are still a few weird exceptions getting reported, but for the most part I can happily ignore them now.
I'm vaguely considering making some custom plaintext files for special-case patterns like the bumpers and bouncers, where there are extra gliders added for animation purposes that happen to increase the bounding box beyond the 64x100 limit. It seems reasonable to upload plaintext versions without the extra gliders for those cases.
That will give me an excuse to go through the report and make sure there aren't any other odd cases where patterns are mysteriously getting missed, even though they should be small enough for a plaintext version. I think that's not a problem any more, but I haven't triple-checked. If anyone sees leftover stuff that the auto-upload script still isn't handling correctly, please let me know. Dvgrn (talk) 23:17, 2 April 2019 (UTC)
I skimmed through the list, and the only problem I found was that switchenginechannel.cells didn't seem to get generated despite being smaller than the 64x100 limit, even though it has shown up in all of the "Cells files created" sections in User:Dvgrn/Plaintext files. Other than that, there doesn't seem to be any errors on the computer's part. I saw a few small patterns in the "No plaintext param in infobox" section, but that appears to be due to my own error, so I'll double-check that whenever I get the chance. Ian07 (talk) 23:33, 2 April 2019 (UTC)
Huh, that's an odd one. There were a couple of nonstandard things about the uploaded RLE, so I replaced it with a more standard version. Will re-run the script at some point and see if I get a .cells file out, and one way or another that should help me track down the bug -- can't see why the code has been skipping that pattern, but the script is getting embarrassingly messy so there could be all kinds of subtle errors hiding in there. Thanks for the review! Dvgrn (talk) 02:33, 3 April 2019 (UTC)

Replacing images with animated viewers

I just started on a project to add more animated viewers in place of static images on the wiki. However, I've already started running into some problems, particularly with the pushalongs in the 114P6H1V0 article. I already created an RLE:114p6h1v0pushalong, but I'm not sure how exactly the comments in the RLE:pname page get translated to the actual files, especially since files like block.rle have comments that aren't in the RLE namespace. I'm worried that I'll unintentionally remove said information from the wiki's pattern collection if I'm not careful.

I'm thinking it might be better for now to just focus on the infobox images and not worry about the rest of the article, especially considering the images in the article have colors and arrows and other things which might be lost with an animated viewer. I'd be perfectly fine with RLE:114p6h1v0pushalong being deleted for the time being so it doesn't replace 114p6h1v0pushalong.rle in the next bulk upload.

Even then, though, as with the Block example above, there's still comments in the original files that may or may not be overwritten since I don't know how bulk uploads work. I'd basically just like to know what precautions to take to make sure I don't break anything with this project before I proceed. Ian07 (talk) 16:06, 2 February 2019 (UTC)

All good questions. The main answer is that the auto-upload script is designed so that it never overwrites any files that are already on the LifeWiki server, so you don't have to worry about overwriting anything. Comments in block.rle are safe, and the addition of RLE:114p6h1v0pushalong won't damage the existing uploaded file on the server.
Now, if we deleted 114p6h1v0pushalong.rle from the server, and added these two comment lines at the top of RLE:114p6h1v0pushalong --
#O Hartmut Holzwart
#C A pushalong for the c/6 orthogonal period 6 spaceship 114P6H1V0.
- then the auto-upload script would regenerate a fairly close copy of the file that we deleted. The #N line would be a little different since the default is now {pname}.rle, and the script produces two URL lines instead of just one: a link to the article followed by a direct link to the (future location of the) file itself on the LifeWiki server.
So far I've always looked through the RLE files produced by the script, and hand-edited anything that didn't come out quite right -- order of comment lines, etc. That's probably a tradition that I'll continue, so that's another line of defense against accidental damage. With any luck the next run won't be quite so much work, as long as no one goes back to uploading new headerless RLE or other nonstandard stuff that the script doesn't know how to clean up.
See also User_talk:AwesoMan3000#Standardization_of_comment_lines for a summary of what should, or could, still be included in comment lines, versus what is auto-generated. Maybe after that summary gets a good trial run, I can migrate it into the actual documentation. It will be strange and wonderful for a new LifeWiki editor to actually have a reasonable way to learn how to add new articles with associated LifeViewer-displayed patterns... the docs have been partly stuck in 2009 ever since, well, 2009 I suppose! Dvgrn (talk) 04:07, 3 February 2019 (UTC)
One more detail that isn't clear from the above:
The auto-upload script will automatically generate a slightly nonstandard #O line including both the discoverer and the discoveryear from the infobox -- like
#O Paul Tooke, 2008
for the 114p6h1v0 article. But that only works for patterns that have infoboxes. Other patterns may also have pnames, but only show up in embedded viewers in some other article. In those cases the script can't be sure that the discoverer or discoveryear will be correct, so it will just leave that optional line out.
Theoretically we could invent some standard way to include attributes in an embedded viewer template to convey that information. But since those attributes aren't actually used by LifeViewer it seems just as easy to make a habit of adding a comment line to the RLE.
For example, adding "#O Hartmut Holzwart, May 2009" to RLE:114p6h1v0pushalong would convey slightly more information (month as well as year) than the auto-upload script manages to collect for main-article patterns. Dvgrn (talk) 04:19, 3 February 2019 (UTC)
Just looked over the first batch of patterns added to the RLE namespace for the convert-static-images-to-LifeViewer project. Everything looks pretty workable. I think I'll adjust the auto-upload script to skip the generation of an #O line if there's one in the RLE already. Usually what's in the RLE will be a more specific date than what the script can produce from the discoveryear parameter.
Maybe I should change the script to find the "name" parameter if there is one, and use that instead of {pname}.rle in the #N line? It's kind of weird having ".rle" as part of the defined name. The problem is, there isn't a name= line in embedded viewers, but there is a pname= line, and I wanted some information in that first line that could be collected consistently. (?)
The only other thing I noticed offhand is that a few RLE files ended up getting comment lines with links: for example, RLE:151p3h1v0 has
#C http://www.conwaylife.com/wiki/index.php?title=233P3H1V0
There's a shorter form that works just as well:
http://www.conwaylife.com/wiki/233P3H1V0
But really I don't think there's any need to add article or pattern links to the RLE namespace. They'll get generated and added automatically by the auto-upload script. If you're actually looking at an RLE file in the RLE namespace, and wondering which article it goes with, then it's pretty quick to click the "What links here" link in the sidebar to find that out, instead of copying and pasting part of a comment line.
Based on experience so far, does there seem to be anything else that really ought to be adjusted for this whole conversion / auto-upload process? Dvgrn (talk) 22:54, 3 February 2019 (UTC)
Oh, one more minor thing: looking at LifeWiki articles with lots of LifeViewers on them, I'm starting to think that there might be such a thing as too much animation sometimes. If the infobox has an animated spaceship or oscillator in it, it might make sense to leave out AUTOSTART on (some?) embedded viewers in the actual article. It can be nice to have something on the page that isn't moving -- or to be able to open in LifeViewer and step through a pattern one tick at a time, without having to disable AUTOSTART first. Dvgrn (talk) 23:12, 3 February 2019 (UTC)
I haven't had any other problems so far, though of course I've only just started this project and have only gotten through around 1% of all the articles. As for the comment lines in RLEs, I'll try and be more consistent with them from here on out. (will double-check the ones I've already made to see if there's anything that should be added or removed) And yeah, I do agree that too many auto-started viewers looks very cluttered, so here's a rule of thumb I'm probably going to use: there should be no more than three AUTOSTART viewers in close proximity to each other. Thoughts? Ian07 (talk) 23:50, 3 February 2019 (UTC)
Fine by me. I've been thinking two animated viewers at once is usually enough action, but it depends on the article. Just maybe something to keep in mind a little bit. Dvgrn (talk) 01:33, 4 February 2019 (UTC)

Arbitrary adjective names

Per this forum post, I've removed every Arbitrary Adjective Name™ I could find on the wiki and moved it to a more easily-recognizable name (article text has also been properly updated to match title). Here's the list of files that need to be deleted as a result:

   absurdlylongboat.rle
   absurdlylongship.rle
   absurdlylongsnake.rle
   boatwithextralongtail.rle
   extralongbarge.rle
   extralongboat.rle
   extralongcanoe.rle
   extralonghookwithtail.rle
   extralongintegral.rle
   extralongshillelagh.rle
   extralongship.rle
   extralongsnake.rle
   extralongsnake_synth.rle
   extralongtubshillelagh.rle
   ludicrouslylongboat.rle
   ludicrouslylongship.rle
   remarkablylongboat.rle
   remarkablylongcanoe.rle
   remarkablylonghookwithtail.rle
   remarkablylongshillelagh.rle
   remarkablylongship.rle
   remarkablylongsnake.rle
   remarkablylongsnake_synth.rle
   ridiculouslylongboat.rle
   ridiculouslylongship.rle
   stupidlylongboat.rle
   stupidlylongship.rle
   terriblylongboat.rle
   terriblylongship.rle
   terriblylongsnake.rle

Ian07 (talk) 17:12, 23 February 2019 (UTC)

I think the above are all cleaned up correctly now, as far as uploaded patterns getting deleted. There was also a file out there called "extraextralongsnake_synth.rle" which turned out to have the Niemiec synthesis file for long^4 snake rather than long^5 snake. (Yup, getting rid of the extra and very and Arbitrary adjectives in favor of a simple long count still seems like a good simplification.)
The _synth files are still troublesome in general, because the files that are already out there often have generic links to the Niemiec database search page, rather than to the actual file. And of course on that database search page, the way you'd find a long^5 snake or whatever is actually by looking up "extra extra long snake"... so there's some possibility that the cleanup of "extra" creates some new confusion while reducing some other old confusion.
Anyway, I'd still recommend not starting any kind of comprehensive review of _synth files until the new version of Niemiec's database becomes available.
The second half of this cleanup will require re-running the auto-upload script, to get the .rle and .cells versions of all these files back onto the server with their new longN* names. I'm planning to wait until at least the end of this week before tackling that job. Dvgrn (talk) 22:27, 25 February 2019 (UTC)
Upload of new RLE and plaintext files should be done now. Some of these names are still preserved as redirects, like Stupidly long boat and also as an alternate name given in the text of the article. I may eventually be inspired to track down all these leftovers and clean them up, but for now I'm kind of worn out from wrestling with the auto-upload script. There's always another degenerate case that hasn't been handled yet... Dvgrn (talk) 14:45, 27 March 2019 (UTC)

Non-notable isotropic rules

Many pages on isotropic non-totalistic rules have been proposed for deletion. It seems that some users (myself included) have moved articles on such rules to their namespace, such as here. This seems to be an ongoing project and deserves discussion here.

Should I adopt salad or would someone else like it? I have a couple collections of ships that I’d like to move to the page should it be adopted. Moosey (talk) 17:15, 28 March 2019 (UTC)

I reverted the speedy deletion tag on Goat Flock because there's a wiki link from the Catagolue rule page which originates from the rule list.
If there's still a consensus that the main namespace redirect should be deleted, then the rule list would need to be updated with 'Goat_Flock' replaced with 'User:AwesoMan3000/Goat_Flock' after the exclamation mark on line 120. Calcyman (talk) 09:53, 29 March 2019 (UTC)
I like the idea of having some space on the LifeWiki for people to document their favorite isotropic rule discoveries. It makes sense to me that all of these could go somewhere other than the main namespace, just to keep things that are spaceships in other rules from getting mixed up with Conway's Life spaceships, and so on. The User namespace seems like a fine place for isotropic rule pages, along the lines of Moosey's suggestion.
But sometimes it's hard to know who should "claim" a rule -- it doesn't necessarily make sense for any particular user to start a page, and yet it's clear that a page should be started. Is there any harm in inventing a new namespace for this purpose? Would anything be wrong with Isotropic:Goat Flock, for example? Dvgrn (talk) 13:59, 29 March 2019 (UTC)
@dvgrn: good idea. It would prevent too much clutter in the main namespace without making anyone frustrated about the fact that [insert frustration here] happened.
who can make new namespaces? Moosey (talk) 14:41, 29 March 2019 (UTC)
I agree with the namespace idea. Perhaps we could name it something like "OCA" so we could move existing articles such as HighLife there. As for specific patterns, I'd suggest making them subpages of their native rules, e.g. OCA:HighLife/Bomber so they don't get mistaken as rules. Of course, the notability guidelines should still apply here, or else this will become way too hard to maintain. Ian07 (talk) 14:33, 30 March 2019 (UTC)
I agree with all of Ian07's suggestions above: using OCA for the namespace, with rule pages (except for CGoL) in that namespace, and rule-specific patterns as subpages of their rules. Calcyman (talk) 17:12, 30 March 2019 (UTC)
@Moosey (and everyone else) -- based on a very small amount of Googling, officially adding a new namespace to the LifeWiki namespace dropdown list is a Nathaniel-only change on the server side. I tried moving the "LifeHistory" article to OCA:LifeHistory as an experiment; the move was technically successful, but I think the article is just called "OCA:LifeHistory" and it's still in the main namespace.
I've sent a request to Nathaniel. I or somebody will post an update here if and when "OCA" becomes an official namespace. Until then there's probably no point in trying to move any more OCA pages. Dvgrn (talk) 19:34, 30 March 2019 (UTC)
There's now an OCA namespace! However, I've sent a follow-up question to Nathaniel, because I'm not sure what the best way would be to clean up an embarrassing problem I created. Currently if you follow the LifeHistory link, you'll see a page called "OCA:LifeHistory", but that's still the actual name of that article, it's not in the OCA namespace. As a weird side effect, it doesn't seem to be possible to either edit or move that "OCA:LifeHistory" page, so it doesn't seem like I can fix the problem.
I can solve most of the problem by changing the LifeHistory redirect and creating an actual LifeHistory page in the OCA namespace. That might leave an orphaned "OCA:LifeHistory" page out there somewhere, but it doesn't seem as if there's any way to get to that article except via the current redirect. Does anyone see an easy way to move that article to where it belongs? I'm a little worried that if I don't clean it up correctly, it will be an unexpected headache sometime somehow. Dvgrn (talk) 15:37, 4 April 2019 (UTC)
Stand by until further notice -- please don't try making any OCA-namespace pages just yet... hoping to get my OCA:LifeHistory mess fixed first. Dvgrn (talk) 17:43, 4 April 2019 (UTC)
Okay, it looks like Nathaniel has successfully cleaned up OCA:LifeHistory, so now it's actually in the new OCA namespace. Let's try moving Goat Flock and other similar pages out of the User namespace and into OCA -- there shouldn't be any need for people to "adopt" these pages individually any more. Dvgrn (talk) 01:55, 5 April 2019 (UTC)

(Resetting indent) All of the rule pages have now been moved to the OCA namespace, and the resulting double redirects fixed, but I have a few questions about how to continue from here:

  1. Should rule families also be moved (e.g. OCA:Generations) or should the namespace just be for individual rules/patterns?
  2. Should we use the same pattern categories as for Conway's Game of Life, or will that cause confusion?
  3. Is it possible to make Special:SpecialPages include OCA pages? This is not as important but it would be nice as a maintenance tool for these articles.

Ian07 (talk) 20:43, 5 April 2019 (UTC)

For #3, I don't think there's a (reasonably easy) way to add something like that to Special:SpecialPages, but a list of all pages in the OCA namespace can already be viewed here. Nathaniel (talk) 21:39, 5 April 2019 (UTC)

Caterloopillar "Family Page" vs. Specific Pattern

Does anyone have any clever suggestions about how to deal with the problem that

1) there is a family of spaceships called Caterloopillar, with different speeds, and different bounding boxes and cell counts for each speed, and

2) there is a specific Caterloopillar with speed c/8 (for example) and a specific bounding box and cell count

?

It would be nice to be able to link to a specific pattern or two, in a separate section inside the generic "Caterloopillar" article. But it doesn't really make sense to have bounding box, cell count, etc. parameters in the infobox for the generic article.

What's the best way to make this kind of thing clearer? Could we invent some kind of special "pattern family" infobox template where no parameters are required, and parameters are only displayed if they're defined? Dvgrn (talk) 15:08, 5 April 2019 (UTC)

We have already several families of patterns. Geminoids are also family and deserve general family page. As well as very soon the 0E0P metacell will start to generate some more interesting news with special cases and other things (especially if we use turing machine to calculate the next iteration). I'm not sure exactly how to classify family. Does the helix based technology which sends *WSS upwards is considered a family of spaceships (as it contains the caterloopillar family). But I think the number of natural families of patterns is small, and it's important to think about pattern families as well. So maybe we need to start from a page where we define what does it means pattern family. I would define it as collection of designed patterns with noticeable feature which constitutes major role in the interest this pattern is arising (geminoids for example, or strange loopers, or helix based spaceships, or natural fuse based etc.).

I think also we in total freedom here in the sense how do we analyze the patterns and the scope of the wiki articles. I think the families ignorance might be our weak spot in how we think about CGOL in general, and new families might be found which are less intuitive to think about now, and those families might bring new discoveries and design patterns just due to someone figuring out a new family.

But to state it simply - it would be also nice to simply separate the two articles of caterloopillars that's all. In the banner we can simply place "-" for everything. The bounding box is the only problem as it creates -x- instead of nothing. We can insert adjustable for speed or "Less than c/4".

Simsim314

Glider syntheses from Shinjuku with help from Catagolue

-- Okay, we can get started on the next stage of improvements for glider synthesis reporting now! This came in from calcyman last night (links slightly edited):

Catagolue can now be queried for syntheses from Shinjuku. Here's the text link that's probably most appropriate for LifeWiki.

Subsequent path parts are ignored, so you can do things such as: https://catagolue.appspot.com/textsamples/xp14_j9d0d9j/b3s23/synthesis/tumbler_synth.rle

The syntheses are also embedded in a LifeViewer on the object pages.

Finally, you can query the best known costs (in gliders) of all objects known to Catagolue. That's good for finding (for example) disparities between LifeWiki and Shinjuku to see whether either of them needs updating.

In particular, the update script uses this so as to only bother uploading (and indeed creating) RLEs of the objects that need to be updated.

My idea is that this should be an additional link in the "glider synthesis" section of relevant infoboxes. If synthesisRLE=true, then we can serve up both these Catagolue links and the uploaded synthesis file (which may be different from the Shinjuku/Catagolue version: uploaded files may contain multiple syntheses with different construction envelopes, or continuous instead of incremental syntheses, sometimes two in a row for spaceships to show the repeat time, etc.)

When the new version of Mark Niemiec's database becomes available, maybe we can use a similar system to link directly to conwaylife.com/ref/mniemiec/*, instead of uploading copies of all those patterns which will then inevitably go out of date.

However, it's not really ideal to use synthesisRLE=true to decide whether to show these links. For example, we can now produce syntheses for all the 12-bit still lifes that AwesoMan3000 made articles for last year, like teardrop with claw and so on. Most of these don't have _synth files in the raw RLE namespace or uploaded to the server -- and now we don't need to do that. But if we had to add synthesisRLE=true to the infobox to get these new Catagolue links, then a link to the LifeWiki pattern collection would also be created.

If we really want all these syntheses to be part of the LifeWiki pattern collection, then we could certainly bulk-upload them all, and do a new bulk upload every year or so to catch anything that's gotten out of date. However, the total number of files on the server is already getting very unwieldy, at least with the current maintenance system, and this would only increase the pain. Maybe it would make sense to remove all the _synth files from the pattern collection instead, and offer a separate downloadable ZIP file for glider syntheses?

Maybe we should just always display a Catagolue synthesis link, and then maybe have Catagolue display something slightly more edifying than "null" if no synthesis is known. Any other ideas or suggestions? Dvgrn (talk) 15:24, 13 April 2019 (UTC)

I think the determining factor (once the remaining small objects are in Shinjuku) is to use Catagolue if there's an apgcode provided, and to fall back on _synth.rle otherwise. The reason is because LifeWiki has Orthogonoid_synth.rle and Demonoid_synth.rle, for instance, and arguably HBK_synth.rle could also be included in LifeWiki but not in Shijuku. Calcyman (talk) 16:10, 13 April 2019 (UTC)
That sounds reasonable-ish. Mind you, people have been adding apgcodes for a lot of things (from lobsters to Sir Robin), so unless we invent a new parameter like minsynthesis=true, we'll occasionally end up making links to Catagolue when no synthesis is actually available. If the link can be created/not created based on the existence of an apgcode without adding any more custom parameters, I think I might rather do it that way and just live with the occasional link to nowhere, instead of taking the minsynthesis=true route.
It doesn't seem like there's any harm providing a Catagolue link and a _synth file link (and a Niemiec-database link, eventually). It's often very useful to have non-record-breaking syntheses of objects, and we won't get those from Shinjuku. When you want to construct a new object near some existing object, for example, you might need an expensive synthesis with gliders from just two directions. Or you might want a synthesis of a two-cell edge that creates both cells simultaneously, to make a pseudo still life with an existing object with a two-cell edge. Existing _synth uploads often have these kinds of options included along with the record-holder. Dvgrn (talk) 16:45, 13 April 2019 (UTC)
Okay, with Ian07's incredibly helpful help, I've made a first attempt at switching over glider synthesis links to the new Shinjuku/Catagolue source. Whenever an apgcode is supplied for an object and the 'synthesis={n}' parameter is set, a Catagolue-generated synthesis link should be provided in the Glider Synthesis section of the infobox.
I also disabled the old links to chris_c's automatically generated syntheses, since those aren't reliably up to date any more. And I tried changing the top-level category from >=1000 glider to >100 gliders. (Looks like I still have to work on that detail a bit more.) Dvgrn (talk) 17:59, 23 April 2019 (UTC)
Here's a current report on discrepancies between LifeWiki and Shinjuku/Catagolue (I'm assuming the last two are reasonably well synchronized at the moment, since the synthesis-costs summary changed since yesterday; I used this morning's cost summary). I've gone through and cleaned up all the LifeWiki articles where a cost was reported that was larger than what's in Catagolue.
This leaves a pile of 170 articles where LifeWiki doesn't know about any synthesis at all... but it looks like that list is being tackled already. Thanks, Ian07! (Anyone else interested, see the above link for how to get the Catagolue synthesis link to pop up in the infobox.)
This is all a huge improvement over the old method of creating separate RLE:{pname}_synth articles or {pname}_synth.rle files and uploading them to the server. Anyone see any problems so far?
The big remaining improvement would be not having to add "synthesis = {cost}" to every article manually, and manually update the numbers whenever they go out of date. This is pretty easy maintenance compared to the admin-only file upload stuff, but still it would be nice if each article magically reported the number and provided a link to Catagolue only if the synthesis actually exists on Catagolue. At the moment, articles like Snake pit 2 that have an apgcode but no known synthesis are cheerfully serving up a link to Catagolue that says "null".
So ... is there a clever template-y way to improve on this? We could import the subset of apgcodes from Catagolue's synthesis-cost list that we have articles for on the LifeWiki, and set that list up as a lookup table, for starters. Then maybe the update problem would be reduced to just updating that subset synthesis-cost list now and then. (?) Dvgrn (talk) 16:48, 24 April 2019 (UTC)
Quick reply, since Dave asked me to chime in, and I'll admit I've only skimmed over the preceding discussion --- with glider syntheses being handled by Catagolue / Shinjuku now, it would obviously be ideal for the LifeWiki to simply pull in glider synthesis information from Catagolue. That is to say:
  1. When a page's parser cache is updated (e.g. when a page is edited), and an apgcode is provided in the infobox template, LW should:
    1. poll Catagolue;
    2. perform a sanity check; and
    3. use that information (perhaps marked in some way to indicate external data) in the infobox, as well as for categories.
  2. When there is an apgcode, and there is a local synthesis, and Catagolue either doesn't have any synthesis or the one it has is worse than the local one, LW should:
    1. use the local synthesis; and
    2. add the page to a tracking category so Shinjuku's DB can be updated. (In the long run, ideally there'd be no such cases --- this'd be a temporary measure, and in fact it might not even be necessary.)
  3. When there is no apgcode, LW should:
    1. use a local synthesis if there is one; and
    2. also add the page to a (different) tracking category, as I believe it already does.
The big problem with this is the "poll Catagolue" bit. I'm not aware of a way for MW templates to programmatically make external requests and process the results.
It could be done client-side, in Javascript, but I believe we don't want that. There's at least two big advantages to doing it server-side:
  1. consistency: every user sees the same data; and
  2. sustainability: if Catagolue is only polled when the page cache is updated, i.e. when Mediawiki re-evaluates templates etc., Catagolue will not be hit with a request every time someone views a LifeWiki page.
That still leaves several more avenues:
  1. on-wiki Lua scripting (MW supports this with an appropriate extension, though the LifeWiki doesn't);
  2. using a bespoke Mediawiki extension; and
  3. keeping things as they are, but using a bot that runs (un|semi)supervised to update template parameters when things change on Catagolue's / Shinjuku's side (the bot in turn could be fed by data pushed out by Catagolue, say an RSS or Atom feed of new/improved syntheses that Catagolue would generate automatically and that the bot would poll periodically).
Unfortunately I can't help with any of these. (I couldn't help with templates either, but that's a different story.)
I don't know if any of this is useful --- but as I said, Dave asked me to chime in, and who am I to say no to that? Apple Bottom (talk) 15:14, 27 April 2019 (UTC)
Maybe it could be linked in with the Catagolue update process. At the moment, syntheses on Catagolue are added/updated in a very precise manner:
  1. A GitLab CI runner is launched;
  2. The entire textcensus of current synthesis costs (but not the syntheses themselves) are downloaded from Catagolue;
  3. Shinjuku is downloaded, and minimum paths to all objects are computed;
  4. Only the syntheses with lower cost than Catagolue are generated;
  5. These syntheses are uploaded (as RLEs) in batches of 1000.
Since LifeWiki need only display the synthesis cost in the infobox, rather than the synthesis (which is available with an external link), then I guess this update process could additionally upload the entire set of synthesis costs to LifeWiki into some page which is queried by the infoboxes.
Of course, this raises the question: how can an external process upload to LifeWiki? That external process can contain secret environment variables (and indeed does, to securely push updates to the live Catagolue). I believe you had an User:Apple Bot which automated things -- does that run externally? Calcyman (talk) 22:52, 27 April 2019 (UTC)