Thread for your script-related questions

[vilc]

The Three-block shifter reaction doesn't seem to be in the octo3obj database.

Code: Select all

x = 8, y = 10, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o4b2o$2o4b2o!

The following pattern yields no result with find-by-octo3.py :

Code: Select all

x = 11, y = 12, rule = B3/S23
4bo$3b3o$2b2ob2o$b2o$3o$b2o$2b2ob2o$3b3o$4bo2$3b2o4b2o$3b2o4b2o!

I wrote a script to parse the collisions in a different way and didn't find it either.

Is it a bug or normal behaviour ?

[confocaloid]

The Three-block shifter reaction doesn't seem to be in the octo3obj database.

Code: Select all

x = 8, y = 10, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o4b2o$2o4b2o!

The following pattern yields no result with find-by-octo3.py :

Code: Select all

x = 11, y = 12, rule = B3/S23
4bo$3b3o$2b2ob2o$b2o$3o$b2o$2b2ob2o$3b3o$4bo2$3b2o4b2o$3b2o4b2o!

I wrote a script to parse the collisions in a different way and didn't find it either.

Is it a bug or normal behaviour ?

Seems like three-block shifter is indeed missing. I unsuccessfully tried to lookup each of 8 orientations of another phase.

It should be in octo3obj, because a "nearby" collision (same 3-block constellation) is there:

Code: Select all

x = 8, y = 9, rule = B3/S23
2o3bo$2ob2o$4b2o5$2o4b2o$2o4b2o!

[dvgrn]

Is it a bug or normal behaviour ?

Seems like three-block shifter is indeed missing. I unsuccessfully tried to lookup each of 8 orientations of another phase.

It should be in octo3obj, because a "nearby" collision (same 3-block constellation) is there:

Code: Select all

x = 8, y = 9, rule = B3/S23
2o3bo$2ob2o$4b2o5$2o4b2o$2o4b2o!

Yup, I'm thinking that has to count as a bug -- maybe in my collision enumeration code, or in some kind of post-enumeration simplification step?

It's hard to guess how that would have happened, given the presence of a different collision with the same constellation in the database. But those databases were all constructed and filtered and optimized more or less manually, so there are lots of places for mistakes to creep in.

So this is another case like 2718281828's 3g collision database, which has turned out to be not quite complete (as well as containing quite a few duplicates). I guess the moral of the story is that independent verification of projects of this size will always be a really good idea!

Someone could find out a little more by going and hunting down which line of which fingerprint file contains the collision that confocaloid posted, and look at adjacent lines of that file.

The generating code for those fingerprint files is mostly all available in the repository, so re-generating the database -- while keeping an eye out for what happens with that particular collision -- would presumably solve the mystery eventually.

[confocaloid]

[...]
The generating code for those fingerprint files is mostly all available in the repository, so re-generating the database -- while keeping an eye out for what happens with that particular collision -- would presumably solve the mystery eventually.

Maybe it would solve the question "what happened with that particular collision" but it may fail to solve the larger question "what happened", and it will not solve the question of independent verification.

It might be better to restart without looking at existing code, and regenerate everything that was meant to be covered from first principles using an independently written code. That way there would be some chance of getting reliable results.

[vilc]

I will first try to generate the collisions again, to understand what happened.

The generating code for those fingerprint files is mostly all available in the repository, so re-generating the database -- while keeping an eye out for what happens with that particular collision -- would presumably solve the mystery eventually.

I'm having some problems using "find-full-participation-collisions_v3.py". Where can I find the ruletables for "Interaction-test" and "Interaction-prep"?

[dvgrn]

I'm having some problems using "find-full-participation-collisions_v3.py". Where can I find the ruletables for "Interaction-test" and "Interaction-prep"?

Hmm. That might need some forensic work on old backups, though I remember what they did and could _probably_ rewrite them correctly from scratch. I'll be able to look in the most likely location in an hour or so, and will update this post.

It's too bad that I never got around to the to-do items mentioned in the octohash README:

I plan to update this README with a walkthrough of the full process of generating a new octohash database, whenever I get around to fingerprinting wildmyron's version of the 3G/4G SJK database (duplicates removed by using canonical Shinjuku glider-collision format to store the 3G and 4G collisions.)

