This is the maiden Reference Manual, version 3.1.0, generated automatically by Declt version 4.0 beta 2 "William Riker" on Sun Dec 15 06:58:14 2024 GMT+0.
maiden/maiden.asdmaiden/package.lispmaiden/toolkit.lispmaiden/conditions.lispmaiden/event.lispmaiden/standard-events.lispmaiden/entity.lispmaiden/consumer.lispmaiden/core.lispmaiden/agent.lispmaiden/client.lispmaiden/documentation.lispThe main system appears first, followed by any subsystem dependency.
maidenA modern and extensible chat bot framework.
Yukari Hafner <shinmera@tymoon.eu>
Yukari Hafner <shinmera@tymoon.eu>
(GIT https://github.com/Shinmera/maiden.git)
zlib
3.1.0
deeds (system).
verbose (system).
trivial-garbage (system).
bordeaux-threads (system).
closer-mop (system).
uuid (system).
form-fiddle (system).
lambda-fiddle (system).
documentation-utils (system).
trivial-indent (system).
package.lisp (file).
toolkit.lisp (file).
conditions.lisp (file).
event.lisp (file).
standard-events.lisp (file).
entity.lisp (file).
consumer.lisp (file).
core.lisp (file).
agent.lisp (file).
client.lisp (file).
documentation.lisp (file).
Files are sorted by type and then listed depth-first from the systems components trees.
maiden/maiden.asdmaiden/package.lispmaiden/toolkit.lispmaiden/conditions.lispmaiden/event.lispmaiden/standard-events.lispmaiden/entity.lispmaiden/consumer.lispmaiden/core.lispmaiden/agent.lispmaiden/client.lispmaiden/documentation.lispmaiden/toolkit.lisppackage.lisp (file).
maiden (system).
*debugger* (special variable).
*root* (special variable).
broadcast (function).
do-issue (macro).
enlist (function).
find-consumer-in-package (function).
format-absolute-time (function).
format-relative-time (function).
format-time (function).
get-unix-time (function).
kw (function).
maybe-invoke-debugger (function).
named-lambda (macro).
starts-with (function).
universal-to-unix (function).
unix-to-universal (function).
unlist (function).
update-list (macro).
with-default-encoding (macro).
with-retry-restart (macro).
xnor (function).
xor (function).
*unix-epoch-difference* (special variable).
make-updated-list (function).
swank-connected-p (function).
update-root-for-image (function).
maiden/conditions.lisptoolkit.lisp (file).
maiden (system).
agent (reader method).
agent-already-exists-error (condition).
agent-condition (condition).
client (reader method).
client-condition (condition).
consumer-name-duplicated-warning (condition).
core (reader method).
core-condition (condition).
existing-agent (reader method).
existing-consumer (reader method).
maiden-condition (condition).
new-consumer (reader method).
maiden/event.lispconditions.lisp (file).
maiden (system).
advice (method).
advice (reader method).
(setf advice) (writer method).
core (method).
define-event (macro).
event (class).
finalize-inheritance (method).
direct-advice (reader method).
(setf direct-advice) (writer method).
event-class (class).
maiden/standard-events.lispevent.lisp (file).
maiden (system).
active-event (class).
client (reader method).
client-event (class).
consumer-added (class).
consumer-removed (class).
core-event (class).
instruction-event (class).
passive-event (class).
print-object (method).
print-object (method).
query-event (class).
respond (generic function).
response-event (class).
maiden/entity.lispstandard-events.lisp (file).
maiden (system).
data (reader method).
(setf data) (writer method).
data-entity (class).
data-value (method).
(setf data-value) (method).
entity (class).
id (reader method).
(setf id) (writer method).
matches (generic function).
(setf name) (writer method).
name (reader method).
named-entity (class).
print-object (method).
print-object (method).
find-entity (generic function).
maiden/consumer.lispentity.lisp (file).
maiden (system).
abstract-handler (class).
add-consumer (method).
add-to-consumer (reader method).
(setf add-to-consumer) (writer method).
consumer (class).
consumer-class (class).
core-handlers (reader method).
(setf core-handlers) (writer method).
cores (reader method).
(setf cores) (writer method).
define-consumer (macro).
define-function-handler (macro).
define-handler (macro).
define-instruction (macro).
define-query (macro).
direct-handlers (reader method).
(setf direct-handlers) (writer method).
(setf direct-handlers) (method).
effective-handlers (reader method).
(setf effective-handlers) (writer method).
(setf effective-handlers) (method).
finalize-inheritance (method).
(setf handler) (method).
handler (method).
initialize-instance (method).
initialize-instance (method).
instances (reader method).
(setf instances) (writer method).
instantiate-handler (method).
lock (reader method).
(setf lock) (writer method).
(setf name) (writer method).
name (reader method).
options (reader method).
(setf options) (writer method).
remove-consumer (method).
remove-consumer (method).
remove-function-handler (function).
remove-handler (function).
remove-instruction (function).
remove-query (function).
start (method).
stop (method).
target-class (reader method).
(setf target-class) (writer method).
validate-superclass (method).
validate-superclass (method).
validate-superclass (method).
validate-superclass (method).
args->initargs (function).
cascade-handler-changes (function).
find-entity (method).
reinitialize-handlers (method).
reinitialize-handlers (method).
slot-args->args (function).
slot-args->slots (function).
update-handler (function).
maiden/core.lispconsumer.lisp (file).
maiden (system).
add-consumer (generic function).
add-to-core (function).
block-loop (reader method).
(setf block-loop) (writer method).
block-loop (class).
consumer (generic function).
consumers (reader method).
(setf consumers) (writer method).
core (class).
deregister-handler (method).
handle (method).
handle (method).
(setf handler) (method).
handler (method).
issue (method).
issue (method).
make-core (function).
primary-loop (reader method).
(setf primary-loop) (writer method).
primary-loop (class).
register-handler (method).
remove-consumer (generic function).
running (method).
start (method).
stop (method).
with-awaiting (macro).
find-entity (method).
maiden/agent.lispcore.lisp (file).
maiden (system).
add-consumer (method).
agent (class).
initialize-instance (method).
matches (method).
matches (method).
matches (method).
print-object (method).
maiden/client.lispagent.lisp (file).
maiden (system).
client (class).
maiden/documentation.lispclient.lisp (file).
maiden (system).
Packages are listed by definition order.
maidenorg.shirakumo.maiden
common-lisp.
deeds.
*debugger* (special variable).
*root* (special variable).
abstract-handler (class).
active-event (class).
add-consumer (generic function).
add-to-consumer (generic reader).
(setf add-to-consumer) (generic writer).
add-to-core (function).
advice (generic function).
(setf advice) (generic writer).
agent (generic reader).
agent (class).
agent-already-exists-error (condition).
agent-condition (condition).
block-loop (generic reader).
(setf block-loop) (generic writer).
block-loop (class).
broadcast (function).
client (generic reader).
client (class).
client-condition (condition).
client-event (class).
consumer (generic function).
consumer (class).
consumer-added (class).
consumer-class (class).
consumer-name-duplicated-warning (condition).
consumer-removed (class).
consumers (generic reader).
(setf consumers) (generic writer).
core (generic function).
core (class).
core-condition (condition).
core-event (class).
core-handlers (generic reader).
(setf core-handlers) (generic writer).
cores (generic reader).
(setf cores) (generic writer).
data (generic reader).
(setf data) (generic writer).
data-entity (class).
data-value (generic function).
(setf data-value) (generic function).
define-consumer (macro).
define-event (macro).
define-function-handler (macro).
define-handler (macro).
define-instruction (macro).
define-query (macro).
direct-handlers (generic reader).
(setf direct-handlers) (generic function).
do-issue (macro).
effective-handlers (generic reader).
(setf effective-handlers) (generic function).
enlist (function).
entity (class).
event (class).
existing-agent (generic reader).
existing-consumer (generic reader).
find-consumer-in-package (function).
format-absolute-time (function).
format-relative-time (function).
format-time (function).
get-unix-time (function).
id (generic reader).
(setf id) (generic writer).
instances (generic reader).
(setf instances) (generic writer).
instantiate-handler (generic function).
instruction-event (class).
kw (function).
lock (generic reader).
(setf lock) (generic writer).
maiden-condition (condition).
make-core (function).
matches (generic function).
maybe-invoke-debugger (function).
named-entity (class).
named-lambda (macro).
new-consumer (generic reader).
options (generic reader).
(setf options) (generic writer).
passive-event (class).
primary-loop (generic reader).
(setf primary-loop) (generic writer).
primary-loop (class).
query-event (class).
remove-consumer (generic function).
remove-function-handler (function).
remove-handler (function).
remove-instruction (function).
remove-query (function).
respond (generic function).
starts-with (function).
target-class (generic reader).
(setf target-class) (generic writer).
universal-to-unix (function).
unix-to-universal (function).
unlist (function).
update-list (macro).
with-awaiting (macro).
with-default-encoding (macro).
with-retry-restart (macro).
xnor (function).
xor (function).
*unix-epoch-difference* (special variable).
args->initargs (function).
cascade-handler-changes (function).
direct-advice (generic reader).
(setf direct-advice) (generic writer).
event-class (class).
find-entity (generic function).
make-updated-list (function).
reinitialize-handlers (generic function).
slot-args->args (function).
slot-args->slots (function).
swank-connected-p (function).
update-handler (function).
update-root-for-image (function).
Definitions are sorted by export status, category, package, and then by lexicographic order.
This variable sets whether an internal error should call out to the debugger or not.
On deployed systems, this should probably be NIL. The
default value is whether the SWANK package is present
or not.
This variable holds a directory pathname that points to the "root" of the Maiden installation.
The root should mainly be used for storage of runtime
fragments such as configuration, cache, and so forth.
Shorthand to define a consumer class.
This is like CL:DEFCLASS, with the appropriate superclass and
metaclass injected for you. It also makes sure that the class
definition is available during compile-time as well.
See CONSUMER
See CONSUMER-CLASS
Shorthand macro to define an event class.
This takes care of potentially injecting the EVENT superclass
and setting the necessary EVENT-CLASS metaclass. Otherwise it
is identical to CL:DEFCLASS.
See CL:DEFCLASS
See EVENT
See EVENT-CLASS
Shorthand macro to define an event an a corresponding handler in one go.
Special body options are extracted to provide further control over
the definition of the event:
:SUPERCLASSES The superclass list to use.
:EXTRA-SLOTS A list of extra slot definitions.
:CLASS-OPTIONS A list of extra class options.
:DOCUMENTATION The docstring to use for the class.
:ADVICE The advice value to use for the event.
Note that these options will NOT be passed on to the DEFINE-HANDLER
form.
The ARGS are used both for the arguments to DEFINE-HANDLER and as
slot definitions by way of SLOT-ARGS->SLOTS.
See SLOT-ARGS->SLOTS
See DEFINE-EVENT
See DEFINE-HANDLER
See REMOVE-FUNCTION-HANDLER
Defines a new handler on the consumer class.
CONSUMER must be the class-name of the consumer to define on.
NAME must be a symbol denoting the name of the handler
definition. Note that this name will not be carried over
to actual handler instances, as they would otherwise
clash on multiple consumer instances on the same core.
EVENT-TYPE must be a base class for all events that the handler
will receive.
ARGS must be a list of arguments, of which the first two will
be bound to the consumer instance and the event
respectively. The rest of the arguments denote fuzzy slot
bindings of the event.
BODY a number of extra handler definition options as a plist
followed directly by a number of forms to evaluate upon
receiving an event.
The body options are evaluated and passed as class initargs to the
resulting handler instance once one is constructed. Note that as such
the values will be shared across all instances of the handler defined
here. Also note that there are three options which are exempt from
this and play special roles:
:DELIVERY-FUNCTION This option is already provided by default.
Supplying it manually will mean that the body
forms of the DEFINE-HANDLER will be ignored.
:MATCH-CONSUMER Should be a slot name of the event that needs
to match the consumer for the event to be handled.
You’ll want to use this option for handlers of
clients, in order to ensure that the handler from
the client instance that matches the client the
event is intended for is called.
:ADD-TO-CONSUMER By default T; decides whether the resulting
handler instances should be added to the consumer
directly, or to the cores the consumer is added
to.
In effect this constructs an appropriate ABSTRACT-HANDLER instance
and calls UPDATE-HANDLER with it on the consumer class.
See DEEDS:WITH-FUZZY-SLOT-BINDINGS
See DEEDS:WITH-ORIGIN
See ABSTRACT-HANDLER
See UPDATE-HANDLER
See REMOVE-HANDLER
Shorthand macro to define an instruction-like event.
This is essentially the same as DEFINE-FUNCTION-HANDLER with
the following additions:
- INSTRUCTION-EVENT is always injected as a superclass.
- A function of the same name as the instruction is generated that
creates the appropriate event and sends it off to a core.
This thus allows you to simulate a standard function interface
for code that runs over the event-loop. Note that the generated
function will not wait for a response to the event and immediately
returns. The returned value is the generated event instance.
See DEFINE-FUNCTION-HANDLER
See BROADCAST
See REMOVE-INSTRUCTION
Shorthand macro to define a query-like event.
This is similar to DEFINE-INSTRUCTION, with the exception that
possibly two events (one for issue and one for response) are
generated, and that the issue function will await a response
and return with the intended return value, thus simulating a
complete function API over the event system.
If no explicit EVENT-RESPONSE-TYPE is specified, a generic
response event is used instead. See RESPOND.
See RESPOND
See REMOVE-QUERY
Shorthand macro to construct and issue an event onto a core.
The event-type should not be quoted.
See DEEDS:DO-ISSUE
Attempt to construct a lambda with a name.
Note that standard name clashing rules apply and naming the lambda after a CL function will likely fail if the implementation supports package locks.
Macro to update the list with a new item.
The item is added to the list if it is not yet contained
and updated in-place otherwise.
See MAKE-UPDATED-LIST
Waits for a response event to arrive on the core before evaluating the body.
This is useful to write event-driven, reactionary code.
The temporary handler to catch the code is added to the
core’s back loop.
Note that CORE can be one of
- CORE The temporary handler is attached to
the core’s block-loop.
- CONSUMER The first core on the client’s list of
cores is used as above.
- DEEDS:EVENT-LOOP The temporary handler is directly
attached to it.
You can also specify a maximum waiting timeout with the
:TIMEOUT body options. The timeout is in seconds. Similar
to DEFINE-HANDLER, you can also specify a :FILTER test
body option.
See DEEDS:WITH-AWAITING
Evaluate BODY in an environment where the default external format is set to the given encoding.
Only works on:
- SBCL
- CCL
Evaluates body around which a restart is established that allows retrying the evaluation of the body.
Similar to CL:WITH-SIMPLE-RESTART.
Easily add consumers to a core.
The consumers will be started after having been added to the core. Each consumer in the list of consumers can be:
- A symbol denoting the class of consumer to construct
- A string or keyword denoting a package that homes a
symbol denoting a consumer class.
- A list starting with one of the above followed by the
initargs for the class instantiation.
The instances are all constructed before any of them are added to the core or started, so as to catch errors early.
Shorthand function to construct and issue an event onto a set of cores.
Unlike DO-ISSUE, this is a function, so the event-type
has to be quoted.
If THING is a list, it is returned. Otherwise a new list out of the given elements is constructed.
Scans through the symbols in the given package and attempts to find one that denotes a class that is a subclass of CONSUMER.
The first such symbol found is returned.
Formats the universal-time as a timestring in the format of YYYY.MM.DD hh:mm:ss
Formats the time in seconds as a human-readable string.
Time is split up into seconds, minutes, hours, days, weeks, months, years, decades, centuries, and æons.
Formats the universal-time in a (hopefully) appropriate manner.
If the time differs from now by more than the RELATIVE-TIME-THRESHOLD
then the time is printed absolutely, otherwise relatively.
See FORMAT-RELATIVE-TIME
See FORMAT-ABSOLUTE-TIME
Returns the time in seconds since the unix epoch of 1970.
Return the keyword corresponding to the given symbol designator.
Construct a new core instance and add consumers to it.
The resulting core will be started.
See CORE
See ADD-TO-CORE
Might invoke the debugger with the condition.
If *DEBUGGER* is non-NIL, the debugger is invoked with
a CONTINUE restart surrounding it to allow giving up on
handling the condition. Otherwise, if the RESTART
argument is passed, that restart is invoked with the
rest of the arguments as values for the restart.
See *DEBUGGER*
Shorthand function to remove a function-handler definition.
This removes both the event class and the handler it defined.
See CL:FIND-CLASS
See REMOVE-HANDLER
Removes the handler from the consumer-class.
This function simply updates the list of direct-handlers on the class by removing the corresponding abstract-handler.
The class-ish can be a CONSUMER-CLASS, a CONSUMER, or a
SYMBOL naming a consumer-class.
The abstract-handler can be an ABSTRACT-HANDLER, or a
SYMBOL denoting the NAME of an abstract-handler.
See DIRECT-HANDLERS
See ABSTRACT-HANDLER
See CONSUMER-CLASS
Shorthand function to remove an instruction definition.
This removes both the event class, the handler, and the issue-
function it defined.
See CL:FMAKUNBOUND
See REMOVE-FUNCTION-HANDLER
Shorthand function to remove a query definition.
This removes both the event classes, the handler, and the issue-
function it defined.
See REMOVE-FUNCTION-HANDLER
See CL:FIND-CLASS
See CL:FMAKUNBOUND
Returns true if SEQUENCE begins with START.
Convert universal-time to unix-time.
Convert unix-time to universal-time.
If THING is not a list, it is returned. Otherwise the element by KEY from the list is returned.
If both A and B are either true or false at the same time.
If either A or B are true, but not both.
Add the consumer to the core.
If the consumer already exists on the core, nothing is done. If a consumer of the same name already exists on the core, a warning of type CONSUMER-NAME-DUPLICATED-WARNING is signalled.
If a consumer has been added, an event of type CONSUMER-ADDED
is issued onto the core.
See CONSUMER-NAME-DUPLICATED-WARNING
See CONSUMER-ADDED
list)) ¶list) target) ¶Whether the generated handler of this abstract handler should be added to the consumer or the cores of the consumer.
See ABSTRACT-HANDLER
abstract-handler)) ¶automatically generated reader method
abstract-handler)) ¶automatically generated writer method
Accessor to the advice information on the event or event-class.
See EVENT-CLASS
See EVENT
event-class)) ¶automatically generated reader method
event-class)) ¶automatically generated writer method
Accessor to the agent that this object holds.
See AGENT-CONDITION
agent-condition)) ¶Accessor to the blocking back loop of the Maiden core.
This should govern one-time handlers and response events.
See CORE
Accessor to the client that this object holds.
See CLIENT-CONDITION
client-event)) ¶automatically generated reader method
client-condition)) ¶Retrieve a consumer from the core.
If no consumer that matches the ID is found, NIL is returned.
See MATCHES
Accessor to the list of consumers associated with the core.
See CONSUMER
See CORE
Accessor to the core that this object holds.
See CORE-CONDITION
core-condition)) ¶core.
Accessor to the list of cores the consumer is currently registered with.
See CONSUMER
Accessor to the data storage container for the data entity.
See DATA-ENTITY
See DATA-VALUE
data-entity)) ¶automatically generated reader method
data.
data-entity)) ¶automatically generated writer method
data.
Accessor for a single data field in the data entity.
See DATA
See DATA-ENTITY
data-entity)) ¶data-entity)) ¶Accessor to the list of direct handler definitions on the consumer class.
This only holds handler definitions that have been defined for
this specific class directly.
Also note that the handler objects contained in this list are
only abstract-handler instances and cannot be directly used as
handlers.
When this place is set, the consumer-class’ inheritance is
finalized.
See CONSUMER-CLASS
See ABSTRACT-HANDLER
See MOP:FINALIZE-INHERITANCE
consumer-class)) ¶automatically generated reader method
consumer-class)) ¶consumer-class)) ¶automatically generated writer method
Accessor to the list of effective handler definitions on the consumer class.
This holds all handler definitions, including inherited ones.
Note that the handler objects contained in this list are only
abstract-handler instances and cannot be directly used as
handlers.
When this place is set, the list of INSTANCES is updated and
each existing instance is reinitialised through REINITIALIZE-
HANDLERS.
See CONSUMER-CLASS
See ABSTRACT-HANDLER
See INSTANCES
See REINITIALIZE-HANDLERS
consumer-class)) ¶automatically generated reader method
consumer-class)) ¶consumer-class)) ¶automatically generated writer method
Reader for the agent that already exists on the core.
See AGENT-ALREADY-EXISTS-ERROR
agent-already-exists-error)) ¶Reader for the consumer that previously already existed on the core.
See CONSUMER-NAME-DUPLICATED-WARNING
consumer-name-duplicated-warning)) ¶Accessor to the IDentity of an entity.
By default this is initialised to a fresh UUIDv4 string.
See ENTITY
Accessor to the list of weak-pointers to consumer instances.
The elements in the list are instances of TG:WEAK-POINTER and
may point to instances of the consumer class. This list is
necessary to keep track of and properly synchronise the handlers
upon redefinition.
This list is updated whenever a new CONSUMER instance is created
or when EFFECTIVE-HANDLERS of its class is set.
See TG:WEAK-POINTER
See CONSUMER
consumer-class)) ¶automatically generated reader method
consumer-class)) ¶automatically generated writer method
This function creates an actual handler instance from the abstract handler definition.
The instantiation proceeds as follows:
1. The options :FILTER, :DELIVERY-FUNCTION, and :MATCH-CONSUMER
are extracted from the options list.
2. If :MATCH-CONSUMER is given and is eql to T, then the :FILTER
option is extended by surrounding it as follows:
(and (eq ,consumer consumer) ..)
where ,consumer denotes the consumer instance passed to
instantiate-handler.
3. If :MATCH-CONSUMER is given and is not eql to T, then the :FILTER
option is extended by surrounding it as follows:
(and (eq ,consumer ,match-consumer) ..)
where ,consumer is as above and ,match-consumer is the value of
the :MATCH-CONSUMER option.
4. MAKE-INSTANCE is called with the TARGET-CLASS of the abstract
handler, a :delivery-function initarg that is a function that
calls the :DELIVERY-FUNCTION extracted from the option with the
consumer and the event, a :filter initarg that is the value of
the :FILTER option, and the rest of the OPTIONS of the abstract
handler.
See ABSTRACT-HANDLER
abstract-handler) (consumer consumer)) ¶Accessor to the lock that is used to synchronise access to this object.
See CONSUMER
Generic comparator operator.
This compares in a potentially ambiguous "dwim" sense. Various components in the system add methods to make the matching work as much as expected as possible.
named-entity) b) ¶vector) (b vector)) ¶string) (b string)) ¶list) (b list)) ¶uuid) (b string)) ¶uuid) (b vector)) ¶uuid)) ¶uuid) (b uuid)) ¶Reader for the new consumer that is being added to the core.
See CONSUMER-NAME-DUPLICATED-WARNING
consumer-name-duplicated-warning)) ¶Accessor to the list of initargs that the handler should receive upon instantiation.
See ABSTRACT-HANDLER
abstract-handler)) ¶automatically generated reader method
abstract-handler)) ¶automatically generated writer method
Accessor to the primary loop of the Maiden core.
This should take care of the bulk of handlers and events.
See CORE
Remove the consumer from the core.
If the consumer doesn’t exist on the core, nothing is done. Otherwise the consumer is removed from the core’s list.
If a consumer has been removed, an event of type CONSUMER-
REMOVED is issued onto the core.
See CONSUMER-REMOVED
list)) ¶list) target) ¶Respond to the event in an appropriate way.
The response event will be issued on to the same core that the event being responded to was issued to. If the event does not have a specific response event already (through a specialised method on RESPOND), then you may specify the class to use with the :CLASS initarg.
query-event) &key payload) ¶client-event) &rest args &key class &allow-other-keys) ¶Accessor to the target class that the actual handler should be of when the abstract-handler is instantiated.
Defaults to DEEDS:QUEUED-HANDLER
See ABSTRACT-HANDLER
See DEEDS:QUEUED-HANDLER
abstract-handler)) ¶automatically generated reader method
abstract-handler)) ¶automatically generated writer method
consumer-class)) ¶sb-mop.
event-class)) ¶sb-mop.
event-loop)) ¶deeds.
abstract-handler) &rest args &key target-class &allow-other-keys) ¶abstract-handler)) ¶automatically generated writer method
deeds.
name.
abstract-handler)) ¶automatically generated reader method
deeds.
name.
named-entity)) ¶automatically generated writer method
deeds.
name.
named-entity)) ¶automatically generated reader method
deeds.
name.
consumer-removed) stream) ¶consumer-added) stream) ¶named-entity) stream) ¶consumer-class) (superclass consumer-class)) ¶sb-mop.
consumer-class) (superclass standard-class)) ¶sb-mop.
standard-class) (superclass consumer-class)) ¶sb-mop.
consumer-class) superclass) ¶sb-mop.
A condition signalled when an agent of the same name already exists on the core.
See EXISTING-AGENT
See AGENT-CONDITION
See CORE-CONDITION
| Initarg | Value |
|---|---|
:existing-agent | (error existing-agent required.) |
:existing-agent
This slot is read-only.
Superclass for all conditions related to agents.
See AGENT
See MAIDEN-CONDITION
| Initarg | Value |
|---|---|
:agent | (error agent required.) |
Superclass for all conditions related to clients.
See CLIENT
See MAIDEN-CONDITION
| Initarg | Value |
|---|---|
:client | (error client required.) |
A condition signalled when a consumer is added to a core and has the same name as an already existing consumer.
See EXISTING-CONSUMER
See NEW-CONSUMER
See CORE-CONDITION
core-condition.
warning.
| Initarg | Value |
|---|---|
:new-consumer | (error new-consumer required.) |
:existing-consumer | (error existing-consumer required.) |
:existing-consumer
This slot is read-only.
:new-consumer
This slot is read-only.
Superclass for all conditions related to operations on a core.
See CORE
See MAIDEN-CONDITION
core.
| Initarg | Value |
|---|---|
:core | (error core required.) |
Superclass for all condition types in the Maiden system.
condition.
This is an object to represent a handler definition. It contains all data necessary to construct an appropriate handler instance for a consumer.
See ADD-TO-CONSUMER
See TARGET-CLASS
See OPTIONS
See INSTANTIATE-HANDLER
See DEFINE-HANDLER
| Initarg | Value |
|---|---|
:options | nil |
:add-to-consumer | t |
(quote deeds:locally-blocking-handler)
:add-to-consumer
:options
Superclass for all active events in the system.
An active event notifies of a request for an action to be
taken somewhere in the system. It is active in the sense that
it should cause some part of the system to perform an action,
rather than merely notifying of a change happening.
See EVENT
See PASSIVE-EVENT
A type of consumer of which only one instance should exist on a core.
An agent’s name defaults to the agent’s class name.
An agent MATCHES if the class or the class name matches.
If an agent is attempted to be added to a core when an
agent that matches it by name already exists on the core,
a warning of type AGENT-ALREADY-EXISTS-ERROR is signalled.
See CONSUMER
Base class for the block loop on a Maiden core.
See CORE
See DEEDS:EVENT-LOOP
A type of consumer of which multiple instances can exist on a core.
See CONSUMER
Superclass for all events that relate to a client.
This event holds the client it relates to in a slot.
See CLIENT
See EVENT
Superclass for all consumers on a core.
Consumers are responsible for issuing and responding to
events that happen on a core. They do this by having a number
of handler definitions tied to them, which are instantiated
into proper handlers for each consumer instance. Consumers
can have handlers that are registered directly on the consumer
or are instead added to the core the consumer is being added
to. The former allows the grouping of handlers and a more
granular management of resources, whereas the latter allows
you to circumvent potential bottleneck or ordering issues.
See the Deeds library for information on how the event-loop
and handlers work in detail.
Consumers are divided into two classes, ones of which only a
single instance should exist on the core, and ones of which
many may exist on the core. The former are called AGENTS, and
the latter are called CLIENTS. The former usually provide
functionality that is reactionary in some sense. The latter
usually provide some form of connection to another entity and
primarily provide events rather than consuming them. You should
not inherit directly from CONSUMER therefore, and rather pick
either CLIENT or AGENT, depending on which of the two is more
suitable for the kind of consumer you want to write for the
system.
Consumer classes must inherit from the CONSUMER-CLASS class,
which is responsible for ensuring that handler definitions get
properly instantiated and managed over consumer instances.
In order to easily define consumer classes with the appropriate
superclass and metaclass, you can use DEFINE-CONSUMER.
In order to add handlers to the consumer, use DEFINE-HANDLER.
Each consumer has a LOCK that can be used to synchronise
access to the consumer from different parts in the system.
Since Deeds, and Maiden by extension, is highly parallel most
of the time, locking of resources and access to the consumer
from different handlers is vital.
The list of handler instances is held in the HANDLERS slot.
The list of handlers that are tied directly to cores is held
in the CORE-HANDLERS slot. The list of cores the consumer is
on is held in the CORES slot.
You can start and stop all the handlers on a consumer by the
usual Deeds START and STOP functions.
After the initialisation of a consumer, the consumer instance
is pushed onto the INSTANCES list of its class by way of a
weak-pointer. It will also turn all of its effective-handlers
into actual handler instances by way of INSTANTIATE-HANDLER and
push them onto its HANDLERS list.
See NAMED-ENTITY
See COMPILED-EVENT-LOOP
See HANDLER
See CONSUMER-CLASS
See AGENT
See CLIENT
See DEFINE-CONSUMER
See DEFINE-HANDLER
See HANDLERS
See CORE-HANDLERS
See CORES
See LOCK
See START
See STOP
See INSTANCES
See INSTANTIATE-HANDLER
compiled-event-loop.
handler.
named-entity.
Event that is issued after a consumer has been added to the core.
See CORE-EVENT
See CONSUMER
| Initarg | Value |
|---|---|
:consumer | (error consumer required.) |
:consumer
Metaclass for all consumer objects.
It handles the proper instantiation of handler objects when the
consumer is added to a core or the handler definitions are
updated.
See DIRECT-HANDLERS
See EFFECTIVE-HANDLERS
See INSTANCES
See CONSUMER
Event that is issued after a consumer has been removed from the core.
See CORE-EVENT
See CONSUMER
| Initarg | Value |
|---|---|
:consumer | (error consumer required.) |
:consumer
The core of an event system in Maiden.
The core is responsible for managing events, consumers, and
their handlers. It uses two (!) event-loops in the back to
handle event delivery. The first loop, called the primary
loop is where most handlers live. It is (by default) of type
PRIMARY-LOOP and should be fairly speed in delivery, at
the cost that adding and removing handlers will be slow. The
second loop, called the blocking loop is where temporary
handlers that only exist for hopefully a short time live. It
is (by default) of type BLOCK-LOOP and is not optimised
for fast delivery, but much faster at removing and adding
handlers. Thus, whenever you wait for an event for a one-time
request, the handler should be added to the block loop.
Calling DE/REGISTER-HANDLER on a core will automatically add
it to the primary loop. If you want to change the blocking
loop you will have to access it directly.
When an event is ISSUEd onto the core, it is ISSUEd onto the
primary loop and then ISSUEd onto the block loop. The
behaviour for when an event is directly HANDLEd by the core
is analogous.
See PRIMARY-LOOP
See BLOCK-LOOP
See CONSUMERS
See CONSUMER
See ADD-CONSUMER
See REMOVE-CONSUMER
See START
See STOP
See ISSUE
See HANDLE
See WITH-AWAITING
See WITH-RESPONSE
See MAKE-CORE
See ADD-TO-CORE
add-consumer.
add-consumer.
add-consumer.
(setf block-loop).
block-loop.
consumer.
(setf consumers).
consumers.
deregister-handler.
find-entity.
handle.
(setf handler).
handler.
issue.
issue.
(setf primary-loop).
primary-loop.
register-handler.
remove-consumer.
remove-consumer.
running.
start.
stop.
| Initarg | Value |
|---|---|
:primary-loop | (make-instance (quote primary-loop)) |
:block-loop | (make-instance (quote block-loop)) |
:primary-loop
:block-loop
Superclass for all events relating to a Maiden core.
See EVENT
Superclass for entities that have a data storage table.
See ENTITY
See DATA
See DATA-VALUE
Superclass for things that are comparable according to some kind of identity.
See ID
| Initarg | Value |
|---|---|
:id | (princ-to-string (make-v4-uuid)) |
The superclass for all events in Maiden.
An event is an object that represents a change that occurs
in the system. It may also carry relevant information about
the change. Events can also be used to signify requests for
things to happen in the system.
Events need to be ISSUEd onto a core, where they will then
be dispatched to HANDLERs that can process it.
See EVENT-CLASS
See CORE
See DEEDS:EVENT
See DEFINE-EVENT
event.
Superclass for all instruction events in the system.
Instructions are event representations of a change request in the system. They often represent a "virtual" function call.
See DEFINE-INSTRUCTION
See ACTIVE-EVENT
An entity with a human-readable name attached to it.
See ENTITY
See NAME
Superclass for all passive events in the system.
A passive event notifies of a change that happened somewhere
in the system. It is passive in the sense that it provides
information, rather than explicitly requesting information or
explicitly requesting an action.
See EVENT
See ACTIVE-EVENT
Base class for the primary loop on a Maiden core.
See CORE
See DEEDS:COMPILED-EVENT-LOOP
Superclass for all query events in the system.
Queries are events that represent both a change request and
a request for a result to be obtained about the change. They
often represent a "full" function call.
It is identified so that it and its response event counter-
piece can be found.
See DEFINE-QUERY
See DEEDS:IDENTIFIED-EVENT
See INSTRUCTION-EVENT
identified-event.
instruction-event.
Generic response event class.
This event is used to deliver the response payload of a
query-event. Its IDentity must be the same as that of the
query-event that prompted it.
See DEEDS:IDENTIFIED-EVENT
See DEEDS:PAYLOAD-EVENT
See PASSIVE-EVENT
deeds.
identified-event.
passive-event.
payload-event.
| Initarg | Value |
|---|---|
:identifier | (error identifier required.) |
The difference in seconds between universal-time and unix-time.
Converts a lambda-list into a plist to pass as initargs.
More specifically, each variable in the lambda list will be turned into a key-value pair where the key is the keyword corresponding to the symbol name, followed by the symbol itself.
This function computes the effective handlers list for the class and cascades the update downwards in the hierarchy.
Only subclasses that are a subclass of CONSUMER-CLASS and have
been finalized are cascaded.
The EFFECTIVE-HANDLERS list is updated as part of this.
See CONSUMER-CLASS
See EFFECTIVE-HANDLERS
Construct an updated version of LIST where THING is either updated from its old value, or added to it.
The elements in the list are passed through KEY and then
compared against THING using the TEST function.
Converts a list of slot arguments into a lambda list.
See SLOT-ARGS->SLOTS
Converts a list of slot arguments into slot definitions.
The slot-args must be structured like a special kind of lambda-list:
SLOT-ARGS ::= REQ* (&optional OPT*)? (&REST REQ)? (&key OPT*)?
REQ ::= name | (name SLOT-INITARG*)
OPT ::= name | (name default-value? SLOT-INITARG*)
SLOT-INITARG ::= keyword value
In short:
There are no provided-p predicate variables for optional arguments,
but each argument can be followed by a list of possible slot initargs
if it is given as a list.
Each returned slot will also automatically receive an initarg of the same name as the slot, but from the keyword package.
This function is responsible for handling the redefinition of a handler on a consumer-class.
This function simply updates the list of direct-handlers
on the class by replacing the corresponding abstract-handler
or adding it to it.
The class-ish can be a CONSUMER-CLASS, a CONSUMER, or a
SYMBOL naming a consumer-class.
See DIRECT-HANDLERS
See ABSTRACT-HANDLER
See CONSUMER-CLASS
This function attempts to update the *ROOT* to the current location of the image.
See UIOP:ARGV0
Accessor to the advice information that was defined directly on the class.
See EVENT-CLASS
event-class)) ¶automatically generated reader method
event-class)) ¶automatically generated writer method
Attempt to find an entity in a container.
The ID must be matched against each entity in the container
by MATCHES.
See ENTITY
See MATCHES
list)) ¶named-entity)) ¶This handles the updating of handler definitions on a consumer.
The procedure is as follows:
1. All direct handlers are deregistered from the consumer.
2. New direct handlers are instantiated, started, and registered on
the consumer.
3. The old direct handlers are stopped.
4. All core handlers are deregistered from all cores of the consumer.
5. New core handlers are instantiated, started, and registered on the
cores.
6. The old core handlers are stopped.
See CONSUMER
See INSTANTIATE-HANDLER
See HANDLERS
Metaclass for events.
In addition to the effects inherited from DEEDS:EVENT-CLASS,
this class ads so-called "advice". Advice denotes advisory
information about the event that may or may not be processed
depending on whether there are any components that can make
use of the advice.
The advice list is inherited through the class structure.
Advice can also be inhibited for a class and its descendants
by surrounding the advice item with a (NOT ..). Note that
advice items are only tested for equality by EQL.
See DEEDS:EVENT-CLASS
See ADVICE
See DIRECT-ADVICE
| Jump to: | (
A B C D E F G H I K L M N O P R S T U V W X |
|---|
| Jump to: | (
A B C D E F G H I K L M N O P R S T U V W X |
|---|
| Jump to: | *
A B C D E I N O P S T |
|---|
| Jump to: | *
A B C D E I N O P S T |
|---|
| Jump to: | A B C D E F I M N P Q R S T |
|---|
| Jump to: | A B C D E F I M N P Q R S T |
|---|