Majestas32 wrote:Can somebody eli6 how exactly to set up apgsearch for somebody who barely knows what a compiler is?
(It appears that dvgrn and mniemiec beat me to this answer, but we've all said things with slightly different nuances and emphases so I'll post this anyway.)
The instructions in the README file on gitlab are relatively comprehensive, and there are tutorials on LifeWiki pertaining to using apgsearch (many thanks to Apple Bottom!).
If you 'barely know what a compiler is', then this should be a reason to learn rather than to expect a simplified version which hides away what's actually happening. I think that, through experimenting with GoL scripts, programs and libraries, many people on this forum (myself included) have learned a lot more about practical computer science, programming languages, compilers, cryptographic hash functions, and so much more. What might need eliciting are the concepts behind the scenes:
Machine code: The language directly understandable by your computer. Different computer architectures (such as x86_64 and ARM) have completely different and incompatible machine codes. Machine code is a list of bytes, usually displayed in hexadecimal for convenience. It's overwhelmingly rare nowadays to use this instead of assembly language; exceptions might be embedded systems with really low memory, or malware where the machine code is disguised as English text (
this actually exists!).
Assembly language: This differs from machine code in that it's more human-readable, but is essentially interchangeable. That is to say, there are programs (assemblers and disassemblers) which can convert between them with minimal effort. Again, this is architecture-specific. The script rule2asm.py generates x86_64 assembly code for running the specified outer-totalistic rule.
Source code (compiled): Typically high-level human-readable code (e.g. C++) which is compiled into machine code by a compiler such as g++. In contrast with assembly language, compilation cannot be easily reversed, and writing a decompiler is a very difficult problem.
Source code (interpreted): Again high-level human-readable code (e.g. Python), but it is read by an interpreter (itself a machine-code program) instead of being compiled into machine code. Interpreted languages tend to be much slower than compiled languages, by a factor of up to 1000. For most applications, this is unimportant because the most computation-heavy parts are run in a compiled language: machine learning researchers tend to use Python, which is acceptable because the intensive linear algebra operations are delegated to a fast machine-code library (namely ATLAS or openBLAS). This is analogous to how Golly scripts are written in Python (which is slow), but the computationally intensive task of running the cellular automaton is executed by Golly (which is fast).
For instance, versions 0.x and 1.x of apgsearch are written in Python (ergo interpreted), whereas versions 2.x and onwards are compiled from C++ source code. In both cases, they use compiled code for actually running the cellular automaton (Golly and lifelib are both written in C++).
I'm simplifying slightly because I haven't mentioned the idea of the
linker, which combines machine code from various object files into an executable file. It's often convenient to abstract this away and think of it as part of the compiler (g++, for instance, does every stage of compilation, assembly, and linkage). There's also the concept of
optimisation, where the compiler tries to speed up your code by replacing slower instruction sequences with faster equivalent sequences. Compilation is slower (apgluxe and slmake take so long to compile because they use -O3 optimisation on top of a codebase of many thousand lines of C++ and generated assembly) but execution is faster, so it's almost always desirable to compile with -O3.