Things you should do before too much time passes:

• If I had a dime for everytime someone said they could use a refresher in basic programming / problem solving / computer science concepts… and then this bumps into me: UNSW Computing 1 - The Art of Programming 12 week free course starts December 3rd.

• Pop Data Structures Knowledge Assessment at the start of class.

• OPUS Part 3 Keyword is due before it is no longer November 16th.
• Stack Class Reference code is nearing completion. Should have something to poke at in class today. Certainly enough to explore creating and using libraries.
• Might have some sort of timed knowledge assessment on Friday.

• Talked about Makefiles, C standards, C extensions, and other fascinating tidbits related to some of the programming tools we regularly make use of.

• OPUS Part 3 Keyword Selection select a keyword and get started.
• Stack Program due at the start of class. I'll be sitting down and having you run through it.
• Binary Tree Project! Due December 5th, 2012. Get started early, it isn't hard, but it is rather comprehensive.

• Work on stuff day. I am seeing increasing functionality in stack programs. Keep up the good work.

• Due to the uncertainty surrounding classes, power, and general resource availability regarding Hurricane Sandy, I'm pushing the due date for the stacks program back a week, to November 7th.
• Binary trees were the talk of the day, as well as highlighting the approaches to implementation that could be taken-
  • iteratively (in a unidirectional and bidirectional fashion)
  • recursively
  • via stacks
• Some neat things about building and traversing binary trees is how they can naturally sort

• We covered recursion, and stressed its importance as a problem solving methodology.
• We also used the opportunity to introduce and explore function pointers, another powerful concepts.

• Do not be surprised to encounter an ungraded, timed, condition controlled knowledge assessment at the start of class.
• Do not be surprised to then encounter a similar, but graded, experience, at the start of class on Friday.

• Work day.
• Too many people did not have Project #3 ready, so I moved its due date to the 24th (do not expect this to be the norm).
• Speaking of which: Project #3- Douby Linked List Menu-based program due by the start of class October 24th. No exceptions.

• Knowledge check- please complete this Data Structures Knowledge Assessment by Friday, October 19th, 2012. Please work this through on your own- no external help!
• Project #4: Linked List-Based Stack Program by November 7th, start of class.
  • Note that while Project #4 is due at the end of the month, this is in anticipation of code cleaning and reorganization efforts.
  • There may be an additional project making use of queues due around the same time.

• Work on stuff day.

• Project #3 was originally due by October 19th, start of class.
  • Same deal as singly version, only incorporating “prev” into all your logic.
• Starting stacks today
  • A stack is typically an existing container (like an array or linked list) with restrictions placed on its access/manipulation.

• Pre-break “work on stuff” day.
• The menu-based singly linked list program was due today at the start of class.
  • Common problems were experienced with inserting either before node 0 or 1, and removing the last node of a list.

• OPUS Part 2 Keyword is due October 16th.
• Starting this month, I will cease accepting assignments submitted past their due date (unless there are extenuating circumstances). Many people have been getting assignments done on time, others are procrastinating until the last day, and have trouble as they are rushing and don't have much time left. Please don't wait until the last minute, procrastination isn't the way.
• Knowledge check- please complete this Data Structures Knowledge Assessment by Friday, October 5th, 2012. Please work this through on your own- no external help!
• Project #2: (Singly) Linked List Modular Menu-Driven Implementation by October 5th, start of class.

• We spent the class learning about and walking through the usage of a powerful programming aid- the GNU debugger.
  • Sample code which contains logic leading to a segfault was used (based on the modular singly linked list implementation I released a couple weeks ago).
    • The code is located in /var/public/data/fall2012/linkedlist1-debug/
    • Running make copy from within that directory will copy all the code under your ~/src/ directory.
    • Compile it with make debug to get debugging support.
    • In general, the addition of -g to the compiler command-line will enable debugging support.
