Skip to main content Skip to navigation

Department of Computer Science

Supplementary notes on Cadence

How ~empublic/bin/cadence is set up to execute

If you are unfamiliar with Unix, you should note that ~empublic/ is shorthand for /dcs/emp/empublic/. The files in this directory are publically readable, and are a useful source of additional information.

The command ~empublic/bin/cadence is specified using a shell script that can be listed by entering the command

cat ~empublic/bin/cadence

The resulting file is:

#!/bin/sh

export LD_LIBRARY_PATH="/dcs/emp/empublic/lib:/dcs/emp/empublic/share/cadence/modules"
export CADENCE_SCRIPTS="/dcs/emp/empublic/share/cadence/scripts"
export CADENCE_PATH=".:/dcs/emp/empublic/share/cadence/scripts:/dcs/emp/empublic/share/cadence/projects:/dcs/emp/empublic/share/cadence"
export CADENCE_MODULES="/dcs/emp/empublic/share/cadence/modules"
export CADENCE_TKEDEN="/dcs/emp/empublic/share/cadence/lib-tkeden"
/dcs/emp/empublic/bin/cadence.bin $*

This essentially specifies where cadence looks for the resources it needs to load files etc. Note particularly how the shell variable CADENCE_PATH is set up so that cadence first looks for files in the current directory (in which the command is invoked - as specified by '.'), then in the scripts, projects and cadence directories. One of the most important files that cadence loads is the config.dasm file, which (by default - i.e. if there is no config.dasm in the current directory) will be as specified in the ~empublic/share/cadence/scripts directory. The default configuration simply loads the file ui/ui.dasm from this directory. If you inspect the contents of the relevant files, you will be able to confirm the assertion about the default value of the observable '.ui browser root', for instance. Knowledge of how cadence is configured is useful if you intend to develop your own Cadence project.

Useful features of the Cadence IDE

There are a number of features of the Cadence interface that simplify the exploration of models:

  • The Messages, History and Modules tabs associated with the DASM input window respectively give details of feedback and error reports in response to input, record the sequence of inputs entered via the input window, and specify which modules have been loaded.
  • You can right click on a node in the browser to bring up the definition of the corresponding observables in the DASM input window. The current value is also displayed in an auxiliary textbox. For 'is' and ':=' definitions both the definition and the current value are displayed. For an '=' definition, there is only a current value to be displayed.
  • You can also use the environment in the DASM input window created by right clicking on a node to redefine the corresponding observable. For an 'is' definition, only the definition part can be edited, as this determines the current value. For an '=' definition, only the current value can be set. For an '=' definition, you can edit either the definition part, or set the current value. There is a drop-down menu that allows you to switch between these different kinds of definition. To redefine an observable after changing its definition or value, you use the 'Save' button on the left, just above the input window.
  • When you show the history you can double-click on any previous command to bring this into the Input Window. This is a most convenient way to modify the definitions of observables experimentally.
  • You can modify the behaviour of the Browser in several ways by redefining observables associated with the @ui context. Sometimes it is useful to be able to see the ids of nodes, for instance, and this feature can be toggled on and off. In some circumstances, updating the browser consumes too much of the processor time - you can reset the refreshrate for the browser to overcome this.

Some additional points illustrated in Labs 1 and 2

The definitions that you cut-and-paste from the Lab 2 labsheet into the DASM input illustrate some key - and also some tricky - features of Cadence.

As an example of defining a context, see the definition: 

@screen = (.widgets root children);

Note that here the . on the RHS refers to the global root context: the '.widgets root children' context is in effect the desktop area for the WGD environment. Note also that the round brackets () are very important - if they are omitted, you will find that the above definition has the same effect as 

@screen = (.);

Note the very unusual precedence of operators in the arithmetic expression on the RHS of the definition: 

@lift floor_pix is { 400 - (.floor * 100) + (.offsety) };

and in the boolean expression in 

@lift atfloor is {
    .y < (.floor_pix + 2) and (.y > (.floor_pix -2))
};

The association of operators is strictly left-to-right. Note also that putting in extra brackets to make the expression more human readable may lead to parse errors!

Note the use of ".." in the body of the if-statement in this definition (but not in the condition): 

@lift y := {
    if (.atfloor not) {
        ..y + (..direction * (..speed) * (@root itime))
    } else {
        ..y
    }
};

This has to do with the way in which the if-statement is a short-hand ('syntactic sugar') for a more explicit definition in which there is an if 'object' containing 'true' and 'false' components. Note that where there are nested if-statements, you need only use two dots ("..") to reference observables however deep the nesting. For an illustrative example, see the definition of chevdir in the Stargate model (this can be found in gate.dasm in the /dcs/emp/empublic/share/cadence/projects/stargate directory).

Note the way in which boolean expressions can be formulated using 'and', 'or' and 'not'. Note that 'not' should be used as a postfix operator. The use of these boolean operators is illustrated in the definitions of @lift atfloor and @lift y above.

The elegance of Cadence where specifying events is concerned is illustrated in the following code which detects whether the mouse has been clicked: 

        @mouse = (@root input mouse buttons);
        .mousedown := {@mouse left};
        .mouseclick is {.mousedown and (@mouse left not)};

The use of 'is' and 'will be' definitions here neatly expresses the characteristic property of the click event: that at one moment the left button of the mouse is being pressed, whereas at the "very next moment" it has been released.

Cadence remains a prototype, and you should bear this in mind if you intend to use it in your coursework. Be aware - for instance - that the Warwick Games Design (wgd) module was developed by an earlier generation of students who are no longer at Warwick. Whilst the module contains many powerful features, it is still incomplete - for instance, textboxes have yet to be implemented.