... That said, the octohash databases are so much less efficient than they could be, that maybe it makes more sense to re-work the whole process from the ground up -- generate enumerations of constellations and collisions with C++, let's say, and then hopefully move the resulting indexed databases to some queryable online location.

[vilc]

I continued the investigations on the current octo3obj database. "buildconst3obj-comments.py" generated 1,624,450 constellations of three objects in a 11x11 bounding box. Does it mean that less than three collisions on average were stored for each orientation of each constellation ? I must be missing something.

... That said, the octohash databases are so much less efficient than they could be, that maybe it makes more sense to re-work the whole process from the ground up -- generate enumerations of constellations and collisions with C++, let's say ...

I will try to do this, I already had some C++ code for the collisions of a glider and a p1 target.

[dvgrn]

I continued the investigations on the current octo3obj database. "buildconst3obj-comments.py" generated 1,624,450 constellations of three objects in a 11x11 bounding box. Does it mean that less than three collisions on average were stored for each orientation of each constellation ? I must be missing something.

Aha, yes! The explanation for that surprisingly small number of collisions ... is also the reason why the three-block shifter isn't in octo3obj.

The three-block shifter isn't in the database because all collisions with all 1,624,450 constellations would have been too big to index, with the rather slow prototype tools I had hacked together.

That's what the "Interaction-test" and "Interaction-prep" rules are about. I colored all of the stationary objects one color to start out, and the glider another "plague" color, and made it so that even a temporary touch from glider cells will spread the "plague" color to the stationary objects. Then after running the required number of ticks, I ran the Interaction-test rule, removing all of the "plague" cells.

If the resulting population was greater than zero, I didn't index that particular collision with that particular constellation -- because at least one of the objects in the constellation never got touched by the active reaction, so in some sense there was "nothing new" happening there that did not also happen somewhere else in the enumeration. In this case, the two-block version of the three-block shifter will be in the database --

Code: Select all

x = 8, y = 10, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o$2o!

-- but the three-block version won't be, and neither will any other collisions where those two blocks do that same thing and there's another random still life nearby and inside 11x11, like this

Code: Select all

x = 11, y = 12, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o6b2o$2o5bo2bo$7bo2bo$8b2o!

or dozens of other not-so-interesting variants.

I was looking to index as much novelty as possible, and I knew there were a lot of fairly boring collisions in my enumerated set, where a glider just comes in and deletes a block or two.

It would arguably be useful to index all of the collisions with all of the constellations, since that would mean that you could search for the three-block shifter in "octo3objcomplete" and actually find it. But that would take more gigabytes than I wanted to try to share around via GitHub.
Instead we'd probably want very fast generator code so that everyone who wants that particular database could re-create it themselves, in maybe a day or two.

[dvgrn]

That's what the "Interaction-test" and "Interaction-prep" rules are about. I colored all of the stationary objects one color to start out, and the glider another "plague" color, and made it so that even a temporary touch from glider cells will spread the "plague" color to the stationary objects. Then after running the required number of ticks, I ran the Interaction-test rule, removing all of the "plague" cells.

If the resulting population was greater than zero, I didn't index that particular collision with that particular constellation -- because at least one of the objects in the constellation never got touched by the active reaction, so in some sense there was "nothing new" happening there that did not also happen somewhere else in the enumeration.

Sorry, that was the basic idea, but some of the details weren't quite right.

Interaction-prep looks like it was kind of a silly rule -- just converted all state-1 cells to state-3, if I'm reading the code right. Interaction-test then ran regular Life with state-1 and state-3 ON cells, starting with a glider in state 1 and everything else in state 3. I'm thinking that state 2 was an OFF state that showed up whenever a state-1 cell neighbor got overpopulated, and any state-3 cells that neighbored a state-2 or state-1 cell turned to state 1... otherwise I don't know why three states would have been needed.

If I have my theory right, that would allow still lifes to act as induction coils -- e.g., a block could suppress two births from a length-six line without ever neighboring any state-1 cells, and yet the block would still get changed to state 1 appropriately because it modified the reaction -- whereas a block that got passed by a glider one diagonal cell away would stay in state 3, disqualifying that collision.

