Thread for your website-related questions

[confocaloid]

I feel like we need to do something about the "Patterns for NewComers" otismo thread. These patterns are definitely not for newcomers, and it's made worse by being in Patterns rather than Sandbox (although moving it wouldn't fully fix the problem).

Attempting to open that thread causes some significant browser lag for me. Didn't investigate it - probably something related to multiple non-code-tag viewers with autoplay enabled (which is generally a bad idea).

[dvgrn]

I feel like we need to do something about the "Patterns for NewComers" otismo thread. These patterns are definitely not for newcomers, and it's made worse by being in Patterns rather than Sandbox (although moving it wouldn't fully fix the problem).

If newcomers look at the patterns in that thread, what problems are you thinking are likely to occur?

[confocaloid]

I feel like we need to do something about the "Patterns for NewComers" otismo thread. These patterns are definitely not for newcomers, and it's made worse by being in Patterns rather than Sandbox (although moving it wouldn't fully fix the problem).

If newcomers look at the patterns in that thread, what problems are you thinking are likely to occur?

One problem I can see is that it does not appear to be easy for a newcomer to even start looking at some pattern in that thread. There are multiple viewers with AUTOSTART enabled, and with script errors of the form "WIDTH 850: argument out of range".
Multiple autostarted viewers on a page are a bad idea generally. It causes massive browser lag. Further, by the time a reader would reach some viewer down the page, that viewer will already play to some point other than the starting point of the animation.
TL, DR: serious problems with user experience.

Another problem is that it is basically another attempt to advertise Game of Life. As such, I believe it is misguided, and out of place in the Patterns subforum at least.
People who are going to be interested in this game will be interested it, without any of those Heavily Animated Super Duper Patturns(TM).

I think moving the thread to Sandbox would result in Sandbox getting one more problem (in addition to all other various problems that are already there).

[Haycat2009]

I feel like we need to do something about the "Patterns for NewComers" otismo thread. These patterns are definitely not for newcomers, and it's made worse by being in Patterns rather than Sandbox (although moving it wouldn't fully fix the problem).

I have to agree. How does this help newcomers? My opinion is that they should be moved to otismo's userspace, as it will solve most problems while allowing otismo to collect them. What's more, it took me a while to load - this number of viewers will load faster in Lifewiki.

[confocaloid]

What's more, it took me a while to load - this number of viewers will load faster in Lifewiki.

I'd say moving that experiment to LifeWiki is a bad idea.
This number of viewers on a page will continue to load very slowly, regardless of whether it is in a forum thread or in LifeWiki.
Cluttering LifeWiki with more and more slowly loading animated patterns will only create new problems, without solving any old problems.

I suggest to move the forum thread to Sandbox. That's supposed to be the place for "experimental stuff".

[Haycat2009]

I suggest to move the forum thread to Sandbox. That's supposed to be the place for "experimental stuff".

Yeah, but it will not solve all of the problems - Plus, how is it helpful?

[confocaloid]

Helpfulness is in (hopefully) a slight improvement of the S/N ratio on the Patterns subforum.

I suggest to move the forum thread to Sandbox. That's supposed to be the place for "experimental stuff".

Yeah, but it will not solve all of the problems - Plus, how is it helpful?

[...]
This is an academic forum, not a chat or microblogging platform.
[...]
[*] In order to keep the forums organized, please:
[...]
Keep the formatting in your posts simple. The use of bold/italics/underline/font color/font size is not necessary in most cases.
[...] But in most cases it's considered polite to let people make their own decisions about whether to invoke LifeViewer, by using predominantly "code" tags.
[...]

[dvgrn]

On the other hand, while otismo doesn't always explore in a direction that everyone else on the forums agrees with, he does quite often succeed in "pushing the envelope" and bringing up interesting things about the presentation of Life patterns that are really useful for the community to discuss.

The "WIDTH 850" problem has been hanging around for at least two and a half years without it ever coming to my attention, for example.

