Page 5 of 22

Re: apgsearch v4.0

Posted: September 2nd, 2017, 4:26 pm
by drc
A for awesome wrote:
muzik wrote:I would quite like an inflated 1x256 symmetry at the very least.
Inflated 1x256 is worthless. You can get the same results just by running all 2x(2n) solid blocks of cells from n=1–256, which can be achieved using a simple script.
Not for rules with B4i, or rules that don't abide by the 2x2 block rule (e.g. Life)

Re: apgsearch v4.0

Posted: September 2nd, 2017, 4:27 pm
by muzik
...which, in turn, could make searching for that c/5648 ship slightly more possible.

Re: apgsearch v4.0

Posted: September 2nd, 2017, 4:34 pm
by Apple Bottom
drc wrote:
A for awesome wrote:
muzik wrote:I would quite like an inflated 1x256 symmetry at the very least.
Inflated 1x256 is worthless. You can get the same results just by running all 2x(2n) solid blocks of cells from n=1–256, which can be achieved using a simple script.
Not for rules with B4i, or rules that don't abide by the 2x2 block rule (e.g. Life)
What I think Aidan was getting at is that inflated 1x256 soups are composed of just 2x(2n) solid blocks of cells, spaced at least two cells apart, and that none of these blocks will interact with its neighbors over the course of its evolution -- at least in Conway Life. (If I'm not mistaken.)

So for CGoL, inflating 1x256 is indeed not interesting.

Re: apgsearch v4.0

Posted: September 2nd, 2017, 4:36 pm
by drc
Apple Bottom wrote:So for CGoL, inflating 1x256 is indeed not interesting.
Oh, I see. I thought it was only stretched in one dimension, which would just make a D2_+2 symmetric 2x256 soup. My mistake ^^;

Re: apgsearch v4.0

Posted: September 2nd, 2017, 6:00 pm
by praosylen
Apple Bottom wrote:What I think Aidan was getting at is that inflated 1x256 soups are composed of just 2x(2n) solid blocks of cells, spaced at least two cells apart, and that none of these blocks will interact with its neighbors over the course of its evolution -- at least in Conway Life. (If I'm not mistaken.)

So for CGoL, inflating 1x256 is indeed not interesting.
No, I was wrong. I didn't think about it being used for anything other than actual 2x2 block rules — and it's not trivial in CGoL, either:

Code: Select all

x = 114, y = 2, rule = B3/S23
22o2b20o2b22o2b20o2b22o$22o2b20o2b22o2b20o2b22o!

Re: apgsearch v4.0

Posted: September 2nd, 2017, 6:46 pm
by calcyman
v4.15 now allows inflating arbitrary symmetries; for example:

Code: Select all

./recompile.sh --rule b3s23 --symmetry iC1
for an inflated version of C1. The 'inflate' operator is composable, so you can make 8-by-8 blocks using iiiC1.

Re: apgsearch v4.0

Posted: September 2nd, 2017, 7:07 pm
by Rocknlol
It looks like the catagolue website is returning soups from inflated symmetries as though they were uninflated.

Re: apgsearch v4.0

Posted: September 4th, 2017, 3:39 pm
by Rhombic
Rocknlol wrote:It looks like the catagolue website is returning soups from inflated symmetries as though they were uninflated.
Not only that, this is meant to be iD8_1 and it's not even D8:
https://catagolue.appspot.com/hashsoup/ ... 2647/b3s23

Re: apgsearch v4.0

Posted: September 4th, 2017, 3:41 pm
by muzik
I'd assume this is down to the reason catagolue isn't accepting these symmetries as official.

Re: apgsearch v4.0

Posted: September 4th, 2017, 4:43 pm
by Apple Bottom
Rhombic wrote:Not only that, this is meant to be iD8_1 and it's not even D8:
https://catagolue.appspot.com/hashsoup/ ... 2647/b3s23
Catagolue returns all soups as 16x16 C1 soups if it doesn't know how to generate them properly (i.e. if it doesn't recognize their associated symmetry string). As far as the site is concerned (right now at the very least), "iD8_1" and "D8_1" are entirely unrelated, so there's no reason why a D8_1 soup should be shown there.

Re: apgsearch v4.0

Posted: September 4th, 2017, 7:10 pm
by Saka
Apple Bottom wrote:soups as 16x16 C1 soups if it doesn't know how to generate them properly (i.e. if it doesn't recognize their associated symmetry string).
Just like Saka_Test, if you click on the soup from a haul of one of the "arranged" patterns like the xq3s and xq5s, it will return a C1 soup. Another thing is that if you go to the spaceship's page, it says there are no soups stored.

