|
CO538 Anonymous Questions and Answers Keyword Index |
This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.
To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
Keyword reference for q1
2012 |
Submission reference: IN2158
Relating to exercise 1 of the occam exercises (preliminary) worksheet.
I've managed to get my program outputting all the numbers fine but can't get it to implement a filter process. Currently my code looks like this:
PROC filter (CHAN INT in?, out!)
... declare some variables (some are given INITIAL values)
SEQ
... two primitive processes (one input and one assignment)
IF
v > 0
out ! n
TRUE
out ! v
:
... [snip rest of code]
This runs and outputs "5" and then crashes (presumably deadlocked?). I understand why it is outputting 5 — because in the IF loop of filter it is doing ..[snip text].., but why does it deadlock after that on the next iteration?
Any Help Appreciated - I know my code's messy but I've been pulling bits in and out for so long now that I just want to get it working then condense it later. Thank you.
I think you have a slight misunderstanding about how an IF process works in occam-pi.
You mention an "IF loop", but the IF has no loop behaviour — it only happens once. Thus, your "filter" process does its thing once (which produces the value '5') and then terminates — which means it disappears from the network. The rest of the system cannot now continue, because the processes before and after (where filter used to be) will be stuck trying to communicate on channels whose other ends are dangling (i.e. connected to no process). Processes trying to communicate with those stuck processes also become stuck and, very soon for this system, all processes are stuck and we have deadlock.
For this (and other) exercises, we're happy for things to run continuously — any process which needs this behaviour must have a loop in somewhere, as your S0 and S1 processes presumably do. [Aside: you can get the same looping behaviour with recursion, but we haven't told you how to do that in occam-pi yet!].
Final thought: "I know my code's messy ... I just want to get it working then condense it later." This always leads to tears. Messy code is very very very much harder to get working than clean neat code. Always always write clean code, neatly spaced and indented. If you write code that doesn't work as soon as it compiles (and this should not happen), look at it and ask yourself: "Why should it work?" — do not ask yourself: "Why doesn't it work?". Looking at clean neat code gives yourself a chance to understand what it is that your code is really doing, compared with what you want it to do. Looking at messy code hugely reduces that chance.
Keywords: q1
Submission reference: IN2155
From Exercise One:
out.string ("*c*n", 0, out!)
What do the "*c*n" bytes mean please? The documentation says this is the string to be returned via out?
A string literal in occam is almost the same as in Java: text enclosed between double-quotes ("). One difference is the expression of special characters, such as carriage-return and new-line. In Java, these are introduced by the escape-character backstroke (\). In occam, the escape-character is an asterisk (*). So, "*c*n" is a string containing two characters: carriage-return followed by new-line. By the way, to get an asterisk into an occam string, just precede it with the escape-character – for example, "****" is a string containing two characters: an asterisk followed by an asterisk. Here is a list of the common special characters for occam strings:
*c (carriage-return)
*n (new-line)
*t (tab)
** (asterisk)
*" (double-quotes)
*' (single-quote)
Note: the documentation for out.string does not say that anything is a "string to be returned via out". out.string is not a function that returns anything. out.string is a process that runs for a short while, outputting the string (given in its first parameter) down the channel (given in its third parameter), right-adjusted (i.e. padded with spaces) in the field width (given in its second parameter). The field width is only relevant if it is greater than the number of characters in the string – so 0 is always ignored. The output goes one BYTE at a time, in separate communications.
Documentation to the occam-pi libraries is linked from the "Practical Resources" box on the Moodle page for this course. Here is a shortcut to the course module, which contains the out.string process. This is the library made available to your code by the line:
#INCLUDE "course.module"
Keywords: q1 , out.string
Submission reference: IN2154
In q1, a diagram shows that S0 and S1 must be input into alternate. I can't seem to figure out how to turn S0 and S1 into inputs, or how to implement them into the process alternate. Could you possibly give an example of one PROC being fed into the input of another?
First, let's correct the language in your question. This is important because asking the right question shows the way to an answer. Asking the wrong question shows a misunderstanding that needs to be corrected – otherwise, our answer will not be understood.
You write: "In q1, a diagram shows that S0 and S1 must be input into alternate". But S0, S1 and alternate are all processes. And alternate has (two) input channels that deliver integers. Therefore, it makes no sense for a process (e.g. S0) to be input into alternate – only integers can be input into alternate.
You write: "I can't seem to figure out how to turn S0 and S1 into inputs, or how to implement them into the process alternate". But turning processes (e.g. S0 and S1) into inputs makes no sense – neither does implementing them into another process (e.g. alternate).
A correct description is as follows: S0 and S1 are processes with output channels supplying integers; the diagram shows instances of S0, S1 and alternate, where channels connect the outputs from S0 and S1 to the inputs of alternate.
To implement this diagram as the code body for the q1 process, compare with the system and coding in "Basics" slide 9. This shows a process, integrate, with external channels in? and out!. Internally, there are three sub-components (process instances): plus, delta and prefix. These sub-components are connected to each other by three internals channels (a, b and c) and to the external channels (in? and out!). Study the coding carefully.
The diagram in your question is the second diagram on page 2 of the assessment sheet for q1. This shows a process, q1, with external channels keyboard?, screen! and error!. Internally, there are four sub-components (process instances): S0, S1, alternate and print.stream. These sub-components are connected to each other by three internals channels (for which names need to be invented) and to just one of the external channels (screen!). Use the coding of integrate (from "Basics" slide 9) as a template for implementing this version of q1.
Note: the simpler version of q1 in the diagram on page 1 of this question should, of course, be done first!
Note: leaving external channels unconnected ("dangling") is generally not a good idea and the compiler will complain about (though allow) it. Unfortunately, the Windows host version of the Transterpreter requires exactly those three channels as the interface for the main occam process in your program (always the last PROC in your file). The q1 process only needs the screen! channel, but has to have all three.
Your last question was: "Could you possibly give an example of one PROC being fed into the input of another?" You meant: "Could you possibly give an example of the output from one PROC being fed into the input of another?" See "Basics" slide 20 (and 21-25).
Keywords: q1
2011 |
Submission reference: IN2037
How will the assessments be marked? Will we be assed purely on whether our code has the required funcionality, or will things such as style and efficiency be looked at as well?
Correct code is not enough – it must be obvious that it is correct as well! Obscure coding, therefore, will lose marks ... style matters.
Efficiency, at this stage, is not top priority – though code that is gratuitously inefficient will lose marks.
There are, for example, some strangely complicated ways of coding S0. Keep it simple and clear, which is easy to say but one of the trickiest engineering skills to master. Absolutely essential to master though, :).
Keywords: q1
Submission reference: IN2034
I'm trying to put the 'alternate' process in the network for q1, and as far as I can tell things should be programmed about right, but when I run the program, it prints 0 then 1 then it deadlocks and I'm not sure what to do about it.
What should I look for in the code, or what sort of code would likely cause a problem like this so I can change it?
Make sure your 'alternate' has a loop ... that's the most common accident!
If there's no "WHILE TRUE" at the start, the code body will execute just once – enough to get the first two numbers through (one from each input) – and then terminate, leaving the approaching number stream with nowhere to go. The process before 'alternate' blocks trying to output to a terminated process and the ones before that block trying to output to a blocked process. Result: one process terminated, three processes blocked, no other processes to do anything – deadlock!
Check also that your 'S0' and 'S1' have loops! Otherwise, each will only output one number and then terminate ... which also accounts for what you are seeing.
Welcome to the wonderful world of parallel processing, :). Deadlock is a natural hazard ... but (mostly) easy to avoid as soon as you realise what's happening. There are much darker hazards ... like data races, where variables change without your code (apparently) doing anything ... and from which occam-pi protects.
Keywords: q1
Submission reference: IN2033
Any advice on how to go about doing the last part of q1 with regards to the print screen section, as I'm not sure of the best way to tackle this section of the problem?
By "print screen section", I'm assuming you mean the second-last paragraph ... about modifying 'print.stream' to take an extra parameter (say 'nCols') that specifies how many numbers to tabulate across each line of output?
Tabulation is already handled by the line that's already there:
out.int (n, 10, out!)
which formats the digital representation of the value of 'n', right-justified in a field-width of 10 characters (i.e. padded with spaces on the left to make up 10 characters), and outputs those 10 characters (actually, their ASCII BYTE codes) to the 'out' channel.
So, all that's needed is to write some code that ensures that the new-line code:
out.string ("*c*n", 0, out!)
only happens every 'nCols' times around the loop.
If you really did mean the last line of the question (?), all that's needed is to modify your previous code for the body of the 'q1' process to invoke your modified 'print.stream' with a suitable value for its extra parameter.
Keywords: q1
Submission reference: IN2031
For Assessment 1, I can link together SO, S1, print.stream and alternate using channels. I'm sure the code does what its supposed to do. However I'm unsure as to what exactly goes in to PROC q1 (code-wise). Does it take an input from print.stream that then outputs to the screen channel? Or does it output to print.stream? I'm not sure what it's exactly meant to do. I've had a look at several of the example programs and still haven't managed to work it out.
Any hints here would be appreciated :)
If you have done what you say in your first sentence, you are almost done! But where have you done it? This is (or should be) the network shown in the middle of page 2 of the exercise sheet. This network is inside a box labelled q1 (i.e. this network is the implementation of the q1 process). Therefore, the code that builds this network should be the (sole) contents of the body of the PROC q1, replacing the "SKIP" line in your starter file.
The "it" in your fourth sentence makes no sense, as it seems to refer to the code discussed in your first two sentences?! The network diagram (middle, page 2) shows the output from alternate fed (via a channel whose name you have to choose) to the input of print.stream, whose output is fed to the external screen channel. The network your code implements cannot go between print.stream and the screen channel – that makes no sense! The network your code implements ("linking together SO, S1, print.stream and alternate using channels") should represent the diagram (middle, page 2) and its output should connect to the external screen channel.
All the code in the body of q1 has to do is:
Keywords: q1
2009 |
Submission reference: IN1806
I'm having a problem with my filter process. I understand that it needs an input channel of type INT and an output channel of type INT, and my code logic appears to be solid, however I keep ending up with a "Not enough parameters in top level." error. It expects 3 BYTE channels instead of 2 INT channels. Can you give me any pointers as to where I'm going wrong?
In occam-pi, all user-defined things (variables, processes etc.) must be declared before they are used.
I suspect that your filter process is the last item in your file – i.e. after the declaration of the q1 process that is using it. Move the declaration of filter ahead of q1 and that should fix things.
The error message (about expecting 3 BYTE channels) is because the last process declaration in your file is the one from which execution starts and the Transterpreter implementation insists that this must have those 3 BYTE channels (for keyboard, screen and error streams). For this question, that last process must be q1.
Keywords: q1
Submission reference: IN1805
Hi,
Please can you specify the requirements of our modified print.stream process (the last part of Exercise 1) if we pass in '0' as the number of columns - do you want no new lines?
The question says that the parameter "specifies the number of columns of output produced". So if its value is 0, no columns of output should be produced ... which could be interpreted as nothing or, possibly, an infinite number of newlines! It's also possible to interpret this as you suggest: if the output is a single infinite line of text, there will be no columns!
For your answer, you may assume that sensible values are supplied – i.e. 1 or more.
To be robust, you may deal with bad values (e.g. 0 or less) in some way that you document. For example, you could round such bad values up to 1. That would be great (but there are no extra marks for such care – for this exercise).
Keywords: q1
Submission reference: IN1803
Can you give any tips on filter for q1? I've got a filter procedure. I'm just not sure how to use this in PROC q1 without it deadlocking.
You need a filter process – in this case, a forever-running process like all the others(S0, S1, alternate and printstream) in this exercise. Your filter process should have one input and one output channel that carry INTs – its job is to remove (i.e. not pass on) any integers that are exact multiples of 5. As the question says, this filter process just needs to be spliced into the existing network (i.e. it runs in parallel with the other processes).
Keywords: q1
2008 |
Submission reference: IN1504
For the filter in Assignment 1, does 0 count as a multiple of 5? ie; should we have the program produce 0, 1, 2, 3, 4, 6... or 1, 2, 3, 4, 6... when the filter is implemented?
Yes, 0 is a multiple of 5 ... (5 x 0 = 0), :).
Keywords: q1
Submission reference: IN1501
Hi, I am currently doing the first exercise on assessment 1, the part which requires us to alter the print.stream process to allow multiple columns. I was wondering, are you expecting us to define a new process for dealing with this, that we then use in print.stream process?
Thanks.
No. The question says: "modify print.stream so that it takes an extra (VAL INT) parameter that specifies the number of columns of output produced". So, for this part we do want you to change the process code (header and body) of print.stream. It would not be easy modifying the stream of characters (BYTEs) coming out from print.stream in another process downstream from it.
Keywords: q1
Submission reference: IN1489
Hi Peter/Fred, For the first assessment, when we're altering the print.stream proc, do you want us to sensibly deduce the colwidth based on the size of the numbers? Or are you happy with it staying as 10?
The largest/smallest 32-bit integers are 2,147,483,647 and -2,147,483,648 respectively. Without the commas, therefore, the longest number of characters needed for such an integer is 11. So, keeping a fieldwidth of 10 will mis-align large negative numbers and cause large poisitve ones to run into each other if they happen to occur in adjacent columns of the same row. Play safe: use a fieldwidth of, say, 15 (which will let you have up to 5 columns in an 80 character wide terminal window).
Keywords: q1
2007 |
Submission reference: IN1295
What should the column value be? It is not specified anywhere in the early-exercises.doc so do we hard code it to any value we like? Do we read it in from the keyboard? I have lost marks for silly things like this before. Thanks ciao
Any sensible value (for the number of columns) will do – say 10 ...
Keywords: q1
Submission reference: IN1294
Hi, Are we supposed to check for a column size < 1? There is no mention in the spec and I assume that we are not going to get extra marks (or be marked down) for these kind of checks since this is not the purpose of the exercise. Ciao
Nope – for this exercise, your modified print.stream may assume it will be given a sensible value for the number of columns requested (e.g. more than zero and less than ten).
Your point is a good one though. In general, code should be robust against bad arguments.
Keywords: q1
Submission reference: IN1292
When will submission for the assessment part 1 be open as the deadline isn't all that far off?
Submission directories are open now on raptor:
S:\proj\co631\simplestreams\<your-login-name>\
Please copy your completed q1.occ file to the above. You can do so as often as you like until the directory closes (at midnight, Tuesday, 29th. January, 2008). That's the midnight between Tuesday and Wednesday.
Please only submit one file containing as many stages of the exercise as you have completed. Do not submit separate files for each stage.
Keywords: q1
Submission reference: IN1287
In regard to exercise 1 final part, modification of print.stream: are you expecting the pause(delay) per line or per number?
Per line. So with a delay of 100000, there should be ten lines per second - no matter how many numbers are tabulated on each line.
Keywords: q1
2006 |
Submission reference: IN987
In the older answers, you mention model answers. Are these still available to look at?
OK - I've put model answers to completing q1.occ,
q2.occ, q3.occ and q4.occ
in the raptor folder:
\courses\co631\answers\
Submission reference: IN747
For the assessment, are you counting 0 as a multiple of 5 seen as 0 x 5 = 0?
Yes, that's correct: 0 is a multiple of 5; also because (0 \ 5) = 0.
Keywords: 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
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
