CS 404/504: Program Monitoring and Visualization HW#3

In this homework you are to get your feet wet with the Unicon monitoring facilities. If monitoring facilities are available, the command unicon -features and the Unicon keyword &features will list event monitoring in your build.

Note to Windows users: Windows Unicon binaries built from sources in the period 1/6/2019 to 2/13/2019 (possibly longer) may claim event monitoring to be present, but was not reporting events due to a bug. Test whether things work, and report your experiences to me. If event monitoring is broken in current public binaries, I will post some new ones on the class web page.

1. Test the co-expression switch on your version of Unicon. A simple test of these facilities from the Icon and Unicon test suite is given in coexpr.icn. It should not crash, and should produce output something like this. I have seen some implementations where this test passes, but heavier uses of co-expressions such as program monitoring may still fail.
2. Try the monitors scat.icn and piano.icn, discussed in class. Download and compile (with unicon -c) scatlib.icn before compiling scat.icn.

   In order run piano or scat, you will have to have a unicon program that can be run under the monitor. The recommended sample programs to play this role are at http://www2.cs.uidaho.edu/~jeffery/courses/monvis/suspects/. To try each one, you would download the .icn and the corresponding .dat file, compile the .icn file, perhaps test to see that they run outside of monitoring OK, and THEN you can try running scat or piano on them. For example, if you downloaded the first one (beards.icn and beards.dat) you would say unicon beards to compile it, and then say

   ./beards <beards.dat
   

   to run it outside of monitoring, or

   ./piano beards <beards.dat
   

   to run it under the piano monitor. As a reminder, here are the suspects/ that you may want to use first in experiments and homeworks in this class. The suspects have pre-generated .json files, created using this reference implementation of HW#1. It might have bugs; please report any trouble.
3. Modify your HW#2 and animate the active procedures using the color coding given by scat (red for user-defined procedures, green for built-ins). The active procedure should be drawn in a solid color with white text. Other currently live procedures that are inactive waiting for a value should be rendered with an oval around the procedure name in the color that is defined by scat for the number of calls that have been made on that procedure. Procedures not currently live should be drawn with a washed out color halfway between their scat color and white. Procedures that were never called at all should be drawn in black and white. After an initial full rendering in black a la HW#2, you should use the evaltree library module like scat does.