I'm leaving open a post report about moving otismo's thread to the Sandbox, in case it might attract the attention of some other moderator who has a different opinion from mine -- but I'm not going to move that thread myself. I think it's fine where it is for now -- it can always be moved later.

It would be good if everyone remembered that these forums are "reluctantly moderated". Post reports have been coming in recently at about fifty times the old normal rate, directing that posts should be moved to one place or another, sometimes for very minor categorization offenses.

So far nobody who is saying that "we need to do something" about otismo's thread... has really tried any negotiations in good faith with otismo directly, about posting future experiments in the Sandbox. Granted, direct negotiations might not work, but if they're done politely they seem like a really good first step here.

[rowett]

Some relevant LifeViewer information for the Patterns for NewComers thread:

1. WIDTH 850 argument out of range
By default embedded LifeViewers here on the forums are automatically sized so they are the width of the post body. Specifically they are limited by the width of the code box containing the RLE.
If you set a specific width with the [[ WIDTH number ]] command then the specified number must be from 480 to the width of the code box. Anything else will generate the "argument out of range" script error. The [[ WIDTH ]] command is probably best suited for creating fairly narrow embedded LifeViewers.

2. AUTOSTART
Javascript is single threaded so when you run multiple LifeViewers at once you are sharing a CPU thread between them. The more you run, the slower each one will run. If you are using the popup LifeViewer (via SHOW IN VIEWER link) then this is not an issue since there is only one LifeViewer.
If you are running multiple LifeViewers and the one you are watching is running slowly then you can use Settings->Advanced->Stop Others to stop any other running LifeViewers (hotkey Z).
Also if you include the script command [[ EXCLUSIVEPLAY ]] then pressing play on that LifeViewer will automatically stop any other running LifeViewers. You can have LifeViewers ignore the automatic stop by using the script command [[ IGNOREEXCLUSIVE ]].

3. Memory
There are two limits in Javascript for memory. The first is total heap size. This is the maximum amount of memory that Javascript will allow to be used in each browser tab. This differs between browsers but is typically a few Gb of RAM.
The second is how much memory Javascript will allow for a single typed array. Again this differs between browsers but is typically 1Gb to 8Gb.

Finally there is your system limit. If the browser as a whole uses too much memory and your device doesn't have much RAM this can cause failures.

When LifeViewer tries to allocate memory and it fails it will report what it was trying to do at the time. In Dave's report it said:

Code: Select all

Failed to allocate 268435456 element Uint8 array for Life.colourGrid

This means that the the first limit was reached. The Javascript heap was used up and did not have enough space to allocate this Uint8 array. If you're interested LifeViewer was attempting to allocate the array that holds the cell colours for a 16384x16384 grid.

You can see how much memory LifeViewer thinks it is using (for all LifeViewers on a page) by checking out Help->Memory. This does not include browser resources.

4. Start Time
Once a page has loaded on the forum (or LifeWiki) LifeViewer scans it for RLE. Embedded LifeViewers are initialized and code boxes containing RLE have a SHOW IN VIEWER link added. This involves reading, decoding and validating the RLE text. The start time will be related to the number of patterns and their size.

[dvgrn]

Some relevant LifeViewer information for the Patterns for NewComers thread...

Thanks! I've added a link from that thread to this one.

The [[ WIDTH ]] command is probably best suited for creating fairly narrow embedded LifeViewers.

The use case that I'm most immediately interested in is this one. otismo isn't the only person for whom a WIDTH 850 setting seemed very useful, and this is one of the less obvious reasons.

In the rare cases where someone really wants to use a "viewer" tag rather than a "code" tag -- where it seems worth getting an animation of something in front of people's eyes immediately, with no need for them to click on "Show in Viewer" -- the polite way to do this is to use the THUMBNAIL command to take up less vertical space. This ends up being a good compromise: people on smaller screens don't have to scroll forever to even see that there's more text below the viewer -- let alone to get to the next post -- but people with bigger screens are just one click away from a good close-up view.

