CSC323 2010S, Class 13: Concepts: Dynamic Code

Overview:
* Quick project discussion.
* Dynamically loading modules in Python.
* Dynamically loading modules in Java.
* Fun with Make.
* Beautiful Code: Code in motion.

Admin:
* I've made a few updates to the schedule.  I'm also making some updates to the grading policies, since the course has taken a bit of a different tack than I had planned.
* Reading for Thursday: Thinking in Tkinter.  Send questions.
* No BC reading for Thursday.
* Thursday will be a "headless lab".  I'd recommend that you all do it during class time, but you may find it useful to do it at other times.
* Assignment for next Tuesday: A preliminary UML architecture for the project.
  * Client and a server, need UML for both
  * Write with your project group
* No, you don't need to code for my class during spring break.

Project Stuff:
* This week: Build UML
  * Don't expect it to be final
  * Be prepared to share with your classmates
  * Be prepared to critique each others'
  * Think about acceptable subparts
* Next week: 
  * Talk about UML
  * Set up a project schedule
* You need project teams
  * Sam's hypothesis: Three teams of four
  * Options for picking teams
    * Random
    * The hell of high-school gym sports
    * Cliques
    * Random as categorized
    * Randomized pairs
      * Jeff + Dennis + Dylan + Nathan
      * Josh + Jordan + Terian + Nora
      * Alex + Jesse + Ravi + Aaron
* Remember: Your pointy-haired manager is likely to shuffle groups

Friday's CS table: An interesting perspective on code.  Your applications
should be able to dynamically load parts of their code.
* Useful technique
  * Can change your program on the fly
  * Extend without recompile and without relinking
  * Ideally, no downtime in the system, even when you're applying patches
* Let's try to build a system that does this
  * Read-Eval-Print loop: Repeatedly
    * Read in a class name
    * Build an object in that class (if possible)
    * Call that object's run method
* Let's try it in Python and in Java
* Design UNIT TESTS
  * Really basic tests
    * Confirm that the class name, as typed in, is correct.
  * User types in name of existing class and it runs successfully
  * User types in name of non-existing class and it reports an error
    but does not crash
  * Make a class, type in the name, and it loads the new class and
    runs successfully.
* Build a class that will run that loop 
  * Steps in the main body
    read in a class name
    try-catch block to make sure that it succeeds
      create an element of that class
      run its run method
    catch
      print error message
* See Examples/Dynamic/Python for the Python version
* Java steps to build the object
  * Call Class.forName(str) to get the Class (c)
  * Call c.getConstructor() to get the Constructor (cons)
  * Call cons.newInstance() to get the object (o)
  * Call o.run() to run it.
* See Examples/Dynamic/Java/Sam for a Java version
  * Problem: Doesn't reload when code changes
* Note: Our unit tests can even create Python source code on the fly,
  so we can write unit tests that say "Check non-existant file, Make
  file, Check again."

Makefiles
* When building large projects, you often have to type long complicated
  commands
  cc -L. -L/tmp/foo -I/glimmer/bin -lbozo -Wall -g -O3 -foo.c
* You also need to sequence commands
  * Build .o files before you link them together
* Make exists to help automate these tasks
* Normal structure:
TARGET: THINGS-IT-DEPENDS-UPON
        INSTRUCTIONS-FOR-MAKING-THE-TARGET
* Variables help you
  * E.g. Flags for compiling .c files
  * Define with
    VARNAME = WHATEVER
  * Use with
    $(VARNAME)
* Some variables get built in
  $< - things on right (or newest thing on right, I never remember)
   - prefix of the target (if the target is foo.py, this is just foo)