Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Thomas Sha nks is a fourth-year Electrical Engineering and Computer Science double major. He is just encountering the horridly different yet perhaps beautiful world of Squeak. He likes things that go beep. He lives very near campus and likes interesting conversation and good music.
- He definately knows C Programming, with some Java, etc.
- He is somewhat experienced with VHDL, logic gates, playing with microcontrollers, you know, simple CompE stuff.
- He knows someone that knows the answer to almost any question.
- GUI Implementation
- Email: tREMOVETHISshanks -AT- gatech.edu / tREMOVETHISshanks -AT- cc.gatech.edu / gtg937d -AT- prism.gatech.edu
- Mobile/TXT: tREMOVETHISshanks -AT- tmomail -DOT- net (entire message including headers must not exceed 1000 characters)
- More information on facebook
A really amazing squeak tutorial is here:
I did not create this tutorial.
A WARNING TO FUTURE VICTIMS OF THIS CLASS:
- Write simple, deliberate, clear code.
- COMMENT. EXPLAIN EVERYTHING. Especially overall methods and reasoning.
- USE DESCRIPTIVE METHOD NAMES so others know what to call.
- Use extremely descriptive variable names.
- WRITE UNIT TESTS.
- Update unit tests when you update code.
USE COMMENTS TO EXPLAIN THINGS. YOU ARE NOT THE ONLY PERSON WHO MUST USE YOUR CODE.
USE UNIT TESTS OR YOUR PROJECT WILL FAIL CATASTROPHICALLY FAIL!
WRITE CLEAR CODE AND PROVIDE A CLEAR WAY TO TEST IT! DON'T END UP IN A GROUP WITH PEOPLE WHO WILL NOT!
Don't break your teammate's code that DOES have unit tests, then complain about everything not working!
Never let teammates submit code without unit tests. Because if you do, no one will have any way of telling when they break that code. If the teammates also forgot to include descriptions of how to start and use that code, then the others can't even manually test the code. They, therefore, will have absolutely no way of telling if they broke that code in the process of their work.
Co-Web Assignment 1
Method Finder (on Tools menu)/ Selecter Broswer (window's name):
Finds methods and their classes based on part of their name
Good when you don't know what does something you want to do
Browses by class (and catagory)
Good for understanding classes you don't understand yet by reading the code
Also good for code editing
Shows "Transcript" output of running code
Good for seeing debug outputs
Recent (on Tools menu) / Recent Submissions:
Shows you the code that was most recently modified, by method
Allows you to figure out what your groupmate did while you were eating dinner and he was coding (for example)
or figure out what you coded while you were half-asleep.
The following is a class method of Integer:
"Answer the nth fibonacci sequence number of the receiver."
| prevInSequence currentInSequence |
nth = nth integerPart
ifFalse: [self error: 'Cannot take fibonacci of non-integer.'].
ifTrue: [self error: 'Cannot take fibonacci of negative number.'].
nth <= 1
ifTrue: [^ nth]. "fibonacci 0 is zero. assignment was wrong."
prevInSequence := 1.
currentInSequence := 1.
do: [:b |
| prevPrevInSequence |
prevPrevInSequence := prevInSequence.
prevInSequence := currentInSequence.
currentInSequence := prevPrevInSequence + prevInSequence].
Co-Web Assignment Two
How to Use Monticello
First thing you need is a server to stick the code on that you have write access to. For use normal humans, such a server would be an HTTP or FTP server. Personally, our group used a seperate FTP server hosted at my place. For an FTP server, you want a new directory with a simple name, as you will be typing it each time you begin to code in a new image.
You will also need all your classes stored in their own separate class category. You can make Monticello store youir modifications to existing classes by placing your created and/or modified methods in a catagory that ends with the exact same text as your chosen class category.
Lastly, you will need your author initials properly set in your squeak image, as your teammates will see them on your submissions. Use 'Utilities setAuthorInitials: 'TLA'' to fix this if necessary.
Next, open the World menu by clicking the left mouse button on the desktop. Click "Open..." on the World menu, then click Monticello Browser. A window like that in the screenshot will pop up.
Add your new project (called a 'Package') to Monticello by clicking '+Package'. It will now ask you what to call your package. All of the code that you wish Monticello to save must either be in a class category that begins with your exact package name or in a method category that ends in your exact package name. This is so that Monticello knows what code to save. Fill in your package name and press 'Accept'.
Select your package so that it is highlighed ('painted').
Now you must add your repository to Monticello. Click '+Repository', which will bring up a list of the types of repositories that you can add. Click the type of repository you have, and a dialog like that on the right will pop up.
In the dialog, fill out the provided fields surrounded by single quotes in the text box with the address of your server (without the slashes for FTP, with them for HTTP), the username, the password, and for FTP, the directory name. Click OK when that's all filled out. Monticello will now add your new repository to the repository list.
Highlight your project again. Highlight your new repository and click 'Save' at the top of the Monticello Browser. Monticello will now ask you for a description of what comment to save along with your first submission of your new project, as shown below.
Fill in a proper description and click 'Accept'. Your submission will save, and squeak will provide a confirmation dialogue as shown below.
In order to save future submissions, open the Monticello Browser, select your project, select your repository, and hit 'Save' in this manner. It is not necessary to add your repositiory again unless you are starting from a fresh image.
To load your teammates' submissions of your package, select your project and your repository from the Monticello Browser and click 'Open'. A list of projects available in that repository will be shown.
Highlight your project in the left pane. Each of the submissions sent in by your teammates will be shown in the right pane. Select the most recent submission, or whatever submission you wish to import, and click 'Merge'.
Monticello will now provide a list of differences between the code in your image and the code in the submission. Any changes listed in bold in the top pane are conflicts. You must chose whether to keep the version in the submission or to reject it, thereby retaining your own version. To do this, select each of these conflicting change in the top pane. View the new version of that code in the bottom pane. Then, for each listed conflict, click one of the 'Keep' or 'Reject' buttons in the center of the window depending on whether you want to keep the version in the Monticello revision or reject it. Once you have done this for each of the listed conflicts, the 'Merge' button in the upper left hand corner of the window will become pushable. Press this button, and all of the selected changes will be merged into your version of the project.
Co-Web Assignment Three
History of Object Oriented Programming
Kent Beck created extreme Programming and participated in the creation of CRC cards and in the invention of the ?Unit testing framework paradigm . Extreme programming is a software development methodology which uses pair programming and other software best practices to ensure agile development and the prevention of loss of momentum ("quagmires") in projects. CRC cards are discussed below. Unit testing allows automated regression testing to ensure that elements of object oriented code perform the function they should perform even after recent changes. Regression testing allows caffeinated code monkeys, also known as programmers, to verify that they did not break any code in the process of adding new functionality. In a test-first paradigm, they can also be used to define the functionality of not-yet-written code implicitly.
Ward Cunningham created CRC cards and conceived of the wiki . CRC cards define the responsibilities of a class and what classes it collaborates with in order to accomplish them. CRC cards allow the OO designer to verify that all responsibilities have been assigned to a class such that all use cases can be completed. They also allow the OO designer to verify that these assignments make sense and that there are no god classes. Performing design at this high level allows the designer to see these relationships much more simply and easily. Wikis are collaborative pages that everyone can edit. They allow agile maintinence of information. On a wiki, if someone knows that something needs correcting, they can correct it without having to log in and edit HTML code. Wikis also maintain a history of changes, preventing users from destroying old information.
Garbage collection takes care of freeing up memory used by objects that are no longer needed. It also can compact memory when no contiguous block large enough to hold the desired object is available. Garbage collection frees up the programmer to focus his time on more useful things than explicit memory deallocation. It is also safer, as mistakes (double frees, memory leaks) cannot occur.
Garbage collection takes time, though. It can take several seconds for java to mark-and-sweep the VM memory when running eclipse. Giving the garbage collector the control also takes explicit control away from the programmer. For some applications, the programmer may know better than the garbage collector when would be best to collect specific items. For some mission critical real time applications, garbage collecting at exactly the wrong time could cause disasterous consequences.
With reference counting, each object has a counter associated with it that keeps track of how many times that object is currently referenced in the object memory. Whenever a new reference is created, this counter is incremented. Whenever a refererence is deleted, this counter is decremented. When the counter reaches zero, the object may be garbage collected.
A problem with this setup occurs when two objects reference each other, creating a cycle. Neither of these objects is referenced by any other object outside of the pair in this scenerio. Neither object will have a reference count of zero, but they will be fully disconnected from everything else and will be fully deserving of garbage collection. Cycles are common enough that a reasonable reference counting garbage collection system would need to account for them.
Reference counting garbage collection also slows reference manipulation and derefencing of object pointers. This is due to the need to make all references indirect. Instead of directly pointing to the desired object, references point to a position in a table where the actual location of the target and a reference counter are located.
Example of reference counting:
bob := Object new. "<-- the new object's reference counter incremented to 1"
bob := nil. "<-- the new object's reference counter decremented to zero, object able to be garbage collected"
Mark and sweep works by starting with a single root object and searching for all objects which have references to any other referenced by the root. Each object in a mark-and-sweep system has a flag associated with http://coweb.cc.gatech.edu/cs2340/5178.editit that defines whether it is referenced. As the "sweep" occurs, objects are "marked" as they are found. Any left unmarked are candidates for garbage collection.
The primary problem with mark-and-sweep garbage collection is that it is slow. It can take many seconds to sweep a large VM-memory. Another problem is that all pointers in object memory must be tagged so that the sweeper can tell which words are addresses and which are just integers.
Stop-and-copy deals with problems of memory fragmentation; in other words, no blocks of memory are too small to hold new data, thanks to memory compaction. Stop-and-copy works by dividing memory into several regions and switching between them; all new objects are created in the same regions; when the memory switches to a new region, the old region's data is compacted and collected as needed so that it does not have to return to the old region.
Generational scavenging separates the data into several regions based on the age of its data. Generational scavenging reduces greatly the time consumed by mark-and-sweep garbage collection and tends to keep memory compacted, like stop-and-sweep, with less work, as well. In generational garbage collection, new objects are only placed in the newest ('eden') region. Items are copied into older regions as space for objects is needed in the eden region. Generational scavenging depends on the idea that younger objects are more likely to die than older ones, and so they are more likely to be orphans that may be discarded. Generational scavenging cuts down the time of mark-and-sweep by calling its collecting measures on the younger objects in the eden region first, scanning the other regions only if sufficient space has not already been found.
 Wikipedia contributors (2006). Kent Beck. Wikipedia, The Free Encyclopedia. Retrieved 14:57 UTC, April 28, 2006 from http://en.wikipedia.org/w/index.php?title=Kent_Beck&oldid=45543929.
 Wikipedia contributors (2006). Ward Cunningham. Wikipedia, The Free Encyclopedia. Retrieved 15:56 UTC, April 28, 2006 from http://en.wikipedia.org/w/index.php?title=Ward_Cunningham&oldid=49872215.
Links to this Page