However, there's a balance between taking up less vertical space and actually being able to see the action in the viewer-tag-wrapped pattern... which is the original purpose of using viewer tags in the first place. There's a limited range of THUMBSIZEs -- 2, 3, or 4. Sometimes -- like in the above case -- I find that I want the "biggest possible small square pattern", which translates to THUMBSIZE 2 WIDTH 850 HEIGHT 850.

The upper limit is 856, so technically if I want a square for my "default case", I could maybe just put in HEIGHT 856 and skip the WIDTH parameter. But that will produce ugly non-square displays for people who, for whatever reason, have a different code-block width from mine.

I think that the majority of laptop and desktop systems are going to have a code block width of 856, since that's the maximum width that the forums seem to allow no matter how many pixels wide the display is. If you make the browser window wider than 1200 pixels or so, the wallpaper strips along the edges just get wider without changing the code-block width:

What a viewer looks like in a forum page with a browser width of 1920 pixels

maximum-width-code-block.png (36.45 KiB) Viewed 1076 times

But what I'm looking for here is a way to use THUMBNAIL, THUMBSIZE, HEIGHT, and/or WIDTH parameters to make a viewer-tag-wrapped pattern that remains square for everybody who is looking at it, and always displays the entire pattern not just a random central piece of it -- without ever popping up any ugly WIDTH errors.

TL;DR:
Maybe it would make sense to skip the display of WIDTH errors by default, unless there are additional errors that need to be displayed anyway.

Code block width is very device- and browser-window-specific, such that it seems to be uniquely easy to end up with these kinds of mysterious errors that some people see and some people don't. But there aren't currently any obvious warnings about not using big numbers for WIDTH -- so this problem is likely to reoccur fairly often unless something gets adjusted at LifeViewer's end.

[rowett]

Maybe it would make sense to skip the display of WIDTH errors by default, unless there are additional errors that need to be displayed anyway.

Code block width is very device- and browser-window-specific, such that it seems to be uniquely easy to end up with these kinds of mysterious errors that some people see and some people don't. But there aren't currently any obvious warnings about not using big numbers for WIDTH -- so this problem is likely to reoccur fairly often unless something gets adjusted at LifeViewer's end.

I'll take a look. Suppressing the error message is trivial. What's more interesting is keeping the requested aspect ratio.

In the mean time if you're interested in page load times then LifeViewer outputs timing information in the browser console (hard refresh your browser to make sure you have the latest version).
LifeViewer will say three things:

• LifeViewer read popup: x ms
• LifeViewer read embedded: x ms
• LifeVewer page scan: x ms

The first (read popup) is the time taken to scan a code box and appears even if the code box does not contain valid RLE.
The second (read embedded) is the time taken to intialize an embedded viewer.
The final (page scan) is the time taken to scan the entire page.

On my desktop machine loading the Patterns for Newcomers thread in Chrome on Windows shows the following timing in the console:

Code: Select all

LifeViewer read popup: 0.276ms
LifeViewer read embedded: 73.134ms
LifeViewer read embedded: 20.828ms
LifeViewer read popup 7.479ms
LifeViewer read popup 14.082ms
...
LifeViewer read embedded: 415.134 ms
...
LifeViewer read embedded 1231.902ms
...
LifeViewer read popup: 0.110ms
LifeViewer page scan: 1906.558ms

I omitted several "read popup" entries for brevity. From this data we can see that once the page loaded it took LifeViewer 1906ms (just under 2 seconds) to scan. We can also see that the major culprits were the embedded viewers, the slowest being 1231ms (1.2 seconds), which is the Glider Synthesis pattern. This pattern is 12723x12688 cells in size.

Note: these timings are accurate if the rules used by the patterns are built in to LifeViewer. If the rules have to be fetched from the LifeWiki repository then this time is not included since that happens asynchronously.

[confocaloid]

You can see how much memory LifeViewer thinks it is using (for all LifeViewers on a page) by checking out Help->Memory. This does not include browser resources.

Here is the displayed output of "Help -> Memory" in my case, after loading the first page of the Patterns for Newcomers thread, from the first non-code-box viewer ("State-of-the-Art Universal Construction Technology builds Two-Engine Cordership"):

