Skip to main content Skip to navigation

Department of Computer Science

Cadence resources

A number of resources relating to the Cadence environment are linked to this webpage. There are many issues surrounding Cadence and its relationship to EM - these will be subject of Nick Pope's forthcoming doctoral thesis. In keeping with its status as a research prototype, Cadence has evolved to what is now a relatively stable form, but is still far from fully documented and explored (to some extent the best way in which to describe Cadence is still unclear and its semantics is best grasped through its use). If you wish to use Cadence in an exploratory fashion, it makes sense to work alongside others so that you can compare notes and more readily distinguish quirky features from genuine bugs. The material on this page will be developed and supplemented in response to requests made and information contributed by CS405 students between now and the WEB-EM-7 submission deadline. Requests and contributions should be made via the Cadence DIY ("do-it-yourself") thread in the CS405 forum.

Documentation

Cadence is an environment that is centred on the DOSTE interpreter. The Cadence IDE, the Warwick Games Design (WGD) library and EDEN are all examples of modules that can communicate with DOSTE. DOSTE itself is conceived as a special kind of operating system, and has been indeed deployed in this way (there is a version of DOSTE that will boot entirely on its own). In the CS405 module, the main interface to DOSTE is via the DASM notation.

Where EDEN aspires to represent all kinds of state by definitive scripts, DOSTE captures current state via a combinatorial graph: a family of nodes connected by directed edges. Each directed edge has a label which is also the label of a node in the graph. A DOSTE observable is associated with a sequence of labels that is interpreted from L to R and thereby identifies a node and label. Whereas the values of observables in a definitive script change only through the intervention of agents (all state-change is by "explicit" redefinition), observables in DOSTE can be dynamic in character. The current state in DOSTE is at all times being updated, so that the structure of the graph is subject to change. For more details of how DOSTE relates to Cadence, see Lecture 2 at http://www2.warwick.ac.uk/fac/sci/dcs/research/em/teaching/cs405-1011/lectmon2.pdf. For more about the syntax and interpretation of DASM, consult Chapter 4 of Nick's draft thesis.

A particular strength of DOSTE is the management of context. A node can be interpreted both as an observable in its own right and/or as an observational context for other observables. As a simple example, a string in DOSTE has a standard representation by an observational context that contains observables 0,1,...,N, where N+1 is the length of the string s and i is assigned the value of the i-th character, together with an observable size.

The computational model underlying DOSTE can be viewed as based on navigation. The actual interpretation of labels attached to nodes is exceedingly flexible. For the purposes of performing arithmetic we may wish to interpret numerical labels as integers in a suitable context for instance, and interpret the node associated with "1 plus" as labelling edges from node 1 to node 2, node 2 to node 3, etc. More general types of computation can also be treated as a form of generalised 'look-up' in this way. For more discussion of such issues, see section 4.3.2 of Nick's draft thesis.

The semantics of DASM was the subject of Lab 3 in CS405 in 2009-10. Significant changes have subsequently been made to the notation, of which the most radical is the introduction of a new mode of definition resembling the 'is' in EDEN (in effect 'is' in last year's DASM was what is now 'willbe'). An updated version of last year's Lab 3 (likewise Lab 4) will be made available shortly, but it is still possible to make sense of the lab exercises provided that you read 'is' as "willbe" (in the present version of DASM denoted by ':='). Another syntactic change to DASM has been in the form of the conditional, and the use of ".." to specify the context for observables in the branches of the conditional expression.

Though knowledge of the inner workings of DOSTE should not typically be necessary, html documentation of the source code can be generated automatically. The most recently generated documentation can be found here.

Context variables: an expression of the form @X can be used to designate a node in the DOSTE graph. This expression serves as a temporary store for a specific node in the graph to enable quick acess. Assignments of the form:

@X = (.a b c);

and

.a b c = @X;

are both valid. The currently defined context variables can be identified by looking in the

.notations dasm variables

observational context.

Tutorial materials

We are hoping to compile some notes on the following topics, which have so far only been covered incidentally in labs from this year and last:

  • prototypes: cloning and deep cloning - for an ilustrative example, consult the wordgame exercise in Lab 6 and the prototype Scout interface below. In cloning rather than deep cloning, a copy is made using the current values of observables that are associated with subobjects. In deep cloning, these subobject observables are themselves cloned. You can see the impact of this by omitting the %deep annotations from the prototype Scout interface script below, and noting the impact on the values of the observables x and y.
  • making your own C++ extensions (the subject of Lab 4 in CS405 in 2009-10 with reference to: Making a GUI, Adding a module, Agents and events)
  • using the Warwick Games Design library (WGD)
  • basic support for agency within DOSTE itself (a recent experimental feature added by Nick - see simple example)

Another topic to be considered is the environment you should use for the submission of Cadence models and how the standard config.dasm files can be customised.

Examples

In the absence of detailed documentation of Cadence, it will be useful both to consult actual working models and to read more about the motivating ideas behind them. Examples of Cadence models are the subject of Chapter 5 of Nick's draft thesis. Other examples can be found in the labs, and will be made available when WEB-EM-6 is published. Models that should be available now or very shortly include:

The traffic lights model and the last two examples are hybrid Cadence-EDEN models. As discussed in Lab 6, these have to be run with the EDEN module loaded by entering the following command via the Cadence IDE:

%include "eden/eden.dasm";

In principle, these hybrid models can be captured in a single EDEN script incorporating "%dasm" segments that can be loaded via the EDEN interface, but in practice this seems to be problematic (cf. note in the Cadence DIY Forum). In interpreting such an EDEN script, you should enter the code segments associated with %dasm (without of course entering the %dasm itself!) via the DASM interface in the Cadence IDE as scheduled in the script.

Installing Cadence

To date, the best way to make use of Cadence outside the department has been to install it on Ubuntu. The source for Cadence can be found in the subversion repository at http://svn.uwcs.co.uk/repos/knicos/projects/Cadence. Details of how this installation can be done can be found here. Cadence has also been installed on the Mac platform. It can be challenging to install the WGD and EDEN modules. WGD requires a good graphics card with the appropriate drivers, whilst EDEN involves a complex configuration of packages.

Aspirations

There are several projects concerning Cadence that may be of interest:

  • A topical focus for future work (including some MSc dissertations) is on developing networking extensions: based on distributed, web-enabled, mobile architectures etc, and constructed either by combining Cadence at the very bottom level, adding a web interface, or introducing a simple JAVA API for services.
  • There is also scope for new interfaces e.g. a QT interface for EDEN.
  • Agency extensions to DOSTE beyond those discussed above are worth exploring.
  • Domain-specific languages can be added to DOSTE using C++ modules.