|Home >> All|
|||alice.infrastructure.* (2)||||alice.logictuple.* (6)||||alice.respect.* (21)||||alice.tucson.* (28)|
|||alice.tuplemedium.* (42)||||alice.tuprolog.* (99)||||alice.util.* (26)|
JEditTextArea: jEdit's text area component. It is more suited for editing program source code than JEditorPane, because it drops the unnecessary features (images, variable-width lines, and so on) and adds a whole bunch of useful goodies such as: More flexible key binding scheme Supports macro recorders Rectangular selection Bracket highlighting Syntax highlighting Command repetition Block caret can be enabled It is also faster and doesn't have as many problems. It can be used in other applications; the only other part of jEdit it depends on is the syntax package. To use it in your app, treat it like any other ...
Automaton: Defines a more involved type of TuCSoN agent (compared to Agent one). The agent is structured as a finite state automaton. The behaviour of its states is defined writing public methods; the become method is used to go make a transition from state to state, which in this case means from method to method. It's based on continuation-passing style of arranging computation. TuCSoN automata are spawned using Threads: new Thread(new MyAutomaton()).start the first state (method) executed is always "boot" state (method). to stop shutdown the automaton the state "end" is provided: become("end")
Library: this abstract class is the base class for developing tuProlog built-in libraries, which can be dynamically loaded by prolog objects. each library can expose to engine: a theory (as a string assigned to theory field) builtin predicates: each method whose signature is boolean name_arity(Struct goal) is considered a built-in predicate provided by the library builtin evaluable functors: each method whose signature is Term name_arity(Struct goal) is considered a built-in functors provided by the library typically theory is assigned in library constructor
User: this is the basic class for developing tuple media TCP/IP user. if the user is recognized to be local the interactions with the tuple centre virtual machines are realized directly, bypassing TCP/IP protocol (this is possible because of there is only one daemon service installed on a java VM). if the tuple centre is remote, this class provide the user proxy (or connector) to remote service In this case the class UserListener is the related stub or acceptor, on the remote (daemon) side.
InspectorListener: this is inspector active acceptor class receiving communication events from user proxy and dispatching them to the referenced tuple centre virtual machine. The interaction is bidirectional: output events from tuple centre vm are dispatched to user proxy. the inspector acceptor observe specific tuple centre events according to the current inspector protocol the inspector implements ObservableEventListener in order to observe tuple centre observable events
Event: Represents internal events of the tuple centre virtual machine According to the tuple centre model, an event is characterised by the operation which caused the event, the tuple or the tuple template as information content of the operation, the direction of the event (from agent to the tuple centre, or viceversa), the identification of the agent responsible of the operation, the identification of the tuple centre where the event has happened.
Term: root class for prolog data term. the design follows the Facade Pattern: this class provide the interface for some basic services which are significant only for specific derived classes this is useful because of the derived class are few and well known: Struct and Var. (in this way boring casting is avoid) direct instances of class Term represent numbers (floats and integers)
TokenMarker: A token marker that splits lines of text into tokens. Each token carries a length field and an indentification tag that can be mapped to a color for painting that token. For performance reasons, the linked list of tokens is reused after each line is tokenized. Therefore, the return value of markTokens should only be used for immediate painting. Notably, it cannot be cached.
Inspector: this is the basic class for developing tuple media TCP/IP inspector. as users, inspectors are active agents built with acceptor/connector pattern this class represents the proxy or connector however, different from user, an inspector proxy is connected to only one specific tuple centre inspector can observe a set of events and information described in Inspector Protocol
LogicTuple: Defines the communication language based on logic tuples, which stand both for tuple and tuple template For logic tuple, the matching is the classic prolog matching and the propagation corresponds to unification. A logic tuple is like a Prolog term, usually a Prolog structure characterized by a name and 0 or more argument (which in this case are objects of the class TupleArgument)
TupleCentreVM: Defines the core behaviour of a tuple centre virtual machine. The behaviour reflects the operational semantic expressed in related tuple centre articles. It is abstract because it not specifies how the output events are dispatched. Note that in order to specify a concrete virtual machine, concrete object implementing TupleSet, EventSet, TRSet, Reactor, Reaction must be specified.
Daemon: Daemon class implement the basic behaviour of an TCP/IP infrastructure which listens for new tuple media clients, creates new tuple media, creates client request acceptors. it's the basic component from which derives the infrastructure topology the class has been designed as Singleton pattern: for each java VM only ONE Daemon could be installed
TRSet: Specifies the services which must be provided by the component inside the tuple centre virtual machine collecting and managing triggered reactions as a multiset An important aspect of the component implementing this interface is the ability to execute transactions, that is execute sequence of operations that could be commited or asked to be undone.
UserListener: this is user active acceptor class receiving communication events from user proxy and dispatching them to the referenced tuple centre virtual machine. The interaction is bidirectional: output events from tuple centre vm are dispatched to user proxy an acceptor could serve more then one user proxy (because of it hasn't blocking operations)
TupleSet: Specifies the services which must be provided by the component inside the tuple centre virtual machine collecting and managing tuples as a multiset An important aspect of the component implementing this interface is the ability to execute transactions, that is execute sequence of operations that could be commited or asked to be undone.
TupleArgument: Defines an argument of logic tuple. The argument can be a value ( Value class) or a variable ( Var class). The argument can be constructed using Value or Var - which are used only as constructor classes; instead, the services about argument management are provided by this class
InputHandler: An input handler converts the user's key strokes into concrete actions. It also takes care of macro recording and action repetition. This class provides all the necessary support code for an input handler, but doesn't actually do any key binding logic. It is up to the implementations of this class to do so.
Token: A linked list of tokens. Each token has three fields - a token identifier, which is a byte value that can be looked up in the array returned by SyntaxDocument.getColors() to get a color value, a length value which is the length of the token in the text, and a pointer to the next token in the list.
Prolog: It's the main class of the tuProlog system. Its instances are prolog machine able to manage theories, loading libraries and solving goals. a prolog object is instatiable everywhere and anytime. A prolog object (with default libraries) is also serializable and so transportable through the net.
RTContext: runtime execution context during a demonstration. it keeps track of information necessary to do a correct renaming of variables (time) and a correct unification/deunification of terms (mark) it manages information about current demonstrating goal, current choice explored, open choices
KeywordMap: A KeywordMap is similar to a hashtable in that it maps keys to values. However, the `keys' are Swing segments. This allows lookups of text substrings without the overhead of creating a new string object. This class is used by CTokenMarker to map keywords to ids.
TucsonLibrary: this library allows the exploitation of the TuCSoN coordination alice.infrastructure. only TuCSoN nodes installed on default port (that is 'TuCSoN infrastructure') are reachable through this library refer to tuplemedium documentation for understanding of coordination primitives
Automaton: this abstract class is the base class for implementing automaton abstraction automaton state behaviour is expressed in public method and the become method allows to move computation from state to state method representing state must be public (to allow correct behaviour of reflection)
LuceLibrary: this library allows the exploitation of the LuCe coordination alice.infrastructure. only LuCe nodes installed on default port (that is 'LuCe infrastructure') are reachable through this library. refer to tuplemedium documentation for understanding of coordination primitives
EventOperation: Defines the possible operation types which caused an tuple centre virtual machine event, according to the coordination language of the tuple medium The string representation of the operation involves the name of the operation and the number of argument it requires.