|
CO538 Anonymous Questions and Answers |
This page lists the various questions and answers. 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.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
When asking questions, please do not simply paste in your code and ask what is wrong with it, as these types of question are hard to answer in a public forum (resulting in either no answer, or an answer which will only be of use to the person asking the question). In many cases, a question about code can be formulated in general terms. For example, if you have an `IF' block that results in an `incorrect indentation' error, you might ask, ``what is the correct syntax for an occam `if' statement ?''. Questions of this form are easier to answer, and are meaningful to all.
Questions that are not suitable for these public pages (i.e. those that contain assignment-specific code), should be mailed to your seminar-leader.
Submission reference: IN1561
I've been working through the seminar questions and would like to check my answers for question 5, specifically relating to the correct output for x4. Can this be made available?
The answer (this is for 2004, Co516, Q5, part g) is: 1, 2, 3, 4, ... (until an interrupt arrives - then deadlock).
Keywords: exams
Submission reference: IN1608
Hi, is it possible to make "screen!" shared? Or is there something we can do that offers the same effect?
If you're using KRoC, then you can directly declare the top-level channels as being SHARED, for instance:
PROC q7 (CHAN BYTE kyb?, SHARED CHAN BYTE scr!, CHAN BYTE err!)
... code
:
Which would give you a shared "scr!" (screen) channel, but unshared "kyb?" (keyboard) and "err!" (error) channels.
The Transterpreter does not yet handle shared top-level channels, but you can get the same effect through the use of a BYTE "id" process running in parallel with your code. For example:
PROC new.q7 (CHAN BYTE kyb?, scr!, err!)
SHARED! CHAN BYTE screen: -- output end shared
PAR
--{{{ byte "id" process
WHILE TRUE
BYTE ch:
SEQ
screen ? ch
scr ! ch
--}}}
--{{{ original q7 instance with shared screen channel
q7 (kyb?, screen!, err!)
--}}}
:
Such a procedure can be added to the end of your existing q7.occ file, and becomes the new top-level process.
Keywords: shared-channel , q7
Referrers: Question 106 (2004)
Submission reference: IN1609
How do I pass an integer to "cursor.x.y"? Whenever I try and do this, I get an error about incompatible types.
The "cursor.x.y" procedure requires BYTE parameters. To pass an integer parameter, you must first cast it to a BYTE. Syntactically this is just "BYTE <expr>". For instance:
cursor.x.y (4, BYTE (5 + x), screen!)
Where "x" is an integer variable. If the expression given is out of range for the target type (0-255 for BYTEs), a run-time error will be generated. See other questions relating to cast for more information.
Keywords: cast
Referrers: Question 32 (2012)
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
Submission reference: IN1619
I'm trying to model my q7 on a7.basic, but I'm having difficulty displaying any sort of sensible output. The phils, forks and security each output their state via a shared channel to the display, which outputs to the screen based on which channel the input was received on, using the id of the forks and phils to output to the correct column/row on the screen. However, my display only ever shows (almost) all the phils and forks in all the states at the same time. However, sometimes there is no display to the screen at all. I'm not sure whether it's because I'm not setting my seed correctly, of if its a more general problem with the wiring.
[snip code]
I'm also curious to know why in a7.basic the philosophers often skip the hungry and sitting states, going straight from thinking to eating. Surely the progression through the states happens sequentially?
The code you had there looks fine, so I don't think that's the problem. Check, however, that your display process is flushing the output correctly. That is, terminal output is line-buffered by default, so you normally wouldn't see program output until a newline occurs. You can force the output by writing the FLUSH value to the screen channel, or by including a newline at the end of every chunk of output sent to the screen. That would be my first thought, anyway. Incorrectly set seed values are more likely to result in a non-random animation, rather than a broken animation.
PHW adds: if your display shows all phils and forks in all states (almost) all the time, are you erasing text indicating a previous state when writing the text for the new state? To erase previous text, just overwrite with space characters – of course, you have to work out where the text indicating the previous state is on the screen (but that's no harder than working out where to write the new text).
As far as the model answer goes, the philosophers do go through all the various states sequentially, but this can sometimes happen quickly. Quick to the point where you may not actually get to see it on the screen (i.e. if the "hungry" state is drawn on the terminal and then erased for the next state, before the terminal has had a chance to redraw itself — at 60 Hz or however fast).
Submission reference: IN1620
Hi, when will the folders be created for handing in q7.occ — or are we handing in via a different method?
Submission will be on-line as per the previous assessments. I've asked for these to be created, so they should appear later today.
Submission reference: IN1631
I'm getting a runtime error: CSUB0 at or around this code:
INITIAL INT l.offset IS (id * 4) - 1: INITIAL BYTE r.off IS BYTE r.offset:
where id is an INT I'm then attempting to add r.off to another BYTE value in cursor.x.y. I'm essentially trying to cast an INT to a BYTE value. The INT value should be in the range 0-255, so I'm not sure what the problem is I'm encountering.
First, apologies for the dreadful name (CSUB0) in the error message! CSUB0 is one of the byte codes generated by the occam compiler. Its used for checking ranges: array indices, CASE input tags, type range violations (e.g. for BYTEs). The latter is probably what's happening here.
So long as 0 < id ≤ 64, then 0 ≤ l.offset &le 255 and casting it to a BYTE will be OK.
However, if id were ever to be zero, then l.offset would be -1 and casting it to a BYTE would be illegal and raise an error.
You do, though, cast something called r.offset in the code you quote and say nothing about its value. Might this be your error?
Assuming the casting of r.offset to (your BYTE variable) r.off worked, adding some BYTE (e.g. r.off) to some other BYTE value may overflow (i.e. result in a number greater than 255).
Submission reference: IN1632
Hi there,
I have noticed a lot of warnings being thrown up when using the library useful.lib which is a little disconcerting from a newbies point of view. Is this something that's scheduled to be fixed in the future as I presume it is legacy code, falling fowl of newer tighter compiler controls?
:)
Yep – apologies for this ... it is something we need to fix! Meanwhile, please grit your teeth and ignore those errors, :(.
Submission reference: IN1628
I've read through the previous answers, but I'm still having trouble setting the seed. I understand that the seed is declared in the q7 process in order to receive a value from the keyboard, so are we expected to find a way of passing the seed to the philosophers from within the q7 process? Also, should our animation (modelled on a7-basic) still work without the seed set?
I don't understand what you mean by: "the seed is declared in the q7 process in order to receive a value from the keyboard"?
A seed should be declared and initialised in the q7 process in order to pass unique seeds to the philosophers, which they use in generating random numbers for setting randomised thinking and eating periods. Code for declaring and initialising such a seed is given in your starter file.
Passing the seed to the philosophers is easy: pass it (as a VAL INT parameter) to secure.college and secure.college passes it on (as a VAL INT parameter)to each philosopher, when it instances each philosopher (in a replicated PAR).
The secure.collegeshould also pass a unique id number to each philosopher. Adding that id to its given seed results in a unique seed for each philosopher.
Everyone should trawl through the anon Q&As for information. For instance, check out the keyword index pages for random and q7 and use your browser to search for "seed". You may find Question 55 (2006) particularly helpful.
Finally, if you don't set a seed and pass it on properly, your animation will not be randomised. The random number function requires a seed argument and returns an updated seed value as the second part of its answer (the first part being, of course, the random number it choose for you). Make sure you know how to use this function properly.
Submission reference: IN1633
My dining phils program is working but I'm worried about my code! It's got great chunks of code repeated with the only difference being magic numbers for all the different coordinates needed to make reports in the right places for the different phils and forks.
Should I be concerned? Thanks.
You should be concerned!
Check out the keyword index page for q7 and use your browser to search for "magic". Especially, discover Question 68 (2000), Question 104 (2004) and Question 103 (2006) ... :)
Keywords: q7
Submission reference: IN1635
I'm a little confused as to whether we are supposed to control timing issues only in the philosopher process or also through the display process?
For the basic solution, only the philosopher needs to manage time delays (for modelling thinking and eating periods). For more sophisticated animation (e.g. showing actual movement), extra animation processes will use delays to space out updates after moving to new positions. The display process itself should be fairly dumb, just being responsible for placing text in response to client requests (from the philosopher and any animation processes).
Keywords: q7
Submission reference: IN1639
Hi there, I have a question about the current assessment. I am a little confused as to what the security guard should be doing. Am I right in thinking that it only needs to report the number of philosophers currently inside the college (i.e. sitting and eating)? And that this value should be gained by each philosopher reporting its state to the process via a protocol?
Thanks.
Security already keeps a count of how many philosophers have been admitted (i.e. the number sitting, but not necessarily eating since their forks may not be available). Initially, and whenever this count changes, security should report the new value.
Note that security should do this (via a suitably protocolled report channel). There is no need to pass this information to any philosopher and get them to make the report. For a basic solution, all reports (from philosophers, forks and security) should be received by a display process and animated.
Keywords: q7
Submission reference: IN1640
Hi, I'm trying to refine my reporting for the dining philosophers assessment. At the moment I have the philosophers report via the secure.college process which communicates with a display process. Is it okay to leave it like this, or do we need to have the philosophers reporting directly to a display process?
Cheers.
Each philosopher, each fork and the security guard should make reports on an external (i.e. parameter) report channel. Those processes do not care where that report channel goes – that's not their responsibility.
The above processes are run in parallel by secure.college. This process needs its own external (i.e. parameter) report channel (if SHARED) or array of channels (if not). All secure.college needs to do is connect its external report channel (or channels) to the instances of philosopher, fork and security it is running. There is nothing else for secure.college to do! In particular, it should not attempt to receive reports from its sub-processes and relay them onwards – that would be a waste of time. See slide 60 from the applying slides for a diagram (where secure.college has been re-christened reporting.college).
So, yes, each philosopher (and fork and security) will be reporting directly to a display process. But all they know is that they make reports. The secure.college, which runs them, connects their report channels to its given report channel(s) and knows/cares not where they go. It's the responsibility of whatever is running secure.college – in this case, your q7 process – to connect the report channel(s) from secure.college to a display process.
Keywords: q7
Submission reference: IN1643
Hi there, I am having a little bit of a problem in connecting up my shared report channel. I get the error message (type mismatch for parameter 1 in secure.college), but I can't see where I am going wrong. I have declared the channel passed to the secure.college as SHARED and I have a SHARED CHAN within my q7 process that I pass to secure.college. I'd be grateful if you could possibly point me in the right direction. Within q7:
SHARED CHAN P.DISPLAY reporter: secure.college (reporter!)
header of secure.college :
PROC secure.college (SHARED CHAN P.DISPLAY reporter!)
Thanks,
The code you have written in the question looks fine, though in this particular case, the "reporter" channel should only be shared at its output end, i.e. be declared:
SHARED! CHAN P.DISPLAY reporter:
This is on the (usual) understanding that the "display" process reading from the shared channel is the only process doing so. As you're seeing a "type mismatch" error at the point of the procedure call, double-check that the code is as you have it above. Specifically, check that there is not anything else also called "reporter" declared between that shared "reporter" channel and the error-generating call to "secure.college". For example, the following code will generate a similar error:
PROC foo (CHAN BYTE out!)
INT x:
SEQ
x := 42
... some other code
INT out:
SEQ
out := 19
out.string ("Hello, world!*n", 0, out!)
:
In a similar way, also check that the "secure.college" you mention is the only one declared at the top-level. For instance, if you had:
PROC foo (SHARED CHAN BYTE out!)
... stuff
:
PROC bar ()
... stuff
:
PROC foo (CHAN BYTE out!)
... stuff
:
PROC baz ()
SHARED! CHAN BYTE c:
PAR
... some process reading from 'c'
foo (c!)
:
This will also generate a type-mismatch error, since there is another "foo" procedure declared between the one you intend to use (with a shared channel parameter) and the point where it is called (in "baz").
If you can't spot the error yourself, try mailing your seminar leader with the code and asking for help (we're a bit more used to tracking down errors in occam-pi programs quickly!).
Keywords: shared-channel , q7
Submission reference: IN1656
Why does the robot always turn left no matter which one of the commands (turn.left or turn.right) you send to it ???
Is this deliberate and we are supposed to fix it, or otherwise?
This is most definitely not deliberate, and should not be occuring. A test of movement commands by replacing the SKIP in your default mars-main.occ file with motor.cmd ! turn.left and motor.cmd ! turn.right indicates that the robot can move both ways, so you may want to check the other pieces of your code.
Note that your task is to implement the movement code upon receiving a turn command from the console, which will accept positive values to turn clockwise (right) and negative values to turn anti-clockwise (left). The motor.cmd channel accepts the turn.left and turn.right protocol variants to initiate turns in the respective directions.
Keywords: mars
Submission reference: IN1666
Regarding Mission to Mars, is it acceptable for the operator to send a command, for example, turn -180 degrees, and to have the robot turn -181 degrees?
It is acceptable to turn slightly more than the amount, and the tolerance suggested here is fine. If the difference in the amount turned and the amount commanded is much more than 3, you should investigate your code, as there is probably a bug.
It certainly wouldn't be acceptable to turn >185 if the user asked for a turn of 180.
Keywords: mars
Referrers: Question 52 (2009)
Submission reference: IN1648
Hello, I am having a timing issue with my fork animation. At the moment it appears as though a philosopher is dining with one fork. However, the other fork is displayed but a bit later on (quite often after the philosopher has finished eating). Is there a way I can have my case statements for the left and right pick ups be carried out in parallel?
Thanks.
Sorry – this question came in just three and a bit hours before the assessment was due, which was too late to be answered, I'm afraid!
The display process should only deal with one report at a time (since the screen channel, used to drive the display, is a serial device). So, there is no point in it being able to deal with reports about left and right pick ups in parallel.
Did you remember to FLUSH the screen output made by your display process at the end of its response to each received report? If you did not, the screen outputs would not reach the screen until a buffer (somewhere in the system, outside your occam program) fills up ... and screen updates would be very very bursty.
Keywords: q7
Submission reference: IN1650
Hi, Not that I really mind this time around as I had already submitted my solution for q7, but I believe the submission directory was closed 54 minutes early at 23:05pm (according to the time I recieved the email), rather than 23:59pm as stated on the module webpage.
With all the work I have to do in these last few weeks of term (hense why I am sadly working late on a Tuesday evening!), I may need all the time I can get for the next assessment, so please could you state the correct time for submission of the last assessment on the module webpage.
Thanks!
Sorry! As explained elsewhere, this was our mistake (which we will try and not repeat next time).
Anyone who mailed us their assessment (or an updated version of their already submitted assessment) had that mailing accepted as their actual submission. If there is anyone else who was not aware of this and feels they missed out, please contact us. Thanks.
Keywords: q7
Submission reference: IN1678
Hi I'm looking at these hazard channels on the robot. What is the coverage of the channels? Are the channels split by 90* so 2 for the front and 2 for the back? Or are they done starting at a 45* offset so that there's one for the front and back and 2 more for the sides? (although this makes less sense to me as the side ones would be fairly redundant being as the robot only actually moves forwards and backwards). Anyway my main question is - how are the channel array numbers applied? Thanks.
The document isn't very clear about this (I'll think about how to improve it). There are some constants in the mars-robot.inc file to help with this task though.
You should think of each hazard sensor as an object camera, pointed at the center of the 45 degree offsets (i.e front left, front right, back left, back right), which covers 90 degrees of scan range (front to left, front to right etc.) The hazard value you get on each channel is created by assessing the hazard using the minimum distance to an object in each quadrant.
The constants should help you get a grip on where things are pointing/looking, and you can use them in place of numbers when writing code that uses the hazard array. Hope this helps!
Keywords: mars
Submission reference: IN1665
In task 4 of the "Mission to Mars" assignment:
The "bearing" field, of the BLOB structures returned, can contain both positive or negative numbers. What do these numbers represent and how can they be used to position the robot. Any hints ???
Cheers.
The bearing field of the BLOB structure is the offset of the object from the robot's dead-reckoning of 'forward'. If you do a scan with the camera and find a BLOB at bearing -30, you could turn left 30 degrees to make the robot point at the object.
Keywords: mars
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
