|
CO538 Anonymous Questions and Answers |
This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
When asking questions, please do not simply paste in your code and ask what is wrong with it, as these types of question are hard to answer in a public forum (resulting in either no answer, or an answer which will only be of use to the person asking the question). In many cases, a question about code can be formulated in general terms. For example, if you have an `IF' block that results in an `incorrect indentation' error, you might ask, ``what is the correct syntax for an occam `if' statement ?''. Questions of this form are easier to answer, and are meaningful to all.
Questions that are not suitable for these public pages (i.e. those that contain assignment-specific code), should be mailed to your seminar-leader.
Hi, When I log into the exceed system, is my login and password the same as the the one I use on public PCs or is it one we need to obtain from the computing service reception?
No, it's not the same password. There is a single password for Computer Science, but this is different from your Computing Service password. If you don't yet have a Computer *Science* password, visit service reception to get it sorted.
Keywords: exceed
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
I seem to have some problems when I run q1.occ and q2.occ. They both compile but when i run them I get:
Program deadlock: no process to run.
What am I doing wrong ?
This generally means that your program deadlocked before anything useful happened. A common error is mis-construction of the top-level process, using `SEQ' instead of `PAR'.
If you have access to KRoC on a Linux system, compile the program with the `-d' flag (debugging). When the system deadlocks, it will report the location (in the source file(s)) of deadlocked processes, e.g.:
linux$ kroc -d q1.occ -lcourse
kroc: Selecting post-mortem debugging
Warning-oc-q1.occ(40)- Parameter error is not used
Warning-oc-q1.occ(40)- Parameter keyboard is not used
linux$ ./q1
KRoC: Deadlock:
Instruction "OUTWORD"
in PROC "A"
in file "q1.occ"
near line 29
In this case, the system deadlocked with the `A' PROC trying to perform an output (line 29 in this particular q1.occ). Note that this will not work with the version of KRoC on raptor. It will, however, work on gonzo.
In question 2 we display the numbers on the screen. Trouble is that the numbers go too fast and end up giving a fatal error. Is their a way, or a command, to show a window's worth and than wait for you to push a button. Also, what output should we be getting from numbers anyway.
You can pipe the output through "more", e.g.
./q2 | more
Hitting the space bar will give you another screenful of output. Pressing `control-c' will interrupt it, but that leaves the terminal in a funny state, with echoing turned off. Type (blind)
stty sane
to restore sanity.
The fatal error that occurs is usually integer overflow. Don't worry too much about this yet, but in general, it is an important consideration for software systems. Integer overflow in question 2 ought not to happen until a significant number of values have been input. If it overflows early, there's probably a problem with your code/network.
The `numbers' process generates the sequence `0, 1, 2, 3, 4, ...', forever. After being sent through `integrate' and your `differentiate', you should get the same sequence (0, 1, 2, 3, ...).
There are executable answers in `/usr/local/courses/co516/answers' on raptor, for all 7 questions.
Keywords: fast-output , q2
Referrers: Question 6 (2003)
How do we submit the occam coursework due in next week ?
You should print out your code and submit it with a cover-sheet to CAS reception. Remember also to include a network diagram of your `differentiate' process. You can do the diagram in ASCII-art, print it separately, or hand-draw it (neatly, please!).
Keywords: q2 , submission
Is it possible to work on occam programs from off campus ? I am using putty to access raptor, but when I type `gvim', an error message is produced:
(E233: cannot open display)
Are there instructions anywhere to show us how to edit and execute occam programs off campus ?
Yes, it is possible. There are three sensible ways, more or less:
A more basic editor is `pico', and is also installed on raptor.
Running X apps off raptor at home is possible, but slightly tricky to set-up and often hopelessly slow. ADSL copes reasonably well with gvim, but a dialup won't.
To use X: you need to start exceed first and then ssh to raptor with putty. In putty itself you must switch "X tunneling" on.
Once you've got an edited source file, compile it in the following way:
raptor$ kroc q2.occ
As before, ignore the warnings about un-used top-level PROC parameters -- don't remove them!
Once successfully compiled, run it with:
raptor$ ./q2
Refer to Question 4 (2003) for how to control the output.
Keywords: off-campus , putty
In the method `tabulate.int' from q2.occ, how does the sequence:
SEQ
in ? n
out.int (n, 15, out)
out.string ("*c*n", 0, out)
work ?
I'm curious because I'd like to make a:
PROC testing (CHAN OF BYTE in, CHAN OF INT out)
procedure/method for testing purposes. In other words, how does the conversion work and is it basically the same to convert the other way around?
The conversion from an `INT' value to the sequence of decimal digits that represents it is performed inside `out.int'. Essentially it involves a sequence of `modulo 10' then `divide-by 10', until the value is zero. It's mildly more complicated since the digits are generated in the reverse order.
The code for `out.int' can be found on raptor in:
/usr/local/courses/co516/libsrc/utils.occ
Converting the other way is, as you suspect, largely the reverse. However, it's already been programmed for you (also in `utils.occ'):
PROC ask.int (VAL []BYTE prompt, INT n, VAL INT max, CHAN OF BYTE in, out)
As an example, your `testing' PROC can be implemented with:
PROC testing (CHAN OF BYTE in, out, CHAN OF INT vals.out)
WHILE TRUE
INT n:
SEQ
ask.int ("Enter a number: ", n, 11, in, out)
vals.out ! n
:
The `in' and `out' channels should be wired to the keyboard and screen respectively. The screen channel is needed so that characters can be echo'd as typed, in addition to displaying the prompt. `ask.int' handles all the unpleasantness of keyboard input, such as rejecting invalid characters and handling backspace properly.
The `max' parameter specifies the maximum number of digits that may be entered, inclusive of any leading `+' or `-'.
Keywords: q2 , output , conversion
Are we required to prepare anything particular for the seminars, or will we be discussing what was previously covered during lectures ? Is there a schedule of seminar topics or will the topics be announced before each session?
The seminars cover a variety of things, including material from the lectures, extra topics, help with assessments, feedback from assessments, and looking at old exam questions. There is no predefined schedule. You should generally come prepared with your lecture notes and current coursework.
Keywords: seminars
In `demo.occ', why does the Fibonacci list produce negatives ? Is it to do with the maximum size a number can be ?
The numbers in the Fibonacci sequence increase very rapidly, and soon exceed the capacity of a 32-bit INT, so integer overflow occurs. The results are then effectively meaningless, and are as likely to be negative as positive.
Unlike programming languages such as Java, occam normally checks for such errors - prefering to crash rather than give wrong answers. However, the component processes in demo.occ use explicitly unchecked arithmetic operators (PLUS, MINUS, TIMES), and not the usual checked ones (+, -, *). If they did not, the run of demo would be rather short!
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
I was wondering if it is possible to create a global boolean value that can be changed. I know that you can write:
VAL BOOL name IS TRUE:
and this can be used by any method, but you can't change this. So is there another version of writing this which will allow me to change it?
No; the compiler will not allow you to declare variables at the outermost level.
If you REALLY want to do this, you could re-structure your program so that everything is inside the main PROC; for example:
PROC main (CHAN OF BYTE in, out, error)
BOOL b: -- local to main, but
-- global to set & clear
PROC clear () -- nested PROCs
b := FALSE
:
PROC set ()
b := TRUE
:
SEQ -- body of main
clear ()
set ()
:
But this sort of global variable is a very Bad Thing!
Any attempt to use such a variable in parallel (that is not CREW) will result in the usual compiler errors.
Keywords: global-variables
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
For Q4 what is the command to make the terminal bleep when any other character is entered apart from those specified?
Output an ASCII "bell" 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)
I've just followed the instructions for setting up Vim (v6.2) at home. As far as I know, I have done everything properly yet when I try compiling an occam file I get this error message:
'kroc' is not recognized as an internal or external command, operable program or batch file
Do you know what the problem could be??
Thanks
(ps... I'm using MS Windoze XP if that helps)
The KRoC occam system isn't available for windows. The kroc command (which you're seeing an error about), is the bit that compiles and links occam programs. We've tried a couple of times to make a version of KRoC for win32 (cygwin in particular), but there are still some outstanding problems. Added to which, UNIX is a much more suitable environment for programming.
You'll either have to use the KRoC installed on raptor, or find a Linux machine at home and install KRoC/Linux. To compile occam programs from a command-line on raptor, simply type:
kroc file.occ
(replacing `file.occ' with the occam source file you want to compile). On KRoC/Linux, you need to explicitly add ``-lcourse'' if your occam program `#USE's' course.lib.:
kroc file.occ -lcourse
It should even be possible (in theory) to create a setup where vim uploads the file to raptor, compiles it, then sends back the results. This would probably be tricky, however -- you'd need to get friendly with vim scripting and ssh/scp.
Keywords: vim , compiling , windows
Are you going to release the answers for question 3 before the homework deadline? It's not an assignment so there shouldn't be any reason why its not up already.
This is now available (as of Saturday 15th). The file can be found on raptor in:
/usr/local/courses/co516/answers/a3.occ
With an executable version `a3' in that directory also. If you're browsing from windows, replace the leading `/usr/local/' with `\\raptor\files\' (and turn all the slashes into back-slashes).
Keywords: q3
[code snipped]
This is what I have for step 2 or the assignment. When I compile I get an indentation error on the ':' marked ***. I cannot see any reason why this is so or is there something wrong with the rest of my code?
Also, could you tell me if I'm heading along the right track here please (not being able to compile and check it means I'm unsure of it being correct)
In answer to your first point, you have something of the form:
PROC something (CHAN INT in?)
PRI ALT
in ? x
... local processing
TRUE & SKIP
: -- ***
The error you are seeing is in fact right. The structure of an occam ALT is:
ALT -- or PRI ALT
guard
process
guard
process
...
...
I.e., the second (`TRUE & SKIP') guard has no process. The compiler expects the indentation after the guard to be more than the guard, but in your code, it finds the PROC-finishing `:' at less indentation than the guard above it, hence the incorrect-indentation error. A more useful error would be `Missing process'. As an additional point, think hard about your `TRUE & SKIP' guard. Do you really need polling ? -- we think not..
In general though, please do not post code to this question page and simply ask what is wrong with it. Such questions cannot be answered in this public forum. If you are still lost, you could try mailing your seminar leader for some clues ...
Keywords: incorrect-indentation
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
[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
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
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
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
