CodeSlinger is a Hexarc module that runs user-created programs on one or more machines of the arcology.

Core Concepts

CodeSlinger manages the set of user-created programs on the arcology. The basic workflow is as follows:

• A user creates a program (via some UI) which creates an entry in the Arc.programs table with a unique 8-character ID. The source files are stored in a file hierarchy under the ID in the Arc.source table.
• The user runs the program (via some UI) by specifying its ID and possibly passing in parameters.
• CodeSlinger looks up the program and compiles it, if necessary. The compiled program is stored in files under the ID in the Arc.code table.
• CodeSlinger keeps a data structure of running programs. For each program we keep the entire environment (CHexeProcess).
• Some programs run on different machines. In that case, Prime CodeSlinger keeps track of which machine has which program and forwards messages appropriately. [Perhaps later we can store this on Mnemosynth so that all machines have the list.]
• Messages to CodeSlinger can inquire and manipulate running programs.

Parameters

Programs define the parameters they accept. This allows adding programmatic UIs on top and chaining programs together.

UI Abstractions

We define several UI abstractions.

Distributed Processing

Specific primitives that parallelize are implemented by their own archons. For example, a program can call Luminous.render, which sends a message to the Luminous archon; the Luminous archon is responsible for distributing that message across multiple machines.

At runtime, a program requests a certain number of concurrent CPUs. The request is passed on to the message as an option (in the example, we pass it to Luminous.render). The value can come from an input parameter set by the user at runtime.

Inside Luminous.render, we call back to CodeSlinger to make sure the program has permission to request that many threads. We probably also call back with a status reporting the number of threads being used (so that CodeSlinger can record in its status record).

Program Status

CodeSlinger keeps status for all running programs. The status consists of two or three pieces of data:

1. A well-defined status code, such as running or idle or whatever.
2. A human-readable string that can be set by the program.
3. An optional progress bar indicator (%) related to the status string.

CodeSlinger set the status to various defaults. For example, when the program is running, when it's waiting for an event, etc.

A program may set the status to show custom program progress to the user.

When invoking a primitive from the program (e.g., a database query operation), we pass enough information for the long operation to send messages to update the program status.

Example: Console Program

1. The user creates a new console program by calling an API such as /api/createProgram. The input is the authToken, the program name, etc.
2. We add an entry to Arc.programs (assigning it an ID) and return a program descriptor (which includes the ID).
3. We create an initial source file: Main.gs (Grid Source) and store it on Arc.source under the proper ID.
4. The UI gets the program descriptor and requests the source code. The UI displays the source code in an editor.
5. The user can edit the source code; we either provide Save/Cancel buttons or we continuously save. Later we can create versions.
6. When the user runs the program, we call an API to start running: /api/runProgram, which gets the program ID and any parameters (which we can handle later).
7. CodeSlinger creates a program instance record in memory. Program instances communicate via program ports, which have a well-defined protocol. One port protocol is "console", which allows a program to output line-oriented data, and receive input.
8. We run the program on a thread in CodeSlinger and allow it to interact with its ports via standard primitives.
9. The UI polls for events from the running instance and gets updates, such a port changes (output) and program events (termination).