Building git from Source on Ubuntu 8.10 Hardy Heron

VMWare supports Hardy Heron as a guest operating system in Fusion 2, so that's what I use for Linux work.  The Hardy Heron version of git is 1.5.6.3 though, and today's version is 1.6.2.  Here is what I did to build git 1.6.2 from source.  It is a mix of command line and GUI tools

1. Using the Synaptic Package Manager, mark git-core for installation and verify that zlib1g, zlib1g-dev, libexpat1, libexpat1-dev, and curlInstall git-core from the Synaptic Package Manager.
2. Open a terminal window, make the directory that you want to hold the git tree (I used ~/work), change to that directory, and invoke git clone git://git.kernel.org/pub/scm/git/git.git
   
3. Using the Synaptic Package Manager, remove git-core and install if necessary tk, libcurl4-openssl-dev, zlib1g, zlib1g-dev, libexpat1, libexpat1-dev, and curl.
   
4. In the terminal window, change to the directory where you cloned git.
5. make prefix=/usr/local all
   
6. sudo make prefix=/usr/local install
   
   

Base class ReferenceProperty in AppEngine

Google AppEngine

Mixed polymorphic and monomorphic classes

from google.appengine.ext import db

from google.appengine.ext.db import polymodel



class Base(db.Model):

  date_added = db.DateTimeProperty(auto_now_add=True,auto_now=False)



class Person(Base):

  name = db.StringProperty()



class Item(Base, polymodel.PolyModel):

  owner = db.ReferenceProperty(Person, collection_name="stuff")

  motive = db.StringProperty()



class Book(Item):

  title = db.StringProperty()



class Weapon(Item):

  name = db.StringProperty()

  battleground = db.StringProperty()



p = Person(name="Barack")



p.put()



Book(title="Quantum Mechanics", owner=p, motive="Curiosity").put()

Weapon(name="Wit", battleground="Debate", owner = p, motive="Education").put()



b.put()



for x in p.stuff:

  print "%s: %s" % (x.motive, x.date_added)

PEP 8 is prescriptive about the preferred location for import statements:

Imports are always put at the top of the file, just after any module
comments and docstrings, and before module globals and constants.

This has bugged me. I think it reminds me of the "include the world" messes I saw in C++ code that resulted in massive overdependency and lengthy recompilations. With the import remote from the use, it is easy for crud to accumulate. Someone writes a tiny method (for debugging, as an experiment, for a one-off) that uses something used nowhere else in the module and now everything in the module is (lexically) dependent on that import, and so is the module's every consumer. Ugh.

I wonder what the rationale is. A benefit is that missing modules will be discovered early: "cannot import" complaints will appear at startup, not after a possibly lengthy time of apparent stability when a rare event occurs. A drawback is that some refactoring, e.g. moving a class to its own module, is tricky to do perfectly. If I copy the entire import block to the new module, it is guaranteed to work, but there is a good probability that that block will be more than necessary, because the module was a candidate for refactoring in the first place.

So I prefer import statements to go in the class; and the basis of this preference is that I think of the class as the unit of reuse, not the module; and I think that because I am still speaking Python with a C++ accent.