|
| AIR
/ OpenAIR |
|
|
|
AIR is the message layer
of Psyclone. Psyclone is Fully OpenAIR
Compliant. OpenAIR is never used directly by users of Psyclone,
however, calls are made to it via CMLabs AIRPlugs,
which make hooking external programs to Psyclone easy. Including
an AIR Plug in your code allows your program to communicate seamlessly
with other Psyclones running anywhere in the world, through any
TCP/IP (IPv4) network including
the Internet, even through firewalls and home ADSL routers.
RELATED: AIR
plugs JavaAIRPlug JavaOpenAIR
CppAIRPlug OpenAIR
specification AIRCentral |
| AIR
plugs |
|
tutorial_:: |
|
CMLabs calls its non-open-source
AIR adapters "AIR plugs". These are code libraries that
implement the AIR message and routing protocol. The adapters are
used for external executables to easily hook them into Psyclone.
AIRPlugs are available in Java and C/C++ at the time of this writing,
and will be available for various programming languages over time.
Related: AIR
JavaOpenAIR CppAIRPlug |
| after= |
|
tutorial_:: |
|
A parameter of the trigger
message as specified in the psySpec.
Specifies that the triggering should happen a certain number of
milliseconds after the listed message type is posted. Example:
<trigger after="2000"
type="System.Ready"/>
RELATED:
message type |
| Blackboard |
|
|
tutorial_:: |
| A blackboard is a special
kind of information and data store, meant to keep global state of
an evolving system, often at multiple levels of representation detail.
The blackboard also is a way to keep global state for a system.
Although used primarily in A.I. for systems trying to understand
its inputs in order to respond intelligently, blackboards are can
be extremely useful for building systems with complex, evolving
states, as well as for systems with distributed processing. Psyclone's
whiteboards are a special implementation of a scheduling blackboard.
RELATED: whiteboards |
| Boostrapping the
system |
|
|
tutorial_:: |
| In an event-driven system
there is always the question of which event is the initial one.
When Psyclone starts up it creates the Whiteboards first and then
it posts a message called Psyclone.System.Ready.
You can start your system by using this message type as a trigger
for one of your modules. You can also attache timing to the startup
of your modules using the after=
parameter in the trigger specification:
<trigger after="500"
type="Psyclone.System.Ready"/>
This will trigger the module 500 milliseconds after the message
Psyclone.System.Ready has been posted.
RELATED: whiteboards triggers
|
| Catalogs |
|
|
tutorial_:: |
| Catalogs are components
that can provide access to large amounts of data and that have a
query mechanism built in. Catalogs are a way to abstract access
to information. Catalogs follow a simple query-response pattern
that is separate from the whiteboard messaging system. There are
two catalogs built into Psyclone: FileCatalog,
which provides an easy API to reading and writing files in a runtime
specified location, and Persistent
Record Storage Catalog, which provides modules with the
ability to save their state or data for later reloading, in the
present runtime system or at a later time during a different run.
A generic catalog is typically created using the SDK and loaded
into Psyclone from a dll.
Any module in the Psyclone system can ask a catalog a question
and receive an answer back, without actually having to know the
format of the data stored. An example could be a large SQL database
with proprietary information, where modules need to extract names
and addresses, but cannot know the format of the database. A Catalog
could be constructed with a bit of code, which can receive questions
from modules, then search the database and provide an answer back.
Another hypothetical example is a Google Catalog, where modules
can ask a question and get search result URLs back, without having
to know how to communicate with Google. A third example is for learning,
where some modules add data to a knowledge base and others ask questions
about the data.
|
| Console
/ command line |
|
|
| Psyclone is started from
the command line in a console window.
Example (Linux):
>./psyclone port=20000
Command line parameters that can be passed into Psyclone: |
| PARAMETER |
VALUE |
EXAMPLE |
COMMENTS |
| port= |
[portnumber] |
port=10000 |
This is the only
required parameter. Must be a positive integer above 1024 |
| spec= |
"[path][valid psySpec]" |
spec="../myPsySpec.xml" |
The path is optional |
| verbose= |
1 ... 4 |
verbose=3 |
How much run-time
info Psyclone prints to the console |
| html= |
"[path]" |
html="html" |
Where Psyclone's
built-in Web server can find the HTML files. Default is 'html'.
|
| psycloneport= |
[portnumber] |
psycloneport=10001 |
This will override
any specification of Psyclone port in the psySpec and the default,
which is 10000 |
|
| Constructionist
AI |
|
|
|
Constructionist AI is a general methodology in that facilitates
the development of large artificial intelligence systems. An example
of a methodology following the philosophy of Constructionist AI
is the Constructionist
Design Methodology described on the MINDMAKERS
site. The main premise of Constructionist AI is to develop tools,
principles and mechanisms for helping AI researchers construct enormously
large systems with more speed and efficiency.
RELATED: CAI
|
| Contexts |
|
tutorial_:: |
|
Contexts are global states
in Psyclone. They can be used to manage the runtime behavior of
modules. Contexts are defined as a tree, e.g. Root.Branch1.Branch2
or A.B.C.D; in a typical system
specific modules are used to post contexts and manage transitions
between them. The syntax of contexts is period-delimited —
they look exactly like message types.
Example: If we create a system that records the
color of people's garments as they walk by a camera pointed out
the window we might have a people-detecting module that detects
the presence of people and several color-estimation modules that
estimates the color of clothing (each module is a specialist in
a particular color). We now create a context called People.Present.
The people detector will post this context whenever it detects
people and the color modules will then be in-context and thus
will be able to process the video. When people are not present
the people detector will post a different context, People.Absent.
As soon as People.Absent context is posted, Psyclone
will list the color modules as out of context,
they would receive no triggers from that point on, and hence,
would not run until People.Present was posted again.
A context is specified in the psySpec using the <context>
tag in the <module> spec.
All modules have a context in which to be active (having no context
specified is like having the global, top-level context). A module
can have more than one context specified, however, at runtime a
module picks one and only one of its contexts (the last one posted)
in which it is active.
The dot notation in the above examples is always used to build
the context tree. To post a context use the Psyclone.Context message
type and append :<myContextName>
after it, where <myContextName> is e.g. A.B.C.D
or Root.Branch1.Branc2. Notice the
use of colon for separation, resulting in an actual posted message
type of Psyclone.Context:Root.Branch1.Branch2.
(Expert point: This posted
message type is an actual message posting event, so context postings
can also be used as triggers — i.e. any module can be triggered
off a context posting.)
There is no use of wildcards in context notation. |
| CoreLibrary |
|
|
| Psyclone builds on the CMLabs
CoreLibrary for many of its basic functions. CoreLibrary is a multiplatform
object library for C++ (Linux, Win32, MacOSX, PocketPC). It provides
many of the common objects found in Java (Strings, Threads, Collections,
etc.) and has the ability to send objects across the network.
RELATED: CoreLibrary
on SourceForge |
| Cranks |
|
|
|
A
crank is a Psyclone term for a method
which can be referenced from the psySpec
as part of a module's functioning. All modules have one crank per
phase [example].
Cranks are specified in the phase part of a module. When a module
gets a wakeup its crank gets run. Typically the first thing that
the crank should do is check the trigger message or the retrieved
message whether it makes sense for it to run the main part of the
crank, which typically involves computing what the module is made
for computing.
RELATED: psySpec
phases wakeup
|
| External
modules |
|
tutorial_:: |
| External modules are written
to connect to Psyclone but to run in their own process space. External
modules can run on the same machine as or on a separate machine
from Psyclone. Additionally, external modules can be started manually
or they can be started
automatically with special configuration for the module in a
psySpec.
Like all modules, external modules register with whiteboards for
triggers (message and stream types), and post results of their processing
to whiteboards, in the form of messages and/or streams. External
modules use AIRPlugs to connect and
talk to Psyclone. Even though the external modules live outside
Psyclone, their phases, triggers, cranks, parameters and contexts
can still be defined in a psySpec; doing so has several benefits,
among others to increase the speed at which the whole system can
switch between system-wide states, so-called contexts.
RELATED: modules
internal modules whiteboards
contexts |
| FileCatalog |
|
tutorial_:: |
| The FileCatalog allows a
module to read a write files from a name location specified in the
PsySpec. It uses the generic Psyclone catalog
functionality but is built directly into Psyclone and therefore
available to be used by any module, internal or external. The FileCatalog
has Catalogs can have any number of parameters and is typically
created using the SDK and loaded from a dll.
RELATED: catalogs
StorageCatalog |
| Internal
Modules |
|
|
|
Like External
Modules, Internal Modules can be configured in the psySpec with
triggers, retrieves, posts and cranks. Cranks are code infused from
external libraries (dlls on Windows
and Shared Objects on Linux and
Mac), meaning these run inside Psyclone, which typically makes them
run much faster than External Modules. Cranks for Internal Modules
are created using the Psyclone Software Development Kit (SDK).
Note: The nature of dynamically
loaded libraries where they are loaded and unloaded periodically
means that static and global variables loose their meaning. When
creating internal crank functions do not use global or static variables
in your code. Furthermore, on some UNIX systems such as Linux you
will get errors when trying to load a library with static or global
variables, usually complaining about an undefined symbol: __dso_handle.
If you see this, go through your code and remove all global and
static variables.
RELATED: modules
external modules OpenAIR
specification whiteboards |
| maxcount= |
|
|
|
The maximum number of messages
that a whiteboard should hold at
any one time.
RELATED: whiteboards |
| maxsize= |
|
|
| The maximum size, in megabytes,
that a circular media stream buffer can hold. Once the maximum is
reached the oldest data starts to get overwritten.
RELATED: whiteboards |
| Media
streams |
|
tutorial_:: |
| A media stream is a type
of streaming data that a whiteboard
can make available on a subscription basis. Streams is a more efficient
mechanism for transporting data between modules in cases where the
meta-information about the data doesn't change. It's interface (API)
is very similar to the message API.
RELATED: whiteboards |
| Message
type / stream type ontology |
|
|
| Using an ontology to define
message and stream types can grately enhance the future flexibility
of a system, making it easier to (a) change, (b) integrate with
external, unknown systems, (c) expand and build upon. To make an
ontology for message types, each level in a dot-delimited message
type graph (TopLevel.Sub1.Sub2.Sub3.Etc.LeastSignifLevel)
is carefully defined so that other users can use the levels to describe
their own message types.
The top level should always be a unqiue root. For example, if a
company called XYZ creates its ontology, putting XYZ as the top-level
makes all subsequent type identifiers unique to that company. Defining
rules for how to use the sub-identifiers makes use of the message
type ontology more consistent. For example, if XYZ builds speech
recognizers, it might have several levels dedicated to the type
of pre-processing that the audio goes through. Hypothetical message
type in such an ontology could be XYZ.Audio.Raw
and XYZ.Audio.Filtered.EchoCancellation.Stage1.
|
| Messages |
|
tutorial_:: |
Messages in Psyclone are formated
in XML according to the OpenAIR
specification. Psyclone is fully OpenAIR
1.0 compliant; the slot format for messages is specified here.
Message names follow the OpenAIR
specification of message types, which uses a dot-delimited string
where the first part indicates the root namespace, and the subsequent
segments describe the type of content that the message relates to,
of increasing specificity from left to right.
The following table is provided as a quick reference only; the
full spec can be found here.
Implementations of OpenAIR can be found here.
|
| SLOT NAME |
CONTAINS |
COMMENTS |
| Type |
Dot-delimited type |
Example: Input.Audio.Raw
|
| ID |
Global unique identification
tag |
|
| From |
Name of module that posted
the message |
|
| To |
Name of whiteboard to receive
the message |
|
| cc |
Name of module(s) to receive
a copy of the message (whether the module registered for its
type or not) |
Modules listed
will receive the message whether they registered for its type
or not |
| PostedTime |
Timestamp (in milliseconds)
when the message left the module which posted it |
Ex: 2004.02.0001
12:20:41:129 Reflects the moment of the call to post(
) to within a microsecond or less, under normal operation |
| ReceivedTime |
Timestamp (ms) when the whiteboard
(component listed in the To slot) received
the message |
Ex: 2004.02.0001
12:20:40:128 |
| Content &
language |
The
content of the message — what the module whants to convey
by posting it. Must be ASCII.
The language that the Content
is expressed in, e.g. XML, Lisp, Python, HTML, Java Script,
or unspecified. |
The Content
can be autoparsed by the whiteboard if it recognizes the message
type and content format. |
| InReplyTo |
A single Reference to the
Message to which this Message is a reply, grouped by the Reference
tag |
|
| Stored |
Name of the whiteboard where
the message is stored |
|
| History |
References to past messages
relevant to this one. |
This feature
not fully implemented in version 0.5 |
| Comment |
Human-readable comment |
Can be used
optionally as an extension slot |
|
| Modules |
|
tutorial_:: |
|
Modules in Psyclone are a way to organize function. Think "executable
program". A Psyclone module can be (1) a stand-alone executable
that executes in a regular manner as any program would, running
in a computer's operating system (to do so the executable uses a
Plug, e.g. JavaOpenAIR);
a Psyclone module can also be (2) an internal
library that is loaded into Psyclone.
Modules are essentially conceptual constructs which help organize
the creation of large Psyclone systems. Modules register with whiteboards
for triggers (message and stream types), and post results of their
processing to whiteboards, in the form of messages and/or streams.
Internal modules are specified in the Psyspec; external modules
use OpenAIR / AIR plugs
to connect and talk to Psyclone.
RELATED: internal
modules external modules
whiteboards |
| Network |
|
|
|
| Psyclone allows you to run
your system as multiple executables that communicate via messages
or streams. Here are the main topics on networking:
For standard message passing Psyclone relies on TCP, even though
other delivery messages might be added in the future. Each component
will autodetect whether the receiver of a message is located in
the same physical executable, in which case it will be delivered
directly through memory. If not, it automatically opens a TCP connection
to the receiver if one is not already open, and sends the message.
If a connection fails, it will be automatically reconnected if possible
and only after two retries will the message parsing fail with notification
to the sender.
When a module connects to Psyclone through a firewall or some
other unidirectional routing device and it suspects that Psyclone
cannot connect directly back to it, the module can open a two way
connection to the components inside Psyclone. This means it will
hold a normal sending connection as well as one additional receiving
or callback connection, acting as if the remote component had actually
connected back to it in the first place. The remote component will
automatically use this latter connection when sending messages if
this is available. If this connection is broken, the module will
automatically re-establish this if possible or keep retrying until
successful.
If Psyclone loses a connection with an external module and needs
to send a message to it, it will retry twice for every message,
before giving up. This will of course slow down Psyclone a bit as
it can take up to 50 milliseconds to retry a connection, so in the
future Psyclone might try for a set number of times and then unregister
the module completely, waiting for it to reregister when it again
is available. |
| Persistent
Record Storage Catalog |
|
tutorial_:: |
| The Persistent Record Storage
Catalog (StorageCatalog for short)
allows a module to save persistent data that can be reloaded again
after a Psyclone shutdown. It is built into Psyclone and therefore
available to be used by any module, internal or external. A generic
catalog can have any number of parameters and is typically created
using the SDK and loaded from a dll.
RELATED: catalogs
FileCatalog |
| Phase |
|
tutorial_:: |
| Psyclone modules use the
concept of phase to implement a simple sequencer that cycles through
a set of local states (phase = local module state). Typically, when
the module posts a message, it will change its phase (see phase
change). A module can have one or more phases; all phases need
to belong to a context; when the context
is true, the phases can be triggered.
So a module can go through a series of states — phases —
within one context. Say for example that a module is processing
raw images in the context Scene.Normal. This module may then start
by looking for any motion (a) and when this has been found, then
look more specifically at the motion in the immediate surroundings
of the moving object (b). The third phase could then be a boundary
detector (c) and when a good boundary has been found, the module
posts this and goes back to looking at the whole scene to find more
objects. So we have the module processing for context:
Scene.Normal: a-b-c-a-b-c-a-
etc.
If the scene then becomes dark all of a sudden, the global context
may change to Scene.Dark and the
same module may continue doing the same Scene.Dark:
a-b-c-a-b-c-a- etc. or may use one or more completely different
algorithms (= cranks) Scene.Dark: a-b-k-a-b-k-a-
etc. or even Scene.Dark: e-f-k-e-f-k-e-
etc.
RELATED: phase
change |
| Phase
change |
|
tutorial_:: |
|
When a module posts a message, the posting of the
message can cause the module's next phase to be activated. This
is called a phase change. Psyclone changes the phase of a module
A (i.e. de-activates the triggers
for the current phase and activates the triggers for the next phase
in line) when a message posted by module A has
the phasechange parameter (in the psySpec specification
of the module) set to "yes". The module can also explicitly
change phase by posting a message of type Psyclone.Module.PhaseChange.
It is always the next phase in line that gets activated, as specified
in the psySpec.
RELATED: psySpec
tutorial phase |
| Phase
spec |
|
tutorial_:: |
|
When a module gets triggered
— i.e. a message that the module registered
for gets posted — Psyclone sends a Wakeup message to the module.
The content in that message contains specifications for which message
types to retrieve and which crank
to run.
RELATED: psySpec
tutorial cranks |
| port |
|
|
|
|
The Internet Protocol (IP) port number
at which psyclone is running. This is provided on the command
line when Psyclone is started.
RELATED: running
Psyclone |
| post |
|
|
|
|
When a module sends out a
message it is called a post.
The temporal model adhered to in Psyclone is that stamping a message
with the postedtime is the very last thing
a module should do before posting it. The assumption is therefore
that at this moment in time, when the postedtime was written, the
module gave up control of the content of the message and the transmission
is ballistic. Therefore, the semantics are that the content of any
message is assumed to be accurate up until the postedtime —
after that the message was not under the control of the module any
more and may or may not reflect accurately what it refers to.
RELATED: modules
messages postedtime |
| PsyclonePro
/ Psyclone nc |
|
|
|
|
Psyclone comes in two main
flavors, PsyclonePro and Psyclone nc. The latter is available as
a free download from http://www.mindmakers.org/projects/Psyclone/.
The other is available in academic and industry versions.
|
| psySpec |
|
tutorial_:: |
|
The psySpec holds setup
specifications for the system. Loaded at Psyclone startup. The
paths that Psyclone will check automatically, relative to the directory
that Psyclone was run from (if no path is specified), are:
./
../
../../
PsySpecs/
../PsySpecs/
../../PsySpecs/
psySpecs/
../psySpecs/
../../psySpecs/
Psyspecs/
../Psyspecs/
../../Psyspecs/
psyspecs/
../psyspecs/
../../psyspecs/
RELATED: running
Psyclone |
| Pub-sub
(Publish-Subscribe) |
|
tutorial_:: |
|
Phrase that refers to the
mechanism of routing information by individual modules publishing
and subscribing to types of data. In Psyclone information is given
types, typically represented as period-delimited strings, e.g.
My.Data.Type or Input.Hearing.Voice.Human, which modules
can subscribe to. Publishing of information is done via (one or
more) whiteboards; subscription is done to the whiteboards as well.
The whiteboards contain the information needed to route any published
information to those who have subscribed to it. |
| Registration |
|
|
|
The contexts, phases, triggers,
retrieves and cranks specified for a module in the psySpec is called
a registration. In addition to up-front specification of this via
the psySpec any module can update its registration at any time during
runtime.
|
| receive
/ receivedtime |
|
|
|
|
When a module receives a
message it will timestamp it with the time of reception - this is
the receivedtime. The temporal model in Psyclone assumes that the
receivedtime timestamping is the very first
thing a module does when it receives a message, to reflect
as well as possible the actual time of message arrival.
RELATED: post
postedtime
|
| retrieve
/ retrieve spec |
|
|
tutorial_:: |
|
A module can retrieve messages
and streamed data from whiteboards. Which data type to retrieve
can be specified in the psySpec and also done at runtime. Example
XML for such retrieval:
<trigger
from="WB1" type="Input.Sens.MultiM.Vision.Human.Found.True"/>
<retrieve from="WBX"
type="Input.Sens.UniM.Hear.Human.Voice"/>
<retrieve from="WBX"
type="Input.Sens.MultiM.Vision.Human">
<latest>3</latest>
<lastmsec>8000</lastmsec>
</retrieve>
The first retrieve asks to be sent a message of type Input.Sens.UniM.Hear.Human.Voice
along with the message type Input.Sens.MultiM.Vision.Human.Found.True
to which it has subscribed; the second retrieve asks to be sent
a message of type Input.Sens.MultiM.Vision.Human
along with that, but with the conditions that if there are more
than 3 such messages in the last 8 seconds
it will only return the 3 most recent of
those. All conditions that are listed like that are ANDed
together.
Retrieve specs can be tied to particular contexts. For example,
<retrieve from="WBX"
type="Input.Sens.UniM.Hear.Human.Voice"/>
<aftercontext>SoB.Alive.SoS.Awake.DialogOn.I-Have-Turn</aftercontext>
<retrieve>
means that all messages of type Input.Sens.UniM.Hear.Human.Voice
will be retrieved if they were posted after
the context SoB.Alive.SoS.Awake.InDialog.ItookTurn
was posted (using postedtime). Other tags that
are available are <duringcontext>
and <beforecontext>. The latter
means any time before the context was posted (was
active); the former means anything that is not included in the conjunction
of the other two, that is, anything that is not
retrieved by calling both <beforecontext>
and <aftercontext> on the same
context. During means any time between this context last became
active and subsequently became inactive. The syntax can also specify
these conditionals as parameters:
<retrieve from="WBX"
type="Input.Sens.UniM.See.Person"
beforecontext="SoB.Alive.SoS.Asleep">
RELATED: whiteboards
psySpec using
retrieves |
| Satellite
Server |
|
|
tutorial_:: |
|
Psyclone can be set up to
automatically start programs, modules and whiteboards on remote
computers. To do this Psyclone needs to be running on the remote
computer(s) in satellite server mode. To start up Psyclone in this
mode use the following command line parameter:
>./Psyclone -satelliteserver
The switch makes Psyclone run in 'damon' mode (as a standard UNIX
daemon), and thus uses almost no resources when idle. This allows
for allowing easy and automatic startup of whiteboards, internal
and external modules on a remote computer.
So a Satellite server merely provides a way to run a module or
a whiteboard on another computer, and is therefore part of the server
system. To take an example, imagine that your AI application initially
can run on one computer, and support 100 users. When you need to
support 300 users you buy two more computers: continue to run your
main Psyclone on the original computer but start up a Satellite
Server (Psyclone in daemon mode) on the new computers. In the PsySpec
you give each of these two Satellite Servers a logical name, <satellite
name="server2" ....> and <satellite
name="server3" ....> and you specify some of
your modules to run on the other servers, e.g. <module
name="bla" satellite="server2">. This
is an easy way of distributing your application onto many computers
without having to worry about communication, synchronisation, etc.
RELATED: Satellites
|
| Satellites
(a.k.a. starting up modules
or whiteboards remotely) |
|
tutorial_:: |
| A Satellite is a feature
of Psyclone that is used if you want to:
• automatically start your external
modules on another computer
• automatically start your internal
modules on another computer
• run a Whiteboard
on another computer
To use the satellite feature of Psyclone you run Psyclone in satelliteserver
mode Satellite Server
on another computer or computers. By specifying which modules and
whiteboards should be started remotely in the psySpec the Satellite
Server will start a Psyclone "Satellite" on the remote
computer(s). Executables for external modules and library versions
of internal modules will need to be placed on the remote computer(s)
on which they are supposed to run.
RELATED:
psySpec satellite
server
|
| Scheduling |
|
|
| Messages with the same priority
level Psyclone will be transmitted in-order; whiteboards use a FIFO
as their main scheduling mechanism. However, when using messages,
a message at a higher priority level will be sent before a message
at a lower priority level.
RELATED:
priorities
of messages and streams
|
| SDK |
|
tutorial_:: |
| The Psyclone SDK fully enables
the creation of internal modules (aka crank
libraries). |
| spec= |
|
tutorial_:: |
|
Command-line parameter for Psyclone, spec=<psySpec
xml file>, where <psySpec xml
file> is the name of the file containing the psySpec xml.
The file can be located in the same directory or in a separate directory
called psyspecs.
RELATED:
starting Psyclone psySpec
|
| Throughput
/ priority |
|
tutorial_:: |
|
Whiteboards will put messages through as fast as they can. If they
are overloaded and messages have priorities, highest-priority messages
will be handled first. Streams have all equal priority and thus
equal throughput. Streams are higher priority than messages.
RELATED:
whiteboards
|
| Trigger |
|
tutorial_:: |
|
Modules in Psyclone use
the concept of triggers to get alerted about when it might be their
turn to compute. A module registers with Psyclone for triggers,
at which point it may get woken up
when any of those triggers get posted.
When a module registers a subscription with a whiteboard all previous
message types that the module subscribed to will be replaced. Psyclone
prints replaced all previous triggers with 1 new triggers and 0
new retrieves to the console when this happens. |
| verbose= |
|
tutorial_:: |
| Command-line parameter for
Psyclone, verbose=n. Controls the amount of basic output
from Psyclone at the console.
Possible values of n:
0 - System default, minimal output; severe errors only, no runtime
printout after startup
1 - verboseness 0 + normal errors and warnings
2 - verboseness 1 + notification of each instance of the posting
of a message from a module
3 - verboseness 2 + notification of each triggering of a module
by some message
4 - verboseness 3 + notification of each instance of message retrieval
by a module and module context switching
RELATED: spec=
console |
| Wakeup |
|
tutorial_:: |
|
A
module gets a wakeup message from a Whiteboard when a message type
it has registered for gets posted to that Whiteboard. The
message, which is of type AIR.Instruct.Wakeup,
contains, in its content
slot, a specification for how the module should behave as a
result of the wakeup, in the form of a phase
spec. If the module has been specified in the psySpec,
this will contain the message types to retrieve, name of the crank
to run and the next phase to go to.
RELATED: contexts
phases psySpec
|
| Whiteboards |
|
tutorial_:: |
|
There are three kinds of
data storage in Psyclone: whiteboards, catalogs and specs. Whiteboards
hold data at run-time, specs hold initialization
data and catalogs hold both.
Whiteboards hold its data in two very different formats, as discrete
messages and as continuous streams.
Messages are like email: You receive a message and that it is that,
unless you write back that is. Streams are like a phone call: You
get a ring and you pick up, and there is something more coming;
the whole thing continues until you hang up. During the phone call
you know that what comes through is audio (as opposed to video or
a fax).
The parameter maxcount limits the number of messages that
the whiteboard can store at any one time. The value that this parameter
takes is an integer (default value is 10000). Whiteboards can be
set to store up to 65k messages. When the limit (maxcount=)
is reached the whiteboard will start permanently erasing the oldest
messages. All messages on a particular whiteboard are guaranteed
to be permanently available on that whiteboard until its upper limit
is reached. (A future planned feature will enable the whiteboard
to move old messages to a database instead of permanently deleting
them.) The OpenAIR message slot time-to-live of messages is not
parsed or used by whiteboards.
Psyclone posts several messages on the AIRCentral
whiteboard at startup. The most important of these is the Psyclone.System.Ready,
which can be used to automatically trigger the startup of other
modules. The message types that Psyclone posts are:
| Psyclone.System.Report.Spawn.InProgress |
When the whiteboards have been created Psyclone
starts to create the rest of the system. This message denotes
the point at which this happens. |
|
Psyclone.System.Report.Status.Whiteboards.Spawn.Complete |
"Complete" message types denote the time at which
the particular acitivity previously reported ended. |
| Psyclone.System.Report.Modules.Spawn.InProgress |
When modules start to get created. |
| Psyclone.System.Report.Status.Modules.Spawn.Complete |
"Complete" message types denote the time at which
the particular acitivity previously reported ended. |
| Psyclone.System.Report.Services.Spawn.InProgress |
Services start their creation. |
| Psyclone.System.Report.Spawn.Complete |
"Complete" message types denote the time at which
the particular acitivity previously reported ended. |
| Psyclone.System.Report.Status.Ready |
This is the final message type posted by Psyclone before the
first and only Psyclone-generated context gets posted. |
| Psyclone.System.Ready |
A context which denotes that all spawning has been completed. |
RELATED:
max= blackboard contexts |
|
