|
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 q1
2004 |
I have nearly finished the first CO516 occam assesment, but I am getting couple of error messages which have bewildered me.
I am getting two types of error. The first one is "incorrect indentation". I am getting this error in reference to the two lines indicated below, but as far as I can see they are ok.
I am also getting an error which states that "a" and "b" (which refer to PROCs) are "not declared" in "PROC q1".
My code follows, I would be very grateful for any pointers.
PROC q1 (CHAN OF BYTE keyboard, screen, error)
CHAN OF INT aToB:
PAR
a (aToB) -- a not declared
b (aToB, screen)
:
PROC a (CHAN OF INT aToB)
INT num:
SEQ
num := 0
WHILE TRUE
SEQ
IF
(num = 0)
num := 1000
aToB ! num -- indentation error
(num <> 0)
num := num - 1
aToB ! num
:
PROC b (CHAN OF INT aToB, CHAN OF BYTE screen)
INT num:
WHILE TRUE
SEQ
aToB ? num
out.int (aToB, 10, screen)
out.string ("*n", 0, screen)
:
In occam, the scope of PROC declarations follows that of other (e.g. variable) declarations. Specifically that a "name" (as declared by any declaration) may not be used until it has been defined. This applies to PROC and FUNCTION definitions, DATA TYPE and PROTOCOL declarations, and ordinary variable/channel/etc declarations. The "undefined" error you get in "PROC q1" is correct -- "a" and "b" are not defined yet. To correct this, the declarations of "PROC a (...)" and "PROC b (...)" should be moved above the declaration of "PROC q1 (...)". Thus they will be defined when referenced by q1.
Unlike C and Java, the "main" procedure in occam (where the program starts) is not defined by any special name (e.g. "main" in C and Java programs). Instead the last PROC definition in the file is used, and must have the formal parameters:
PROC q1 (CHAN OF BYTE keyboard, screen, error)
in that order. The name of the PROC and names of the parameters are largely unimportant. The Linux version of KRoC allows some of these parameters to be omitted, but does place restrictions on what the parameters may be called. The standard KRoC top-level process interface (as above) will work perfectly (except for warnings about unused parameters).
The indentation error in your code arises because that line of code is incorrectly indented. It is incorrectly indented because it is incorrectly structured. Whenever you have more than one process in occam (e.g. the assignment and output), you need to explicitly state whether they are to be run in sequence or in parallel. See the other questions relating to incorrect-indentation for examples of correct usage.
Although the code for "PROC a" is largely fine, it could be improved somewhat. Firstly, the brackets around the "IF" conditions are not necessary --- brackets in expressions are only required when there is ambiguity (since occam does not have any operator precedence -- see below). "IF" conditions are just boolean expressions. Secondly, the "num <> 0" condition would probably be better as just "TRUE". This is because "num <> 0" can't possibly be false, but also because "TRUE" is more meaningful as "otherwise do this" than some expression. Finally, you have duplicated code in both branches of the "IF" (the output). It would be better to "pull" these outside the IF" (and this sort of thing applies to any programming language). I'd also query the use of "aToB" as a sensible formal parameter name in "PROC a" here. Using "aToB" strongly implies that channel connects this "A" process to some "B" process. Although this turns out to be the case here, it might not be always, and that could be misleading. Better to pick a name that has relevance for "PROC a", but is completely unrelated to any actual usage in a process network (i.e. where the process is "placed"). For example:
PROC a (CHAN OF INT out)
INT num:
SEQ
num := 0
WHILE TRUE
SEQ
IF
num = 0
num := 1000
TRUE
num := num - 1
out ! num
:
Aside: the reason occam has no precedences set for its operators is because many of us cannot remember what they are in those languages that do have them. For instance, how does the following parse in Java:
if ( a > b + 1 << 4 && 3*a + 2 == x) {...}
? Can you remember the relative precedence between all those operators?? Just what does that expression mean?!
In occam, we don't have to remember anything -- but we do have to bracket our expressions explicitly to give the bindings we want. What-you-see-is-what-you-get:
IF
(a > (b + (1<<4))) AND (((3*a) + 2) = x)
... do something
Keywords: incorrect-indentation , variable-scope , q1
I understand when you say that only `screen' is used as an output channel and that `keyboard' and `error' are not used, but I don't see the connection between running:
/usr/local/courses/co516/answers/a1
which produces a continuous list of numbers, and what we have to do check our `q1' works ?
That program (`a1') is the model solution for Q1. Your program should produce the same output as it does (i.e. a continuous stream of numbers).
Keywords: q1
Your reply to Question 16 (2004) was that we can't test out code by typing in numbers. How are we meant to test it then or how are we meant to know if what we've done is correct ?
Also if we don't finish `q2' by tomorrow, is it possible for us to email our programmes to you direct ?
Are you asking about Q1 or Q2 here ? In fact, both Q1 and Q2 should just produce output spontaneously. You can see if you're generating the correct output by comparing with the output from the model solution. Q1 should generate the sequence: 0, f(0), g(f(0)), f(g(f(0))), ..., as produced by the `A' process, displayed in groups of 3 numbers with their average.
The input for Q2 (differentiate) is the `numbers' process, as explained in `q2.occ'. But Q2 is not assessed, so you don't need to submit it. If you want someone to check it over, email your class supervisor, or bring along to the seminar/terminal-session.
Keywords: q1
Can you tell me how we're meant to test `q1.occ', i.e. what inputs are necessary and what the outputs should be ?
I've tried inputting numbers into the console but they come up with errors and I'm not exactly sure how we are meant to test this thing.
You're not supposed to be giving `q1' any input! The network diagram given in `q1.occ' shows that the `screen' channel only is connected -- the `keyboard' and `error' channels should not be used.
To get an idea of the output it should produce, run the model solution on raptor:
/usr/local/courses/co516/answers/a1
The spacing in your output may be different, but the numbers should be the same.
Keywords: q1
Referrers: Question 18 (2004) , Question 22 (2004)
What is `demo.occ' supposed to do and how is it meant to help us with `q1.occ' ?
The `demo' process network outputs 4 columns of numbers from various example process networks. You should be able to understand the code that sets up the network (and draw the diagram for it).
The output from `demo' is similar to the output required from `q1'. In `demo.occ', this is done by the `layout.max.chans' process. The interesting bits are its use of `out.int' and `out.string' for actually outputting numbers and strings on a BYTE channel.
When I compile the program, I get output saying:
Warning-oc-q1.occ(63)- Parameter error is not used
Warning-oc-q1.occ(63)- Parameter keyboard is not used
KROC octran Version 1.0 for sparc-sun-solaris2.5.1
I think this is saying that basically I've defined the variables `error' and `keyboard' but not used them. Was this an error in that we should not have defined `error' and `keyboard' or do we just leave them in and if so what was the point of defining these two variables ?
Does this mean I can't run the program ?
Those messages are warnings, not errors. So, there's nothing to stop you running the program -- it compiled successfully. Your screen-dump also included some GTK messages generated by gvim, but these are totally unrelated (except that gvim was started in that terminal, hence its error messages end up there).
As a point of concept, `keyboard' and `error' are not variables. They are channels and the distinction is important. You should not remove these from the top-level PROC definition, which should always have the form:
PROC thing (CHAN OF BYTE keyboard, screen, error)
The name (`thing') is unimportant -- what makes it the `top-level' process is the fact it's defined last in the source file. If you're using KRoC/Linux or KRoC/cygwin, removing some or all of these top-level channel parameters is safe, but not on the KRoC installed on raptor.
Keywords: q1
What exactly do we need to submit for Q1, e.g. just the code for PROCs `a', `b', `q1'. Are any special network diagrams required ?
How do we submit Q1, e.g. print out of code, hand in to CAS with coversheet, or email, or both ?
These questions have almost certainly been answered in the lectures and classes... You should submit a print-out of your `q1.occ' file, with a cover-sheet, to CAS. Coversheets are available in the CO516 pigeonhole.
No special network diagrams are required, because there should already be one in the `q1.occ' file -- showing the three processes and their wiring.
Please also remember to print your code in a monospaced font. To print from raptor, you can use a command like:
a2ps -1 -L100 -o - q1.occ | psdouble | lp -d times
Replacing `times' with a different printer if needed.
Keywords: q1
I keep getting the output:
KROC: Program Deadlocked (no processes to run) but I can't figure out why.
I've looked at the keyword list and the Q&As associated with the word deadlock but still haven't come up with anything.
[code snipped]
Posting questions like this to the anonymous Q+As is not generally advised -- the answer is only likely to be meaningful to the person that asked the question. Please direct such questions to your seminar supervisor.
But looking at your code: you have your `B' process outputting integers, that is not wrong as such, but a little more complex than was expected for this assessment. The system deadlocks when `B' tries to output, since the corresponding inputting process is executing in SEQuence with it. Moving the instantiation of `B' in the `q1' process will fix one problem, but leave some others.
For this assessment, it's easier to have the `B' process do the output to a `BYTE' channel that `q1' simply connects to its own `screen' channel.
Keywords: q1
On the `q1' program after we have output the 3 intergers and then their average, are we to output the next 3 + 1 on a new line and if so how do you have a newline character in occam ?
Yes, the numbers output should be tabulated, as seen in the `demo' program. Finding out how to produce a new-line should be pretty simple (look at the code for `layout.max.chans' in `demo.occ', lines 15 and 16). A slightly quicker way is just to output a newline character to the screen channel:
screen ! '*n'
(note that asterisk is the escape character in occam, similar to backslash in C and Java)
Keywords: q1
Is it a possible for you to give a brief example of the kind of output you are expecting from q1 ? I.e. it says tabulated, but I have also been told string form. Many thanks.
Not sure what you mean by "string form"; but ultimately you have to output BYTEs from the program, usually formed into strings (see the various example "hello world" programs for an idea of this).
The "demo" program is a good idea of what is expected for output, at least in layout. You can view the output a screenful at a time with:
raptor$ ./demo | more
(where `|' is the pipe symbol, shift-backslash on UK keyboards). The key lines in `demo.occ' for tabulation are 15 and 16.
Keywords: q1
2003 |
In q1.occ, what's the name of the channel that connects A to B? Is it screen? In that case, how can B receive inputs from the channel screen and then output values to that channel again?
The channel between A and B needs to be declared by yourself in the body of the main process (PROC q1). You can give it any name you like, provided the name is not already in scope - i.e. you can't call it screen as this is already declared in the header of the q1 process. As you mention correctly, it would not make sense (and be illegal in occam anyway) to use the same channel for both input and output.
Keywords: q1
2002 |
For question 1 of the Exercise sheet, how do you get process q1 to actually communicate processes a and b?
Don't really understand this question. Process q1 contains one instance each of processes a and b - it doesn't communicate them?!! If still puzzled, go to your classes and ask your class supervisor.
Keywords: q1
2000 |
In PROC B from question 1 of the OCCAM EXERCISE SHEET, I have got the program to work by using the procedure:
out.int (x, field, out) -- the out channel is connected to the screen
However I was wondering if there is any way to do it without using that procedure?
Well, you certainly can't:
out ! x -- won't compile!
since out must be a channel carrying BYTEs and x must be an INT.
Casting it into a BYTE (see Question 7 (2000)) won't help either:
out ! BYTE x -- will compile but is wrong!
Suppose x were the INT 65. What we want to do is output the ASCII codes for the characters '6' and '5' to the screen - this is what the PROC out.int does. If you cast x into a BYTE as above and send that to the screen, what you would see on the screen is the character 'A'!
So, you have to use out.int (or something that does a similar job).
Keywords: q1
Was Q1 a little bit over our Occam level, or is it just me? :)
We still have not covered enough occam in the lectures to answer this. However, by looking ahead in the slides a little bit and reading the first 6 or so pages of the occam2.1 Chekclist ... and by working with friends, you should be able to crack it! It's a challenge and is not for assessment. You should certainly be able to do it by the end of next week (27th. October) ...
Keywords: q1
|
Last modified Mon May 15 17:39:47 2006
|