• We also talked a bit about hex editors, and how many people have done some “debugging” without knowing it– through the use of video game modifying peripherals like the game genie, which let you specify an address, and change the contents of data located at that address (to modify various attributes or properties within the game).
• Clearly many people wanted to do that, but it cannot be stressed enough that such endeavors are the result of being VERY familiar with your particular object you are modifying. It isn't something you can just “pick up” and master in a few minutes… you need to have an understanding of related hardware, the native assembly language/hex opcodes, and spend some time analyzing the machine code to gain an appreciation for what is going on.
  • An example I suggested was looking up studies of the original NES Super Mario Bros. game– it has received a considerable amount of coverage in this regard (especially related to things like the “negative worlds”).
  • Again, you need to walk before you can run. There's a ton to understand before you can really do more than simple tweaks, and you almost have to learn everything over again when you change a variable like the targeted game/application, CPU, and related hardware.
  • Off-topic for the class in general, but I wanted to show where exceptional knowledge of the debugger could lead (it isn't just some tool to help you debug the programs you write). Maybe it will inspire a few to learn the debugger better- and as a result you'll gain invaluable development experience.
• I have been getting some excellent questions, and I think by and large the work-on-stuff days have been doing us a wealth of good.
  • Make sure you have a handle on singly and doubly linked lists- everything else in the course will be based on them in some form.
  • The more you can recognize fundamental linked list operations, the quicker and easier a time you'll have understanding the data structures build atop these.
• Remember, OPUS Part 1 (in its entirety), is due once it becomes October 1st.
• I think an increasing number of people are seeing that procrastination doesn't pay. Don't wait until the last minute to start- you'll not only get frustrated, but you'll also likely not learn as much. Get in the habit of starting early. Please.
• The abstract nature of this class also requires a clear mind- if you find yourself under the weather or lacking sleep, I'd MUCH PREFER you put off trying to do work and get better/get rested; you'll find catching up to be far easier. This isn't an excuse not to do any work.
• Again, there IS a tutor for Computer Science classes.

• OPUS Part 1 to be completed by October 1st.
• OPUS Part 2 Keyword Selection by October 1st.
• Some observations from the past couple of days:
  • Drawing pictures and stepping through the logic remains the best way to work through code problems with linked lists.
  • Make sure you understand the code you are working with- a few people have been asking me some GREAT questions. Please keep doing so.
  • If drawing pictures is difficult, the sooner you start, the sooner it will become less difficult. Don't not do it just because you think you can't- this is really THE big clincher for helping you to understand.
  • Don't get hung up on what you THINK should be happening- the computer will only do what you tell it to do, whether or not you think you've told it the correct thing. Debug and step through your code!
  • Work on noticing when you are trapped in your code- trying to fix errors by staring intently at one section of code and slowly losing awareness of the bigger picture. Step back and take a fresh look.
  • Use strategically-placed output statements throughout your code (printing key variables if need be) to verify things are as they should be, and progressing as they should be. THINK that loop is iterating correctly? VERIFY it. When there are problems, anything could be the culprit- including that variable that you incorrectly (or neglected to) adjusted three sections back.
  • After you have narrowed things down with helpful output statements, and problems still persist, we can deploy the BIG GUNS- using a debugger.
• For those that enabled workdue notifications in gimmeh, you may have started receiving daily e-mails (depending on your settings). Remember, it is a double opt-in system- you have to enable workdue-status, AND email-workdue, otherwise it'll skip you by.

• I intentionally did not wander around to check up on everyone on Wednesday (until the very end). For most of class I waited until I was called upon or “flailed down”. This was also a test to see if you would ask questions. Many people did. Some who did not need to continued on with their thing. But if you had a question and did not ask it- that is a problem.
  • I want you to become comfortable with asking questions. Especially if you choose to sit on the outer edges of the room. I will happily make the assumption you know what is going on. It is your responsibility to take command of your learning, and asking questions is one of the best ways to do so. Magical things start to happen when you start asking questions, and I want everyone to experience the magic of learning.
• Project #0: (Singly) Linked List Node Removal/Deletion by September 26th.
• Project #1: (Singly) Linked List Node Insertion by September 28th.

• Be sure to evaluate your received OPUS Part 1 Keyword by September 24th. Then get started on the demonstration before the month is up.
• With no questions, we launched into doubly linked lists, challenging the class to come up with an equivalent program as what we came up with for singly linked lists; namely, the following:
• nodes now have a prev pointer in addition to a next pointer
• you can now have an end node pointer in addition to a start node pointer
• prompt the user for input (-1 to stop)
• build a list with those user-input values (essentially appending)
• display the list (forward)
• display the list (backward)
• prompt for node to insert after
• prompt for value of new node
• insert newly valued node after indicated node
• display the list (forward)
• display the list (backward)
• As we finish up the singly linked list operations for insert and remove, don't be surprised to see similar projects for the doubly linked list.
• Most importantly- make sure you do both. Just doing the doubly linked list operations is only half the story. I will want to see completed projects employing logic for singly as well as doubly linked lists.
• I saw increasing instances where drawing pictures would have saved confusion. I am not going to bail you out in such situations. I will help, sure. But when I see a case where I thing your problem can be worked out by drawing a picture and working yourself through the logic, I will tell you.
• It isn't helpful to help someone extensively through this process- we're learning an algorithm as much as a concept. If you can't become comfortable with drawing pictures and working through (and recognizing) the necessary steps of the operation, you'll quickly find yourself limited, or needing constant help.
• Please aim to do the insert and remove operations on your own.

• I had some questions on the binary/decimal/hex stuff that has come up in many of our class discussions. I eventually suggested that a good starting point is to understand and be able to produce this table from memory. Look at it, produce it by hand. Do the same tomorrow. And the next day, and the next. Keep doing it until it is second nature. Then many things will be easier.
• I also adapted the above mentioned table to incorporate signed values. If you're not comfortable with two's complement, you may want to ponder that table for a bit.
• Until we get to implementing more of the basic bignum functionality, it would be best to avoid running “make clean”… as that will remove object files which you can't just recompile.
• Please be looking through the bignum repository code and example programs.
• We started covering (singly) linked lists. Please look over the sample code.
• I asked everyone to try their hand at implementing deletion (removing a specified node from the list) for next week.
• Also try your hand at insertion (insert before specified node. How is it similar to append? How is it different?

• Try your hand at taking your multi-datatype-of-the-same-type-to-store-larger-numbers-in-hex program, and add in any appropriate logic to get it to display correct decimal (base 10) values.
  • You will very likely want to work out a few examples on paper first before attempting to code this.
  • The intended approach is to use data types no larger than what you use to store individual portions of the number.
  • Hint: Math and logic operations are key to this implementation.
• After this, we'll be looking more at the array-based store-a-single-digit-in-each-array-element bignum approach, using the bignum repository you cloned from last week's instructions as a reference framework.
• We will also be moving into the heart of Data Structures, looking to start covering (Singly) Linked Lists.

• Implement that multi-datatype-of-the-same-type-to-store-larger-numbers-in-hex program.
• Think about implementing the same thing but using an array, where each array element contains/manages JUST a single digit/bit/octet/etc.
• We'll be doing some work on a bignum implementation.
  • If you haven't yet, clone the bignum repository: hg clone http://www/hg/project/bignum-fall2012 ~/src/bignum
  • Go there: cd ~/src/bignum
  • Poke around, look at the source and other non-object files. Ask questions about it. Figure out how it works.
  • Build the library and support files: cd ~/src/bignum; make
  • Look at and play with the examples in cd ~/src/bignum/testing; ls

• I had a request for documentation on setting up the screen/irssi session for class chat. Here it is.
• Remember that, with respect to the size/range program, you probably don't want to use “%d” for EVERYTHING.
• If you enjoy contemplating incomprehensible objects and seeing their adoption into culture, check out the blivet.
• Please Subscribe to the class mailing list
• and: Select your Part 1 Opus keyword BEFORE September 7th. I will be counting both of these as projects.

• Clone and start using your personal Lab46 Mercurial Repository
• Choose a keyword to work on for Part 1 of the Opus
• Start working on said keyword, for you need to have the definition part done by mid-September.
• Before leaving, detach from any screen sessions (CTRL-a d), log out of any terminals (exit command), close any web browsers or other open applications on your desktop, and right click → exit to log off. You do NOT want to leave while still being logged in!
• Expand the data type size example to all common data types (char, int variants, float/double) and determine the upper and lower bounds, plus the total quantities for all the non-floating point types (both signed and unsigned). What limitations do you run into?
• Expand/play with the pointer code we started, making sure you understand what is happening.
• Review pointers (address of, dereferencing, declaration, allocation)

• Edit/customize the Title and Introduction sections of your Opus by Thursday, September 6th (have it done by 11:59:59pm Wednesday, September 5th)
• Subscribe a frequently checked (or pushed) e-mail address to the class mailing list
• When you come to class, remember to open a Lab46 terminal, which will be used for attendance/participation purposes.
• Make sure you can access the DATA course homepage from home (you may want to bookmark it).
• Make sure you can log into Lab46 from home with your username/password (using PuTTY if on Windows, or some other SSH client).
• Get on the class chat, and familiarize yourself with basic screen usage (attaching/detaching).
• Finish data type size example for all int variations.
• Play with data type size example, experiment with it a little.