Want me to reconstruct those rules, or is the description good enough?

[confocaloid]

Instead we'd probably want very fast generator code so that everyone who wants that particular database could re-create it themselves, in maybe a day or two.

Most likely configurable bounding box and the number of "objects". Probably also configurable types of "objects" (effectively specifying which multisets/bags of "objects" should be included). And maybe also configurable type of the hitting spaceship (so one could choose glider/LWSS/MWSS/HWSS / glider pair / ...).

Even better if the code would work for alien objects and alien spaceships in other rules. E.g. hitting 10x10 Blockic constellations with a lepa in LeapLife.

[vilc]

Thank you for your explanation, that's very helpful.

Want me to reconstruct those rules, or is the description good enough?

Thanks, that should suffice for me, the rules don't look so complicated.

[dvgrn]

Even better if the code would work for alien objects and alien spaceships in other rules. E.g. hitting 10x10 Blockic constellations with a lepa in LeapLife.

Yup, that's a really good use case to keep in mind -- or even gliders hitting LeapLife constellations. In Life you can assume that nothing interesting will happen if a glider stays two diagonal cells away from the closest live cell in a constellation, but in rules like LeapLife there's still an interaction on those lanes.

Some of the enumeration code that's in the octohash repos actually did get used to do some work on LeapLife one-time turners, once upon a time. The enumeration code also had to change a bit to exclude Life "quasi-still-life" arrangements.

Want me to reconstruct those rules, or is the description good enough?

Thanks, that should suffice for me, the rules don't look so complicated.

My apologies for losing track of those rules! They should have been checked in to the repo along with everything else. If you do rebuild them, please post a copy and I'll test them out and add them to the repo.

[vilc]

If you do rebuild them, please post a copy and I'll test them out and add them to the repo.

Here they are, along with the rule trees (feel free to correct any mistake in the comments). They seem to work correctly according to your description and on the script's end : now it discard around three-quarters of the collisions, a reasonnable value given my estimates (a little too low, perhaps).
By the way, is it normal that the speed of the script is roughly 1 constellation/second ? Recompiling the collisions would take a month of computing.

Code: Select all

@RULE Interaction-prep

Helper rule to convert state 1 cells to state 3 cells.

@TABLE

n_states:4
neighborhood:vonNeumann
symmetries:permute

var a = {0,1,2,3}
var b = {a}
var c = {a}
var d = {a}

1,a,b,c,d,3

@TREE

num_states=4
num_neighbors=4
num_nodes=5
1 0 3 2 3
2 0 0 0 0
3 1 1 1 1
4 2 2 2 2
5 3 3 3 3

Code: Select all

@RULE Interaction-test

State 1 and state 3 patterns each follow B3/S23 as long as they don't interact.
If there is an interaction, state 3 patterns gradually become state 1
(with some help from state 2 if there is no direct contact).

@TABLE
n_states:4
neighborhood:Moore
symmetries:permute

var a = {1,3}
var b = {a}
var c = {a}
var d = {a}
var e = {a}
var f = {a}
var g = {a}
var h = {a}
var i = {a}

var o1 = {0,2}
var o2 = {o1}
var o3 = {o1}
var o4 = {o1}
var o5 = {o1}
var o6 = {o1}
var o7 = {o1}
var o8 = {o1}
var o9 = {o1}

var any1 = {0,1,2,3}
var any2 = {any1}
var any3 = {any1}
var any4 = {any1}
var any5 = {any1}
var any6 = {any1}
var any7 = {any1}
var any8 = {any1}
var any9 = {any1}

# surviving live cells become state 1, except if only state 3 and state 0 cells are involved
3,3,3,0,0,0,0,0,0,3
3,3,3,3,0,0,0,0,0,3

a,b,c,o1,o2,o3,o4,o5,o6,1
a,b,c,d,o1,o2,o3,o4,o5,1

# underpopulated or overpopulated live cells die
a,o1,o2,o3,o4,o5,o6,o7,o8,0
a,b,o1,o2,o3,o4,o5,o6,o7,0

