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 ansi
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'?
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
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |