Lab 4 gave you an introduction to JS-EDEN, a web variant of tkeden. It was apparent that JS-EDEN is still relatively immature by comparison with tkeden ("EDEN"). This lab revisits some of the problematic issues that came to light in Lab 4, and gives some guidance on how these may in some cases be addressed.

It then goes on to consider how to make a JS-EDEN counterpart of a standard EDEN model, bubblesortBeynon2007.

Part 1 - Reviewing Lab 4

In this lab, we will again use the Emile variant of JS-EDEN, available at:

http://jseden.dcs.warwick.ac.uk/emile/

Recall the following disclaimer: JS-EDEN is a "work in progress" so be aware that some/all models have bugs/problems.

Please note that this disclaimer is not meant to deter you from using JS-EDEN. Though you are unlikely to be able to make models as ambitious as those that can be developed using the traditional EDEN interpreter, this will not in any way count against you in the assessment of your WEB-EM submission. On the contrary, you are likely to find that it will be easier to think of interesting novel topics to explore if you use JS-EDEN, and this will be to your advantage.

The problems of JS-EDEN use, though somewhat irritating, do not generally have serious consequences and can be surmounted with care. With experience, and judicious use of the Chrome Console and Elements environments, you should be able to steer clear of problematic situations and resolve the issues you encounter (cf. Advice on Using JS-EDEN). An important EM principle to keep in mind in using JS-EDEN is that of continuously tracing the stream of thought, and - when the state becomes temporarily disrupted - you should give high priority to trying to restore stability rather than rush into restarting the modelling activity.

By way of further explanation and illustration, you should first consult a JS-EDEN presentation that revisits Lab 4, and provides some additional commentary on matters arising. This presentation can be loaded directly into JS-EDEN by typing

include("models/cs405/lab4revisited.js-e");

into the EDEN Interpreter Window.

Part 2 - Converting an existing EDEN construal

When you have gained some confidence that you know how to handle the annoyances of JS-EDEN, you are ready to tackle the principal exercise. Your task will be to make a JS-EDEN variant of a standard EDEN model, viz bubblesortBeynon2007. You can find this model in the EM archive. It is also the theme of one of the EMPE presentation presbubblesortBeynon2007 that you can find in the UsingEMPE directory that you should have downloaded into your own space previously following the instructions in Lab 2.

Your first task is to become familiar with the way in which the bubblesort model has been constructed and can be used. You can develop a basic understanding of the model by experimenting with it and by reviewing the contents of the files in bubblesortBeynon2007. The files that define the basic observables are listed in Run.e - they comprise sort.s, sort.d, sort.e, exc.e, maxminfl.e, selmaxminfl.e and rangeline.e. The more sophisticated observables that relate to phases in the sorting process can be found in the bubblesortagents.e file.

Pay particular attention to the key observables that are characteristic of the sorting scenario (such as the list val which contains the keys to be sorted) and those characteristic of bubblesort (such as which phase of sorting is currently in progress - bs_pass - and which position within that phase is currently the focus of attention - bs_pos). The sorting process is automated when the observable autoset has value 1. With autoset=0, you should be able to simulate the process manually by setting the values of bs_pos, bs_pass and exchanging keys as appropriate using the action defined in exc.e.

In preparation for the 'translation' task, you should first check out which definitions in these files can plausibly be directly imported into JS-EDEN, bearing in mind the fact that you may need to re-order definitions to avoid introducing undefined observables on the RHS of a definitions. Note that what translation means in this context is 'finding suitable metaphors for expressing the set of key observables using JS-EDEN rather than EDEN'. A suitable example of a visualisation using JS-EDEN is depicted beneath the EDEN visualisation in the following figure:

In the JS-EDEN visualisation, the array is represented using an html table. The elements that are yet to be sorted are highlighted on a lightblue background - this segment of elements directly reflects the current value of bs_pass. The element that is the current focus, as determined by bs_pos, is depicted without a black border. The maximum and minimum elements amongst those yet to be sorted are shown in green and red respectively. Note the precise correspondence between these visual devices and the alternative devices used in the EDEN construal depicted above.

In order to construct the JS-EDEN construal of bubblesort, you use a Div() in place of the visualisation that is given in sort.s, sort.d and sort.e. The basic template for this Div is as follows:

offsetx = 20; offsety = 10; arrwinDiv is Div("keyarr", offsetx, offsety, 50, 500, arrwinSpec);

where arrwinSpec is defined as follows:

arrwinSpec is "
<table border = '2'>
<tbody>
<tr>
  <th style =" // A_v1 // ";" // B_v1 // ";" // C_v1 // ">" // str(val[1]) // "</th>
  <th style =" // A_v2 // ";" // B_v2 // ";" // C_v2 // ">" // str(val[2]) // "</th>
  <th style =" // A_v3 // ";" // B_v3 // ";" // C_v3 // ">" // str(val[3]) // "</th>
  <th style =" // A_v4 // ";" // B_v4 // ";" // C_v4 // ">" // str(val[4]) // "</th>
  <th style =" // A_v5 // ";" // B_v5 // ";" // C_v5 // ">" // str(val[5]) // "</th> 
  <th style =" // A_v6 // ";" // B_v6 // ";" // C_v6 // ">" // str(val[6]) // "</th>
  <th style =" // A_v7 // ";" // B_v7 // ";" // C_v7 // ">" // str(val[7]) // "</th>
</tr>
</tbody>
</table>";

and the strings A_v1, B_v1, C_v1 etc are defined by dependency so that they specify the CSS style appropriately. For instance, the definition of A_v4 is as follows:

RED="red";
GREEN = "green";
BLACK="black";
A_v4 is "color:"// (( val4==minelt) ? RED: ((val4==maxelt) ? GREEN: BLACK));

- it ensures that the font color is red, green or black according to whether or not the 4th element is currently the largest or smallest amongst the keys yet to be sorted.

The strings B_v4 and C_v4 are similarly specified so as to reflect the status of the 4th element with respect to "being included amongst the elements to be sorted in the current pass" and "being the current focus of attention in the sorting process" respectively. For this purpose, you need to supply quite simple conditions in place of the ...'s in these formulae.

B_v4 is "background-color:" // (...) ? LIGHTBLUE : WHITE;
C_v4 is "border-style:solid;border-color:" // (...) ? ORANGE : BLACK;

The introduction of these new metaphors for state in the bubblesorting is essentially all that needs to be done to realise the JS-EDEN construal depicted above. Much of the EDEN code in bubblesortBeynon2007 can be directly re-used. The process of construction is a little messy because of the need to ensure that JS-EDEN is dealing with reasonably well-defined state at all times. You will probably not have time to complete the construction during the lab, but should be able to figure out what you need to do in principle. Should you require more guidance, the complete history of the interaction that was used to create the JS-EDEN construal depicted above (warts and all!) can be found in the file

/dcs/emp/empublic/teaching/cs405/lab5/historyconstrual.js-e