Re: apgsearch v4.0

Posted: September 5th, 2017, 5:28 am
by Apple Bottom
Saka wrote:Another thing is that if you go to the spaceship's page, it says there are no soups stored.
Catagolue doesn't store sample soups for sufficiently common objects. And those spaceships were very common in those hauls. ;)

Re: apgsearch v4.0

Posted: September 5th, 2017, 6:11 am
by Saka
Apple Bottom wrote:
Catagolue doesn't store sample soups for sufficiently common objects. And those spaceships were very common in those hauls. ;)
Ah, of course! It shows Saka_Test on xp-2 and xp-3 as a peach-colored dot. We shouldn't be talking about that here, though.

Back on topic, how is apgluxe-nt going?

Re: apgsearch v4.0

Posted: September 5th, 2017, 3:55 pm
by muzik
Silly impractical suggestion I've been thinking about:

Since we can do multiple iterations of the "inflate" command to soups, why not also treat the existing symmetries as commands as well?

For example, here's a "D4_+2 C4_4" soup:

Code: Select all

x = 64, y = 64, rule = B3/S23
3bo2b2o2b2o2bo4b5obob4o2b4obob5o4bo2b2o2b2o2bo$2o2b3obob2o2b3ob4o6b3o
2b3o6b4ob3o2b2obob3o2b2o$2ob5o5bob6o2b3ob2o6b2ob3o2b6obo5b5ob2o$5o2bob
ob2ob2ob2ob3o2bob3ob2ob3obo2b3ob2ob2ob2obobo2b5o$ob2ob3o2bob6o6bobob3o
2b3obobo6b6obo2b3ob2obo$4b3ob2obobo2b4ob4ob2ob2o2b2ob2ob4ob4o2bobob2ob
3o$ob2o2bo2bo3b3obobobo2b4ob6ob4o2bobobob3o3bo2bo2b2obo$2bob3obo3bobo
2b2obobo4b3ob2ob3o4bobob2o2bobo3bob3obo$obo2bo2b8ob2ob2ob2obo3bo2bo3bo
b2ob2ob2ob8o2bo2bobo$o2bobobo3bobob2ob4obob2obo6bob2obob4ob2obobo3bobo
bo2bo$2obob2ob2obo2bobo6bo3bo2b4o2bo3bo6bobo2bob2ob2obob2o$4o3b3ob2o3b
8o2bobob4obobo2b8o3b2ob3o3b4o$3o2b2o2bob5obob2o2b2o2b2o6b2o2b2o2b2obob
5obo2b2o2b3o$b3obob3obo2bobo2bo2b2ob3obo4bob3ob2o2bo2bobo2bob3obob3o$
2b7o2b2o2bo2b2obob3ob2ob4ob2ob3obob2o2bo2b2o2b7o$b2ob2o3b3obo3bobo2b2o
bob4o2b4obob2o2bobo3bob3o3b2ob2o$b4obob2o2bobo3bob3o3b2ob2o2b2ob2o3b3o
bo3bobo2b2obob4o$2ob2ob3obob2o2bo2b2o2b7o4b7o2b2o2bo2b2obob3ob2ob2o$2b
ob3ob2o2bo2bobo2bob3obob3o2b3obob3obo2bobo2bo2b2ob3obo$3b2o2b2o2b2obob
5obo2b2o2b6o2b2o2bob5obob2o2b2o2b2o$2obobo2b8o3b2ob3o3b8o3b3ob2o3b8o2b
obob2o$2o2bo3bo6bobo2bob2ob2obob4obob2ob2obo2bobo6bo3bo2b2o$3bob2obob
4ob2obobo3bobobo2b2o2bobobo3bobob2ob4obob2obo$bo3bob2ob2ob2ob8o2bo2bob
2obo2bo2b8ob2ob2ob2obo3bo$ob3o4bobob2o2bobo3bob3obo4bob3obo3bobo2b2obo
bo4b3obo$3ob4o2bobobob3o3bo2bo2b2ob2ob2o2bo2bo3b3obobobo2b4ob3o$b2ob2o
b4ob4o2bobob2ob3o8b3ob2obobo2b4ob4ob2ob2o$b3obobo6b6obo2b3ob2ob2ob2ob
3o2bob6o6bobob3o$ob3obo2b3ob2ob2ob2obobo2b10o2bobob2ob2ob2ob3o2bob3obo
$3b2ob3o2b6obo5b5ob4ob5o5bob6o2b3ob2o$b3o6b4ob3o2b2obob3o2b4o2b3obob2o
2b3ob4o6b3o$b4obob5o4bo2b2o2b2o2bo6bo2b2o2b2o2bo4b5obob4o$b4obob5o4bo
2b2o2b2o2bo6bo2b2o2b2o2bo4b5obob4o$b3o6b4ob3o2b2obob3o2b4o2b3obob2o2b
3ob4o6b3o$3b2ob3o2b6obo5b5ob4ob5o5bob6o2b3ob2o$ob3obo2b3ob2ob2ob2obobo
2b10o2bobob2ob2ob2ob3o2bob3obo$b3obobo6b6obo2b3ob2ob2ob2ob3o2bob6o6bob
ob3o$b2ob2ob4ob4o2bobob2ob3o8b3ob2obobo2b4ob4ob2ob2o$3ob4o2bobobob3o3b
o2bo2b2ob2ob2o2bo2bo3b3obobobo2b4ob3o$ob3o4bobob2o2bobo3bob3obo4bob3ob
o3bobo2b2obobo4b3obo$bo3bob2ob2ob2ob8o2bo2bob2obo2bo2b8ob2ob2ob2obo3bo
$3bob2obob4ob2obobo3bobobo2b2o2bobobo3bobob2ob4obob2obo$2o2bo3bo6bobo
2bob2ob2obob4obob2ob2obo2bobo6bo3bo2b2o$2obobo2b8o3b2ob3o3b8o3b3ob2o3b
8o2bobob2o$3b2o2b2o2b2obob5obo2b2o2b6o2b2o2bob5obob2o2b2o2b2o$2bob3ob
2o2bo2bobo2bob3obob3o2b3obob3obo2bobo2bo2b2ob3obo$2ob2ob3obob2o2bo2b2o
2b7o4b7o2b2o2bo2b2obob3ob2ob2o$b4obob2o2bobo3bob3o3b2ob2o2b2ob2o3b3obo
3bobo2b2obob4o$b2ob2o3b3obo3bobo2b2obob4o2b4obob2o2bobo3bob3o3b2ob2o$
2b7o2b2o2bo2b2obob3ob2ob4ob2ob3obob2o2bo2b2o2b7o$b3obob3obo2bobo2bo2b
2ob3obo4bob3ob2o2bo2bobo2bob3obob3o$3o2b2o2bob5obob2o2b2o2b2o6b2o2b2o
2b2obob5obo2b2o2b3o$4o3b3ob2o3b8o2bobob4obobo2b8o3b2ob3o3b4o$2obob2ob
2obo2bobo6bo3bo2b4o2bo3bo6bobo2bob2ob2obob2o$o2bobobo3bobob2ob4obob2ob
o6bob2obob4ob2obobo3bobobo2bo$obo2bo2b8ob2ob2ob2obo3bo2bo3bob2ob2ob2ob
8o2bo2bobo$2bob3obo3bobo2b2obobo4b3ob2ob3o4bobob2o2bobo3bob3obo$ob2o2b
o2bo3b3obobobo2b4ob6ob4o2bobobob3o3bo2bo2b2obo$4b3ob2obobo2b4ob4ob2ob
2o2b2ob2ob4ob4o2bobob2ob3o$ob2ob3o2bob6o6bobob3o2b3obobo6b6obo2b3ob2ob
o$5o2bobob2ob2ob2ob3o2bob3ob2ob3obo2b3ob2ob2ob2obobo2b5o$2ob5o5bob6o2b
3ob2o6b2ob3o2b6obo5b5ob2o$2o2b3obob2o2b3ob4o6b3o2b3o6b4ob3o2b2obob3o2b
2o$3bo2b2o2b2o2bo4b5obob4o2b4obob5o4bo2b2o2b2o2bo!

