About Project Prerequisites

In a (curious) attempt to make it easier for you, the user, to get the software projects available from Cat's Eye Technologies up and running on your own computer, we have compiled this glossary of things you will need, referenced by each project.

Build vs. Run

Some prerequisites are build requirements, meaning that you will need them only if you want to build the project. Other requirements are run requirements, which will be needed whenever the executables of the project are run.

Note that some projects do not ship with executables, and will require that you build them to produce executables for your system before you run them. This is generally true for projects written in systems-construction languages like C.

Projects in other languages, such as Erlang, often ship with compiled files which can be executed immediately. However, if you wish to change the programs by changing the source code, you will need to re-build these executables.

Still other projects, such as those in Perl, do not have executables; the scripts are directly executable by an interpreter, and changes to them are immediately reflected without having to build anything.

Some of the files in this project are descriptions of cellular automata, written in the ALPACA meta-language, version 0.97 or later. Using them to direct (in some automatic fashion) the evolution of a cellular automaton will require some tool which implements the ALPACA language.

We're not aware of any implementations of ALPACA besides Cat's Eye Technologies' own ALPACA-to-Perl compiler written in Perl, which we've linked to here (which will serve as a reference implementation, until such time as we get around to writing a specification for ALPACA).

The C-language source files in this project conform to ANSI C (aka C89). We have tested them with at least gcc 2.95.3, and probably gcc 3.4 as well. (If you're curious why 2.95.3: this is the version of gcc that ships with FreeBSD 4.x.) The souce files compile with the -ansi flag (and usually -pedantic, too,) and should (in theory at least) be buildable with any ANSI C compiler.

The C-language source files in this project conform to the C99 standard. The souce files generally are such that they would compile with the -ansi flag, except that they rely on extra headers, such as for POSIX system calls.

Some or all of the programs in this project are Erlang modules, and running them requires a copy of the Erlang/OTP runtime system, version R9C or later, or a fully-compatible runtime system.

Note that compiled Erlang modules are .beam files in the ebin directory. The source code lives in the src directory, and an Erlang compiler (such as the one which ships with Erlang/OTP) is required to build the modules.

Any Haskell 98-conforming implementation of Haskell should be able to handle the sources for this project. In order to compile a binary with a Haskell compiler such as ghc, you may need to add some driver code.

Some or all of the programs are written in Java 6 source code, and creating Java classes from them requires a copy of the Java Development Kit, version 1.6.0 or later, or a fully-compatible compilation environment.

Note that the Java source code lives in the project's src directory, and a Java compiler such as the one which ships with JDK 1.6.0 is required to build the class files from the sources.

Some or all of the programs this project are implemented by Java 6 classes, and running them requires a copy of the Java Runtime Environment, version 1.6.0 or later, or a fully-compatible runtime environment.

Note that compiled Java classes are .class files in some subdirectory of the project's bin directory.

Some or all of the programs in this project are Lua scripts, and running them requires a Lua interpreter, version 5.0.x. (The latest version, as of this writing, is 5.0.3, and this version is recommended. Note that the 5.1.x series of Lua is not generally compatible with the 5.0.x series.)

While there are several implementations of Lua, we're not aware of any standards documents defining the language aside from the reference implementation produced by the Lua project, which we've linked to here.

Some or all of the programs in this project are Lua scripts, and running them requires a Lua interpreter, version 5.1.x. (The latest version, as of this writing, is 5.1.3, and this version is recommended.)

While there are several implementations of Lua, we're not aware of any standards documents defining the language aside from the reference implementation and manual produced by the Lua project, which we've linked to here.

Some or all of the programs in this project are Perl scripts, and running them requires a Perl interpreter, version 5.005_03 or later. (If you're curious why 5.005_03: this is the version of the Perl interpreter that ships with FreeBSD 4.x.) We'll try to make sure they still run the same on more modern versions, like Perl 5.8.x, but won't make any guarantees there.

We're not aware of any implementation of Perl which conforms to version 5.005_03 that isn't based on Larry Wall's source base, so that's the link we've given here.

Some or all of the programs in this project are Perl scripts, and running them requires a Perl interpreter, version 5.8.8 or later. We'll try to make sure they still run the same on later 5.x versions of Perl, but we won't make any guarantees there.

We're not aware of any implementation of Perl which conforms to version 5.8.8 that isn't based on Larry Wall's source base, so that's the link we've given here.

Some or all of the programs in this project are Python scripts, and running them requires a Python interpreter, version 2.5.2 or later. (Actually it's quite possible older versions of Python will work, but we haven't confirmed them.)

While there are several implementations of Python, we're not aware of any standards documents defining the language aside from the reference implementation and manual produced by the Python project, which we've linked to here.

We have also tested our Python scripts on Jython 2.5.1 and found that they seem to run quite well on it.

Any R⁵RS-conforming Scheme implementation should be able to handle the sources for this project. In order to compile a binary with a Scheme compiler, you may need to add some driver code.

The project contains grammars written in the dynamic language of Zz, version 2.0. While Zz was implemented as part of the APE100 parallel computing project, the only freely available implementation of Zz that we're aware of is OpenZz. Our projects have been tested with the OpenZz interpreter version 1.0.4-4.

In order to build this project automatically, you will need a make utility compatible with BSD make. This is also known as pmake, however that should not be confused with pmake - a perl 'make' replacement. GNU make is generally capable of handling BSD Makefiles, but we aren't making any guarantees.

More specifically, you will need the bsd.*.mk files that ship with most BSD-based operating systems, and which provide common targets for the Makefiles.

Without BSD make, you can still build the project; you will just have to find another way to invoke the compiler (or whatever) on all the source files.

The source code for this project was developed with Borland C++ 3.1 (although it is almost certainly written in C, not C++.) It may use Borland C++-specific extensions and libraries. Borland C++ 3.1 is not free software, although you can apparently download a set of Borland's later tools free of charge. I don't know if they'd be useful to compile these sources.

Some files in this project are x86 (a.k.a IA-32) assembly-language sources written in the syntax of the NASM assembler. You'll need an assembler that conforms to NASM's syntax in order to build executables from these files. Since the only assembler we know of that uses NASM's syntax is NASM, and since that's the assembler we tested the project with, that's the assembler we'll recommend that you use here.

Many of these NASM files were converted from older assembly-language sources written in the syntax of Turbo Assembler 3.1. This is an old-school x86 assembler for DOS, written by Borland. In most cases the Turbo Assembler sources are still included in the project for historical interest, but the newer NASM sources are what the binaries are built from.

Some files in this project are 6502 assembly-language sources written in the syntax of the P65 assembler. You'll need an assembler that conforms to P65's syntax in order to build executables from these files. Since the only assembler we know of that uses P65's syntax is P65, and since that's the assembler we tested the project with, that's the assembler we'll recommend that you use here. Note that we've only tested assembly using P65-Perl 1.1, and not the later "Ophis" Python-based version of P65.

In order to build this project automatically, you will need a make utility capable of handling fairly generic Makefiles. GNU make should be generally capable of handling these kind of Makefiles.

Without a make, you can still build the project; you will just have to find another way to invoke the compiler (or whatever) on all the source files.

Executables of this project need to run in a terminal which understand the ANSI terminal control codes (more formally known as "ECMA-48") in order for their output to be intelligible. Almost all modern consoles and terminal emulators understand these codes, sometimes under the guise of a particular terminal standard which includes them, such as vt100 or vt220. For older MS-DOS systems, a driver such as ANSI.SYS may need to be loaded.

This project assumes that it will be running on a stock Commodore 64, great microcomputer of old (well, if you consider things from the early 80's to be old...)

Of course, not everyone owns a Commodore 64, but these days, quite good open-source C64 emulators are available for most platforms. We suggest VICE.

This project requires the Cygwin POSIX-emulating layer for Windows. For projects whether this is a build requirement, this means that building it on Windows assumes the mingw compiler and the associated framework around it that Cygwin provides. For run requirements, this means that the Cygwin DLLs will be required when the project is run.

This project requires that it run under FreeBSD 4.x or something which is sufficiently compatible with it, such as (perhaps older versions of) DragonFlyBSD.

Note that if a project requires FreeBSD 4.x, it almost certainly won't work on 5.x or 6.x; the format of many FreeBSD-specific things (such as kernel modules) changed between 4.x and 5.x.

This project assumes that it will be running under Microsoft Windows, or something which emulates Windows sufficiently well. These projects are generally pretty generic 32-bit Windows executables, so should run on Windows 98, ME, NT, and Vista. However, due to variations between these products, there's no guarantee. See the project itself for any further information.

This project assumes that it will be running under MS-DOS or something which emulates MS-DOS sufficiently well. This includes both the standard DOS INT 21h handler, and the standard DOS utilies like, for example, DEBUG.COM.

You can try (at your own risk, of course) using the project under some more-or-less modern version of Windows and hope that it emulates DOS well enough to work. It might, it might not. If not, FreeDOS is an open-source re-implementation of DOS under which we try to test our DOS-based projects.

This project needs to run on some platform which supports the Single UNIX Specification version 3, also (and more popularly) known as POSIX. Generally, this is so that the operating system can provide the programs with resources such as clock information and network sockets.

Most modern UNIX-like operating systems implement something approximating the POSIX interface. For Windows, compatibility layers such as Cygwin fill this role.

Note that the specification linked to is actually SUSv7, which is very similar to SUSv3, but unlike SUSv3 has freely-accessible documentation on the web.

This project assumes that it will be running on a fairly standard x86-based (IA-32) computer architecture, from the lineage that dates back to those old IBM PC's. Probably a 486 with a BIOS, keyboard, and basic VGA is the minimum to make it worthwhile. While most modern PC's can handle that reasonably well, often a better choice — because it can run under a modern OS, rather than actually dedicating the entire computer to it — is to run such things under an emulator. In which case, we recommend Bochs.

This Perl project uses Cat's Eye Technologies' own Console::Virtual interface to provide a simulated console on which to display random-access, coloured textual output, and from which to take raw key input. Running the programs of the project will require that version 2007.1122 or later of the Console::Virtual module, or some other module which provides a compatible interface, be installed.

This Erlang project uses Cat's Eye Technologies' ce module, a library of common Erlang routines. Running the programs of the project will require that version 2003.0522 or later of the ce module be locatable by the Erlang runtime.