In this lab, we shall explore the possibility of linking EDEN and DOSTE that tkeden-2.10 supports. Some prerequisite knowledge of how DOSTE and EDEN work independently such as has been introduced in previous labs will be assumed.

1. Basic exercises in linking DOSTE with EDEN

The link between observables in DOSTE and observables in EDEN is established via observables that are represented by scalars (integer and real) and strings. To check this out, you should first carry out a few simple experiments in the DOSTE-EDEN environment of tkeden-2.10. To this end, first invoke the command:

~empublic/teaching/cs405/run lab6

You will notice that the interface contains four notation radio buttons: the %eden, %donald and %scout notations associated with the EDEN interpreter, and the %dasm notation associated with DOSTE. The only direct link between EDEN and DOSTE is made via observables defined in the Eden notation. Since Donald and Scout both translate to Eden, it is possible to link observables in these notations to DOSTE also, as will be illustrated in the lab.

In the Input Window, you can enter Eden definitions that define scalar and string values. For instance, you might write a short script to record the number of days (days), hours (hrs), minutes (mins) and seconds (secs) in a number of weeks (wks), and set up an observable numsecs that contains the string: "There are <secs> seconds in <wks> weeks" [hint: str() will convert a numerical value into a string, and // can be used to concatenate strings]. Check your script by assigning different values, and using the writeln() and querying (?) features. When you have developed such a script, it is a good idea to register a version of it in the Input Window with a prefix "%eden", as this input can then readily be recalled and re-executed without needing to touch the notation radio buttons.

In the interests of experiencing changes of state, it is useful to set up a simple means to monitor the current values of scalar observables. The simplest way to do this is to use a triggered action:

proc wnumsecs : numsecs { writeln(numsecs); };

but this is best used for rough and ready visualisation (which can be undone by making the redefinition):

proc wnumsecs  { };

An alternative way to present the current state is to use a Scout window:

%scout
string numsecs;
window displaysecs = {
  type: TEXT
  string: numsecs
  frame: ([{10, 10}, 1, strlen(numsecs)])
  sensitive: ON
  bgcolour: "white"
};
screen = < displaysecs >;

You can check out the syntax for such a window from the 'Scout quick reference' on the Help menu of the Input Window. To appreciate how the components displayed in Scout are translated into Eden, you can query Scout observables in Eden:

%eden
writeln(screen);

This shows that scalar and string data has a prominent role in display definition. (Evaluation in Eden of this nature is also useful in disclosing when some component of the display is undefined (@), which typically accounts for a failure in the screen updating.)

You may have noticed that EDEN output  is returned in the Output Window, whereas DOSTE output is returned via the console window in which the interpreter was invoked. In studying the integration of DOSTE and EDEN, it may helpful to detach the EDEN Ouput Window so that it can be relocated independently on the display - this can be done via an option under the View menu in the Input Window. To see how Eden observables can be viewed in DOSTE, you can invoke:

%dasm
 %list .eden base;

- not forgetting the 'space' before the '%list'. The output from this query is the list of all the observable names currently in the EDEN symboltable - for instance, you can find the observables 'wks' and 'secs'. In other words, the EDEN symboltable is the set of attributes of the @root eden base object in DOSTE. The values of explicitly defined scalar and string observables  can be redefined either in EDEN or DOSTE. You can check out this out by redefining the value of the observable wks in DOSTE and EDEN, and inspecting the result in both. More interesting is the way in which you can define the EDEN observable wks by an is definition in DOSTE. For instance, try making an is definition for wks that causes it to decrement from any positive value to zero. Notice how (as discussed in Lab 3) this decrementing process continues to operate when new explicit positive values are assigned to wks. To gain further control over the speed of the decrementing process - which is rather fast if unconstrained, you might like to experiment with the clock mechanism introduced in Lab 3. This can be accessed and loaded via the File menu in the Input Window as the file tick.dasm.

Generally, it is the explicitly defined observables that are amenable to manipulation in this way. You can relate this to the capacity we have for conceiving observables as having a current value (as in a snapshot), yet also being continuously changing (as in a video). It is worth being aware that the continuous processes of update in DOSTE are based on an underlying clock implemented in EDEN (see the discussion of edenclocks in the Eden Quick Reference and query the value of this special observable in EDEN). Note that in some circumstances, the value of edenclocks may be reset - as, for instance, when you import an existing file that already contains a definition of this observable.

Another way in which to connect EDEN with DOSTE is to link the values of Eden observables to mouse actions, and then refer to these in DOSTE is definitions. For instance, you can arrange that the 'numsecs' display is static unless the left mouse is depressed in the text window. [Hint: First choose the View history option under the View menu, then observe how depressing the mouse in the text window generates a definition for the Eden observable displaysecs_mouse_1. Write a definition for an integer observable monitormouse that  registers when the mouse is depressed. Now use this observable to control the way in which the observable wks is updated in DOSTE.]

As an independent exercise to test whether you have assimilated the general ideas introduced above, use DOSTE with EDEN to create a environment in which the number of minutes and seconds  elapsed is recorded on the display, and recording can be reset and resumed under mouse control.

2. Making a cartoon Stargate

This exercise highlights the different styles of modelling in DOSTE and EDEN by linking the original DOSTE Stargate model (cf. Lab 1) with a 'cartoon' style Stargate created in EDEN using Donald. An important aspect of the exercise is to expose some of the hidden issues that you encounter when adopting these styles and encourage you to think about the relative merits and drawbacks of the two approaches.

Restart tkeden-2.10 by running the Lab 6 script again. To load the Donald cartoon Stargate, use the File menu to open cartoonstargate.d then press the Accept button to execute the script. In this cartoon, the 9 chevrons are equally spaced around the perimeter, as are the 38 symbols indexed from 1 to 38 on the inner wheel. If you inspect the end of the cartoonstargate.d file, you will find two for-loops commented out. Either can be used to rotate the inner circle,  as in dialling, by incrementing the observable _angle. Note the use of _angle to reference the Donald observable angle, and the role of eager() in this context. Why is the choice of 342 in the second for-loop significant?

Suppose that ix is an index that takes on values 0 to 341 modulo 342. Formulate a definition for _angle in terms of ix and the constant pi (PI in Eden) to ensure that chevron 1 meets a symbol (i.e. exactly bisects the segment of the inner ring corresponding to a symbol) whenever ix is divisible by 9. Assuming that chevron 1 meets symbol 1 when ix is zero, formulate definitions for the observables meets1 and symbolmeeting1, where

• meets1 is true for the current value of ix if chevron 1 currently meets a symbol
• symbolmeeting1 is the index of the symbol that meets chevron 1 whenever meets1 is true.

Animate the cartoon Stargate in such a way that chevron 1 is locked whenever meets1 is true, and that a message of the form "Chevron 1 meets symbol <x>" is displayed. Now formulate corresponding definitions for observables meets2 and symbolmeeting2 for the other chevrons. [Hint: if you can't immediately spot an answer, or want to check an answer, experiment with the model manually first, then frame your definitions. You may find it useful to reindex / relabel the chevrons!]

Now load the DOSTE Stargate by using the File menu and navigating to the appropriate subdirectory Stargate in CS405 and load stargate.dasm then gate.dasm. Link the behaviours of the 'real' Stargate and the cartoon Stargate to the ticking observable included in the tick.dasm file. For this purpose, attempt to frame DOSTE definitions such that

• ix is incremented every second
• the lighting up of chevrons in the real Stargate is synchronised with the locking of corresponding chevrons in the cartoon Stargate.
• @stargate rotation is synchronised with changes in the observable _angle.
  

Explain why the chevrons in the real Stargate don't then light up when they meet a symbol! [Hint: If it's not obvious, reorient the Stargate so that it is being viewed like the cartoon Stargate.]

Reflect on the following relevant issues:

• The way in which the real and cartoon Stargate models were initially conceived.
• How easily each model could be to changed so that it conformed with the other.
• What criterion is used in the real Stargate to identify locking.
• How we could determine whether - or ensure that - only one chevron-symbol meeting occurs at any moment.
• How the abstract model of chevron-symbol meeting for the cartoon Stargate might best be modified to be faithful to the real Stargate.

3. Another basic exercise in linking DOSTE and EDEN

Exercises 1 and 2 illustrate some of the potential of DOSTE as a way of supporting analogue processes and giving greater realism to models. Another powerful feature of DOSTE is the support it gives for referenciing observables - e.g. for switching attention between one observable and another. Earlier versions of EDEN do offer very limited support for this through the 'virtual agent' feature, but this is only implemented in a superficial way, can be problematic, and is now deprecated. The following exercise shows how the much more powerful and well-conceived referencing mechanisms in DOSTE serve to give better support for virtual agency in EDEN.

For this exercise, restart tkeden-2.10 as before, and load in the file template1sq.s. This file is a template for a cell from the Sudoku grid (cf. Lab 5). Now enter the following input:

%eden
 >>square12

This creates a new "virtual agent" context within the Input Window, as shown by the annotation "current agent: square12". Make the definitions:

parX = 1;
parn = 2;

Type ">>" to return to the normal context.

You can inspect the value of the observables associated with the virtual agent "square12" by querying the observable square12::parX etc.

Repeat the above steps to create appropriate values for parX and parn within the context of the virtual agent "square23".

The observables created within these virtual agent contexts are recorded within different subobjects of the eden object within DOSTE. To see this, enter:

%dasm
@eden = (.eden base);
@sq12 = (.eden square12);
   %list @sq12;

and check out the values of the DOSTE observables @eden parX and @sq12 parn. Define the context @sq23 similarly.

Introduce an observable choosesquare in EDEN, then construct a dependency in DOSTE such that the value of the @eden parX  is that of @sq12 parX when choosesquare is 0 and is otherwise that of @sq23 parX. Adapt your model so that (e.g.) the square on the screen moves from one position to the other whilst the left mouse is depressed.

4. The 8 puzzle

For a rather more ambitious exercise, you can try to implement a variant of the well-known sliding tile puzzle, which normally operates with 15 tiles in a 4 by 4 grid. In this case, the puzzle has 8 tiles arranged in a 3 by 3 grid. The objective is to set up a particular arrangement of tiles by sliding tiles into the vacant square.

Some resources that might save you effort in building the puzzle are supplied. They consist of

• definitions for nine windows labelled with the letters A,B,C etc, together with a spare window that you may wish to use
• DOSTE definitions that identify the grid as a combinatorial graph in which the 9 squares are linked by adjacency via Left, Right, Up and Down
• some Eden definitions to capture Scout observables as explicitly defined observables that can then be accessedd via DOSTE.

These resources can be found in the files scoutdefnsEx4.s and gridindasm.dasm.