---

Script debugging

We would like to offer several tips on debugging scripts:

• Print statements of two kinds can be placed in scripts:
  • Slice.LogLine(string) prints a line on the console window.
  • MessageBox.Show(string) pops up a message box and leaves it there until you click the "OK" button.

  (Make sure the argument in each case is a string. Use the str function to convert ints, floats, TreeNodes, or any other value to string.)

• When Slice crashes, it pops up a dialog box showing the stack trace. For example, a common error is to look for a node with a certain property, knowing that such a node exists, and then using it, only to discover that, in fact, no such node exists, e.g.:

  n = GetCurrentSlide().GetChild("Label")
n["ImageLayout"] = "Tile"
  

  If the current slide doesn't have an underlying image (the Label node), n would be null and the second line would crash. Here is an example of what the stack trace window might look like:

  

  You will note that most of the stack trace refers to code that is in the IronPython implementation, or perhaps in the C# core of Slice; in either case, you have no reason to know or care about it. Starting at the top, look for the first line that is in a Python script, which you can tell because its filename ends with "py". In this case, it is ten lines down: line 419 in scripts.py, which is the second line given above. It's clear in this case what happened. (The function containing these lines happened to be directly bound to a button; if it had been called from another Python function, we would have seen that function named farther down in the window.)

• It is unfortunately impossible for us to rule out the presence of bugs in the Slice implementation itself. There are two ways to know that you have found a Slice bug (although it is also possible to have a Slice bug without either of these conditions):
  • If Slice crashes as above, and there is no Python code appearing in the stack trace, then it can only be a Slice error.
  • If you make a change in the tree that should cause the screen to look a particular way, but it doesn't, then do this: (a) Save the state after making the change, by clicking the save (diskette) button. (Our apps all have such a button, but if you are writing a new app, you may need to add one, if only for debugging.) First review it in a text editor to see if the change you think you made is actually in the tree; if not, then it's your error; but we'll assume that it is there. (b) Start Slice.exe in the Slice folder (normally in C:Program Files), and when the dialog box comes up, select the XML file you just saved. If the display is now correct - that is, the way you thought it should have looked - then the underlying Slice implementation is at fault. Remember, the rule is that the tree is always right; in this case, the tree changed, but Slice didn't respond to that change correctly. If, on the other hand, the screen is the same as it was, then maybe the change in the tree isn't exactly what you thought; for example, maybe you have Visible=False, or you've misspelled the name of a node, or something like that.

    (Note: it is sometimes difficult to simply reload a saved XML file, because each such file has associated initialization functions that may not be appropriate, such as establishing a network connection. You can try removing the Init attribute, but that may cause other problems. In the end, you may have to do some fiddling to get the XML file to load so that you can see whether it is displaying correctly.)

  In either case please write to us at slice@cs.illinois.edu, and give as full a description of the problem as you can. (If you're seeing a stack trace dialog box, you can get an image by clicking Alt-PrtScr and then pasting the image into a mail message.)

• Debugging networked applications can be particularly difficult, not only because there can be problems related to timing and network failure that are difficult to reproduce, but also for a simple mechanical reason: it is inconvenient to debug programs running on several machines, and it is time-consuming to start up several instances of Slice each time you want to do a test run. To ease the latter problem, we have included several Python scripts in the Slice folder that can be used to start multiple Slice instances within an application. In each case, you can look in the script to find a command line that can be cut and pasted into a command window. All these scripts basically work the same: The command line identifies the different instances you want to start; you then hit the space bar to start them one at a time; and finally type "q" to terminate them all. (The scripts assume that you have Python on your machine; when you install Slice, it will copy a dll for IronPython, but that does not give you the command-line version; you should get a version from python.org.)
  • 242.py: Runs one or more 242 apps, depending upon how many times "242" is given in the command line.
  • spring09.py and wipte.py: Runs instances of the various "roles" used in this application: one server, one lecturer, one dashboard, and one or more students. (N.B. For technical reasons explained in the documentation, students are known to the server in this application by machine name rather than student name. This means that any message sent to a student is actually delivered to all students on that machine. In the classroom, there is one student per machine, so the result is to deliver each message to a single student, but this causes confusion when debugging, since all students are running on the same machine. So be forewarned.)
  • display.py Should be invoked with two roles, Display (which must appear first) and Lecturer.