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 output

Question 103 (2004):

How do I output the value of "n.sat.down" to the screen ? Is the only way to add an "out" channel the PROC header and do an "out.int" on it ?

Answer 103:

If "n.sat.down" is a tag in a variant protocol, it doesn't have any meaningful value. Some meaningful data might be communicated as part of the protocol, however. You mention adding an "out" channel, but to what PROC in particular ?

To avoid complication, the correct place to handle the output of this information is in your "display" process. Wiring it up to the "security" process (by default the only process that knows how many philosophers are sat down) should be fairly straight-forward.

Keywords: q7 , output

Question 100 (2004):

Where can we get help on how text (ASCII characters) are laid out on a screen ?

Answer 100:

This has been covered (or for Friday groups, will shortly be covered) in your seminars. However, there is plenty of information in past questions. E.g. the questions related to animation.

Keywords: output

Question 27 (2004):

When I run `./q1' I get the following error message:

    KROC: Range error / STOP executed (signal 4)
    KROC: Fatal error code 1, core dumped
    Abort (core dumped)

Could you give me some hints about what's wrong with my code ?

    [snip]
    out !  BYTE x
    out !  BYTE y
    out !  BYTE z
    out !  BYTE avg 
    out !  BYTE '*n'
    [snip]

Answer 27:

The above outputs will definitely cause the problem. If the value in `x' were 0, this will output an ASCII-null -- which produces nothing on the screen, not the character `0'. If the value in `x' were 65, this will output the character `A' -- since 65 is (I think) the ASCII code for `A'. It will definitely not print out the string "65"! If the value in `x' were 1000, this will crash your program as you cast `x' to a `BYTE' -- occam BYTEs only take values between 0 and 255 inclusive. None of this is what you want!

Your `out' channel is connected (from its instance in your `q1' process) to the top-level `screen' channel. To print INT values to such a channel, you must convert them to the characters (BYTEs) coding the decimal digits that we use to represent them. This is not trivial. Fortunately, there's a ready-made PROC in the course library that you can use to do this -- out.int. Suppose we invoke:

    out.int (x, width, out)

where `x' has the value 1234, say, and `width' is 6. This outputs ` ', ` ', `1', `2', `3', `4' to the `out' channel. The `width' in the argument list is the field width -- it outputs spaces before the number to make it that many characters wide (which is useful if you want to print right-justified columns of numbers). Have a look at `examples/test_utils.occ' for examples of using it -- and, of course, the model answers to Q1 from the exercise sheet.

To output strings, there is another library PROC. For example:

    out.string ("hello world", 0, out)

outputs `h', `e', `l', etc to the `out' channel. In this example, the field width, 0, happens to be less than the number of characters in the string -- in which case, it is ignored. If we had use a field width of 20, say, than 9 spaces would have been output first (making 20 characters in total).

Keywords: output , out.int , out.string

Question 7 (2003):

In the method `tabulate.int' from q2.occ, how does the sequence:

    SEQ
      in ? n
      out.int (n, 15, out)
      out.string ("*c*n", 0, out)

work ?

I'm curious because I'd like to make a:

    PROC testing (CHAN OF BYTE in, CHAN OF INT out)

procedure/method for testing purposes. In other words, how does the conversion work and is it basically the same to convert the other way around?

Answer 7:

The conversion from an `INT' value to the sequence of decimal digits that represents it is performed inside `out.int'. Essentially it involves a sequence of `modulo 10' then `divide-by 10', until the value is zero. It's mildly more complicated since the digits are generated in the reverse order.

The code for `out.int' can be found on raptor in:

    /usr/local/courses/co516/libsrc/utils.occ

Converting the other way is, as you suspect, largely the reverse. However, it's already been programmed for you (also in `utils.occ'):

    PROC ask.int (VAL []BYTE prompt, INT n, VAL INT max, CHAN OF BYTE in, out)

As an example, your `testing' PROC can be implemented with:

    PROC testing (CHAN OF BYTE in, out, CHAN OF INT vals.out)
      WHILE TRUE
        INT n:
        SEQ
          ask.int ("Enter a number: ", n, 11, in, out)
          vals.out ! n
    :

The `in' and `out' channels should be wired to the keyboard and screen respectively. The screen channel is needed so that characters can be echo'd as typed, in addition to displaying the prompt. `ask.int' handles all the unpleasantness of keyboard input, such as rejecting invalid characters and handling backspace properly.

