CSC323 2010S, Class 18: Project Status Day Overview: * Exercise: Comparing Status. * Full Group: What We've Learned. * Detour: More Networking Basics. * Detour: Sockets. * Exercise: Combining Projects. Admin: * Reading for Tuesday: Chapters 6 and 7 of Head First OO&D. * Don't forget the talks today and tomorrow. * Additional goal for next Thursday: An additional six hours of work per person (log your hours and tasks). * Please don't forget those reading responses. EXERCISE * Get copies of each of the groups' codebases * Compare what's been accomplished * Compare particulars of code * What is similar? * What is different? * Which code is the best for each category? * What will you have when you combine the important parts? UGLY CODE / CRITIQUES / ETC. * Bad documentation def setSpecies(self, name): """A method to set the Creature's species to a give type.""" self.species = name vs. """Set this creature's species to name.""" * What's the appropriate indent? (see group1 code for Sam's concern) * Two spaces * Four spaces * More "bookish" * Guido recommends * Tab * Easy * Usually * Can lie to ourselves that tabs are four spaces * Easier to back up * Decision? * Four spaces * And learn how to use your editor so that it inserts four spaces when you hit tab. * Where's the testing? * Needs to be there * Violating the UML diagram * What's in a state? * Added priorities Detour: Thinking about neighbors class Neighbors(): def get(direction): """Gets the state of the neighbor in a particular direction.""" implementation one: Use dictionary def __init__(self, dict): self.dict = dict def get(self, direction): if (self.dict.contains(direction)) return self.dict[direction] else return State.EMPTY implementation oneb: Use dictionary def get(self, direction): try: return self.dict[direction] except Exception: return State.EMPTY implementation two: Allow yourself to keep track of the world def __init(self, x, y, world): self.x = x self.y = y self.world = world def get(self, direction) if (direction == Direction.LEFT) return self.world.getCreature(self.x - 1, self.y).state ... implementation twob: Do this a bit more cleverly hoffset = [] hoffset[Direction.LEFT] = -1 hoffset[Direction.RIGHT] = 1 hoffset[Direction.UP] = 0 def __init(self, x, y, world): ... ... Didn't Ravi and Aaron suggest this to begin with? * We've abstracted a bit so that we can choose different designs * How are we going to represent the predicate tree? (toString/fromString) * S-expressions (or XML) * Representation of tree data ( children ) or LEAF WHAT WE'VE DONE/LEARNED SO FAR * We don't know enough Python * What process did you use for building what you have? * Some group: * Looked at UML diagram * Picked a starting point - LocalWorld and Creature * Seemed to be the basic foundations * Understandable * Allowed us to skip the stuff that sam made confusing in the diagram * Sketched the class * Tried to implement the function * Some other group: * Started with predicates, since they're a leaf in the diagram * Talked a bit about design. * Divided work - A&B coded Predicates, C&D looked at design for Rules * Tweaked code, and continued to move up the tree * A non-functional group * Decided to split the work by each doing everything him or herself * Looked at UML diagram * Picked something that might be useful to colleagues and that seemed doable (LocalWorld) * Worked on it * Another member of the non-functional group * Looked at UML diagram * Queried project leader about confusing parts of the diagram * Misunderstood unclear instructions * Implemented predicates * Wrote rule sets for hypothetical species * Made states * What observations did you have? * It takes awhile to figure out how to translate what you want to do into Python * Hopefully, the overhead of Python will soon decrease * What could have gone better? What will you do differently next time? * Need more concrete ideas of what we're doing. * Need to spend more time making sure that we understand the parts and their purpose. There's clearly a lot implicit, even in an amazingly well done UML diagram. (There's even more implicit in Sam's UML diagrams.) * Schedule multiple meetings. * Don't have tornado-like hailstorms * Stick with the basics of the design DETOUR: SOME OTHER NETWORKING BASICS DETOUR: SOCKETS Basic questions * What is the author's ? * There are multiple ways to implement networks * [Can you have a thesis in a paper that's more descriptive than argumentative.] * Sockets and the related technologies are a good way to do networking. * What code is clear, elegant, understandable? What code matches the normal rhetorical structure of the language it is used with? * What code is otherwise? A variety of questions * This article seems to indicate that there is a significant amount of similarity between UNIX interprocess communication and internet intermachine communication. Am I right about this or am I just reading this completely wrong? * They are very similar * And that's great, because you don't have to change a program much to make it work on the Internet. * And that also means that it's part of your normal toolset. * Why would two way communication through a single pipe be complicated if both parent and child have the address of the receiving and sending end? * Might be complicated * What happens with simultaneous writes or reads? * Why doesn't the UNIX domain allow for communication between different machines? * It's not intended for that purpose. * I'm having difficulty analyzing the process diagrams (the ones with the circles with lines going down to list-boxes), mainly with their interactions with the list-boxes. * I don't really understand the significance of the UNIX 4.2BSD release's ability to communicate within a single machine via pipes. A basic function of computers has always been to communicate throughout a single machine. What made this development so important, aside from its eventual contribution to communication between multiple machines? * Both in lecture and in the reading the datagram type of communication has been described as "unreliable". What is it about datagrams that causes this? I do not see why the data would "disappear" when sent. Even if it were to disappear, why would streams not suffer the same problems? * How often are each of these methods used? My current understanding of networking is that the lowest level of data sent are packets. Are these packets equivalent to datagrams? Our ability to use streams implies that they are not. Is the data transmitted through the stream packed into packets in the same way datagrams are? * On page 20-2, the authors discuss descriptor table indicies as storage for input/output destinations. How are these tables created, accessed, and modified in memory to specify I/O? * In modern networking, are streams and datagrams still the primary tools? If not, what has replaced them? Protocl-Oriented Questions * On page 20-7, the authors define a protocol as a "a set of rules, data formats and conventions that regulate the transfer of data between participants in the communication." Would these be protocols such as IP and TCP (the Internet Protocol Suite)? What exactly comprises a protocol? What are some other protocols used in modern communication? * You've suggested that a server or client might append characters to the end of a message to ensure that the recipient realizes the end of the message. Would you be able to use the same character for number data, string data, and character/byte data? I realize it's all converted when it's being sent, but is there any kind of checking done to ensure that the content of a message is all of the same format? Would this checking object to a universal end-of-message code in some cases? I suppose that means we should choose our end-of-message symbols carefully. * The paper points out that send() and recv() support "peeking" to see how large the next message is. Is this the usual solution to receiving messages of arbitrary length - peek to see the size of the message, and then receive it? If so, is it still necessary to include end-of-message codes? If a server or client didn't know whether its intended recipient used peeking or simply received until an end-of-message code, wouldn't that result in junk being sent sometimes? Operating Systems Issues * The paper makes signals from the operating system sound important enough that programmers need not explicitly listen for them. By what means are they transmitted from the operating system to the program? What can the OS do to programs that ignore signals, if that is possible? * What is an inode? Is it physically written to disk or is it maintained in memory as a reference to something that could be a file? * In my limited experience with network programming in C, the use of forks presented serious risks. Have modern languages implemented them in a less hazardous way? What are/would be any negative consequences of doing so? PROJECT WORK TIME * No New groups! * Merge code! Fun fun fun.