|
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 q4
2004 |
This may sound silly but there are no questions about using "CASE", could you please tell me a bit more about it and when it's used please. Thanks.
The "CASE" construct is much like C and Java's "switch". In occam, "CASE" can be used in three places: as a "switch" on some variable/expression; in tagged protocol definitions; and in tagged protocol input. There are plenty of examples of "CASE" usage -- see the past questions, course notes, the model answer to Q4 (its "keys" process) and this occam tutorial. It would also be neater to use a "CASE" for examining the result of a "compare.string" function, rather than an "IF", in Q6.
Keywords: tagged-protocol , CASE , q4 , q6
When will the q4 model answer become available?
Done! Also for q5. See:
answers/a4_slow.occ
answers/a4.occ
answers/a5.occ
in the usual place.
Keywords: q4
Are differentiate and minus predefined or do we have to define them?
You have to define them -- they are not in the course library.
You will have been told this in your seminar groups. You could also find out for yourself by browsing through the course library:
/usr/local/courses/co516/libsrc/README.txt
Note: you don't have to write a differentiate process for Q4! Nor do you have to write a minus process ... read the fifth modification (in your starter file) carefully. Resetting the pairs process causes its adder sub-process to change behaviour so that it subtracts the numbers arriving on its two input streams from each other (careful to do this the right way around) rather than adding them. This has the effect of turning this reset pairs into a differentiator (which is merely a comment, describing the result of this change). One way to do this might be to wire a minus process into the circuit, but that is some way from the simplest solution.
Keywords: q4
Where do we use numbers.reset? After the second modification you ask us to declare numbers.reset and integrate.reset, but the diagram has numbers as its component?
There wasn't space in the ASCII-art diagrams to write a revised name for the resettable processes. Clearly, the processes labelled numbers, integrate and pairs -- that have reset lines coming into them -- are the resettable processes you have to produce. What you call them (e.g. numbers.reset etc.) is up to you! Just don't continue to call them by their original names, since those names are already in the course library and the linker will complain.
Keywords: q4
Talking about the resettable running-sum integrator, you said in the lecture that there was an argument for putting replace between plus and delta or between delta and prefix. Does this mean that the former of the two actually resets to 0 or output 0 instead of the latter that will output 0 plus the last number that came on plus?
Slide 6-21 in your printed notes (currently slide 22 of chapter 6 in the Powerpoint set) places replace between the delta and prefix. This means that, when a reset (e.g. a zero) comes in, it goes through the plus (and gets something added to it) before going through the delta and being output. Therefore, resetting with a zero does not cause zero to be output -- you will get zero plus the next input. However, the running total was zapped to zero, which is all we were wanting to do.
If we placed replace instead between the plus and the delta, a reset of zero also zaps the running sum to zero and we will see that zero emerge -- which lets us see more directly that the reset has happened.
Placing replace between the prefix and the plus has the same behaviour as the first option above.
So, the replace can be added anywhere in the original circuit and it will have the required behaviour (of zapping the current running sum).
Note that with any of these positions for replace, the next number output by the device -- following a reset -- may be the old running sum (before it is removed when it next passes through the replace). This just depends on where that old value is in the circuit when the reset happens. If that were a real concern, we could not use a replace. Instead, we would have to modify the delta process to take the reset channel itself (and PRI ALT between that reset and its normal input). That's easy -- it's a folding together of the logics for replace and delta into a single process:
PROC delta.replace (CHAN OF INT in, reset, out.0, out.1)
WHILE TRUE
PRI ALT
INT x:
reset ? x
PAR
INT any: -- remove old value
in ? any
out.0 ! x -- copy through new value
out.1 ! x -- copy through new value
INT x:
in ? x
PAR
out.0 ! x -- copy through value
out.1 ! x -- copy through value
:
But I prefer not to disturb existing components unless I really have to!
Keywords: q4
This question regards the `pairs.reset', which we are supposed to program for Q4. Is it okay to say we can program two methods, `pairs.plus' and `pairs.minus', and the `monitor' method choses which one of these to implement depending on the key-press; would this work?
And also, with the `monitor' PROC, is it alright to say that if I type `n' into the keyboard it sends the number 0 to the `numbers' method as an imput? If this is the case am I to asume that if monitor dosen't send a number (i.e. 0) to it, it would carry on as the normal `numbers' and not reset the numbers PROC ?
Also the timer, which we had to implement in q3:
TIMER tim:
INT t:
SEQ
tim ? t
tim ? AFTER t PLUS delay
where can we put this ? In the `monitor' method, or is it more sensible to implement it somewhere in `layout.max.chans', because it's connected to the screen ? A student told me somewhere in `numbers', `integrate' or `pairs' would be suitable.
Programming two separate `pairs' methods is possible, but quite a long way round. You can't `switch' between them, however -- you have do run both (in parallel) and then work out how to feed them inputs and collect outputs. It's easier (and arguably better) to just modify the internals of `pairs'.
As for the resetting of `numbers', yes, that's the way it'd generally be done -- in fact, there isn't any other way in occam. You can't interact with a process unless you have explicit wiring for it (e.g. one process cannot directly change the value of a variable in another process -- the processes have to communicate over a channel to achieve this). And yes, the `numbers' process should carry on generating numbers as normal, until it is reset. What happens inside another process (e.g. `monitor') can have no effect on `numbers' (or, indeed, any other process) unless communication takes place between them! This is what makes occam systems so robust as new components are added or existing ones changed -- unlike systems currently running the Social Services disability section, the Child Support Agency, ...
The timer code can be put anywhere where it will limit the speed of program output. The program is basically a pipeline of processes, so slowing down any one component in that pipeline will slow down the whole pipeline (the pipeline in this case is: "numbers -> integrate -> pairs -> layout.max.chans". `monitor' would not normally be part of this pipeline (although it could be). However, there's no need to complicate the code in `monitor' with timeouts (and making it part of the pipeline) -- the timeout code can go somewhere else. For clarity and simplicity, it's often better to engineer these sorts of things into stand-alone components, then wire them into the process network. Pencil and paper come in handy for this.
Keywords: q4
Hello, I'm having trouble with the `monitor' procedure, my code is below:
PROC monitor (CHAN OF BYTE k, CHAN OF INT num, int, prs)
PAR
IF
k = 'n'
num ! k
IF
k = 'i'
int ! k
IF
k = 'p'
prs ! k
:
I get indentation errors, and I'm not sure how to fix this, I was told by a colleague that we are supposed to implement an infinite loop in the `monitor' process -- why is this ? and what use could this be ?
Also, in the specification for the assignment, when we press `s' to suspend the output to the screen I'm assuming that this supposed to be implemented by the `monitor' method -- am I right?
Yes, this code has incorrect indentation. The "occam-2 checklist" in the course notes (and linked from the course web-page) provide a good deal of information on the layout of occam code. The correct layout for an occam `IF' (conditional process) is:
IF
condition.0
process.0
condition.1
process.1
...
The operation is: the various conditions are checked in the order written; the first one that evaluates to `TRUE' is selected and the process under it run. The rest of the conditions are then ignored. If you look at this occam tutorial, you'll see that the equivalent Java is something like:
if (condition.0) {
process.0
} else if (condition.1) {
process.1
} else if ...
...
In occam, however, one of the processes must be selected -- if the `IF' "falls-off" the end, it behaves as `STOP', generating a run-time error.
What you have in your code is some way to being a nested `IF'. The correct layout for that would be:
IF
condition.0
process.0
IF
condition.1
process.1
IF
...
...
But this is exactly equivalent to the version above, with all the conditions aligned.
The process needs to be an infinite loop otherwise it will run once then terminate, deadlocking anything else that tries to communicate with it (since it isn't there anymore). Parallelism does not imply repetition -- if you want the network to run forever, make each component run forever. And visa-versa -- if you want the network (or a sub-network) to run once (or n-times), make each component run once/n-times. Infinite loops are just `WHILE' loops that never terminate (because their condition never becomes `FALSE'). For example:
WHILE TRUE
out ! 42
Will just output 42 on the channel `out' forever (or until it deadlocks).
The suspend signal needs to be handled in `monitor' in the sense that's where the key-presses arrive and are processed. Again, it's a design decision (up to you) as to whether the `monitor' process actually does the suspending of screen output, or whether it simply signals another component in the network, that suspends there. Suspend processes (e.g. for Q3) have been covered in the seminars, so it might make sense to re-use that.
Keywords: q4 , incorrect-indentation
Concerning q4: `PROC pairs' uses `delta', `tail' and `plus' components linked together. For the assignment we need a toggle on `pairs' in order to add numbers or take them away from each other. If we created another procedure which changed between `plus' and `minus' depending on key presses, and used that procedure in place of `plus'. Is this along the right lines or should there be something internal to `pairs' which decides if there should be a toggle ?
That is largely up to you! Both ways are essentially acceptable, assuming a nicely coded solution. The difference is usually the breakdown between parallel and sequential code. A single component will generally be sequential code only, whereas a network of processes requires parallelism (but the individual sequential processes are simpler).
One way to find out, of course, is attempt to program this both ways, and see which gets you to the finish-line first..
Keywords: q4
Is there any way the output can be slowed down its very hard to see if my code is working. If not is there any way we can output our results to a text file and look at them in there ?
The easiest way to slow down the output is using some suitable `delay' component, either inside the network somewhere, or just before the network connects to the `screen' channel (but this latter delay process is slightly more complicated, as you only want to delay when a newline character goes through). As has been mentioned in the seminars, look at the following files on raptor for an idea of how to do this:
/usr/local/courses/co516/answers/a1_slow.occ
/usr/local/courses/co516/answers/a2_slow.occ
/usr/local/courses/co516/answers/a3_slow.occ
The last of these implements a fixed slow rate (10 lines/second) and has the simplest code ...
Keywords: q4
In the code given in q4 there is a replace procedure. I don't understand what it does. Could you explain how it works please.
This question was discussed in the seminars, attendance at which is compulsary. If you miss one, it is your responsibility to find out what you missed!
Having said that, look at slides 6-21/22/23 ... and ...
This procedure is probably best explained in terms of its occam code -- occam is actually very structured, although getting used to the syntax/indentation can take a little time. The code for `replace' (with the channels dressed up with direction specifiers) is:
PROC replace (CHAN INT in?, control?, out!)
WHILE TRUE
PRI ALT
INT x:
control ? x
PAR
INT any:
in ? any
out ! x
INT x:
in ? x
out ! x
:
The main body of this process is a `WHILE TRUE' loop, so it's going to do something forever. The process inside the `while' is a `PRI ALT' with two guards. The first guard will accept an input from the `control' channel, that has priority over the second guard, an input from `in?'.
As with most ALTs, if neither channel is ready the process will stop running and wait until one of them is. If the `in' channel is ready, and selected, a value will be read and simply output on `out' -- so values can just "flow" through the component unhindered.
However, if the `control' channel is ready (and this will be selected if both channels are ready) a value is read from it and placed in `x'. The code then, and in parallel, performs an input from `in' (throwing the value away) and output the value sent down the `control' channel to `out'. The effect of this is that a communication on the `control' channel causes the next value on `in' to be replaced. In this version, the communications are done in parallel -- so the replaced output may appear before the value that it was replacing. This is not a problem however, and those communications could be done sequentially if desired.
The `replace' component should have been covered in the seminars already, however..
I'm struggling with the `monitor' method: checking previous anonymous Q+A's I found a student starting the method this way:
PROC monitor ([]CHAN OF INT out, CHAN OF BYTE keyboard, intr)
--{{{ forever
WHILE TRUE
... wait for `intr' and process accordingly
--}}}
:
while I have done it this way:
PROC monitor (CHAN OF INT keybrd, num , int , prs)
PAR
id(keybrd, num)
id(keybrd, int)
id(keybrd, prs)
:
I'm totally sure my own version is wrong, what I don't understand is what I'm meant to do exactly for this method; and also I would have thought the input for keyboard would have been a string for "s" "n" etc.. so you can compare which one to reset. I have done the methods for `numbers.reset', `integrate' and `pairs' and they're working. I'm not sure where to proceed from here though.
PLEASE HELP!!!! :'(
Going from your last paragraph, keyboard input is characters -- that are represented by BYTEs in occam. occam doesn't have a native `string' type like Java, so that rules that out. Strings in occam are done using arrays of BYTEs.
What you suggest is largely sensible (and correct): wait for some input from the keyboard, then compare to decide which component to reset. The first code fragment above is on the way to doing this. The second code fragment isn't; this will fail to compile due to the parallel inputs on "keybrd" -- also it's unclear what such code should do: relay the values on "keybrd" to each of the three reset-able processes ? Better to do the input first, then decide what to do with it.
Just as a point to convention: occam PROCs should be called "processes" or "procedures", not "methods" (a term from OO programming, which occam isn't). occam also has FUNCTIONs (that return values) and these are very different from PROCs (non-value parameters can be used to "return" data from PROCs, however).
Keywords: q4
I am trying to set up a reset for pairs. Where do you best suggest I have replace? Before the input or after? Or can I have more than one replace in a process?
Yes, you can have as many replace processes as you like in any process network (such as the one needed for pairs.reset). Actually, you should add no replace processes there -- they offer no help in implementing the required change in behaviour of pairs.reset when a reset signal arrives.
Keywords: q4
I've completed q4 - but just testing it I've found that my implementation for pairs resetting is a bit odd.
If left on its own the program runs fine and loops round every 20 secs or so. If i press `p' I start to see the list of natural numbers - but the program then crashes at 65535. Is this ok?
Yes, that's not too serious -- but the crashing is a pain and easily fixed.
The `pairs' process, when subtracting, behaves like `differentiate' (except that it loses the first value communicated -- because of the `tail'). Thus you'd expect to see natural numbers -- or at least the input to the (`integrate' -> `differentiate') part of the pipeline.
Your program crashes when your resttable `pairs' process is reset, because your code uses (I strongly suspect) either a `+' symbol (instead of a `PLUS', which wraps round on overflow without crashing) or a `-' symbol (instead of a `MINUS', which also wraps round on overflow without crashing). The course library `plus' process uses a `PLUS', precisely so that it can be used on number streams that get too large or too small.
Your program `crashing' is expected behaviour, if you have used the algebraic operator symbols. The sum of 1..65535 is just less than 231 -- when 65536 is added, it'll overflow. "Crash" is perhaps a slightly strong term in this case -- the (overflow) error was correctly detected and appropriate action taken. But use the `PLUS' (or `MINUS') operators and the overflow will be ignored -- that's what Java does anyway!
Keywords: q4
When the system is paused, do we need to guard against the user typing in other valid command letters such as `n', `p' etc. ? In my system, when it is paused through a `s' pressing any other valid commands creates a deadlock!
From the `q4.occ' file:
--> 's' ==> suspends output to the screen. Output is resumed by the next --> keypress (which is NOT processed according to the above rules --> -- it is merely the signal to resume output).
So pressing any key whilst paused (including valid command keys) should just resume the output.
Keywords: q4
I was reading the bit about graceful termination in the course notes and understand about sending poison down the line to shut each process down properly. My question is does this mean that we have to change every single component that we use, i.e. `delta', `succ', etc. ?
Yes, to get processes like `delta' to shut down nicely, modification will be required. However, you're not expected to implement graceful termination for Q4 -- you can do if you like, but it's quite a lot of hard work. Essentially anything that has a `WHILE TRUE' loop needs adjusting in some way -- such loops cannot terminate..
Keywords: q4 , graceful-termination
I'm now somewhat through Q4 and have noticed that I'm using polling `PRI ALT's. It says in the coures notes that they should be used only as a last result -- I'm wondering if this is acceptable in Q4?
I'm not sure of another way of interupting a process based on a signal that may or may not arrive. I've created PRI ALTs in the new control PROCs that have been added to `numbers', `integrate' & `pairs'. I'm now planning on using it to react to the byte `s'
As the course notes say, polling should only be used as a last resort. I wonder, however, if you're actually polling.. Polling code is specifically this:
PRI ALT
c ? x
... do something with `x'
TRUE & SKIP -- skip guard
SKIP -- do nothing
When executed, if data is available on the `c' channel (i.e. the corresponding outputting process is blocked in the output), then that data will be accepted immediately (placed in `x') and the guarded process runs. If data is not available on the `c' channel, the `SKIP' guard is selected and does nothing -- so the `PRI ALT' finishes immediately.
That code is polling, and it can create problems.. For example:
WHILE TRUE
PRI ALT
c ? x
... do something with `x'
TRUE & SKIP
SKIP
This code will consume as much CPU as it can until some data arrives on the channel `c'. Of course, the correct code in this case (since the process does not interact with anything else in the loop) would be:
WHILE TRUE
SEQ
c ? x
... do something with `x'
This code, on the other hand, will wait for something to arrive on `c' then do something with the data received. And waiting (either blocked on channel communication or waiting for a timeout with `AFTER') does not consume the CPU. (although busy-wait versions of these could be created easily, it would be daft..).
It's the `SKIP' guard in the `PRI ALT' (and subsequent do-nothing process or do-very-little process) that constitutes polling.
The following code, for example, is not strictly polling (but it is not nice code):
WHILE TRUE
PRI ALT
c ? x
... do something with `x'
TRUE & SKIP
SEQ
d ? y
... do something with `y'
If you've written stuff like that, you probably wanted instead to write:
WHILE TRUE
PRI ALT
c ? x
... do something with `x'
d ? y
... do something with `y'
These two code fragments do not behave in the same way, however. The first will commit to input on `d' if `c' is not ready -- refusing then to service `c' until something has arrived on `d'. The second will happily wait for both, and service the first channel that becomes ready (or `c' in preferance to `d' if both are ready).
You can read some more on ALTs and polling in this occam tutorial.
In the diagrams that you have put into Q4, you have connected the `monitor' only to `numbers' `integrate' and `pairs'. Surely this also needs to be connected to the `layout.max.chans' as to allow output to the screen or not? That is the way I managed to do it in Q3 and it seemed to work ok.
The keyboard characters input by the `monitor' process do not have to be echoed to the screen channel.
I assume you are talking about the suspend mechanism, in reaction to an `s' keyboard input -- the fourth modification. From `q3.occ':
--{{{ data-flow diagram
--
--Sorry ... you're on your own here.
--
--}}}
So yes, some extra connectivity is required beyond that shown on the diagram for the third set of modifications.
However, altering `layout.max.chans' (to take that extra connectivity) is not the simplest approach -- the re-programming is untidy; since it takes its original inputs in PARallel, you will need to poll the extra one separately.
A simpler approach, as discussed in the seminars for Q3, is to create a separate `suspend' component that can be added to the existing process network (with some minor extra wiring) -- and leave `layout.max.chans' unchanged.
It's usually better engineering to add new functionality by adding a new (parallel) process specifically to implement it, rather than by modifying an existing component to add to its responsibilities. For performance reasons, we may sometimes need to fold parallel processes together into one single (but more complex) serial process -- but that can be done later (and fairly mechanically). In this exercise, there is no such performance constraint. In fact, the model answer adds code to slow the system down to produce output at only 10 lines/second, so that it's easier to see the effect of the controlling keystrokes. You might like to do the same -- though this is voluntary!
Keywords: q4
2003 |
I have done the rest of the assignment but Im have trouble with pairs.mod, I have defined new PROC's:
[snip code]
Below is my code for `pairs.mod':
[snip code]
PAR
replace.bool (l.2,control,l.1)
[snip code]
SEQ
prefix.bool(TRUE, l.2, l.1)
delta.bool(l.1, l.2, l.3)
The trouble I have is that it says I have parallel inputs on channel `l.1', but this is similar to the way I implemented the other mods and they all work...
This can't be right -- both these processes run for ever, so it doesn't make sense to execute them sequentially. Once `prefix.bool' starts, control can never return, so `delta.bool' never runs.
There appear to be two parallel OUTputs on channel `l.1', in replace.bool and prefix.bool
Keywords: q4
Additional to Q40, I havn't actually started using `layout.max.chans' yet, because none of my deltas will work. Currently I've got numbers outputting into the delta I gave which outputs one channel into an output module which just outputs whatever ints it gets onto the screen straight away and the other output going to nowhere. If I remove the delta i get the output i expected, but with the delta in between I get no output. The only thing that can possibly be wrong is the delta. Any more ideas?
If you leave the second output of the delta unconnected, the delta will get blocked when it tries to output. If you want to discard the data, connect it to an INT style black-hole:
PROC int.black.hole (CHAN OF INT in)
WHILE TRUE
INT v:
in ? v
:
Will I be penalised if I use STOP to create a deadlock for Question 4?
No, but it's not a very nice way of inducing deadlock, and it's not always correct. In the default `error-mode', processes that STOP cause a run-time error and the whole program finishes. In `stop' error-mode (which isn't the default), processes that STOP just die quietly, leaving the rest of the program running. Thus, if you use STOP, you should do it in such a way that the program would deadlock `nicely'.
A quick way of causing local deadlock is to communicate on an unconnected channel, simply:
CHAN OF INT dummy:
dummy ! 42 -- deadlocks here, because there's nothing connected to the other side
Which diagrams do I need to submit with this assignment? (Q4)
You should submit diagrams for all processes you create or modify. I.e., the modified process networks for `numbers', `integrate' and `pairs', and the overall top-level `q4' network. Also include `icons' for processes you create, if these aren't immediately obvious in the other network diagrams.
Referring to Assignment on Q4:
Yes, you may well need to implement a `minus' process, but it depends on how you go about solving that bit. For monitor outputs, a channel-array or separate channels are equally valid. On your third point, technically `INT' is a protocol. The structured PROTOCOL types should only be used if you need them -- you don't need them for this assignment.
Keywords: q4
delta (g, h, c[0])
this is in my main q4 proc. `g' is the input coming from numbers, `c[0]' is an output which will go to layout.max.chans and `h' is an output which will go into integrate. I know numbers gives an output as I've tested it with an output module, but as soon as I attatch the output from number to the input of this delta neither `h' or `c[0]' give any outputs when tested with the same output module.
I can't for the life of me see what I've done wrong! I've checked that all channels are connected correctly over and over so its not that either. Any ideas?
Two numbers must be output by the `numbers' process before any proper output appears. Since all the output is done via `layout.max.chans', that must input from each of its channels before anything will be displayed on the screen. Thus, if any of those input channels are unconnected, nothing will happen -- the `layout.max.chans' process will wait for input forever -- the `max.chans' constant defines how many channels should be `layed-out'. Similarly, if your pairs process doesn't output after two inputs, things will deadlock -- `layout.max.chans' will be waiting for that final input and the remainer of the network will probably be blocked on output.
Keywords: q4
I've done the third mod and it works fine. However, someone has just mentioned that you didn't want us to modify the `plus' process. Is this true ?
The question says:
'p' ==> the first 'p' zaps the adder process within pairs so that it
becomes a subtractor, taking the numbers arriving directly from
the delta process away from those arriving from the tail. In this
state, the modified pairs becomes a `differentiator', undoing
the `integration' effect of the process immediately upstream so
that we see the natural numbers sequence. A second 'p' toggles
the process back to its original state. Subsequent 'p's toggle
between the two states.
There is not a single `right' way to do this. The first line seems to imply that you should modify the adder process, though there is a neat solution that doesn't.
Keywords: q4
Do we have to use the replace function provided for q4 ?
I have a working q4 but it does not use the replace function. That ok?
In theory, yes. However, if your solution would have been more efficient using `replace' you may lose marks based on that. However, if your solution is succinct and correct, no marks will be lost.
Keywords: q4
To suspend screen output, would directing the `out.int' and `out.string' to a `black.hole' be appropriate ? I have tried this but it doesn't seem to work, am I going in the right direction or completely off.
Re-directing the output to a `black.hole' won't suspend it -- it'll gobble it up, like a black-hole. To suspend the output you need to stop the flow of data, which is often simpler than re-directing it. See the model answer for question 3 (on raptor) for an idea of how to do this.
[snip code]
I'm probably missing something really obvious, but why is this not giving any output? There is nothing coming in through the input channel, but yet when I attatch it to a tested output module nothing comes out.
Look carefully at the PROC heading for `replace':
PROC replace (CHAN OF INT in, control, out)
and note the ordering of the `in' and `control' channel parameters.
Keywords: q4
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 ?
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
I'm having trouble with getting the `pairs' process to toggle adding and subtracting. The following code compiles but doesn't do much, the only effect being that an input on the control line stops any other keypresses getting through. Ive tried declaring `subtract' in various places to no avail. Thanks.
[snip code]
See the answer to Question 27 (2003) for a brief description of the problem. Your code contains the process networks for both versions of pairs, but once running, these will never terminate -- they contain `WHILE TRUE' loops. You need to modify the process network itself -- not `wrap' the networks up in other code, as that won't work.
Keywords: q4
I'm having some problems with the new pairs process. This is what I've done:
[snip code]
It doesn't seem to be doing anything. Any suggestion ?
This appears to be a common mistake -- you're instancing the `plus' and `minus' PROCs from inside another component, that results in your component behaving like either `plus' or `minus' respectively. However, once called, these PROCs never return, as they have WHILE TRUE loops.
If you want a single component to take care of the addition/subtraction, you have to engineer (program) it that way -- i.e. a single self-contained PROC, not one that instances other PROCs. If you do want to re-use the existing `plus' and `minus' PROCs, they have to be engineered into a suitable parallel network -- i.e. instanced directly under a PAR, not from sequential code.
Keywords: q4 , process-networks
Referrers: Question 29 (2003)
I have now got a completed version of q4. However, in this monitor process...
[snip code]
.... it will only reset `I' or `P' if I press the key twice and it pauses it inbetween each key press. How come it is doing this as it is only the `S' case that asks for a second input? Also, typing in N twice causes the program to deadlock, yet I can't think of why. Any suggestions?
You have an ALT guard of the form:
in ? y
BYTE x:
SEQ
in ? x
... do something based on `x'
Before getting to the `do something based on `x'' bit, two inputs will happen on "in". Remember that in an ALT, input guards do perform the input before the guarded process runs. The correct guard/process would be something like:
in ? y
... do something based on `y'
Keywords: q4 , alternation
Are we allowed to create a process called `my.prefix', and replace the standard `PROC prefix (...)' within `my.numbers' / `my.integrate' with the new `PROC my.prefix (...)' ?
Yes, in theory there's no problem with doing that. However, for this assessment, there shouldn't be a need to do this, but that depends on how you go about modifying the various process networks.
Keywords: q4
I am having trouble with step 3 of the assessment. I am trying to have a variable that is set to either 1 or -1, and then the one of the numbers within pairs is multiplied by this number before the addition takes place (having the effect of subtraction).
My trouble comes in where to create and initialise the variable (call it `b'). At the moment I have it in my monitor process...
[snip code]
but when I compile, it whinges on the line marked that `b' is not declared. Doesn't the declaration at the top of the PROC last throughout the process ?? If not, how can I introduce the `b' variable without it being reset to one each time the process is run??
The rule with variable declarations in occam is that they are visible in the process following the declaration, and only that process.
For a good description of this, which relates directly to the error in your code, see Question 3 (2000). You should have gotten an error about incorrect indentation in that code too..
Keywords: q4
My part 2 of the assessment will not work. I have tried everything and, despite being able to get it to compile, nothing I can do can get the keyboard input to have the desired effect. I have proved that the keyboard input is being read, but I don't know why it's not running the rest of the program as it should
[snip code]
... am I right in thinking that once it has outputted 0 down either the `n' or `i' channel, it should then come out of the process and go back to my `q4' process (where it was called from), and thus go on to execute the whole number sequence thing but with the values of 0 waiting to be inputted on either the `numbers.reset' or `integrate.reset' processes.
I ask because no matter how I seem to plug these processes together (each one making its own sense), they don't seem to work!!
Removing some of your code, and assuming you fed it `i' on the keyboard, you are left with a process that behaves something like:
CHAN OF INT i:
SEQ
i ! 0
This immediately deadlocks. The reason is that the channel you are trying to output on is unconnected -- there is no parallel process performing the corresponding input (remember that channel communication in occam is a synchronous action, as well as a communication -- i.e., both the inputting and outputting processes must wait for each other before the communication can take place).
The `q4.occ' file shows (in ASCII art), the process network that ought to be constructed:
|
v keyboard
____________________________|___________________________________
| | |
| _____|_____ |
| __________| | |
| / 'n' | monitor | |
| / |___________| |
| v | 'i' |
| / v |
| ____/____ /| _____|_____ /| _______ |
| | | / | | | / | | | |
| | numbers |->- |->-| integrate |->- |->-| pairs |\ |
| |_________| \ | |___________| \ | |_______| \ |
| \|\ \|\ \ | error
| \________ \ \ ------>--
| v v v |
| __\_____________\_____________\__ |
| | | | screen
| | layout.max.chans |------>--
| q4 |_________________________________| |
|________________________________________________________________|
Thus, taking code straight from the diagram, the PROC header for this particular `monitor' process should be of the form:
PROC monitor (CHAN OF BYTE keyboard, CHAN OF INT to.numbers, to.integrate)
... and the monitor process resets the numbers and integrate processes by communicating on the channels given to it as parameters. The actual channels used are part of the `q4' process (i.e. should be declared there) -- as can be seen in the diagram.
Keywords: q4 , parallelism
Is there something special that we need to do to get what we press on our keyboards to register in occam as my program isn't picking up any keyboard inputs, yet by my reckoning it should be. It works for the `a3.occ' file tho ?
Help!
If you have a correctly programmed monitor process, there should be no problem with the keyboard. When you type keys into occam programs, they are not echo'd back to the screen unless you explicitly program this -- so it appears you are typing blind. Might this be the problem ?
If things ought to be happening, but aren't, double-check the `monitor' programming. Also check that it is wired up correctly -- i.e. with the keyboard channel.
Keywords: keyboard-input , q4
[snip code]
I have plugged the `i' and `n' channels into `integrate.reset' and `numbers.reset' respectively and yet, though the program compiles, it only seems to be running the `step1' process and not taking any keyboard input or taking it but not acting on it. Any clues as to what is wrong ??
Yes, although I can only give a fairly restricted answer here. If you want a more detailed response, mail your seminar leader -- they'll be happy to help. If you're in Peter's group, he's not around just at the moment, so you may mail me (frmb) instead.
The main problem with your solution, so far, is that it is not parallel. Your main process either runs the `monitor' code, or the `step1' code. For the network to work correctly, you need to have these as two distinct and separate parallel processes, with channels connecting them.
Keywords: q4
In order to change the behaviour of the pairs process each time `p' is pressed, can we re-implement pairs without including the plus and minus processes, and carry out the calculations using the PLUS and MINUS operators directly ? Or is it best to keep the plus and minus processes involved ?
In many ways, that's entirely up to you -- for example, try both, see how they turn out. What you must not do is trash the default `pairs' process and replace it with a purely sequential `pairs' process. After any/all modifications, the `pairs' process must still be a network of sub-processes. Depending on how you decide to approach this part, you might need to write new processes of your own (as opposed to simply modifying old ones).
Note, however, that the `plus' process and `PLUS' operator are utterly unrelated -- one is a process, the other is used for building expressions. One cannot be substituted for the other, without a significant amount of work. The choice (between operators) of whether to use `+' or `PLUS' is up to you. The former is often better, since the program will Stop before generating incorrect data. The latter simply ignores integer overflow -- which will usually result in incorrect answers being generated.
Keywords: q4
For Q4 what is the command to make the terminal bleep when any other character is entered apart from those specified?
Output an ASCII "bel" character:
out ! BELL
The `BELL' constant is defined in `consts.inc', that is included by q4.occ.
The constant definition is simply:
VAL BYTE BELL IS 7:
It may not work on some terminals -- i.e., those that cannot beep, or those that are configured not to beep.
Referrers: Question 32 (2003)
do we hand in Q4 through reception or online?
At Reception -- cover sheet, printout of code, and process diagrams. The deadline for Q4 is now Thursday 20th November.
Keywords: q4 , submission
Hi, i'm trying to implement the second part of q4, where the inputs `n' and `i' have an effect on the operation of the program.
I have defined a `monitor' process which outputs 1 to a chan, depending on what the keystroke is:
PROC monitor ([]CHAN OF INT out, CHAN OF BYTE keyboard, intr)
--{{{ forever
WHILE TRUE
... wait for `intr' and process accordingly
--}}}
:
When trying to implement my version of `numbers', I wanted to continue using the numbers as normal, but if the INT 1 came in through a `control' chan, to set the value of the input to the prefix as 0 (hence starting it from the beginning again)
PROC my.numbers (CHAN OF INT out, control)
CHAN OF INT a, b, c:
WHILE TRUE
PRI ALT
INT x:
control ? x
IF
x = 1
c := 0
TRUE
PAR
delta(a, out, b)
succ(b, c)
prefix(0, c, a)
:
However, it doesn't work. Any help ? :)
As regards numbers, you can't do what you're trying to do with the above code. The compiler will reject it at the ``c := 0'' line, since you can't assign to a channel. We'll assume you meant to output instead, `c ! 0'.
The compiler won't reject that code (if fixed), but it won't work either. Initially `my.numbers' will wait for a signal on the `control' channel -- and won't output anything.
You'll notice this immediately, and maybe press the `n' key to prod `my.numbers'. Given this, the ALT will wake up and run the IF process. Given that `x' will be 1, `my.numbers' will attempt to output on the `c' channel, and deadlock -- there isn't anything connected to the other side of that channel. If, for some reason, `x' was not 1, the original `numbers' process network is run (by the PAR). That'll happily output numbers forever and ignore the `control' channel, such that an attempt by `monitor' to communicate will cause deadlock (in `monitor' as it attempts to output).
You actually need to modify the original process network for this one, as will be explained in the seminars this week (if it hasn't already). To do this, you need to understand what happens when the `numbers' network is switched-on; essentially a number `flows' round in the loop, being incremented by `succ' each time, with `delta' producing the copy that is output. Thus, to reset the numbers back to zero, you need to interfere with that `flow'.
In occam, you can't interfere with a process externally -- the compiler just won't let you (unless you forcefully turn the checking off, but this is rarely a good thing). Attempts to communicate `externally' on the `c' channel (and in parallel), will be banned by the compiler. The modification needs to be `deeper'.
Note: Eerke has mentioned that the deadline for Q4 has been moved back one week, into project week. From the ukc.cs.cs2 newsgroup:
This also reduces the deadline bunching in week 8: the minor pieces of coursework are still there, the major one for CO516 is now the single deadline in week 9.
.. so you've got a bit more time on this.
Keywords: q4 , process-networks
2002 |
I'm trying to edit question 4 for the assignment but when I open it using 'gvim q4.occ' it opens but is just black and white text and it beeps at me!
Check the answer to Question 16 (2002). Note: starting work for an assignment the morning that assignment is due is probably not a good strategy ...
For the second modification task, I have created my own processors numbers.reset and integrate.reset which respond to the inputs 'n' and 'i' respectively, however when I assign the replace processor to be used within each of these processors, it displays an invalid process error:-
: reset ? ch
: IF
: (ch = 'n')
: PAR
318: replace (a, 0, b)
: delta (b, out, c)
: succ (c, d)
: prefix (0, d, a)
: TRUE
Error-oc-q4.occ(304)- Invalid process
type tree not caught by case (switch) is CHAN
Why does this occur?
Well ... replace takes 3 channel parameters and you supply an INT (0) as one of them! The Solaris kroc compiler does give a poor error message, but nobody at INMOS ever thought someone would write code like that! The Linux kroc handles this better.
Your code is very wrong though. You are misunderstanding something fundamental. See your seminar leader. [If you get an 'n' in the above, you start up a PAR construct that never ends ...?]
For part two of q4, where it states "clearly numbers and integrate will have to be reimplemented", do we declare a new process (such as numbersOne) within q4 and modify this or can we edit the version in demo.nets?
You need to declare a new process (such as numbersOne) before q4 in your file q4.occ. Cut and paste the numbers code from demo.nets and modify that. You can't, of course, edit the file demo.nets - you don't have write permission ...
Keywords: q4
Is it me or for the second modification do you have to change not only numbers to accommodate a reset command but prefix as well? The same goes for changes that have to be made to integrate and its internal code. Is there an easier way to do this or not?
I'm afraid it's you. You have to change the numbers process because it's functionality has changed - it's got a reset line! To make this change, however, you don't have to change any of its old sub-components - i.e. prefix, delta and successor - but you do have to insert one extra sub-component into its circuit. The same observations apply for the needed change to integrate.
Keywords: q4
I have just completed the 'p' operation. It un-does the last operation but the numbers are one out each time:
43902 963714753 43903
43903 963758656 43904
43904 963802560 43905
43905 963846465 43906
Is this still correct or should I be getting the same in the last colunm as in the first colunm?
No - that's fine! The model answer (answers/a4) does the same thing.
Keywords: q4
In q4 you say 'q' should be dealt with by putting the system into deadlock. Can't we use the command STOP instead?
Well ... you can, but it's not very nice. Any process executing a STOP - in the current versions of KRoC - causes the whole system to stop in a rather ungraceful way. On the Solaris version, it even causes a core dump! Later versions of KRoC will offer an option so that only the process executing a STOP will stop (i.e. freeze, which is subtly different from terminate) - leaving the rest of the system running. This is what is supposed to heppen.
So, getting your process to respond to 'q' with a STOP is allowed - you will not lose marks for this solution. For a better solution see Question 12 (2002).
This is the error i keep getting and I don't understand why, max.chans is still set at 3, can you help, I can't seem to get passed this to get on with the rest!?
raptor$ kroc q4.occ
: delta(a,b,e)
: integrate(b,c)
: delta(c,d,f)
: pairs(d,g)
315: layout.max.chans(e,f,g,screen)
:
::
:
:
Error-oc-q4.occ(315)- Too many actual parameters in call of layout.max.chans
You have too many parameters! layout.max.chans takes just two parameters - an array of input channels and an output channel. You are supplying four parameters, :-(.
Your channels e, f and g should be elements of an array - e.g. c[0], c[1] and c[2]. Then, your instantiation would be:
layout.max.chans (c, screen)
An alternative solution is to keep your channels, e, f and g, as they were and construct the array required by layout.max.chans on-the-fly:
layout.max.chans ([e, f, g], screen)
For the final modification to q4, when my program is running, I press q and the screen outut stops, and then if I press any key a deadlock message comes up and the terminal shows the raptor prompt again.
Presumably, you react to the q by sending a suitable signal to the same process implementing the suspend mechanism? What we were suggesting was for that process to terminate (i.e. exit its loop and finish) when it gets that quit signal. That leaves no route for the streams of numbers to get to the screen and most of your q4 system is deadlocked.
However, your keyboard monitoring process is still alive, waiting for more keystrokes. If you type anything but the ones it wants (e.g. anything bar 'n', 'i', 'p', 's', 'q'), it swallows it and loops around and stays alive. If you type an 'n' (for example), it tries to output a reset signal to a deadlocked component. That doesn't succeed and the keyboard process is stuck trying to output. There are now no processes left to run - and, now, the run-time system can announce deadlock and terminate. This solution is fine, but the model answer does something slightly different ...
Referrers: Question 14 (2002)
2001 |
Can you give me a hint on how to implement the `PAUSE' method for part 4? I know how to do the quit function but need to be able to put this deadlock within the pause function.
Implement a `PAUSE' in the same way as you did for question 3 (as discussed in your seminar groups). To cause deadlock as the response to a QUIT, the simplest way is to arrange for the process that manages the PAUSE effect to terminate - that leaves its upstream processes blocked all trying to output. Your keyboard monitor is still active - so your system is not yet deadlocked. But as soon as you type one of the characters to which it responds by outputting to the rest of your (now blocked) system, that output won't be taken and your keyboard monitor will block. Everything is now stuck and the run-time system will detect deadlock and quit.
Keywords: pause-process , q4
I have created the `pause' process to respond to `s' as step 4 of Q4 asks. But where does it go? Does it take input direct from the keyboard and then outputs to the monitor or does the monitor output to the pause process??
It can't take input direct from the keyboard (as happened for question 3), since the keyboard is already connected to the monitor process. Channels may only connect to one process (at each end). So, I guess that monitor must output to the pause process!
Oh - I see what you were wondering: connect keyboard to the pause process along with the input/output channels whose traffic it's going to freeze ... and pass on keyboard input other than `s' to the monitor. Well, you could try that but I would advise against. There is a nasty deadlock lurking if you do this ... can you see it?
Keywords: pause-process , q4
From Question 31 (2000), it says:
Getting the monitor to trigger a deadlock (in response to a `q') is easy and will earn full marks (for this part).
Would we get full marks if we implement a livelock ... or do we have to trigger a deadlock?
Forcing a livelock is a bad idea - your program keeps on running! Forcing a deadlock will terminate your program.
In Question 4, for the monitor process we are asked to implement the following: `any other character is an error and is processed by bleeping the screen'. I've looked at last years Q+A's on the web but I can't find help on this. Could you give some kind of clue as to how we can produce a bleep from the PC squeaker in occam?
You missed it! See the answer to Question 18 (2000).
2000 |
I get an error message when trying to compile the folowing:-
PROC plus.modified (CHAN OF INT in1, in2, control, out)
WHILE TRUE
PRI ALT
control signal
... actions when control signal is received
plus (in1, in2, out) -- <<< ERROR MESSAGE HERE
:
I get an error message saying expected end-of-line found when a ? was needed. What's the problem?
You are creating an instance of the plus process in a position where the compiler expects another guard for your PRI ALT. There is nowhere legal you can put that line without adding an extra SEQ (or, possibly, PAR). Bear in mind that once plus starts, it never terminates - so don't ever expect to go around the loop again if you invoke it somewhere in the loop body ...
The first guard of your PRI ALT is syntactically illegal. There should be a ? in the middle of it - and where is your signal variable defined?
Finally, if your PRI ALT is really meant to have a single guard, it's a bit pointless - better simply to use a SEQ.
Keywords: q4
I am having some trouble with part 3 of the assessment. Here's my code:
... censored
What I'm trying to do is pass through a channel of INTs, multiplying them by a factor, whilst in parallel checking another channel to see if the monitor has passed a zero and, if so, changing the factor.
The problem is that KRoC won't complile the code because it won't let me read and write to a variable in parallel - which is fair enough 'cause I could see some problem arising if they both want access to it at the same time.
Is there a way to get round this, or do I need to rethink my ideas?
I haven't shown the code because it's wrong in too many ways, I'm afraid, and posting it would not help anyone.
It's not KRoC that won't compile it so much as the language doesn't allow it (and, therefore, KRoC rejects it). We are simply not allowed to look at a variable in parallel with another process that's changing it. So, you do need to rethink your ideas. Check out Question 44 (2000) and its answer.
Keywords: q4 , process-networks
I am currently doing the pairs toggling bit of Q4. I am trying to say
IF there is a toggle input THEN switched := NOT switched ELSE carry on excuting the rest of the code.
where toggle is an input channel and switched is a boolean variable.
You are describing a poll on the toggle channel. See slide 5-37 in the notes. You may consider the use of polling absolutely essential (see the comment on slide 5-37) for your solution to this part of the question - even though it's not!
Referrers: Question 47 (2000)
Should we be using PLUS/MINUS or +/- for Q4?
My class supervisor told me that we should be using +/-. But when I do that, my q4 process crashes very quickly due to not being able to wrap round into negative numbers. Is this OK or should I use PLUS/MINUS and allow the program to wrap round?
Please use PLUS/MINUS rather than +/-. That's what the plus process (from the course library) uses and that was chosen specifically to allow these demo programs to run forever. The Fibonacci sequence gets big very quickly - so the demo example program would crash very quickly otherwise. Of course, the numbers in the supposed-Fibonacci column are no longer from the Fibonacci sequence ... but never mind.
However, whether you use PLUS/MINUS or +/-, you will not lose marks. I've squared things with your supervisor!
In the specification for the p bit in q4.occ, it says: "take the output arriving from the tail from that arriving directly from the delta". I'm certain, well confident, well satisfied, ... ERM.. at least I think I've implemented it as specified, but my output gives:
-1 -2 -3 -4 ...
I am very tempted just to switch the channels going into plus so that it gives:
1 2 3 4 ...
when its in subtractor mode. Or are the negative numbers actually what's required ... i.e. the assignment means do as I say not do what you think I mean ... ?
You've got me here! In question 4 on the exercise sheet, it doesn't attempt to specify which way around the minusing should operate (in response to a p from the keyboard). So, doing it either way round would be OK.
In the q4.occ file, I tried to make this precise but - given the complexities of natural language - managed to say it the wrong way around :-( ... Apologies for this. So, doing it either way round - what I said or what I meant - is OK.
Keywords: q4 , negative-numbers
In question 4, when you press the i key to reset the integrate thingy, should it output 0, or the next value that comes in?
The question did not specify - so either version will be accepted.
Keywords: q4
I'm in the process of doing q4 and I've implemented everything except pairs. It all compiles but, when I run it, it immediately gives me an error:
Range error / STOP executed (signal 4) Fatal error code 1, core dumped Abort (core dumped)
First thoughts were that I had used STOP wrong. However, I took it out and still got the same error. I can't work out where I could be going out of range, so I just wondered if you could explain the error message to me so I could work out what part of my code it is refering to.
The run-time error messages are a bit terse, I'm afraid. The above error message can be caused by at least 4 things:
It's probably the last one that's your problem ...
Keywords: q4 , range-error , stop
Do you just want the code for q4.occ or do you want any new diagrams we have done drawn out as well?
You should submit hard-copy of your program listing attached to a cover sheet to the CAS office (by close of business on Thursday, 30th. November, 2000). You should also include network diagrams of any networks you have designed. In this case, that will be for your modified versions of numbers, integrate and pairs, together with the overall network for the q4 process. On these diagrams, channel names should be labelled with the names used in your code and the direction of data-flow should be arrowed. Neat hand-drawn diagrams on you program listings are fine.
For the assessment, are we allowed to code the modified versions of int and pairs sequentially, as is lecture slide 5-11? Or do we have to stick to creating them from the given components in "course.lib"?
No - when you modify those processes to introduce the reset/toggle channels, keep the same level of concurrency. But this can't be done just by inserting extra components from "course.lib" - you have to use some others. A big hint is supplied by the inclusion of the replace process in your starter file (exercises/q4.occ) - you just have to work out how to use it. The model answer reuses the existing sub-components (of numbers, integrate and pairs) unchanged - their behaviour is modified simply by inserting an extra process into their respective circuits.
Modified versions of slide 5-11 type implementations will be accepted, but will not attract full marks.
Keywords: q4
I am having trouble with the layout.max.chans process. I am calling it within another PROC as follows:
PROC q4 (...)
...
...
[max.chans] CHAN OF INT c:
PAR
...
...
...
...
...
layout.max.chans ([c], screen)
:
Am I calling it correctly?
No. Your c variable is already an array holding max.chans elements (that happen to be channels). The expression [c] creates an array with one element (that happens to be an array of three channels) - this is not what layout.max.chans is expecting! Your call should be:
layout.max.chans (c, screen)
Keywords: q4
When implementing the response to an `s' being pressed should it either:
The former - see the answer to Question 26 (2000).
Can we use the keyword STOP in response to a `q' being pressed in Assignment 2?
Yes - but KRoC is currently set up to regard STOP as an error, so your program will crash. That's OK but not very nice!
We might change KRoC to handle a STOP differently - occam allows more than one semantics. The default one is the current one - treat it as an error. The (arguably proper) one is that the process executing the STOP just stops, but other processes running in parallel continue.
If we made this change, then simply getting your monitor process to execute a STOP would stop that monitor - but the rest of your network might carry on producing output (depending on how you set it up). That would be wrong.
So, your monitor process needs to do something to block everything else as well (e.g. cause a deadlock). The model answer blocks all of the network, but leaves the monitor running (all it does is go into a state where it black holes all keyboard input). The system is not deadlocked because the monitor is still alive and accepting further input. Nothing more is being produced, though, and keyboard input is consumed but ignored - we have livelock.
Bringing a network to a graceful halt (by causing all its component processes to reach their natural end without triggering deadlock) is hard. The paper in the course book ("Graceful Termination - Graceful Resetting") shows how to do it - it's fairly mechanical but tedious. For this exercise, you would have to make new versions of all the basic cycle processes used from the course library - these new versions would be ready to terminate (i.e. no WHILE TRUEs).
But graceful termination is not required. Just getting the monitor to execute STOP is also not good. Getting the monitor to trigger a deadlock (in response to a `q') is easy and will earn full marks (for this part).
Referrers: Question 13 (2001)
I am currently working on modification 3 of q4. I have modified the code so that it switches between being a plus and minus process - but when switching to the minus process all the numbers printed are 1 greater than the number entered. Is this OK or should a further modification be made to compensate for this error?
It's OK! Turning the plus into a minus changes pairs into a differentiate, except that the first number that ought to be output is missing. All the question asks is that you make this change (dynamically, in response to a `p' from the keyboard). What it does doesn't matter. So the fact that it turns that last process into something that (almost) cancels out the second, leaving you with traffic that equals the input to the second - except that one number gets lost - is fine.
Keywords: q4
Help! I am trying to do part three of question 4 (the second assignment) and I can't get the following to compile. The error message is that state is not declared on the line marked:
WHILE TRUE
SEQ
BOOL state:
state := TRUE -- start with normal pairs process
WHILE state -- <<<< COMPILER COMPLAINS HERE
... loop body
Surely though, it is - just above the line which causes the compiler to fail!
No it's not!! It's declared two lines before the line complained of by the compiler. Declarations have scope for subsequent declarations and the first executable that follows (which must all be at the same level of indentation). In the above, the first executable following the declaration is the assignment - so state is in scope there, but not for the following executable (the while-loop).
To make the declaration have scope for more than one executable, those executables must be wrapped up in a SEQ (or PAR or WHILE or IF etc.) - that turns them into a single executable. This question has been asked before - see the answer to Question 3 (2000).
Keywords: q4 , variable-scope
Referrers: Question 54 (2004)
When implementing the part where the plus process is changed to a subtractor when `p' is pressed, am I right in saying we don't really have to change pairs apart from the reset. The rest is done by changing the component plus?
Yes - that is one way to do it. There is another way that does not require changing that plus process - merely inserts another component into the (modified) pairs network.
Keywords: q4
In Q4, when you say `suspends output to the screen', do you mean the processes should keep going and not output anything to the screen, or pause and wait until they are allowed to continue?
The latter - the processes should become blocked until output is allowed back through to the screen. Don't modify those processes in any way to get this functionalty. Do it the same way you did it for question 3 from the Execrcise Sheet (which was considered in your seminar groups).
Referrers: Question 32 (2000)
I am working on q4.occ. Inside one of my PROC headers, I have delcared a BYTE variable:
BYTE c:
I then read in a BYTE and store it into this variable. Then, I wish to do checks on this variable to see what character it is holding. For example:
IF
c = 'n'
... do something
This obviously isn't how it's done? Looking back at bugs.occ quotations marks give the ASCII value of the char.
Please let me know how this is done as I can find nothing about this in the notes.
There is nothing wrong with the code fragments above. A character within single quotation marks is a BYTE literal, whose value is the ASCII code of the quoted character. Mail me (or your seminar leader) your complete code and say precisely what goes wrong.
Keywords: q4
On q4, when I convert plus to minus in pairs ... should the output from pairs be one greater than the output from numbers along the same row of data? For example, if the current numbers value is 7, then the value in the pairs column on the same line is 8 ...
Yes. (I'll say a bit more when the q2 submission deadline is over ...)
Keywords: q4
|
Last modified Mon May 15 17:39:47 2006
|