memory.png (30.59 KiB) Viewed 986 times

In the mean time if you're interested in page load times then LifeViewer outputs timing information in the browser console (hard refresh your browser to make sure you have the latest version).

Console log after loading the first page of that thread
(note: currently I have another long-running process which is low-memory but high CPU. So the loading is probably two or three times longer. But hopefully still helpful a for a comparison between different viewers/events.)

Code: Select all

LifeViewer read popup: 31ms
LifeViewer read popup: 30ms
LifeViewer read embedded: 1071ms
LifeViewer read embedded: 419ms
LifeViewer read popup: 315ms
LifeViewer read popup: 801ms
LifeViewer read popup: 84ms
LifeViewer read popup: 1ms
LifeViewer read popup: 13ms
LifeViewer read popup: 2ms
LifeViewer read embedded: 12829ms
LifeViewer read popup: 38ms
LifeViewer read popup: 229ms
LifeViewer read popup: 271ms
LifeViewer read popup: 2ms
LifeViewer read popup: 239ms
LifeViewer read embedded: 48420ms
LifeViewer read popup: 298ms
LifeViewer read popup: 19ms
LifeViewer read popup: 137ms
LifeViewer read popup: 40ms
LifeViewer read popup: 15ms
LifeViewer read popup: 8ms
LifeViewer read popup: 492ms
LifeViewer read popup: 758ms
LifeViewer read popup: 1ms
LifeViewer page scan: 67115ms

Added later:

(note: currently I have another long-running process which is low-memory but high CPU. So the loading is probably two or three times longer. But hopefully still helpful a for a comparison between different viewers/events.)

Thanks for the data! Please let me know the device (CPU and RAM), OS (version) and browser (version).

Celeron 4205U, 4GB RAM, Ubuntu 22.04, Firefox 121.0.1.

[rowett]

(note: currently I have another long-running process which is low-memory but high CPU. So the loading is probably two or three times longer. But hopefully still helpful a for a comparison between different viewers/events.)

Thanks for the data! Please let me know the device (CPU and RAM), OS (version) and browser (version).

[rowett]

otismo isn't the only person for whom a WIDTH 850 setting seemed very useful, and this is one of the less obvious reasons.

LifeViewer build 1101 no longer reports too big [[ WIDTH ]] errors. Instead it attempts to keep the aspect ratio by adjusting the height.

Additionally I made some performance improvements to pattern loading. On my desktop machine the first page of the Patterns for NewComers thread now takes 1233ms to scan vs 1906ms previously. Your mileage may vary.

[dvgrn]

LifeViewer build 1101 no longer reports too big [[ WIDTH ]] errors. Instead it attempts to keep the aspect ratio by adjusting the height.

Looks good! I'm seeing no WIDTH errors and more respect for the intended aspect ratio, in the square sample pattern I linked to above.

That example had a hard-coded ZOOM 4, so on a sufficiently narrow screen it just shows the center of the pattern rather than the full pattern. Here's a copy of that test pattern with no ZOOM 4, and with width and height bumped up to 1200x1200, in case anyone wants to test out an oversized width on their device:

Code: Select all

