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 colour

Question 24 (2008):

Submission reference: IN1607

Hey there, several questions for you here, all of them q7 related!

Firstly, a while ago in the slides you mentioned using "Windows" (not the OS!) to output to certain areas of the screen as part of a test rig. How is this done (and what slides was is in!)? It seems like a necessary thing to do in order to do some nice animation effects.

Secondly - colour. I'm using ASCII art - is there a way to make this colourful in occam? How?

Finally - could you give us more information on how marks are distributed for this piece of coursework. Will there be marks for implementation (should I hold back until more or protocols/shared channels etc has been covered?) and code documentation? How much extra to you gain from making the animation 'nice'?

Answer 24:

The part about using 'windows' for debugging output is about putting your debugging output at the right place on the screen. If you're using PROTOCOLs to drive a display process, and/or a SHARED CHAN BYTE, you can engineer this in fairly simply. The main point is to stop debugging output being trashed by other screen-drawing code (which will probably happen if you just write messages to the top-level "screen" or "error" channels). For example:

  PROTOCOL DISPLAY
    CASE
      ...  existing cases
      debug; INT::[]BYTE            --* Debug message (counted array of BYTEs)
  :

  PROC display (CHAN DISPLAY in?, CHAN BYTE screen!)
    ...  existing code
    in ? CASE
      ...  existing tagged inputs

      INT mlen:
      [256]BYTE msg:
      debug; mlen::msg
        SEQ
          cursor.x.y (1, 24, screen!)
          out.string ([msg FOR mlen], 0, screen!)
  :

Or if you have the top-level "screen" passed down as a shared channel:

  PROC philosopher (..., SHARED CHAN BYTE debug!)
    WHILE TRUE
      SEQ
        ...  existing code

        CLAIM debug!
          SEQ
            cursor.x.y (1, 24, debug!)
            out.string ("This is a debug message in the right place*n", 0, debug!)

        ...  more existing code
  :

Regarding colour, yes, this will work provided you're using a terminal that understands the various VT220/ANSI escape sequences for this. There is some support for this in the shared-screen library that comes with KRoC, although that is fairly old now. Details on the actual things that need to be output to generate this can be found here: Wikipedia:ANSI escape code.

As a quick example, however:

  VAL BYTE FG.WHITE IS 37:
  VAL BYTE BG.BLUE IS 44:
  ...  other colours

  PROC set.fg.bg.col (VAL BYTE fg, bg, CHAN BYTE screen!)
    SEQ
      out.string ("*#1B[", 0, screen!)
      out.byte (fg, 0, screen!)
      screen ! ';'
      out.byte (bg, 0, screen!)
      screen ! 'm'
  :

  PROC display (CHAN DISPLAY in?, CHAN BYTE screen!)
    ...  existing code
    in ? CASE
      ...  other tagged inputs

      show.title
        SEQ
          -- draw a banner of some form
          cursor.x.y (2, 4, screen!)
          set.fg.bg.col (FG.WHITE, BG.BLUE, screen!)
          out.string ("Welcome to the display process", 0, screen!)
          screen ! FLUSH
  :

As far as marking is concerned, you will be marked on a combination of the output your solution produces, and the code that implements it. These are divided amongst the tasks that you have to complete, weighted according to relative difficulty, e.g. "adding a display process", "sensible reporting for the forks", etc. There are, however, a number of "bonus" marks available for solutions that go above and beyond the basic requirements. As a general rule, the model "q7" answer (simple text animation), if perfectly coded, can score 100%. A fully-featured animation (with characters walking around the screen, etc.), as we've shown you in the lectures and seminars, can tolerate some coding errors and still score 100%.

Keywords: q7 , colour , animation , ansi

Question 31 (2002):

I would like to use colour in my solution to Q7. The PROC fg.col in shared_screen.occ looks useful ... however, I am unable to use the shared_screen.occ code. I have the following lines at the top of my source code:

  #INCLUDE "shared_screen.occ"
  #USE "shared_screen.inc"

Many errors are generated relating to this, such as:

  Error-oc-shared_screen.occ(337)- pc subscripted too many times
  Serious-oc- Too many errors, maximum is 100.

What am I doing wrong?

Answer 31:

Sorry - we hadn't told you how to use this package. It's not part of the basic "course" library! Before explaining how to access, let me stress that noone needs to find out about and use this stuff - it's only there to provide a rich set of drawing mechanisms for those who want to do some really fancy animation. Even then, you don't have to use it ... but you will end up inventing something similar.

Something anyone could have done is simply copy those two files:

  libsrc/shared_screen.inc
  libsrc/shared_screen.occ

into the start of your own q7.occ file. Then, your own code could simply use anything defined in them. Note that the order is important - the shared_screen.inc must go before the shared_screen.occ file (which uses protocols and data types defined in shared_screen.inc).

Better would be to copy those files into the same directory as your q7.occ file and start your file with:

  #INCLUDE "shared_screen.inc"
  #INCLUDE "shared_screen.occ"

Again, note the ordering! These directives simply tell the compiler to pull in those files at the point of those #INCLUDEs.

Best is not to copy those files at all and use the library. All you haven't been told is the name of the library - which is "ss". Currently, only PROCs and FUNCTIONS are saveable in kroc libraries, which means that constants, data types, prototcols (etc.) have to be pulled in as #INCLUDEs. Anyway, to do this, your file needs to start with:

  #INCLUDE "ss.inc"
  #USE "ss.lib"

These can be followed, or preceeded, by other library accesses - e.g.

  #INCLUDE "consts.inc"       -- standard course library constants
  #USE "course.lib"           -- standard course library

We're not quite done. When compiling, the occam compiler (invoked by the kroc shell script) will find the relevant files. [Note: those working with the Linux kroc need to ensure their OCSEARCH environment variable is set up correctly.] When doing final linking (also invoked by the kroc shell script), we have to tell the linker where to find the library code. In fact, the kroc script uses the standard gcc (Gnu C Compiler) to do this linking - i.e. something different from OCSEARCH happens. Anyway, the compile command needed is:

  kroc q7.occ -lss

Linux users have always had to do something like this to link in the course library (which the kroc script on Solaris machines has been set up to do automatically). So, on Linux, if you want both libraries linked in to your executable, the command is:

  kroc q7.occ -lss -lcourse

Enjoy!

Keywords: q7 , colour , animation