Re: apgsearch v4.0

Posted: September 5th, 2017, 3:58 pm
by drc
muzik wrote:Since we can do multiple iterations of the "inflate" command to soups, why not also treat the existing symmetries as commands as well?
I would suggest slowing down on the requests, calcyman has a lot of suggestions and he's trying to code the non-totalistic section of apgluxe

Re: apgsearch v4.0

Posted: September 6th, 2017, 12:38 am
by hedgepiggy
drc wrote:I would suggest slowing down on the requests, calcyman has a lot of suggestions and he's trying to code the non-totalistic section of apgluxe
So I take it that requesting the ability to quit midhaul when using parallel threads would not be well received?

Re: apgsearch v4.0

Posted: September 6th, 2017, 12:39 am
by drc
hedgepiggy wrote:So I take it that requesting the ability to quit midhaul when using parallel threads would not be well received?
I was simply implying that muzik was making a lot of requests, no hard feelings whatsoever

Re: apgsearch v4.0

Posted: September 6th, 2017, 6:54 am
by Apple Bottom
muzik wrote:Silly impractical suggestion I've been thinking about:

Since we can do multiple iterations of the "inflate" command to soups, why not also treat the existing symmetries as commands as well?
drc wrote:I would suggest slowing down on the requests, calcyman has a lot of suggestions and he's trying to code the non-totalistic section of apgluxe
I like the idea, though.

