kent logo

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 cursor


Question 47 (2011):

Submission reference: IN2080

ok the good news is that i managed to get things moving inside my prgram, ie, things move to diffrent parts of the screen, the bad news however, is that all that are moving are words rperesenting thte various itmes i have some mulitdimensional arrays set up that create stickmen like figures to use instead of the words, but the problem is, that out.string doesnt seem to acept multidimenisonal arrays, is there a way around this?

Answer 47:

You can easily write your own process to output a 2D array of characters (BYTEs) to the screen. For example, here's one (with a testrig program):

    #INCLUDE "course.module"

    VAL [][]BYTE stickman IS [" O ",
                              " | ",
                              "/ \"]:

    PROC out.icon (VAL BYTE x, y, VAL [][]BYTE icon, CHAN BYTE out!)
        INITIAL BYTE yy IS y:
        SEQ i = 0 FOR SIZE icon
            cursor.x.y (x, yy, out!)
            out.string (icon[i], 0, out!)
            yy := yy + 1                    -- move down a line
        out ! FLUSH

    PROC icon (CHAN BYTE keyboard?, screen!, error!)
        erase.screen (screen!)
        out.icon (39, 11, stickman, screen!)
        out.string ("*c*n*n*n*n*n*n", 0, screen!)

Please see opening rant in the answer to Question 45 (2011).

Keywords: q7 , animation , cursor


Question 43 (2009):

Submission reference: IN1843

How's the effect of moving the characters (philosophers, forks, ...) achieved with the co-ordinate arrays?

Answer 43:

See Question 68 (2000) and Question 104 (2004) (and other questions and answers under the cursor and animation keywords).

Keywords: q7 , cursor

Question 36 (2009):

Submission reference: IN1836

I've been told that I have to use cursor.x.y to create the interface, however, I don't understand how that would work. Could you explain it to me please? Thanks.

Answer 36:

See slide 14 from these slides and this documentation. You should also look at test-utils.occ from your examples folder and check out the cursor keywords entries in the anonymous Q&As.

Keywords: q7 , cursor


Question 68 (2000):

I've forgotten how to implement the lookup table for the screen positions for the dining philosophers. Any help would be appreciated.

Answer 68:

Your animation code should not be highly repetitive with the same logic repeated with different magic numbers - e.g. for displaying new positions of the different philosophers. Having a table of anchor coordinates for each philosopher may help. A table is simply an array of VALues (i.e. constants). For example:

  VAL [][2]BYTE phil.anchor IS [[40, 5], [70, 10], [55, 15],
                                [35, 15], [10, 10]]:

where the [][2]BYTE could have just been [][]BYTE, but being specific about the dimension of the coordinates (rather than the number of them) seems right. We could have been even more explicit and written [5][2]BYTE, but that seems too much. Any way, the compiler will fill in the sizes of any blanks in what we write after the IS.

With the above, it's nice to give names to the two indices of the [2]BYTE array coordinates - e.g.


Then, if we want to move the screen cursor to the anchor point for philosopher i - and we know that that i is a valid philosopher number (i.e. 0 through 4):

    cursor.x.y (phil.anchor[i][X], phil.anchor[i][Y], screen)

or, more efficiently:

    VAL [2]BYTE phil.i IS phil.anchor[i]:
    cursor.x.y (phil.i[X], phil.i[Y], screen)

since it only checks the array index (for out-of-bounds error) and calculates the address of phil.anchor[i] once.

Keywords: q7 , cursor , table , animation

Referrers: Question 43 (2009) , Question 30 (2008) , Question 84 (2003) , Question 29 (2002)

Question 66 (2000):

For question 7, I am trying to draw a boarder for the dining philosophers room. I can do it with lots of cursor.x.y and out.string procedures but this seems time consuming. I thought of doing it in a replicated PAR or replicated SEQ and I wrote this code:

  #INCLUDE "consts.inc"
  #USE "course.lib"

    PAR i = 1 FOR 26
        cursor.x.y (4, i, out)
        out.string ("#", 0, out)

  PROC test (CHAN OF BYTE keyboard, screen, error)
      a (screen)
      ...  other things

But when I compile it, it says there is a type mismatch in parameter 2 of cursor.x.y. This is the y coordinate that I am changing so that the character gets printed on the line below the first one to create a column like this:


Why does the compiler not like the second parameter of the cursor.x.y proceedure? Doesen't it just need to be a number?

Answer 66:

The second parameter of cursor.x.y needs to be a BYTE. Replicator control variables (e.g. your i) are INTs. You need to cast it into a BYTE:

        cursor.x.y (4, BYTE i, out)

See the answer to Question 7 (2000) for information on casting between occam types.

Your PAR replicator also won't work because it implies parallel outputs to the out channel - illegal! So it has to be a SEQ replicator. In any case, unless the occam kernel supports, and is running on a multiprocessor machine, the SEQ replicator for code like this will be faster than a PAR (which will have to startup and shutdown 25 software processes).

Your code would also be slightly snappier with:

      cursor.x.y (4, 1, out)
      SEQ i = 1 FOR 26            -- the "2" could be anything though
          out ! '#'               -- don't need out.string for a single char
          cursor.down (1, out)
          cursor.left (1, out)
      out ! FLUSH

Keywords: q7 , type-mismatch , cast , cursor

Referrers: Question 32 (2012) , Question 21 (2001) , Question 74 (2000)

Valid CSS!

Valid XHTML 1.0!

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Last modified Mon May 20 13:50:26 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.