Catagolue Oddities

[confocaloid]

Recently links from https://gitlab.com/hatsya/open-source/catagolue/-/jobs started displaying an error:

https://gitlab.com/hatsya/open-source/catagolue/-/jobs/7516103771

temp.png (66.74 KiB) Viewed 6722 times

[Vort]

Recently links from https://gitlab.com/hatsya/open-source/catagolue/-/jobs started displaying an error:

Works good for me, most likely, problem is already solved:

catagolue_job.png (93.02 KiB) Viewed 6703 times

[confocaloid]

Recently links from https://gitlab.com/hatsya/open-source/catagolue/-/jobs started displaying an error:

Works good for me, most likely, problem is already solved: [...]

Unfortunately not solved yet, still the same error ("500 something went wrong").

[Vort]

Unfortunately not solved yet, still the same error ("500 something went wrong").

I found how to reproduce this problem:
When user is logged in, no error appears, but after logout (or without logging in at all), "something went wrong" is displayed.

It may be just bug, or GitLab is forcing users to make accounts this way.

[muzik]

Is this supposed to be marked as (true)?
https://catagolue.hatsya.com/object/xp1 ... jz01/b3s23

[dvgrn]

Is this supposed to be marked as (true)?
https://catagolue.hatsya.com/object/xp1 ... jz01/b3s23

I wouldn't think so, due to T = 6 +15N in the LifeViewer pattern. "Pseudo" seems right when the two pentadecathla are connected by a patch of stays-dead-due-to-overcrowding cells.

[vilc]

There is currently a huge overload on Catagolue's readsynth queue. It caused the last two updates of the synthesis database to fail : many syntheses were not recorded and the queue was not cleared. As a consequence, this problem will likely persist if no manual intervention is done, and may even get worse as new syntheses are submitted.

Most syntheses were submitted by batches of a few thousands, close to Catagolue's limits. Some other were submitted individually (which makes it more difficult to count them). The proper way to submit this many syntheses would be (if I understood correctly) to create a merge request on Gitlab for Shinjuku, and add .sjk file in /shinjuku/comp/autogen.

[confocaloid]

Recent "shinjuku" jobs fail: https://gitlab.com/hatsya/open-source/catagolue/-/jobs

[Vort]

There is currently a huge overload on Catagolue's readsynth queue. It caused the last two updates of the synthesis database to fail...

Overloads usually cause timeouts, not fails.
Commit 795d93e7 lowered load, but queue is still clogged: "HTTP Error 500: Internal Server Error".

[Chris857]

I mentioned this on Discord a few days ago but will repeat it here:

I found a few patterns where there's an intermediate step that's cheaper, but the final pattern shows a more expensive step for some reason. This happened for a couple spaceships and oscillators even where I submitted something recently that should have lowered the cost.

• xq4_y258880638gszwu1w32gkoz34j0ozx11 claims to cost 68G and shows the intermediate xp2_o8y62c34z012462461tazw8ak4y0113 as costing 12G over the still life, but that particular page shows it costing only 8G over the still life to add the clocks

• xq4_y0gmdxsg8zsg4knfzwg01f6zw321 claims to cost 51G and shows the intermediate xp2_06a8o0o4a952zy1hhowca23gg8z653032y5211 as costing 6G to add the clock, but that particular page shows it costing only 4G

• 6 David Hilbert variants have syntheses at https://catagolue.hatsya.com/census/b3s ... costs/xp23, three costing 91G and three 96G, but they all start with xs32_ydo8b9czyg356zo8gz0d5k46zw11 which costs 12G in one step, but the expensive synths show it as 17G in five steps, despite being the exact same pair of still lifes

Got another one - https://gitlab.com/hatsya/open-source/c ... 8167320431 shows that xp2_696o8bbgz065w2521xgg8zy9211 now costs 19G, while xp30_y1ca23zz1fuiuf1zy38k2s3z43c2y1h030ggy131e8zy325a98ci9gzy533w121 shows that intermediate costing 33G with the old steps.

Should drop the cost of xp30_y1ca23zz1fuiuf1zy38k2s3z43c2y1h030ggy131e8zy325a98ci9gzy533w121 to only 31G.

Code: Select all

