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 flush

Question 16 (2012):

Submission reference: IN2168

What is the exact syntax for outputting BELL along the error channel? I am simply writing:

    error ! BELL

and getting an "I/O list item 1 does not match protocol" compile error.

Answer 16:

That compiler error message is generated if BELL has a type that is different from that carried by the error! channel.

The include directive:

    #INCLUDE "course.module"

in the program file makes available lots of things, including BELL (which is defined as a BYTE constant with VALue 7, the ASCII code for bell). So long as you haven't re-declared BELL with another type in your own code following that directive, it has type BYTE.

How is the error! channel declared, somewhere above your line that doesn't compile? It should be a "CHAN BYTE error!" parameter. If it is, then your line will compile. Honest!

For the code to execute correctly, that "CHAN BYTE error!" parameter must be connected to the second output channel parameter of the main q4 process (also called error! in your starter code file, q4.occ). At least, the ASCII code in BELL will be delivered to the terminal window running your program. So long as that terminal window is configured to react to that code (e.g. by pinging or flashing the screen or both, as does the occPlug window), then all will be well.

Beware that some older releases of the Transterpreter required the error! to be flushed, in the same way as needed by the screen! channel. The current Windows version (20110201.1855) does not have that requirement.

Correct (Unix) behaviour for the standard error channel is that anything sent there is delivered immediately to the terminal window. For the standard screen channel, characters are buffered until either an end-of-line ('*c') or flush (FLUSH) is received, or the buffer becomes full: when any of these things happen, the buffer is flushed to the terminal window.

Keywords: q4 , flush

Question 74 (2011):

Submission reference: IN2144

Consider the following top level processes:

  PROC main.1 (CHAN BYTE out!)
    out.int (1, 0, out!)
  :

  PROC main.2 (SHARED CHAN BYTE out!)
    CLAIM out!
      out.int (1, 0, out!)
  :

The first prints "1", whereas the second prints nothing. Adding a FLUSH (or newline) "fixes" it.

Why does a SHARED channel introduce this behaviour?

Answer 74:

First, I confirm getting the same behaviour that you report (using KRoC under Ubuntu, version 11.04, Linux).

The need to flush characters sent to the screen channel depends on the operating system (if there is one) in which the occam-pi program is running. Both in the KRoC support for occam-pi (compiled code plus multicore scheduler) and in the Transterpreter (interpreter), we have tried to provide the behaviour that is normal for Unix standard output (which is that characters are buffered until either the buffer is full or a special flush character is received).

What happens to characters still in the Unix standard output buffer when a program ends is a grey area. It would be OK simply to discard them, as happens with your main.2 program. It would be OK to flush them out, as happens with your main.1 program. However, we ought to be consistent about this and we will see if we can do that!

Thank you for your question. It is really about the interaction between the occam-pi system and its host operating system. Please be assured that such matters are not part of the syllabus for this module and no questions requiring such knowledge would be asked in the exam on this module.

Keywords: flush , shared-channel

Question 37 (2009):

Submission reference: IN1837

What does flushing the screen do?

Answer 37:

Look at the questions under flush in the keyword index (see below for a link), especially Question 91 (2000).

Keywords: flush

Question 51 (2004):

I have started Q5 and was wondering if you could give any tips on how to convert a character to upper case. And also what you mean on flushing and how to do this.

Answer 51:

Just as a side-note, Q5 is not for assessment -- but doing it anyway yourself is useful! There are essentially two ways to convert between lower and upper case characters. The first is to do it arithmetically (since `BYTE's can be treated as regular values):

    upper.char := (lower.char - 'a') + 'A'

Of course, you'd better check that `lower.char' really is in the range `a' to `z' first. The second method is more cunning, and relies on the way ASCII characters are assigned:

    upper.char := lower.char /\ #DF

For flushing, see the answer to Question 91 (2000).

Keywords: q5 , flush

Question 114 (2003):

Hi,

I dont quite understand when we should use `flush(out)'. Should this be after every time we make a statement like:

    out.string ("Philosopher ", 0, out)

or after each set of changes such like:

    out.string ("Fork ", 0, out)
    out.int (n + 1, 0, out)
    flush (out)

Answer 114:

After each set of changes. See the answer to Question 91 (2000).

Keywords: q7 , flush

Question 23 (2001):

What is the difference between:

  out ! FLUSH

and:

  flush (out)

Answer 23:

None! As you can see by looking at the source code in /usr/local/work/co516/libsrc/utils.occ:

  PROC flush (CHAN OF BYTE out)
    out ! FLUSH
  :

Keywords: flush

Question 91 (2000):

A friend told me that I should be using:

    out ! FLUSH

after every single output. My program works perfectly well without them. Do I need to include them for safety?

Answer 91:

Not for safety reasons. Unix flushes characters written to its standard output whenever the associated memory buffer gets full or when it gets a new line character. In addition, KRoC forces Unix to flush its buffer when the FLUSH character is sent.

You should flush your animation output after each completed update of the screen (but not, of course, after each character). If you did not and action was progressing slowly in your animation, you would not see anything until the Unix buffer became full when, suddenly, you would see everything that had happened since the last time the buffer was flushed. This is because individual animation updates would not usually include a new line character. If your animation is very active, you will be continually filling the Unix buffer and, so, would see things happening suddenly in bursts (as a full buffer is flushed), separated by periods in which nothing seems to happen (as the buffer is being filled).

However, if your animation is very active but includes a user freeze command and you haven't sent a FLUSH, the animation would freeze but you would not see the latest updates. Of course, you could respond to a freeze by sending a FLUSH ...

But if there are other ways of interacting with the animation (see a7-1997 and a7-1998 in the answers directory on raptor), you will need those FLUSHes. Otherwise you may run into latency problems: what you see on the screen might be the state of the animation a while back - the latest updates are buffered up somewhere and have not been sent to your screen yet!

Keywords: flush , animation

Referrers: Question 33 (2010) , Question 37 (2009) , Question 51 (2004) , Question 114 (2003)