Multi-User Domain

Edit and load code modules over the web with an online IDE. Anything you can enter into the console can be automated with a script.

The requirement of a programming language originates from the interactive command-line experience of the MOO. Multiple commands batched together and structured programming syntax implements microservices in terms of individual instructions run within the server vm.

The motivation behind new code and not say, hacking PyPy, is in not trying to emulate a precise version of Python. Moreover, the language design is guided by emulation of the MOO VM.

Agent System Library

The two primary types of resource in the library are activity modules and interfaces. Both are represented by text documents, but are used in different ways. Interfaces are commonly used for the purpose of addressing and serving web views. The url path is used to step into the library tree, and then into the YAML structure of the interface document to find a named view that can be processed for each web request. Interfaces can also be loaded from running programs using the 'structure' native, and are loaded such that uncontrolled access to the memory is protected meaning allocations are limited by user quota.

Writing a Native Tool

A native tool is set in the configuration under the AgentSystem section. The tool's scope contains members and functions available to the executing agent.

Parameters:

path: the path in the agent system where the scope of the tool is hosted. package: a fully qualified package/module import name that must be on the python path.

Cannot be combined with filename.

filename: a local filesystem path specifying a script to load the tool from:

.py: load a new dynamic python module initialized with the code in the script

file and set that module as the native tool scope

.wmc: requires WRLC. Load a YAML structure from file as tool scope.

Cannot be combined with package.

access: optionally, when filename is .wmc. A dot-separated list of attribute

strings that are sequentially accessed from the top of the structure. The last attribute is stored as the tool scope.

Writing a Service Facility

A service is an object that is loaded from the python import system, initialized in python and then set in the registry with a pre-specified name. Services are set in the configuration under the Services section.

Each option's key name must begin with the identifier 'facility.' and can follow with anything. These keys are first sorted in alphabetical order and then loaded that way, so you can specify that a service load before or after any others by sequencing this key name.

The option's value is a fully qualified python package/module import name that specifies a module on the python path as well as the last attribute dereferencing an object class within that module. That class is then instantiated during registry configuration and the service is started and stored.

Agent System Calling and Object Instantiation

A call into the library is divided into two categories: method invocation and instantiation.

Instantiation is a chance to create a memory-sensitive storage object, but it must be tied to a library module as its type. Having a type defines the activity and operation of the object (subroutine methods), organizes the runtime, and enables the power of a native interfacing layer. As a memory object, an instantiated ($) version of a library path can store properties and data according to user quota.

Accessing an attribute on the 'create' native allows for an attribute chaining method that builds a path to the target path, but the objects emitted for an attribute lookup are not themselves LibraryNodes. Rather, they are temporary create._index nodes that represent an attribute-based access layer to the library. Therefore, accessing the underlying LibraryNode is done with another call to 'create', for example, to access a method defined by the library activity at the path:

$($.components.services.object).method(args)

This is because the attribute chain of create carries with it the intended operation of an instantiation:

$.components.services.object(args) # Instantiate components/services/object

Dot syntax emits the underlying LibraryNode already, because the intended action of a dot expression is to access an object attribute, not perform instantiation:

...services.object.method(args) # Calls the method

But an instantiation can be performed on a LibraryNode object, allowing this syntax:

$(...services.object, args) # Instantiate ../../services/object

The difference is that of one between a relative and an absolute import.

Similarly, the 'call' native object allows attribute-chaining of path components but the intended action is to perform a method invocation. In this case:

call.components.services.object.method(args)

bypasses instantiation and attempts to execute the subroutine or package tool native. The same thing can be achieved by calling 'call':

call('components/services/object/method', args)

Agents are Asynchronous

Programs in the agent system are effectively interrupted, periodically, allowing multiple user tasks to execute concurrently. In contrast, Python is a synchronous language because even with async def/await it still relies on explicit program- pausing statements in the code in order to yield. Similarly, greenlets allow task switching but only with explicit calls in the python code.

One way to think of the platform is that it exposes computational capabilities and the python runtime by embedding it in any variety of program, while limiting storage and executionary resources. When enabling an object model as a network service, use the StuphOS library as a layer in between your program and your users to organize access.

Users should be concerned by the platform only to use it to generate (or view) content, and be aware of permission requirements when doing kernel-specific actions, or, when programming access by granting these permissions for agent system access by user identities.

Termination & Stepping Control

The phaseware kernel avoids relying on pthreads or native threads so that it can decide when to suspend or terminate a task, and instead relies on a hypervisored virtual machine to sequence multi-tasking instructional contexts. This separates individual thread-like execution continuations into systematically controlled units while providing seamless interoperation of all commands, triggers and library program code. In this system, memory and database resource usage is tracked and constrained by user allocation limits.