The `max' parameter specifies the maximum number of digits that may be entered, inclusive of any leading `+' or `-'.

Keywords: q2 , output , conversion

Question 12 (2002):

For the final modification to q4, when my program is running, I press q and the screen outut stops, and then if I press any key a deadlock message comes up and the terminal shows the raptor prompt again.

Answer 12:

Presumably, you react to the q by sending a suitable signal to the same process implementing the suspend mechanism? What we were suggesting was for that process to terminate (i.e. exit its loop and finish) when it gets that quit signal. That leaves no route for the streams of numbers to get to the screen and most of your q4 system is deadlocked.

However, your keyboard monitoring process is still alive, waiting for more keystrokes. If you type anything but the ones it wants (e.g. anything bar 'n', 'i', 'p', 's', 'q'), it swallows it and loops around and stays alive. If you type an 'n' (for example), it tries to output a reset signal to a deadlocked component. That doesn't succeed and the keyboard process is stuck trying to output. There are now no processes left to run - and, now, the run-time system can announce deadlock and terminate. This solution is fine, but the model answer does something slightly different ...

Keywords: q4 , output

Referrers: Question 14 (2002)

Question 8 (2001):

Is the following ok to allow me to see the output clearly in my answer to q2?

  PROC tabulate.int (CHAN OF INT in, CHAN OF BYTE out)
    INT t:
    TIMER tim:
    WHILE TRUE
      INT n:
      SEQ
        in ? n
        out.int (n, 15, out)
        out.string ("*c*n", 0, out)
        tim ? t
        tim ? AFTER t PLUS 1000000
  :

Answer 8:

Yes - but that waits a whole second between each line (which may be a bit long). Also, it's nicer to localise the declarations of the TIMER and its associated variable t (these declarations cost nothing at run-time - so it doesn't matter if they're inside a loop). Follow the link in the answer to Question 7 (2001).

Keywords: output

Question 7 (2001):

When I run my q2 solution, the numbers scroll past so fast I can't see whether it starts with a zero (like it should!). How can I check if my program is working correctly?

Answer 7:

Please refer to Question 13 (2000).

Keywords: output

Referrers: Question 8 (2001)

Question 13 (2000):

I am doing q2. When I run it I can't tell if it is working properly because once I break, I can't scroll up and see whether the 0 appears in the output. Is there any way of dumping my ouput to a file so I can see it all?

Answer 13:

The simplest answer is to get a scroll bar - see the answer to Question 9 (2000) to find out how to get one.

It is possible to redirect your output to a file - but, in this case, that's not a good idea since the output is infinite and you will flood the disc!

Simpler is to pipe your output through the Unix more utility:

  q2 | more

Now, you only get a screenful at a time. Press carriage-return to see one more line or space for a further screenful. To end your program, type ctl-C. Warning: do not type q to quit the more program. That sends a broken pipe signal to the occam process which doesn't handle it properly. Your occam program will exit but not reset keyboard input to echo mode. That means that you get back to the Unix prompt and type in commands ... but you won't see those commands. To restore things to normal, type in (blindly!):

  stty sane

and you will now be able to see what you type again.

An alternative to all this is to slow down the output so that you can read it! For example, put in a tenth of a second delay after printing each output line. Then, only 10 lines per second will be displayed and you will have time to check if your output sequence starts with a zero. One way to do this is to modify the tabulate.int (see the latest version of q2.occ) as follows:

  PROC tabulate.int (CHAN OF INT in, CHAN OF BYTE out)
    WHILE TRUE
      INT n:
      SEQ
        in ? n
        out.int (n, 15, out)
        out.string ("*c*n", 0, out)
        --{{{  delay 100 milliseconds
        TIMER tim:
        VAL INT milliseconds IS 1000:    -- TIMERs measure microseconds
        INT t:
        SEQ
          tim ? t
          tim ? AFTER t PLUS 100*milliseconds
        --}}}
  :

Keywords: q2 , output

Referrers: Question 24 (2003) , Question 7 (2001)