In fact, taking this a bit further, symmetry types could be turned into a string of commands executed by a simple stack machine to generate the soup in question. Some commands would generate soups of specific sizes, and put them on the stack; others would pop one or more soups off the stack, apply some transformation, and put the result back on. At the end of the process, the topmost soup on the stack would be fed to the searcher proper.

Have each command represented by a single character, and parse the entire symmetry type right-to-left. i already stands for 2x2 inflation. Use 1, 2, 4, 8, 6 to generate soups of size 1x256, 2x128, 4x64, 8x32 and 16x16 respectively. Use a and o for "and" and "or" of two soups, respectively. Use t and w ("turnwise" and "widdershins") to rotate a soup clockwise/counter-clockwise by 90°. Use d ("duplicate") to duplicate the topmost soup on the stack. Use x for the D2_x transformation (clear all cells in the soup where x < y, then mirror the remaining half of the soup along the x=y axis). Use h and v for regular horizontal and vertical mirroring. And so on.

This would allow you to express a fairly large number of soups already "6" is equivalent to C1. "awwd6" would be equivalent to C2_4: generate a 16x16 soup, duplicate it, rotate the first copy by 180°, merge the two results, and so on.

The devil's in the details, of course; you'd want to be able to specify around which point to rotate soups and along which axis to mirror them. You might want to generate soups of different sizes. So maybe the stack should hold both soups and (natural) numbers; instead of 1,2,4,8,6 you'd have a "generate soup" command, and any sequence of numbers in the input string would be treated as a natural number, with the comma acting as a number separator. C1 would then be "g16,16". C2_4 might instead be ac0,0c0,0dg16,16, while ac8,8dg16,16 would yield a 25% density 16x16 soup. Of course the whole thing would lose some of its elegance then...

None of this is likely to ever be implemented (in any form), but it's fun to think about.
hedgepiggy wrote:So I take it that requesting the ability to quit midhaul when using parallel threads would not be well received?
That's a good idea, actually. The only reason I didn't do this in the patch that Calcyman merged is that I'm not using OpenMP-based searching, and have no way of testing this. But if you'd like to I can try and send some patches your way.

Re: apgsearch v4.0

Posted: September 7th, 2017, 2:56 pm
by muzik
Again on the topic of new symmetries, how about gutter symmetry as seen in spaceship searches and the like? This would be D2_+1 with the middle strip of cells removed, and would make searching for patterns such as the p54 shuttle and centinal much easier.

Re: apgsearch v4.0

Posted: September 7th, 2017, 3:36 pm
by calcyman
drc wrote:
muzik wrote:Since we can do multiple iterations of the "inflate" command to soups, why not also treat the existing symmetries as commands as well?
I would suggest slowing down on the requests, calcyman has a lot of suggestions and he's trying to code the non-totalistic section of apgluxe
Thank you, Daniel; I'm very grateful that someone appreciates the finiteness of my time. I tend to operate in bursts, and I'm currently working on non-GoL projects. But I'll happily respond to democratic consensus.

Re: apgsearch v4.2

Posted: September 10th, 2017, 6:27 pm
by calcyman
Apologies for the double-post, but v4.2 now supports non-totalistic isotropic rules.

Please note: The executable is now called 'apgluxe' rather than 'apgmera', so you need to run:

Code: Select all

./apgluxe [OPTIONS]
Judging by the haul timestamps for b37s2-i34q/C1, it appears to be roughly 3 or 4 times faster than the Golly Python version.