a,b,c,d,e,o1,o2,o3,o4,0
a,b,c,d,e,f,o1,o2,o3,0
a,b,c,d,e,f,g,o1,o2,0
a,b,c,d,e,f,g,h,o1,0
a,b,c,d,e,f,g,h,i,0

# dead cells with three living neighbours become state 1 except when only state 3 and state 0 cells are involved
0,3,3,3,0,0,0,0,0,3
o1,a,b,c,o2,o3,o4,o5,o6,1

# overpopulated dead cells become state 2 only when the middle cell is state 0
# and some state 1 and state 3 cells are involved

0,1,3,d,e,o1,o2,o3,o4,2
0,1,3,d,e,f,o1,o2,o3,2
0,1,3,d,e,f,g,o1,o2,2
0,1,3,d,e,f,g,h,o1,2
0,1,3,d,e,f,g,h,i,2

o1,a,b,c,d,o1,o2,o3,o4,0
o1,a,b,c,d,e,o1,o2,o3,0
o1,a,b,c,d,e,f,o1,o2,0
o1,a,b,c,d,e,f,g,o1,0
o1,a,b,c,d,e,f,g,h,0

# otherwise, state 2 cells die
2,any1,any2,any3,any4,any5,any6,any7,any8,0

@TREE

num_states=4
num_neighbors=8
num_nodes=90
1 0 0 0 0
2 0 0 0 0
1 0 1 0 1
2 0 2 0 2
1 0 1 0 3
2 0 2 0 4
3 1 3 1 5
1 1 1 1 1
2 2 7 2 7
3 3 8 3 8
3 1 3 1 3
1 3 1 1 3
2 4 7 2 11
3 5 8 3 12
4 6 9 10 13
1 2 0 0 0
2 7 0 7 15
2 7 15 7 15
3 8 16 8 17
3 8 17 8 17
4 9 18 9 19
4 10 9 10 9
2 11 15 7 0
3 12 17 8 22
4 13 19 9 23
5 14 20 21 24
2 0 0 0 15
2 15 15 15 15
3 16 26 16 27
3 17 27 17 27
4 18 28 18 29
4 19 29 19 29
5 20 30 20 31
2 7 15 7 0
3 8 17 8 33
4 9 19 9 34
5 21 20 21 35
2 0 15 0 0
3 22 27 33 37
4 23 29 34 38
5 24 31 35 39
6 25 32 36 40
3 26 26 26 27
3 27 27 27 27
4 28 42 28 43
4 29 43 29 43
5 30 44 30 45
5 31 45 31 45
6 32 46 32 47
3 33 27 33 37
4 34 29 34 49
5 35 31 35 50
6 36 32 36 51
3 37 27 37 37
4 38 43 49 53
5 39 45 50 54
6 40 47 51 55
7 41 48 52 56
4 42 42 42 43
4 43 43 43 43
5 44 58 44 59
5 45 59 45 59
6 46 60 46 61
6 47 61 47 61
7 48 62 48 63
4 49 43 49 53
5 50 45 50 65
6 51 47 51 66
7 52 48 52 67
4 53 43 53 53
5 54 59 65 69
6 55 61 66 70
7 56 63 67 71
8 57 64 68 72
5 58 58 58 59
5 59 59 59 59
6 60 74 60 75
6 61 75 61 75
7 62 76 62 77
7 63 77 63 77
8 64 78 64 79
5 65 59 65 69
6 66 61 66 81
7 67 63 67 82
8 68 64 68 83
5 69 59 69 69
6 70 75 81 85
7 71 77 82 86
8 72 79 83 87
9 73 80 84 88

@COLORS
1 0 255 0
2 0 0 128
3 216 255 216

A test pattern showing glider interactions/non-interactions, B3/S23 emulation by state 1 and 3 and the propagation of state 1 without contact.

Code: Select all

