Pattern viewer for forum threads

[muzik]

Some performance tests:

Testing again with the latest build:

Go To Gen 174762b:
- [R]Standard: 1.7s
- [R]History: 1.5s
- [R]Super: 5.5s
- [R]Investigator: 34.5s
- Ruletable: 11.8s
- Margolus: 2.0s
- General range: 5.5s

Still on iPad Air 4th with safari, but this time it's iPad OS 17.2. Investigator is still sticking out as the slowest, but as discussed previously this is probably a safari issue.

For patterns with no special states like state 6 and the [R]Investigator states (and no command that could create any), could performance be improved by not running any checks for them and just treating them like [R]Standard (indeed, does this already happen)?

[rowett]

For patterns with no special states like state 6 and the [R]Investigator states (and no command that could create any), could performance be improved by not running any checks for them and just treating them like [R]Standard (indeed, does this already happen)?

I did a prototype a while back that proved this was not worth adding.

[rowett]

I ran the latest LifeViewer build through the benchmarks across the latest build of five common browsers on Windows 11. Interestingly Firefox is showing a good lead in the more expensive algos.

lifeviewe-perf.png (12.74 KiB) Viewed 2061 times

[muzik]

Experiencing a weird bug on Linux (yet to test Windows) where identifying a valid oscillator then attempting to view the period map will cause all of the UI elements to disappear completely. This affects both the embedded viewer and popup viewer at https://lazyslug.com/lifeview/plugin/viewer.html. It does not appear to affect the forums, however.

UI derendering issue.png (30 KiB) Viewed 1889 times

Kubuntu 23.10, affects both Firefox and Brave.

[rowett]

Experiencing a weird bug on Linux (yet to test Windows).

Fixed, thanks!

[muzik]

This should be identified as a period-2 oscillator and not as a still life, correct? I know that Margolus rules used to be special-cased, but this was before strict volatility support and such.

Code: Select all

x = 3, y = 2, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15
bo$2bo!

Conversely, having this be identified as period 2 but the only constituent cell as period 1 seems off to me. This is a major reason why I think period maps and such should have unique colors for all [R]Investigator cells.

Code: Select all

x = 1, y = 1, rule = B3/S23Investigator
F!

I forget - for themes without history such as Mono, are dead cells that were once alive still intended to be duplicated across layers? I find this looks strange and counterintuitive.

Code: Select all

x = 5, y = 5, rule = B2-ac3-i45678/S012345-i678
b2obo$o2bo$obobo$bo2bo$ob2o!
[[ X 5 Y 5 THEME Mono LAYERS 10 STARTFROM 20 ]]

This pattern might be fun for benchmarking - took 273 seconds on my end to get a period measurement, and 314 for everything else. Interestingly, it got to over twice its period in generations before deciding it was periodic, which isn't something I see often.

Code: Select all

x = 10, y = 4, rule = B2-an3-iq4-acqw5aijq6aen7e8/S02k3nqy4inqrtwy5-ekq6-i78
3bo2bo$b8o$2ob4ob2o$bob4obo!

Also, the prior bug did appear to affect Windows as well, and seemed to be localized to the site.

[rowett]

This pattern might be fun for benchmarking - took 273 seconds on my end to get a period measurement, and 314 for everything else. Interestingly, it got to over twice its period in generations before deciding it was periodic, which isn't something I see often.

Code: Select all

x = 10, y = 4, rule = B2-an3-iq4-acqw5aijq6aen7e8/S02k3nqy4inqrtwy5-ekq6-i78
3bo2bo$b8o$2ob4ob2o$bob4obo!

On my desktop machine it takes 225 seconds for period detection and 282 seconds in total.

On Golly using oscar.lua it takes 376 seconds for period detection.

On Golly using oscar.py it takes 1034 seconds!

Also, the prior bug did appear to affect Windows as well, and seemed to be localized to the site.

Yes it was due to CSP changes on the website.

[rowett]

This should be identified as a period-2 oscillator and not as a still life, correct?

Yes, fixed.

Conversely, having this be identified as period 2 but the only constituent cell as period 1 seems off to me.

The off phase of [R]Investigator on/off pairs is now treated as a dead cell during Identify.

I forget - for themes without history such as Mono, are dead cells that were once alive still intended to be duplicated across layers?

Yes. Themes without history are treated no differently than other themes.

[Haycat2009]

Can you please allow clipboard copying for mobile or at least a way to show the rle and edit it directly?

[rowett]

Can you please allow clipboard copying for mobile or at least a way to show the rle and edit it directly?

Copy to clipboard should now work (in LifeViewer build 1100) on Safari mobile. Please let me know if it works for you.

[Haycat2009]

Can you please allow clipboard copying for mobile or at least a way to show the rle and edit it directly?

Copy to clipboard should now work (in LifeViewer build 1100) on Safari mobile. Please let me know if it works for you.

I am using google

[rowett]

I am using google

On which device?

[Haycat2009]

I am using google

On which device?

Mobile. It still does not work

[rowett]

I am using google

On which device?

Mobile. It still does not work

I need more details: What make and model of device do you have? Which version of the OS is it running? Which browser and version are you using?

Important: please confirm you are using LifeViewer build 1100 or later. You can see the build number when you press the Help button at the top right.

[Haycat2009]

On which device?

Mobile. It still does not work

I need more details: What make and model of device do you have? Which version of the OS is it running? Which browser and version are you using?

Important: please confirm you are using LifeViewer build 1100 or later. You can see the build number when you press the Help button at the top right.