x = 26, y = 34, rule = B3/S23
23bo$17bo5bobo$16bo6b2o$16b3o21$5bo$4bobo$2obobobo11b2o$2obo2bo11b2o$
3bo16bo$3b2o$b2o2bobo$o2bo2b2o14b2o$b2o18b2o$23bo!

Edit: xp2_y42c34zgg0g8k8gyg31e8zh98n48hoz011zy4c453 is the first step in the most recent one which did not update correctly, and it does not appear when doing a search in https://gitlab.com/parclytaxel/Shinjuku ... njuku/comp (earlier steps do show up in a search).

Edit2: resubmitting the later (existing) steps of the synth seems to have corrected the p30 to use the new cheaper intermediary. Edit3: doing so for the others has forced them to update, but it's weird that I thought I had maybe done that in the past and it hadn't worked.

[CARuler]

is this from a time when RLEs were read differently?
https://catagolue.hatsya.com/object/yl6 ... ef3d/b3s23
edit:
also, shouldn't there be a separate part for searches using ikpx, qfind, cfind, etc?

[confocaloid]

is this from a time when RLEs were read differently?
https://catagolue.hatsya.com/object/yl6 ... ef3d/b3s23

Do you mean the "sample soups" failing to produce an infinite growth, or something else?

Also, there is an existing forum thread:
viewtopic.php?f=7&t=2224 "Catagolue Oddities"

[LaundryPizza03]

Soups containing the 3c/12d spaceships in b2-a3acers123ceikn/C1 seem to be repeatedly misreported as zz_EXPLOSIVE.

Code: Select all

x = 16, y = 16, rule = B2-a3acer/S123ceikn
obobbbobooobbobb$
ooobbbobooboooob$
bbooobbbobobobob$
oooooobobooooboo$
oooobobooobobobb$
obbbbobbooobbobb$
bobboboobobooobo$
obooooobbbbbobob$
obbbbobbbboobobo$
bboobobbboboboob$
oboooooobbbbbbbb$
ooboobobobbobbob$
boobbbooooobbooo$
bbbobooboobbobbo$
boobbbobbobbobbb$
ooooobobbboobooo!

[pifricted]

What happend?

[b-engine]

What happend?

This is the exact link shown in second image:
xp4_69b88cikb73zw6513
It might be a problem related to region; implied by the display language you might be in mainland China.

I could open the link without any problem:

Screenshot_20241221_201137_com.android.chrome.jpg (507.92 KiB) Viewed 3213 times

I'm located in Southeast Asia, and no website is unopenable there due to regional problems.

[Vort]

What happend?

Looks like MitM.

Do you want to share TLS certificate you see?
Here is what my browser shows:

Code: Select all

