Execution Platforms

A number of execution platforms are envisaged, but they share the same API when viewed from the network.

Currently, there is an interpreter for the bytecode in the badger/pushlogic directory that can be compiled for embedded systems or workstation use. When compiled for a workstation it is called pusher. A native compiler for the CAN/PIC platform is also planned (has been envisaged).

The pusher interpreter may also pretend to be an execution platform pebble, meaning that it might beacon some metainfo so that a domain manager gives it some bundles to run.

Currently, all platforms speak the ETC protocol over the network.

There is a utility called cmdline that enables one to manually send low-level ETC commands over the network.

The cmdline program allows platform reboot and field read, write and subscribe operations.

Arg syntax is

 cmdline [-nNONCE] [-pNNN] [-dURI] reboot
 cmdline [-nNONCE] [-pNNN] [-dURI] w tag v [ tag v ...]
 cmdline [-nNONCE] [-pNNN] [-dURI] r tag
 cmdline [-nNONCE] [-pNNN] [-dURI] s tag

For example, to change the value on the display panel pebble one can use something like to set a remote field

 cmdline -d tup://169.254.25.193:253 w Pebbles#Display#value 'Hello World'

Several field, value pairs can be supplied to one write command.

There is also a pushdown operation for tuplecore use, but that is not currently used.

Registration

A platform must announce its presence and register with one (or more) domain manager(s).

We have had various registration technologies, including O2S. Atif is currently implementing UPnP and RDF registration.

Device API reflection is currently achieved through the code reflection interface.

Code reflection

A platform exports the source code of its running bundles, including the assertions about the operation of the enclosing domain that its bundles have made. This is called code reflection.

Code reflection is achieved using an HTTP GET and the code is encoded in XML.

Web Interface

Many platforms implement a web interface that allows web-based viewing of internal state and a certain amount of commanding. The web server provides XML and also a canned CSS style sheet for easy viewing.

Pusher: Command Line and GUI Tool

The interactive interpreter for pushlogic on workstations is called pusher.

Figure 10.1: Lanterns - An Example of Pushlogic under GTK GUI

Pusher can be run standalone, on a workstation, with a number of bundles loaded from the command line. Figure 10.1 shows a bundle called Lanterns under the GUI, The output `outside#lantern' is a label and cannot be changed directly with the GUI. It is updated when the value of this variable changes. The input `mains#supply' has a menu from which the user can select `on' or `off'. The inout variables `hall#light' and `hall#Switch' can be changed by the user as well as by a Pushlogic program. Program counters and other local variables are stored in tuples held under the `Local' tab, in a unique sub-tuple for each bundle instantiated on the platform. We also have a locally-written universal UPnP control point, that can perform roughly the same function for a subnet of UPnP devices. We will shortly merge the functionality of these two GUIs.

The GTK GUI allows the user to view and manipulate the TupleCore tree in real time. It uses the tuplecore library to access the TupleCore and it needs a function 'get_domain' which is included in the PushLogic library. It needs to be initialized using 'init_gtk()', and 'gtk_tree(root_tup, NULL)' builds the user interface. A thread needs to be created which runs 'do_gtk()' to exercise the GUI. It creates a gtk_label for output and local variables, which are updated with an upcall from the tuple substrate. For inputs it creates either a gtk_scale if the domain is an integer range, or a gtk_combo_box (i.e. a menu) for an enumerated type.

Th pusher interpreter may also pretend to be an execution platform pebble, meaning that it might beacon some metainfo so that a domain manager gives it some bundles to run.

Pusher Command Line Arguments

Command line arguments are compiled bytecode bundles or options.

The '-nogui' command line option disables the GUI and directs all output to the console.

The '-cycles=nn' command line option makes the platform exit to the OS after so many seconds.

The '-tupdump' command line option prints the internal tuplespace to the console every few seconds.

Bundles should have suffix `.plc ' and this is added if no dot is present in the filename. Alternatively, bundles should have suffix `.plcx '.

Bundles with a .x suffix are XML coded bundles, as reflected from execution platforms. NB: the compiler, pushcomp, generates four object files from each compilation, two of which are loadable by pusher and the remainders are for canning to device ROMs (pushlogic bytecode or .net bytecode).

Bundles are loaded from the current directory or any directory listed on a colon-separated list of directories stored in the PLPATH environment variable.

Bundles can be listed on the command line along with an instance name, separated by an equals. This allows two instances of the same bundle to be loaded. Each will put its local fields in its own local tuple, named with the instance name: for example `ins1=ding.plc ins2=din.plc '.

Console Output

Under the debugger, it is possible for a Pushlogic program to write strings to the console and to exit with a return code. This is done by sending events to certain fields of a local tuple called Platform#System. Library functions to assist with this are provided.

Any constant assigned to Platform#System#sysprint is displayed on the console.

Any integer assigned to Platform#System#sysexit causes the platform to return to the OS using the integer as the return value.

  output Platform#System#sysprint : event;
  output Platform#System#sysexit : event (0..255);