I just checked, and I am. I am using mobile on chrome.

[muzik]

Is it at all possible to change the fonts used within LifeViewer? I've seen it vary across certain pages (but can't remember exactly where this was the case).

No, the fonts are not configurable.

I assume these are tied to how the browser or operating system in question renders characters? I've noticed differences across Windows and Linux even when using the same browser.

Brave, Windows:

image.png (50.01 KiB) Viewed 979 times

Brave, Kubuntu:

Screenshot_20240107_154036.png (46.34 KiB) Viewed 979 times

Notice how the 1 looks different, for example.

EDIT by dvgrn: Was getting broken-image links with the externally-hosted images, so I moved them to inline attachments.

[rowett]

I assume these are tied to how the browser or operating system in question renders characters? I've noticed differences across Windows and Linux even when using the same browser.

Must be. I specify the same font on any platform.

[wirehead]

Request for two-finger touch zoom on mobile.

It is getting very annoying to use the zoom slider and have the pattern of interest get moved offscreen because I didn’t center it properly.

[Tawal]

About the viewer on the tag </>, where can I find a list (notice, manual or better tutorial) of the commands like :

• [[ ZOOM 6 ]]
• [[ STOP 87 ]]
• ...

?

I grabbed some on users which use it on theirs posted patterns.

Thanks

[confocaloid]

About the viewer on the tag </>, where can I find a list (notice, manual or better tutorial) of the commands like :

• [[ ZOOM 6 ]]
• [[ STOP 87 ]]
• ...

? [...]

LifeViewer/Scripts might help.

[muzik]

The way this zooms out does not appear to be completely smooth, especially at the end where it suddenly changes to fit the pattern

Looks good to me.

A gif might not be the best way to communicate this, but here's what I'm seeing:


Everything looks smooth until generation fifty-something, when the spaceship suddenly becomes much closer to the left edge of the window than it was before. When we reach the target generation of 80, the zoom level and positioning instantaneously changes from what it was immediately beforehand.

Perhaps autofit's behaviour is browser or something dependent as well?

[muzik]

Something weird is happening again when identifying this: it correctly says "Oscillator period 2", but the rest of the output is akin to that of a still life.

Code: Select all

x = 3, y = 2, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15
bo$2bo!

[rowett]

Something weird is happening again when identifying this: it correctly says "Oscillator period 2", but the rest of the output is akin to that of a still life.

Fixed, thanks!

[muzik]

Identifying this seems to cause a crash.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ PASTET EVERY 24 PASTE 6o! -4000 -4000 PASTET EVERY 24 12 PASTE 6o! 4000 4000 ]]

This appears to get identified as a spaceship, although since it relies solely on pasting I'm not sure if it's a valid report.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ PASTET EVERY 2 PASTEDELTA 1 1 PASTE 2o! 0 0 PASTET EVERY 2 1 PASTEDELTA 1 2 PASTE b2o! 0 2 ]]

Likewise for this, which is indeed a spaceship, but has an invalid mod transform:

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ PASTET EVERY 2 PASTEDELTA 1 0 PASTE 2o! 0 0 PASTET EVERY 2 1 PASTEDELTA 1 0 PASTE b2o! 0 1 ]]

Another paste anomaly, this should be recognised as period 4:

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[
PASTET EVERY 4 0 PASTE o! -1 -1
PASTET EVERY 4 1 PASTE o! -1 0
PASTET EVERY 4 2 PASTE o! 0 0
PASTET EVERY 4 3 PASTE o! -1 0
]]

This one you'd expect to have a mod:

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ ZOOM 4 
PASTEDELTA 1 1 PASTET EVERY 2 PASTE o! 0 0
PASTEDELTA 1 1 PASTET EVERY 2 1 PASTE o! 0 1 ]]

I haven't been able to reproduce this since, so I'm assuming it was a one-time occurrence, but identifying this resulted in an error message being spammed halfway through:

Code: Select all

x = 29, y = 32, rule = B2e3ajk4akqw5ajk6e/S2e3ajk4akqw5ajk6e
5$2bo$3bo$4bo16bo$5bo14bo$6bo12bo$7bo10bo$8bo8bo$9bo6bo$10bo4bo$11bo2b
o$12b2o$12b2o$11bo2bo$10bo4bo$9bo6bo$8bo8bo$7bo10bo$6bo12bo$5bo14bo$4b
o16bo$22bo$23bo!

If you press play after everything dies, the final two cells will appear to remain alive.

Code: Select all

x = 29, y = 2, rule = R1,C30,S,B2
ABCDEFGHIJKLMNOPQRSTUVWXpApBpCpDpE$ABCDEFGHIJKLMNOPQRSTUVWXpApBpCpDpE
!
[[ STARTFROM 242 X -256 MAXGRIDSIZE 9 ]]

Here's the gif from a previous post, s8ncw it now appears to be giving a broken image error:

[rowett]

Identifying this seems to cause a crash.

Firstly, Identify does not support patterns with PASTE operations.

Secondly, in this specific case it's not crashed it's just busy since the created pattern is large (roughly 8000x8000). On my machine Identify completes in 41 seconds. However it's invalid because as stated above Identify does not support PASTE operations.

I haven't been able to reproduce this since, so I'm assuming it was a one-time occurrence, but identifying this resulted in an error message being spammed halfway through

The clue is in the error message. LifeViewer ran out of memory. After which you should refresh the browser since LifeViewer won't be in a happy state.