ConwayLife.com

Is there any way to change the name that is displayed as your username on Catagolue?

Yes, by re-registering your payosha256. However, that would erase all of your progress (i.e. pie chart sectors) and discoveries.

testitemqlstudop wrote:Yes, by re-registering your payosha256. However, that would erase all of your progress (i.e. pie chart sectors) and discoveries.

I don't think he has any yet, so it's okay, I think.

Hdjensofjfnen wrote:

testitemqlstudop wrote:Yes, by re-registering your payosha256. However, that would erase all of your progress (i.e. pie chart sectors) and discoveries.

I don't think he has any yet, so it's okay, I think.

I do.

Moosey wrote:

Hdjensofjfnen wrote:

testitemqlstudop wrote:Yes, by re-registering your payosha256. However, that would erase all of your progress (i.e. pie chart sectors) and discoveries.

I don't think he has any yet, so it's okay, I think.

I do.

Yikes. Maybe Adam P. Goucher has magical powers.
EDIT: How would I go about installing apgluxe (not the precompiled version)?

Hdjensofjfnen wrote:EDIT: How would I go about installing apgluxe (not the precompiled version)?

Tutorial, tutorial, here is a tutorial... ♫

Someone PLEASE, PLEASE mark "heavgolue" a troll symmetry.

Several symmetries in B3/S23 (D8_1 and D8_4 in particular) are primarily/solely being searched by carybe and seem to have a large backlog of unverified hauls. I'm doing a verification run for D8_4 at the moment, but that's really only a stop gap. From my understanding of how verification rules work I'm not sure how the census got into this state.
Edit: Most of the C2, C4, D2, and D4 symmetries are in a similar state. I have done verification runs for D8_4, D8_1. Doing the same for D4 now and may get to some of the others later.

====

I think I incorrectly remembered the current rules - is it that self-verifications are allowed when the backlog reaches 50 hauls? If this is the case then I guess with only one person searching, things are at an equilibrium - and will return there fairly quickly if no one else is searching those symmetries.

Is gol.hatsya.co.uk connectable from China? I have a 40M haul to D2_x because EVERY SINGLE TIME it won't connect to either of gol.hatsya.co.uk or catagolue.appspot.com.

testitemqlstudop wrote:Is gol.hatsya.co.uk connectable from China?

It seems to be, yes. Try it for yourself: https://gol.hatsya.co.uk/home

I have a 40M haul to D2_x because EVERY SINGLE TIME it won't connect to either of gol.hatsya.co.uk or catagolue.appspot.com.

There's a 50M haul here, so it looks like it succeeded eventually...? https://gol.hatsya.co.uk/haul/b3s23/D2_x

Ah yes, it's fixed now.
It's just that for some reason there are these "temporary outages" in which several weird things happen at once:

1. my browser vpn stops working;
2. I can't reach gol.hatsya.co.uk from my browser;
3. neither can apgluxe reach gol.hatsya.co.uk;
4. but my WiFi is OK, since I can still visit China websites;