-----BEGIN CERTIFICATE-----
MIIFNDCCBBygAwIBAgIQQ2iucKgqhokSffSbfo7cvDANBgkqhkiG9w0BAQsFADA7
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMQww
CgYDVQQDEwNXUjMwHhcNMjQxMTAxMDkxNzIwWhcNMjUwMTMwMTAwODMyWjAfMR0w
GwYDVQQDExRjYXRhZ29sdWUuaGF0c3lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAOOep4UFzzOYbrfwSZvEl9hSGMKf9Jz9v11UTLrCxfDnp9j9
ZisydGYwSTOIA23XHzYcsX1o1OoWiHd9oLHwMywZxl+ZFZYhECoJWiJxTiPviGN5
bbg3wdONxTx+hsa5BeWEX7WpnOUXXEFx3EdTLDZfaWTitRBPBIQK00XD7peN5m7+
wBWkzqhHlq4B3n84C3ZBRbK2VHg9tFe9dgncMNAcmi8BEiaP+2iTNEOR4hbvZ9EZ
2+ja2f54fqCVGWrjsbRRFEdMCte4+J6IzR4/M4v/Puys6H9Jt57+/nIp9t8xT7XJ
/nhdcNSsD6IdKFtzkGK2UaAzzMAFXE0IashTDPUCAwEAAaOCAk4wggJKMA4GA1Ud
DwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0G
A1UdDgQWBBRHxNm2+S2UG5+p4Hv3VcmhO3djTzAfBgNVHSMEGDAWgBTHgfX9jojZ
ADxNY6JQMSSgziP+IzBeBggrBgEFBQcBAQRSMFAwJwYIKwYBBQUHMAGGG2h0dHA6
Ly9vLnBraS5nb29nL3Mvd3IzL1EyZzAlBggrBgEFBQcwAoYZaHR0cDovL2kucGtp
Lmdvb2cvd3IzLmNydDAfBgNVHREEGDAWghRjYXRhZ29sdWUuaGF0c3lhLmNvbTAT
BgNVHSAEDDAKMAgGBmeBDAECATA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vYy5w
a2kuZ29vZy93cjMvelpNSzd2aktKUk0uY3JsMIIBBQYKKwYBBAHWeQIEAgSB9gSB
8wDxAHcAzxFW7tUufK/zh1vZaS6b6RpxZ0qwF+ysAdJbd87MOwgAAAGS5zrDTQAA
BAMASDBGAiEAiQZxgrOgRk9IUOVcvEhq0C5Dmy0IQ21G2M+MbYagLJkCIQCrzfbk
u54QL3SJcQIzqNsw7hfR+zt4HaBtbZ+ooP0HfQB2AObSMWNAd4zBEEEG13G5zsHS
QPaWhIb7uocyHf0eN45QAAABkuc6wzAAAAQDAEcwRQIgW+MzoJOW1RUiprSLFbke
O/sTF2m1GfzUMKwWd14rMEcCIQDJmxFQewv+0ejCr/ygfpWp9YPtHK4JB+F0VxBI
u5l2MTANBgkqhkiG9w0BAQsFAAOCAQEAeAwpL8gwONn3tg/I4hzyJWLJilZvD0e/
Iip8nsGJGHXf4ljsCjuIRMISH1/EqUDQFeVIxXCgBZfhk0VzFa4PnQsRPrti4qet
cRUrdQ3RFnvufDNPsani7UtoaRh73Ydo8ZK9sWSxCy55IFGv5RQWu2LBl8Z2cp1t
m++1lNvOy7fm//6elX8Ohnm6SnDe7lAkONDMQfCqIIqfjjIs7aGQO8BQgGGUV4Al
vJCaH9sHfv+XOBFVEt/oV51akcvpnLIr11E5iV1jnIoxKxVsJDI/xfXaLSpSQ8Zq
/JyQmeYRmFb3N7xMPba0+zZ3IDwftBusSYH2UV01uF5J0FZWZCj3qA==
-----END CERTIFICATE-----

[confocaloid]

edit 2025-01-06: I believe the links in the snippet below are all those logs that "failed" due to this issue. The error appears to be resolved. The previously submitted syntheses seem to be processed in #8771748798.
edit 2025-01-02: apparently the error described below stuck, and the recent logs all end with the same error message: https://gitlab.com/hatsya/open-source/catagolue/-/jobs
edit 2025-01-03: even though the error persists, a glider gun submission got processed (gun_2025) in https://gitlab.com/hatsya/open-source/c ... 8759506277

Code: Select all

https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8771720944
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8771624070
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8771303211
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8770909930
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8770512016
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8770091070
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8769702143
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8769328988
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8768965525
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8768558938
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8767764375
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8767230792
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8766263679
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8764790951
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8763033523
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8761515752
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8760414892
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8759506277
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8758391786
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8756880571
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8755040246
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8753535839
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8752779160
https://gitlab.com/hatsya/open-source/catagolue/-/jobs/8752252912

--------

Code: Select all

x = 115, y = 32, rule = B3/S23
114bo$112b2o$113b2o$89bo$90bo$88b3o$13bo$11b2o$12b2o14$98b2o9b3o$98b2o
3$4b3o$4bo79bo$5bo78b2o$2o81bobo$b2o$o!

Submitting the above glider synthesis of xq4_g0g265z13 (which is displayed as unsynthed as of the time of this post) apparently triggered an interesting error. The error message mentions "determine_if_gun" / "idgun.py".
See the linked log: https://gitlab.com/hatsya/open-source/c ... 8752252912

Code: Select all

2 can be updated
Updating 2 apgcodes: ['xp15_4r4z4r4', 'xq4_g0g265z13']
Written apgcodes

Greetings, this is apgluxe v5.43-ll2.5.8, configured for b3s23/stdin.

Lifelib version: ll2.5.8
Compiler version: 12.2.0
Python version: '3.8.20 (default, Sep 27 2024, 06:05:08)  [GCC 12.2.0]'