#C [[ HEIGHT 1200 WIDTH 1200 THUMBNAIL THUMBSIZE 4 AUTOSTART ]]
x = 202, y = 202, rule = B3/S23
81b2o$80bobo$74b2o4bo$72bo2bo2b2ob4o$72b2obobobobo2bo$75bobobobo$75bob
ob2o$76bo2$89b2o30b2o$80b2o7bo26b2o3bo$80b2o5bobo26b2o4bo$87b2o32b2o$
120bo$120b3o$123bo$122b2o3$54bo22b2o$54b3o21bo$57bo17b3o$56b2o17bo20bo
$96b3o$99bo$48b2o48b2o$48bo$45b2obo9b3o$45bo2b3o7b3o$46b2o3bo5bo3bo$
48b4o6b2obo$48bo9b3o3b2o$49b3o12bobo41b2o$52bo13bo34b2o5bobo$47b5o14b
2o33b2o7bo$47bo62b2o$49bo$48b2o47bo$96bobob2o$96bobobobo$93b2obobobobo
2bo$93bo2bo2b2ob4o$95b2o4bo$101bobo$102b2o$27b2o$27bobo$29bo4b2o$25b4o
b2o2bo2bo$25bo2bobobobob2o$28bobobobo$29b2obobo80b3o$33bo80bo2bo$117bo
$19b2o92bo3bo$20bo7b2o87bo$20bobo5b2o84bobo$21b2o7$31b2o$31bo$32b3o68b
2o$34bo68b2o5$3b2o$4bo$2bo$2b5o14b2o$7bo13bo$4b3o12bobo$3bo15b2o164b2o
$3b4o178bobob2obo$b2o3bo3b2o175bobob2o$o2b3o4b2o175b2o$2obo$3bo$3b2o
185b2o$190b2o2$11b2o$12bo$9b3o$9bo156bo$166b3o$169bo$40b2o126b2o$40bo
30bo$30b2o10bo29bo24b3o$22b2o6bobo5b5o27b3o26bo60b2o$23bo6bo6bo59b3o
34b2o24bo$23bobo8bo2bob2o93b2o21b2obo$24b2o15bo115bo2bob2ob3o$31b2o3bo
3b2o116b2o7bo$34bo7b2o116b2o3bo3b2o$34b3ob2obo2bo115bo15b2o$41bob2o21b
2o93b2obo2bo8bobo$41bo24b2o34b3o59bo6bo6bo$40b2o60bo26b3o27b5o5bobo6b
2o$102b3o24bo29bo10b2o$130bo30bo$32b2o126b2o$32bo$33b3o$35bo156bo$190b
3o$189bo$189b2o2$10b2o$10b2o185b2o$198bo$198bob2o$13b2o175b2o4b3o2bo$
9b2obobo175b2o3bo3b2o$9bob2obobo178b4o$15b2o164b2o15bo$180bobo12b3o$
180bo13bo$179b2o14b5o$199bo$197bo$197b2o5$97b2o68bo$97b2o68b3o$170bo$
169b2o7$179b2o$85bobo84b2o5bobo$84bo87b2o7bo$84bo3bo92b2o$84bo$84bo2bo
80bo$84b3o80bobob2o$167bobobobo$164b2obobobobo2bo$164bo2bo2b2ob4o$166b
2o4bo$172bobo$173b2o$98b2o$98bobo$100bo4b2o$96b4ob2o2bo2bo$96bo2bobobo
bob2o$99bobobobo$100b2obobo$104bo47b2o$152bo$90b2o62bo$91bo7b2o33b2o
14b5o$91bobo5b2o34bo13bo$92b2o41bobo12b3o$136b2o3b3o9bo$140bob2o6b4o$
140bo3bo5bo3b2o$141b3o7b3o2bo$141b3o9bob2o$153bo$102b2o48b2o$102bo$
103b3o$105bo20bo17b2o$124b3o17bo$123bo21b3o$123b2o22bo3$78b2o$78bo$79b
3o$81bo$79b2o32b2o$79bo4b2o26bobo5b2o$80bo3b2o26bo7b2o$79b2o30b2o2$
125bo$121b2obobo$120bobobobo$117bo2bobobobob2o$117b4ob2o2bo2bo$121bo4b
2o$119bobo$119b2o!

There's still some slightly odd behavior at very low widths. Starting with a minimum width Chrome window, I get a horizontal scroll bar for the LifeViewer frame at first. As I gradually widen the browser width, the scroll bar eventually goes away, then suddenly comes back again and LifeViewer goes back to being narrower, and then eventually the browser pane gets wide enough that the scroll bar isn't needed again. -- However, I'm pretty sure that that all of this is a rendering decision about including/not including the whitespace to the right of the phpBB frame that contains the entire post. Probably there's nothing going on there that's really specific to LifeViewer.