x = 182, y = 40, rule = Interaction-test
90.4A3.10A4.A3.4A$93.2A.A6.A.2A2.A2.A2.A.A34.4C3.10C4.C3.4C$89.2A2.3A
2.5A.A.A.2A3.2A.2A37.2C.C6.C.2C2.C2.C2.C.C$90.2A2.A4.A.2A.A3.A3.6A.A
31.2C2.3C2.5C.C.C.2C3.2C.2C$89.2A.A3.2A7.A2.A4.A.A2.A33.2C2.C4.C.2C.C
3.C3.6C.C$90.A.3A4.2A2.A.2A.2A.A3.5A31.2C.C3.2C7.C2.C4.C.C2.C$90.A2.
2A.7A.A.A2.A4.6A32.C.3C4.2C2.C.2C.2C.C3.5C$91.A4.2A.2A2.A2.2A.A2.A.2A
.A.A32.C2.2C.7C.C.C2.C4.6C$89.3A3.A2.A.3A3.A3.A2.A.3A35.C4.2C.2C2.C2.
2C.C2.C.2C.C.C$92.A.A3.A2.A.2A3.2A2.A2.4A32.3C3.C2.C.3C3.C3.C2.C.3C$
89.A2.2A.A2.5A.A.3A.A2.A.5A34.C.C3.C2.C.2C3.2C2.C2.4C$89.3A3.3A.6A6.
3A.A2.2A31.C2.2C.C2.5C.C.3C.C2.C.5C$89.A.A3.2A.2A.A.3A3.A.2A.A.2A33.
3C3.3C.6C6.3C.C2.2C$92.A2.A2.A2.3A.5A2.A.3A.2A31.C.C3.2C.2C.C.3C3.C.
2C.C.2C$3.A13.A71.2A.A2.2A.A2.2A.A.A.A2.A.2A.A.2A34.C2.C2.C2.3C.5C2.C
.3C.2C$4.A13.A27.10A34.2A2.2A.A2.4A4.A.A2.2A4.A31.2C.C2.2C.C2.2C.C.C.
C2.C.2C.C.2C$2.3A11.3A70.A2.A.7A2.A.A4.2A2.A4.A32.2C2.2C.C2.4C4.C.C2.
2C4.C$90.3A.A.A6.2A.A.A2.A3.A.2A32.C2.C.7C2.C.C4.2C2.C4.C$89.2A3.4A2.
2A3.2A.4A.A2.A.2A32.3C.C.C6.2C.C.C2.C3.C.2C$2C13.2C33.2C39.A2.3A5.A4.
A.4A.A4.A31.2C3.4C2.2C3.2C.4C.C2.C.2C$2C13.2C33.2C42.A.A5.2A.A.2A.2A.
3A.A.A33.C2.3C5.C4.C.4C.C4.C$90.A2.4A3.2A2.A2.A.2A4.3A38.C.C5.2C.C.2C
.2C.3C.C.C$90.A.A4.A2.A2.3A.A2.2A2.2A.2A33.C2.4C3.2C2.C2.C.2C4.3C$91.
2A2.A.6A.7A.A4.A.A32.C.C4.C2.C2.3C.C2.2C2.2C.2C$89.2A.A3.3A2.A2.6A.9A
33.2C2.C.6C.7C.C4.C.C$89.A2.A.A.A.A2.3A.A3.A2.4A2.2A31.2C.C3.3C2.C2.
6C.9C$151.C2.C.C.C.C2.3C.C3.C2.4C2.2C5$12.A$13.A$11.3A3$15.2C$15.C$
16.3C$18.C!

[dvgrn]

By the way, is it normal that the speed of the script is roughly 1 constellation/second ? Recompiling the collisions would take a month of computing.

Hmm, that seems a bit slow. I remember it taking a few days, but not as long as a week, let alone a month.

Given "LONG_ENOUGH = 65536", the only thing I can think of offhand is that find-full-participation-collisions-v3.py doesn't include code to specify an algorithm, so you might possibly be running it in QuickLife. In that case, using HashLife instead ought to be quite a bit faster.

If we're only indexing the first few hundred ticks of each collision, anyway, I'm not sure why LONG_ENOUGH is set quite that high -- but in HashLife it really shouldn't matter much.

[hotdogPi]

I had about a 2.5x speedup from my 2019 computer to my 2023 one running Python programs in Golly. It might depend on computer.

[vilc]

Hmm, that seems a bit slow. I remember it taking a few days, but not as long as a week, let alone a month.

