XML CO538 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for debugging

Question 66 (2011):

Submission reference: IN2099

Can we leave the debug dumps (log!) in our code (I use it to display all the calculations and steps)?

If I leave it there, it messes up the operator response part of the output.

Answer 66:

If you have masses of log reports and the screen output is too messy, please comment them out ... but read on ...

A better way (than commenting) to switch on and off debugging reports is to declare somewhere close to the top of your program:

    VAL BOOL debugging IS TRUE:      -- for no debug reports, change to FALSE

and then to wrap all debugging reports with:

    IF
      debugging
        ...  sequence of "log !" reports
      TRUE
        SKIP

Then, you can easily switch off debugging with a single-line change of the declared VALue of debugging to FALSE.

Set this FALSE for your submission. If your program does not work for some tasks, include a README.txt file in your submission that says what does not work and mention the debugging reports in your code and how to switch them on. Making it easier for your markers is always a good idea!

Keywords: mars , debugging

Question 13 (2008):

Submission reference: IN1536

It was mentioned in a seminar that there is a quick solution for doing basic print to screen, for basic debugging in occam, akin to System.out.println() in Java.

I appreciate that test-rigs are the proper way to go, but they are a bit overkill when all one would like to do is inspect a variables contents e.g. corner-cases testing etc. I am using Kroc.

Answer 13:

The code below will work in KRoC, as you are using, but will not work in the Transterpreter (yet!). At the start of your program, somewhere near the #INCLUDE directives:

  #PRAGMA EXTERNAL "PROC C.out.stderr (VAL []BYTE str) = 0"
  #PRAGMA EXTERNAL "PROC C.out.stderr.int (VAL INT n) = 0"

These make available two routines defined in the run-time system for outputting simple strings and integers. To use, e.g.:

  PROC debug (CHAN BYTE kyb?, scr!)
    INT x:
    SEQ
      x := 42
  
      C.out.stderr ("Hello world! x happened to be ")
      C.out.stderr.int (x)
      C.out.stderr ("*n")
  :

As you point out, test rigs (or other screen-connection mechanisms to get program output) are the better way, but can be awkward sometimes. Something that hasn't been covered in the course yet (see slides 2..26 of the shared-etc) is the ability to have a shared screen channel, e.g.:

  #INCLUDE "course.module"
  
  PROC do.stuff (VAL INT x, y, SHARED CHAN BYTE scr!)
    SEQ
      -- maybe do something useful with 'x' and 'y' :)
  
      -- debugging
      CLAIM scr!
        SEQ
          out.string ("Hello world! x happened to be ", 0, scr!)
          out.int (x, 0, scr!)
          out.string ("*n", 0, scr!)
  
      -- maybe do something else
  :
  
  PROC my.program (CHAN BYTE kyb?, SHARED CHAN BYTE scr!, CHAN BYTE err!)
    SEQ
      CLAIM scr!
        out.string ("Hello, shared-screen world!*n", 0, scr!)
      -- now run 3 processes, all writing to the SHARED screen channel
      PAR i = 0 FOR 3
        do.stuff (i, 42, scr!)
      -- without the SHARED attribute, the above would be illegal
  :

This is [amongst many other things!] a handy way to share the screen (or error) channel for debugging purposes. Note the use of CLAIM blocks around outputs to the channel. Some other examples of shared-channels can be found via the shared-channel keyword. This is standard occam-pi and will work in the Transterpreter.

Keywords: debugging