XML

kent logo

CO631 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 out.int

2004

Question 75 (2004):

Hi, can you talk me through what is happening with the outputs here? Thanks very much.

    string; name.length::name; mark
      SEQ
        out.string ([name FOR name.length], max.name.length, out)
        out.int (mark, max.name.length, out)
        out.string ("*c*n", 0, out)

Answer 75:

This code-fragment is not a valid occam process -- to be meaningful it needs a bit more context (in particular the "in ? CASE" above it, since the line starting "string" is part of the tagged protocol input). As for the outputs: in sequence, this outputs the first "name.length" characters of "name", in a field-width of "max.name.length", then outputs the value held in "mark" (again in a field-width of "max.name.length") and finally outputs a carriage-return/newline pair (strictly speaking only the newline bit is required, so you could just write "out ! '*n'" instead (or "out.string ("*n", 0, out)"). See the course library documentation for a detailed description of these procedures. And the related questions about array-segments for information on the "[name FOR name.length]" expression.

Keywords: out.int , out.string , array-segments


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!

You cannot, of course, dispense with your casting to a BYTE since the code will not then compile -- you cannot output INT values to a channel carrying BYTEs. That is not what you want to do anyway!

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

2003

Question 90 (2003):

For Q7 I am trying to use the `INTTOSTRING' routine in "convert.lib", so that I can directly output the id of a philosopher to the screen, rather than have a load of IF statements and duplicated code.

Currently I have:

    INT g:
    [5]BYTE string:
    INT n:

    INTTOSTRING (g, string, n)

but get "fatal symbol referencing errors" when I try to compile. It seems the compile goes ok, but the error occurs at linking.

I'm assuming we need to convert integers to []BYTE or CHAR at some point in the display process, or is there another way?

Answer 90:

Firstly, you don't need to use routines from Inmos libraries. Technically there's nothing wrong with them, though (some are particularly useful, like the routines that turn REAL64s into strings).

The linker is probably failing because you're not linking in the convert library -- you reference it from your code, but don't include it at compile time. The `course.lib' is special in this respect -- KRoC/Sparc (on raptor) automatically adds the `-lcourse' option when compiling programs. To get the Inmos conversion library linked in, just:

    kroc myfile.occ -lconvert

There may be inter-library dependencies, so other libraries might be needed too. `string.lib' is another (`-lstring' on KRoC's command-line).

Back to the main point, if you want to output an integer to the screen, just use `out.int'. This is in the course library and has been mentioned/ described many times in lectures and seminars. If you really want to turn INTs into an array of BYTEs, a better approach would be to use the code from the course library's `out.int', which is available on raptor in:

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

There are not many IFs, and hardly any duplicated code, though.

Keywords: out.int


Question 31 (2003):

I'm a bit confused about the `out.int' and `out.string' PROCs in `layout.max.chans' in Q4. Are they already defined somewhere, because I can't seem to find them. Or are we meant to define these two PROCs ?

Answer 31:

They are defined elsewhere -- in `course.lib' to be precise, so you must not define them yourself -- doing so will result in linker errors when it finds two copies of each (one from the course library and one from your code).

These two PROCs just write INTs or BYTE-arrays to a BYTE channel, aligning in the given `field' (2nd parameter). Writing `out.string' is easy, `out.int' less so. You can find the code for these on raptor in:

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

Keywords: out.int , out.string , q4

Valid CSS!

Valid XHTML 1.0!

Last modified Mon May 15 17:39:46 2006
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.