"One month" was a quick (and rather pessimistic) estimate. I benchmarked more accurately (only running golly) and it reduces my estimate to 15 days.

In that case, using HashLife instead ought to be quite a bit faster.

Switching to HashLife doesn't change anything because Interaction-test implicitly runs with RuleLoader.

If we're only indexing the first few hundred ticks of each collision, anyway, I'm not sure why LONG_ENOUGH is set quite that high -- but in HashLife it really shouldn't matter much.

Good point, but lowering LONG_ENOUGH (even to 256 generations) only offers a few percents increase in speed.

The easiest solution to significantly shorten the running time is probably to split the big constellations file into chunks according to the bounding box (that's feasible thanks to the comments), and then parallelise using several instances.
The collision file's names in the databse seem to indicate that this method was used (with 7 chunks).

I am currently rewriting the script that generates the collisions to make long searches easier and safer. I will soon start rebuilding the collisions files.

Edit :
I figured out that the constellation count the script provided was inaccurate. There are actually around 841,000 constellations in the resulting file. I started the computation with 3 instances, it should take only a few days.

Edit 2 :
The script that generates constellations skips some of those that contain quasi still-lifes with transition B2i or B2k. It comes from the following lines in builsconst3obj-comments.py:

Code: Select all

g.setrule("B12345678/S012345678")
neighbors=g.evolve(item,1)
g.setrule("B2345678/S012345678")
zone=g.evolve(neighbors,1)

This code is supposed to compute a zone around a pattern where no live cell should be found. Test the procedure with a beehive and you will understand the problem with quasi still-lifes. For example, the following collision is not in the database :

Code: Select all

x = 11, y = 11, rule = B3/S23
bo$2bo$3o2$6b2o$6b2o3$3b2o3b2o$2bo2bobo2bo$3b2o3b2o!

I guess this is fine because such constellations are more difficult to build and therefore less likely to yield interesting results, unlike constellations with B2n.

[C_R_116]

Problem with compiling barrister. Solution?

Code: Select all

~/barrister$ make
clang++ -std=c++20 -Wall -Wextra -pedantic -O3 -DNDEBUG -march=native -mtune=native -flto -fno-stack-protector -fomit-frame-pointer  -o Barrister Barrister.cpp -Wl,-stack_size -Wl,0x1000000
make: clang++: No such file or directory
make: *** [Makefile:20: Barrister] Error 127

Installing clang:
Edit: Ugh

Code: Select all

~/barrister$ make
clang++ -std=c++20 -Wall -Wextra -pedantic -O3 -DNDEBUG -march=native -mtune=native -flto -fno-stack-protector -fomit-frame-pointer  -o Barrister Barrister.cpp -Wl,-stack_size -Wl,0x1000000
In file included from Barrister.cpp:13:
./LifeUnknownState.hpp:144:43: warning: unused parameter 'stable' [-Wunused-parameter]
  void SanityCheck(const LifeStableState &stable) {
                                          ^
./LifeUnknownState.hpp:215:14: warning: unused variable 'on3' [-Wunused-variable]
    uint64_t on3 = stateCount.bit3[i];
             ^
./LifeUnknownState.hpp:216:14: warning: unused variable 'on2' [-Wunused-variable]
    uint64_t on2 = stateCount.bit2[i];
             ^
./LifeUnknownState.hpp:217:14: warning: unused variable 'on1' [-Wunused-variable]
    uint64_t on1 = stateCount.bit1[i];
             ^
./LifeUnknownState.hpp:218:14: warning: unused variable 'on0' [-Wunused-variable]
    uint64_t on0 = stateCount.bit0[i];
             ^
./LifeUnknownState.hpp:220:14: warning: unused variable 'unk3' [-Wunused-variable]
    uint64_t unk3 = unknownCount.bit3[s][i];
             ^
./LifeUnknownState.hpp:221:14: warning: unused variable 'unk2' [-Wunused-variable]
    uint64_t unk2 = unknownCount.bit2[s][i];
             ^
./LifeUnknownState.hpp:222:14: warning: unused variable 'unk1' [-Wunused-variable]
    uint64_t unk1 = unknownCount.bit1[s][i];
             ^
./LifeUnknownState.hpp:223:14: warning: unused variable 'unk0' [-Wunused-variable]
    uint64_t unk0 = unknownCount.bit0[s][i];
             ^
./LifeUnknownState.hpp:271:12: warning: unused variable 'stable_on' [-Wunused-variable]
  uint64_t stable_on = stable.state[i];
           ^
./LifeUnknownState.hpp:265:12: warning: unused variable 'stateon' [-Wunused-variable]
  uint64_t stateon = state[i];
           ^
./LifeUnknownState.hpp:267:12: warning: unused variable 'stateunkstable' [-Wunused-variable]
  uint64_t stateunkstable = unknownStable[i];
           ^
./LifeUnknownState.hpp:272:12: warning: unused variable 'stable_unknown' [-Wunused-variable]
  uint64_t stable_unknown = stable.unknown[i];
           ^
./LifeUnknownState.hpp:266:12: warning: unused variable 'stateunk' [-Wunused-variable]
  uint64_t stateunk = unknown[i];
           ^
./LifeUnknownState.hpp:358:14: warning: unused variable 'on3' [-Wunused-variable]
    uint64_t on3 = state3[i-1];
             ^
./LifeUnknownState.hpp:370:14: warning: unused variable 'stable_on' [-Wunused-variable]
    uint64_t stable_on = nearbyStableState[i];
             ^
./LifeUnknownState.hpp:371:14: warning: unused variable 'stable_unknown' [-Wunused-variable]
    uint64_t stable_unknown = nearbyStableUnknown[i];
             ^
In file included from Barrister.cpp:14:
./RotorDescription.hpp:26:13: warning: enumeration values 'NORESULT', 'STABLE', and 'OTHER' not handled in switch [-Wswitch]
    switch (type) {
            ^~~~
./RotorDescription.hpp:51:48: warning: unused parameter 'resType' [-Wunused-parameter]
                                     RotorType resType) {
                                               ^
./RotorDescription.hpp:86:13: warning: 8 enumeration values not handled in switch: 'ReflectAcrossXEven', 'ReflectAcrossYEven', 'Rotate90Even'... [-Wswitch]
    switch (transf) {
            ^~~~~~
Barrister.cpp:300:22: warning: unused parameter 'everActive' [-Wunused-parameter]
    const LifeState &everActive,
                     ^
Barrister.cpp:301:51: warning: unused parameter 'activeTimer' [-Wunused-parameter]
    const LifeCountdown<maxCellActiveWindowGens> &activeTimer,
                                                  ^
Barrister.cpp:302:51: warning: unused parameter 'streakTimer' [-Wunused-parameter]
    const LifeCountdown<maxCellActiveStreakGens> &streakTimer)
                                                  ^
23 warnings generated.
/usr/bin/ld: Warning: grouped short command line options are deprecated: -stack_size
/usr/bin/ld: Error: unable to disambiguate: -stack_size (did you mean --stack_size ?)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:20: Barrister] Error 1

EDIT: Fixed

[b-engine]

What configuration for LLS was used to find the 16x16 2EC soup?

[confocaloid]

What configuration for LLS was used to find the 16x16 2EC soup?

Probably it was computed by creating a text file with several generations (T = 0, 1, 2, 3) filled with asterisks, and with generation T = 4 specified to match the desired 20x18 predecessor. See "How to use LLS" here: viewtopic.php?p=55605#p55605

Terminology note: the word "soup" should be put in quotes, because that 16x16 pattern is "merely" a predecessor that was computed by an algorithm that differs from randomly assigning cellstate values to cells. That 16x16 predecessor is not a soup.

[b-engine]

How can I configure a specific spaceship partial for WLS?
It gives me an error when I try to configure it and search.

[dvgrn]

How can I configure a specific spaceship partial for WLS?
It gives me an error when I try to configure it and search.

That's ... an extraordinarily vague problem description. There are lots of subtle things that can go wrong at the configuration stage. It's easier for people to help if you provide some specifics about the spaceship and/or the error.

Can you generate a WLS save file with the spaceship partial that you're trying to search on -- whatever the state is that's giving the error -- ZIP it up, and attach it here?