Using seed k_j5NXpyGTrr6b
Instruction set AVX2 detected
Running 10000000 soups per haul:
b3s23/stdin: 2 soups completed (125.000 soups/second current, 125.000 overall).
----------------------------------------------------------------------
2 soups completed.
14978 tiles processed.
Attempting to contact Catagolue...
Saving results to log.1735777770.k_j5NXpyGTrr6b.txt
Connection was successful.
New seed: k_LARF4W5gVTvB; iterations = 1; quitByUser = 1
Terminating...
Log file: log.1735777770.k_j5NXpyGTrr6b.txt
2 objects are true.
Performing consistency check...
Instruction set AVX2 detected
Checking 3 components...
Creating payload...
Traceback (most recent call last):
  File "diffupdate.py", line 273, in <module>
    main()
  File "diffupdate.py", line 229, in main
    N, pat = lookup_synth(min_paths, apgcode)
  File "/builds/hatsya/open-source/catagolue/initialise/shinjuku/search.py", line 181, in lookup_synth
    res = slock(lines[::-1], gnf=gnf)
  File "/builds/hatsya/open-source/catagolue/initialise/shinjuku/search.py", line 104, in slock
    p, start = cycle_detect(stage)
  File "/builds/hatsya/open-source/catagolue/initialise/shinjuku/search.py", line 72, in cycle_detect
    dct = f(2 ** expo - 1)
  File "/builds/hatsya/open-source/catagolue/initialise/shinjuku/search.py", line 70, in <lambda>
    f = lambda n: pat[n].oscar(eventual_oscillator=False, verbose=False, maxexp=20)
  File "/root/.local/lib/python3.8/site-packages/lifelib/pythlib/pattern.py", line 513, in oscar
    rv = determine_if_gun(self, maxexp)
  File "/root/.local/lib/python3.8/site-packages/lifelib/pythlib/idgun.py", line 53, in determine_if_gun
    if (len(r) != 4):
TypeError: object of type 'NoneType' has no len()

[Chris857]

This morning, catagolue does not appear to be loading its life viewers - on either my phone or laptop. The viewers here on the forum and wiki are loading just fine.

[get_Snacked]

i've been having the same problem.

[Chris857]

Seems to be working now.

[get_Snacked]

xs28_c4o0e93zg5t079cz11 is identified as pseudo (check the RLE for the glider synthesis) yet still has occurrences in C1 and C2_1. did the way for checking pseudo-SLs change midway in that it used to be identified as strict but is now a pseudo-SL? or is this just still being counted as strict in soups yet pseudo in glider syntheses?

[confocaloid]

xs28_c4o0e93zg5t079cz11 is identified as pseudo (check the RLE for the glider synthesis) yet still has occurrences in C1 and C2_1. did the way for checking pseudo-SLs change midway in that it used to be identified as strict but is now a pseudo-SL? or is this just still being counted as strict in soups yet pseudo in glider syntheses?

There are also occurrences from soups in b38s23, in b38s238 (three C2_1 occurrences from 2016-10 by 'Apple Bottom'), and possibly for some other CA where the same still-life exists.

Here is a predecessor from a soup:

Code: Select all

x = 11, y = 9, rule = B3/S23
5bobo$2o3bobo$obo2b3o$bo2$9bo$3b3o2bobo$3bobo3b2o$3bobo!

I tried to feed that RLE into apgluxe compiled for b3s23/stdin_test and the program reported two instances of xs14_g4s079cz11 (instead of one 28-bitter). It looks likely that there was a change in apgluxe at some point in the past, changing how the program "understands" the strict/pseudo distinction (and the visible soups were submitted before that change). Trimmed output below:

Code: Select all

# ./recompile.sh --rule b3s23 --symmetry stdin_test
Success!
# cat input.txt
x = 11, y = 9, rule = B3/S23
5bobo$2o3bobo$obo2b3o$bo2$9bo$3b3o2bobo$3bobo3b2o$3bobo!

# ./apgluxe -t 1 -L 1 -n 10000 -i 1 < input.txt
# cat log.*.txt
testing
@VERSION v5.43-ll2.5.9
@RULE b3s23
@SYMMETRY stdin_test

@CENSUS TABLE
xs14_g4s079cz11 2