(yeah it's been 10 days since I moved from the US to China, and I HATE the great firewall )

It seems to be OK for now.
Also, can I host a mirror of catagolue that also has all the census data? (Running "./update-catagolue.sh" didn't work...)

testitemqlstudop wrote:It seems to be OK for now.
Also, can I host a mirror of catagolue that also has all the census data?

Not really, because there's many tens of gigabytes of data in Catagolue's datastore, and no easy way to extract it. (The gol.hatsya.co.uk 'mirror' is really just the same Catagolue masquerading under a different URL, rather than an actual mirror.)

If there's a particular rule you want to search locally, then run-catagolue-locally.sh will give you an empty Catagolue running on your own computer (which persists any census data to your hard disk).

(Running "./update-catagolue.sh" didn't work...)

That's by design: it would be very dangerous if someone could simply download the source code, edit it, and run that script to change the live Catagolue. At the moment that script only works in the GitLab continuous integration, where there's a secret environment variable containing an API key.

testitemqlstudop wrote:Ah yes, it's fixed now.
It's just that for some reason there are these "temporary outages" in which several weird things happen at once:

1. my browser vpn stops working;
2. I can't reach gol.hatsya.co.uk from my browser;
3. neither can apgluxe reach gol.hatsya.co.uk;
4. but my WiFi is OK, since I can still visit China websites;

(yeah it's been 10 days since I moved from the US to China, and I HATE the great firewall )

It seems to be OK for now.
Also, can I host a mirror of catagolue that also has all the census data? (Running "./update-catagolue.sh" didn't work...)

Some IP addresses of gol.hatsya.co.uk are blocked in China. You can ping it to find out which IPs are not blocked, and then edit your hosts file.

The version of LifeViewer used on Catagolue is quite outdated (build 301, while build 321 is current). There's also a built-in Catagolue theme, which can be used instead of setting a custom theme (and also has built-in colours ready for Generations).

muzik wrote:The version of LifeViewer used on Catagolue is quite outdated (build 301, while build 321 is current).

Thanks; updated in commit 0e525fc8.

There's also a built-in Catagolue theme, which can be used instead of setting a custom theme (and also has built-in colours ready for Generations).

Changed in commit 8baddef1. (Can I be sure that [[ THEME 14 ]] will always be this Catagolue theme, and won't change in a future build of LifeViewer?)

calcyman wrote:

There's also a built-in Catagolue theme, which can be used instead of setting a custom theme (and also has built-in colours ready for Generations).

Changed in commit 8baddef1. (Can I be sure that [[ THEME 14 ]] will always be this Catagolue theme, and won't change in a future build of LifeViewer?)

It should be, but it might be a wiser idea to use the namespaced [[ THEME Catagolue ]] just in case.

muzik wrote:

calcyman wrote:

There's also a built-in Catagolue theme, which can be used instead of setting a custom theme (and also has built-in colours ready for Generations).

Changed in commit 8baddef1. (Can I be sure that [[ THEME 14 ]] will always be this Catagolue theme, and won't change in a future build of LifeViewer?)

It should be, but it might be a wiser idea to use the namespaced [[ THEME Catagolue ]] just in case.

I didn't realise that was possible -- thanks!

G and H symmetries are listed as official symmetries on object pages, but unofficial on rule pages.

muzik wrote:G and H symmetries are listed as official symmetries on object pages, but unofficial on rule pages.

On a similar note, with G1 being an official symmetry directly corresponding to C1: Do objects found in G1 count towards the statistics for the b3s23/C1 census?. E.g., this 27 bit still life has appeared in a G1 soup, but not yet in C1:
https://catagolue.appspot.com/object/xs ... 2qic/b3s23

Additionally, do "discoveries" in G1 count towards discoveries listed on User pages?

I've just noticed that I accidentally uploaded some hauls with a version of apgluxe where I had tweaked the maxgen value. These hauls were run with maxgen for the GPU preprocessor set to 4500 in place of 12000 (objects/soup = 0.263 in place of 0.192):

https://catagolue.appspot.com/haul/b3s2 ... 0a43430c0c
https://catagolue.appspot.com/haul/b3s2 ... 32245e872b
https://catagolue.appspot.com/haul/b3s2 ... b54d145cdb

I don't think this is a big issue for the H4_+2 census, certainly less than the CPU searcher soups which went into G1, but I thought I should mention it in case it aroused suspicion.

Edit: Oops, those small hauls by anonymous are also due to me mistakenly submitting hauls whilst testing the effect of maxgen on the GPU preprocessor.

====

Is it possible for users to determine why hauls were rejected? There seems to continue to be sporadic rejection of hauls in most of the official symmetries for B3/S23. Most often this seems to be occurring when hauls are being verified by different versions of apgsearch, e.g. v4.9X - v5.0XX and v3.28 vs v4.9X. In some cases though, hauls are being rejected by the same instance that submitted them, e.g. some of carybe's hauls in b3s23/D8_4 and these hauls in b3s2/C1. It's probably not a big problem for the censuses as a whole because only a very small fraction of hauls are affected, but it would be good to know what's happening. If the individual pages for these rejected hauls displayed a more useful message than "The integrity of this haul was verified by <user>.", that would clarify the situation.

More broadly, it seems that this verification system (at least the user based soup verification part) is not doing much outside of the main C1 census. For quite some time until recently, carybe has been the only user submitting hauls to most of the non-C1 symmetries. I've recently set up a process to do verification runs which cycles through the non-C1 symmetries, just to keep the length of the verification queues down and keep the censuses a liitle more up to date. Incidentally, those rejected 1 soup hauls submitted by me originated from the testing phase of this process.

I though Catagolue had duplicate haul detection? (resubmitting schick engine haul)

http://gol.hatsya.co.uk/haul/b3s23/C1/d ... 3708fba462

testitemqlstudop wrote:I though Catagolue had duplicate haul detection? (resubmitting schick engine haul)

http://gol.hatsya.co.uk/haul/b3s23/C1/d ... 3708fba462

Come to think about it, someone could fake a haul with the impossible seed 'l_YemQ9b3PrYV9288' and get the Schick engine within 30k soups. Hopefully nobody does that though.

testitemqlstudop wrote:I though Catagolue had duplicate haul detection? (resubmitting schick engine haul)

http://gol.hatsya.co.uk/haul/b3s23/C1/d ... 3708fba462

Ouch. It does check for duplicate hauls, but it doesn't check for proper prefixes/suffixes.

I've now modified Catagolue to only accepts seed roots of length 12, 14, or 48, where (length != 14) XOR (second character is an underscore). Moreover, Parmenides only allows up to 30 digits after the root, so you can't get a collision between a length-12 and a length-48 root to pass verification both times.

The rationale for 12, 14, and 48 is that the Python versions used 12 characters, the C++ versions used 14 characters, and the cryptocurrency will use 48 characters.

b3s23/C1 has reached 400 trillion objects!

Is there any way of determining who it was that contributed the 400 trillionth object?