Also, non-totalistic rules are currently SSSE3-dependent. If anyone encounters any problems (of the form 'Illegal instruction (core dumped)' or similar), then please let me know and I'll try to make an SSE2-compatible version.

Re: apgsearch v4.0

Posted: September 10th, 2017, 8:21 pm
by drc
Great! However, there is an issue where a certain error pops up extremely often:

Code: Select all

Using seed l_HGzVgFGVsa6T
Computing 2^18-entry lookup table...done!
Computing 2^24-entry lookup table...done!
Computing 2^18-entry mixing table...done!
Running 1000000 soups per haul:
xp3_gl54zaa0q0mgzx1 would take infeasibly long to brute-force separate.
5018 soups completed (501 soups per second).
xs19_04k0v0mgzkk501 would take infeasibly long to brute-force separate.
Linear-growth pattern detected: yl80_1_18_fd2c1824a2c770cedaaeec7e00fad0fa
9683 soups completed (391 soups per second).
xs24_gkkl5kz0aaag54zw3 would take infeasibly long to brute-force separate.
xs30_88b8zlllll5z22aa2 would take infeasibly long to brute-force separate.
14582 soups completed (489 soups per second).
xp15_088bz88bw8z1d1t14c would take infeasibly long to brute-force separate.
Linear-growth pattern detected: yl80_1_18_fd2c1824a2c770cedaaeec7e00fad0fa
xs28_89bz11lllkzwaai44zy01 would take infeasibly long to brute-force separate.
xs27_8b88z4lllllzw2q2 would take infeasibly long to brute-force separate.
18378 soups completed (379 soups per second).
I'm using the rule B2-ac3i4a/S12, I don't think this matters much, just wondering if that's normal for a rule of that nature.

Also, the amount of RAM taken up grows as the search progresses, is that normal?

EDIT: It seems to stop around 516KB, which is okay.
EDIT2: It's worse with D4_+2:

Code: Select all

Using seed l_JmEMDZPfpqx3
Computing 2^18-entry lookup table...done!
Computing 2^24-entry lookup table...done!
Computing 2^18-entry mixing table...done!
Running 1000000 soups per haul:
xs20_1107o3883o7011 would take infeasibly long to brute-force separate.
xs36_88b88b88zgllllllgzw6w6 would take infeasibly long to brute-force separate.
xs20_1lkkl1z8a22a8 would take infeasibly long to brute-force separate.
xs40_kkllkkzaaaaaaz55ll55 would take infeasibly long to brute-force separate.
xp3_08b80cz11d11d0d0c would take infeasibly long to brute-force separate.
xs28_44ll44z0aaaaz44ll44 would take infeasibly long to brute-force separate.
xs26_60f0s0u0u0s0f06 would take infeasibly long to brute-force separate.
xs20_22070f0220f07022 would take infeasibly long to brute-force separate.
xs48_gkkllzgg6o0oz0lklz46ge0cz4klkkzx22 would take infeasibly long to brute-force separate.
1109 soups completed (110 soups per second).
xs30_60v0v07070v0v06 would take infeasibly long to brute-force separate.
xp2_8bazj0u0iu0jz5kky01z01 would take infeasibly long to brute-force separate.
xs23_aagngngaazx606 would take infeasibly long to brute-force separate.
xs20_30e088z55l0ggz603 would take infeasibly long to brute-force separate.
xs20_220f07022070f022 would take infeasibly long to brute-force separate.

EDIT3: Sorry for all the edits, but two things happened. A: I've noticed that larger objects are now supported (the example is 6*90), which is pretty cool.
B: This is less cool, an xp114_88b88z1c1d1d18oy1czg6gmgmg23y16z22q22 apparently showed up in the following soup, but it doesn't seem to be there, any idea why this happened?:

Code: Select all

