|
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 diagrams
2012 |
Submission reference: IN2315
How much commenting should we put in our code for Life on Mars?
See Question 30 (2001) for the kinds of comment that should not be made!
Otherwise, you should summarise the purpose of each program entity (e.g. PROC or PROTOCOL) in comments just above its header. Ideally, this should conform to the syntax for occamDoc documentation used in, for example, your q4.occ and q7.occ starter codes and PROC draw.hit.line in the mars-sim.occ file. However, free-format comments will be fine.
In the body of a PROC, 'clever' code must be explained – anything whose purpose would not be obvious to a reader familiar, in this context, with occam-pi. For example, if there is special code to eliminate a danger of deadlock but not otherwise contributing to the purpose documented above the header, you must explain why it's there and how it does its job. It's essential to make your code understandable to readers. A base reason would be that they might be marking it! But one of those readers might be you in a few weeks time and, just because you understood it once, this does not mean you will understand it in the future. Obscure code is, in practice, worthless ... regardless of whether it works or is efficient. Obscure code cannot be maintained. Code that cannot be maintained will be thrown away.
Diagrams are an important part of the documentation of occam-pi systems. Remember to submit a process network diagram (or diagrams) if you have used concurrency in your robot.control logic. This is needed even for networks that are temporary (e.g. for the duration of a turn, move, find or deploy), but not if the concurrency is very short-lived (e.g. a parallel input/output). Diagrams for temporary networks should be enclosed in a box labelled by the PROC that sets it up (with all its external channels) and some text (or number scheme) that indicates when it is set up and for how long it lasts.
Keywords: mars , comments , diagrams
Submission reference: IN2178
Hello there,
For Q4 all seems well in Gaul, however there is just one issue. Originally, when the BELL character is output (BELL flashes my output window), the ability to change speed stops, all output stops as well. Is this the desired beaviour or should it be that output continues? I have it so that output will continue such that when the limit is reached the value fed into pause is halved if at 256 lines per second (or doubled if at 1 lines per second) before the bell is output. That way the the limit is reached and imediately reset to the previous speed and the error is shown. Which way is better or desired?
Also is the diagram compulsory? My ASCII art isn't exactly da Vinci standard.
Thank you for your help.
It is not desired behaviour that the system stops working when a command to change speed would push that speed outside its defined limits. As the question says:
"... the attempt should be ignored and an error message generated. To keep things simple and not interfere with the columns of numbers being output, this error message should be a single BELL character ... sent to the error! channel."
You said: "when the limit is reached the value fed into pause is halved if at 256 lines per second (or doubled if at 1 lines per second) before the bell is output." That implies you do not allow your system to reach either of the defined limiting speeds? If so, that is wrong. What should happen is that if the command would push the speed above 256 lines/second (respectively below 1 line/second), the speed should be changed to 256 lines/second (respectively 1 line/second).
The two diagrams (for pairs2 and q4) are compulsory. You do not have to do ASCII art! There are four options:
2011 |
Submission reference: IN2055
Were the ASCII network diagrams provided in each source file generated by a tool? Perhaps `graphvis`? If they were done by hand, that is a truly valiant effort :).
They were done by hand ;-). We're quite adept at churning these out so it doesn't take too much time!
Keywords: diagrams
2004 |
Can we draw out diagrams for Q4 by hand on paper next to our code, or do we have to do them neatly in the documentation for the coding like you have done?
As you say, submissions for your second assessment exercise (Q4) must include process network diagrams for your modifications. Only the diagrams supporting your submission need be submitted (i.e. only those for your final system -- not all the intermediate stages).
Your submission must be on paper (with cover sheet to CAS by 4pm next Monday). Your code will be a listing of your q4.occ file. Neat hand drawn diagrams on this listing are perfectly fine. ASCII art (as in the starter file) are acceptable, as are diagrams produced by any drawing package, but there are no extra marks for this.
The diagrams need are those for the overall system, plus separate diagrams for each modified process that has a sub-network -- in this case, the resettable versions of your numbers generator, integrator and pairs processes.
Keywords: diagrams
2003 |
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.
2001 |
When is our first assignment (q2.occ) due?
A hard-copy listing of your source code should be handed in to the CAS office by close of service (around 4pm) on Thursday, 8th. November, 2001. Cover sheets will be made available next week.
Note: remember that your differentiate process should be implemented in the same style as the implementation of integrate -- i.e. as a network of simple components of the level of those in the demo_cycles.occ library (see slides 5-3 and 5-8). This requirement is made in the comments in your q2.occ starter file. A solution for differentiate in the form of a single serial process will get a maximum of 6 out of 10. [See also the Hint: given in those comments.]
Note: you must include network diagrams of your differentiate and q2 processes (the latter contains your test rig). These can be hand-drawn neatly on your hard-copy listing or machine-drawn on other paper and stapled to your listing. The diagrams should be annotated with process/channel names that correspond to those used in your code. Channels should be arrowed to show the direction of data-flow. Also, think carefully about the icon you choose to represent the minus component. Unlike plus, minus is not symmetric over its input channels and your icon must reflect this. When looking at its use in a network diagram, we must be able to tell which channel numbers are being subtracted from which.
Note: your source code must be adequately (but not over-) commented, should use meaningful variable names and be well laid out. Of course, you have no choice in indentation layout (;-), but spacing within lines and between them (e.g. between PROC declarations) helps readability (and marking!).
Note: comments in occam source code are introduced by two dashes, --, and include everything following this symbol to the end of the line. [This works like // in Java.]
Keywords: q2 , diagrams , comments
Referrers: Question 6 (2001) , Question 6 (2001) , Question 12 (2001)
2000 |
When drawing the network diagram, do we have to show it as all the philosophers sitting round the table, with the all forks and all the channels - i.e. from the college perspective? Or do we have to draw it as the code we have written - i.e. 1 philosopher, 1 fork, security guard and display taking in channels from those 3 objects?
For each process implemented as a network of processes, you must draw that network showing all connections - i.e. all internal processes, how they are wired together and/or wired to the outside world. If your network topology for the college reflects the college geopgraphy (e.g. philosophers and forks arranged round a table), that's a nice bonus but not essential.
There will be at least two layers of network to draw - the (secure) college network and the q7 network, consisting of the college and display processes. Each network should be drawn separately - do not try to combine two layers of network on one diagram. Ideally, you should also draw individual process icons for each process (e.g. philosopher, fork, security guard, secure college and display) that shows the shape you are using for that process and its external wires (labelled with the relevant formal parameter names used in your code). All wires should be arrowed to show the direction of data flow and labelled with the channel names used in your program. All processes should be labelled with the process names used in your program (plus any non-channel formal parameters).
A note on the diagrams needed in our submission for question 6. The diagram for q6.occ is already in the file - so obviously we don't have to reproduce that. And the diagram for cells is so small and just shows the obvious. Do we definitely have to include a diagram?
No - for the reasons you state and for this submission only, you do not have to include a data-flow diagram.
Further, to save paper, you may delete the documentation I supplied from the program listing you print out. Make sure you still print a complete program and include your own documentation for the modifications you have made.
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.
I have completed q2.occ and as far as I can make out, it works!!!
My class supervisor said we had to produce 2 chip diagrams to hand in as part of our assignment. Am I right in thinking they are:
Is there any particular program I should use to create the diagrams? I done them in Word, using the flowchart symbols, but it don't look that great.
Also, how do I print my source code from Origami on a public PC????
Yes to your first question - you do have to submit these two diagrams as well as your code listing.
No to your second question - the quickest thing is simply to draw them neatly by hand on your listing (next to the occam code that implements each diagram).
Origami doesn't have a print command. The files it produces are, of course, plain text. So you could pick up q2.occ (say) in a Windows editor (e.g. PFE) and print from there. Or you can print the file directly from Unix.
To help with the latter, there are two commands (pt and pq) in the etc directory in the course area:
/usr/local/work/co516/etc/pt /usr/local/work/co516/etc/pq
If you haven't already done so, make a bin directory in your home directory and copy the above files over to it:
mkdir ~/bin cp /usr/local/work/co516/etc/p* ~/bin
Then, set this ~/bin directory to be the first item in your path environment variable. This can be done by editing the definition of that variable in the .cshrc file in your home directory (if you are using the C-shell) or the .bash_profile file in your home directory (if you are using bash). If your unix command prompt ends with %, then you are using C-shell - if it ends in $, you are using bash. The syntax of how to set these environment variables is different for the different shells - but you can work it out from how they are already defined.
Once the above has been done, to print a file (say q2.occ) to a printer (say myprinter), the command is:
pt q2.occ myprinter
To inspect the print-queue on a printer (say myprinter), the command is:
pq myprinter
Keywords: diagrams , q2 , printing
Referrers: Question 15 (2000)
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