One very minor thing that _might_ be controllable by LifeViewer code is what happens when browser width changes. E.g., start with a minimum width browser window and look at the above thumbnail. Maximize the browser window. Notice that the LifeViewer frame width stays the same. Reload the page and notice that the LifeViewer frame width gets bigger.

[b-engine]

Is it possible to rename a forum and/or wiki account? My forum and wiki username is actually supposed to be " T6970 ".

[Haycat2009]

How do I add a Pattern as my profile image?

[b-engine]

How do I add a Pattern as my profile image?

You may screenshot or hand-draw the pattern and upload it.

[confocaloid]

Console log after loading the first page of that thread
(note: currently I have another long-running process which is low-memory but high CPU. So the loading is probably two or three times longer. But hopefully still helpful a for a comparison between different viewers/events.)

Two tests loading the first page of the thread immediately after a reboot, when only the browser was running (Firefox 122, Ubuntu 22.04)

Code: Select all

LifeViewer read popup: 9ms
LifeViewer read popup: 2ms
LifeViewer read embedded: 183ms
LifeViewer read embedded: 107ms
LifeViewer read popup: 42ms
LifeViewer read popup: 104ms
LifeViewer read popup: 23ms
LifeViewer read popup: 1ms
LifeViewer read popup: 2ms
LifeViewer read popup: 41ms
LifeViewer read embedded: 10907ms
LifeViewer read popup: 1ms
LifeViewer read popup: 28ms
LifeViewer read popup: 4ms
LifeViewer read popup: 11ms
LifeViewer read popup: 2ms
LifeViewer read popup: 5ms
LifeViewer read popup: 1ms
LifeViewer read popup: 66ms
LifeViewer read popup: 187ms
LifeViewer read popup: 1ms
LifeViewer page scan: 11825ms

Code: Select all

LifeViewer read popup: 15ms
LifeViewer read popup: 3ms
LifeViewer read embedded: 185ms
LifeViewer read embedded: 124ms
LifeViewer read popup: 64ms
LifeViewer read popup: 93ms
LifeViewer read popup: 20ms
LifeViewer read popup: 1ms
LifeViewer read popup: 2ms
LifeViewer read popup: 44ms
LifeViewer read embedded: 10992ms
LifeViewer read popup: 1ms
LifeViewer read popup: 33ms
LifeViewer read popup: 2ms
LifeViewer read popup: 12ms
LifeViewer read popup: 1ms
LifeViewer read popup: 5ms
LifeViewer read popup: 1ms
LifeViewer read popup: 45ms
LifeViewer read popup: 280ms
LifeViewer read popup: 1ms
LifeViewer page scan: 11966ms

[rowett]

Two tests loading the first page of the thread immediately after a reboot, when only the browser was running (Firefox 122, Ubuntu 22.04)

Thanks for the data!

I've made further performance improvements to pattern loading in LifeViewer build 1105. On my desktop machine the first page of the Patterns for NewComers thread now takes 736ms to scan vs 1233ms.

[TYCF]

One of the questions you need to answer to register a account in the forums is: What is a line of three cells called?
However, the answer could be both line of three or blinker.

[confocaloid]

A line of three consecutive on cells surrounded by off cells could also be described as the 3x1 "I" triomino.
However, when you start thinking about whether or not it's in an otherwise empty universe, or it is surrounded by empty cells, or instead it is a part of some still life (and therefore cannot be the p2 blinker oscillator), or a line of three "off" cells surrounded by "on" cells, or whatever else, then you are not a newcomer anymore.
Maybe the question could be reworded to exclude some of those unwanted answers, but the intended answer is probably blinker, since it is what people new to the game are most likely to know.

One of the questions you need to answer to register a account in the forums is: What is a line of three cells called?
However, the answer could be both line of three or blinker.

[Nathaniel]

I've added a few more accepted answers to the forums registration question, including "line of three".

[Haycat2009]

Can images/life viewers be used in references?

[confocaloid]

>> Can images/life viewers be used in references?

Sounds like a bad idea. Footnotes are for linking to sources to allow verification of claims/data (web pages, forum posts, publications, ...)