x = 32, y = 31, rule = B2-ac3i4a/S12
bbobobbbbboboobbbboobobbbbbobobb$
obbbobbbooboooobbooooboobbbobbbo$
obbobbboobbbbbobbobbbbboobbbobbo$
bobbbbbbbbooooobbooooobbbbbbbbob$
ooboboobboboboooooobobobbooboboo$
bbbbobobbbobbbbbbbbbbobbbobobbbb$
obbboooobboobobooboboobboooobbbo$
bbbbobbobbbbobbbbbbobbbbobbobbbb$
bobbbbbbooobboboobobbooobbbbbbob$
ooooboooobboooboobooobbooooboooo$
bbobbboboobobbboobbboboobobbbobb$
obbobbbbbooobbboobbbooobbbbbobbo$
boboobobobbboooooooobbboboboobob$
obobbbboobboobbbbbboobboobbbbobo$
boooooooboobobobboboboobooooooob$
ooobbooooobbbobbbbobbbooooobbooo$
boooooooboobobobboboboobooooooob$
obobbbboobboobbbbbboobboobbbbobo$
boboobobobbboooooooobbboboboobob$
obbobbbbbooobbboobbbooobbbbbobbo$
bbobbboboobobbboobbboboobobbbobb$
ooooboooobboooboobooobbooooboooo$
bobbbbbbooobboboobobbooobbbbbbob$
bbbbobbobbbbobbbbbbobbbbobbobbbb$
obbboooobboobobooboboobboooobbbo$
bbbbobobbbobbbbbbbbbbobbbobobbbb$
ooboboobboboboooooobobobbooboboo$
bobbbbbbbbooooobbooooobbbbbbbbob$
obbobbboobbbbbobbobbbbboobbbobbo$
obbbobbbooboooobbooooboobbbobbbo$
bbobobbbbboboobbbboobobbbbbobobb!
Also, this got classified as a yl1456 as well as several being classed as zz_LINEARs. I think this is a good test rule:

Code: Select all

x = 16, y = 16, rule = B2-ac3i4a/S12
bob2o2bo5b2o$b2obo2bo2bob3o$2b3o3b3ob3o$5bo2bo3bobo$5b2obo3b2obo$2bo5b
o2b2o$2obo2bob3ob3o$o2bo4bobo2bo$bobobobobob2ob2o$obobob2o2b2ob2o$bob
2o2bo2b2o3bo$o3b2ob2o2bo2bo$o2b3ob5obo$2bo4b2obo3bo$b2o2b6obob2o$bobob
4o3bobo!

Re: apgsearch v4.0

Posted: September 11th, 2017, 2:27 am
by muzik
It seems as though every time I search a non-totalistic rule apgsearch 4.2 is used, but for all other rules it's apgsearch 4.15. Did you somehow get both the scripts to coexist?

Also, i'm still able to call both of them using ./apgmera

Re: apgsearch v4.0

Posted: September 11th, 2017, 3:20 am
by calcyman
muzik wrote:It seems as though every time I search a non-totalistic rule apgsearch 4.2 is used, but for all other rules it's apgsearch 4.15. Did you somehow get both the scripts to coexist?

Also, i'm still able to call both of them using ./apgmera
I imagine that you're calling apgmera (4.15) which realises that the rules don't match, so it calls recompile.sh and builds apgluxe (4.2) which is subsequently called.

If my suspicion is correct, you'll get 4.15 for exactly one rule/symmetry and 4.2 for everything else.

Re: apgsearch v4.0

Posted: September 11th, 2017, 8:43 am
by Saka
the clone is still not working for me :evil:

Code: Select all

sakaf@Surface /home/apgmera/apgmera
$ ./recompile.sh --update
Checking for updates from repository...
./recompile.sh: line 21: curl: command not found
...your copy of apgmera does not match the repository.
New version:
Old version: "v4.1-" LIFELIB_VERSION
fatal: Not a git repository (or any of the parent directories): .git

Guess another manual download is in order :roll:

GOT IT!
But:

Code: Select all

sakaf@Surface /apgmera/apgmera
$ ./apgluxe -n 10000 -k saka29 --rule b3aijn45aiy6acn78/s3inq4aiqr5aiy6acn78
apgluxe v4.2-ll1.2: Rule b3s23 does not match desired rule b3aijn45aiy6acn78/s3inq4aiqr5aiy6acn78.
Skipping updates; use --update to update apgluxe automatically.
Not a git repository; skipping updates...
Symmetry unspecified; assuming C1.
Configuring rule b3aijn45aiy6acn78; symmetry C1
Invalid rulestring: b3aijn45aiy6acn78 is not of the form:
    bXsY
where X, Y are subsets of {0, 1, 2, ..., 8}, or:
    gNbXsY
where N >= 3 is the number of states, or:
    rNbWtXsYtZ
where 2 <= N <= 7 is the range and W,X,Y,Z are positive integers
Oh wait nevermind apg doesnt like the "/" character :P