[ml] Hacking tonight?

[Josh Myer]

On Wed, Sep 02, 2009 at 04:43:01PM -0700, Michael C. Toren wrote:
> On Wed, Sep 02, 2009 at 03:55:41PM -0700, Josh Myer wrote:
> > Tonight, we'll be (and by we, I mean Ted and I =) ) trying to put more
> > bindings and infrastructure around the great code Jim and Michael have
> > been putting together.  At that point, we'll be in a good place to
> > start wrapping up integration and get to a release candidate quickly,
> > with any luck.
> > 
> > 2169, 8PM, if you'd like to come help with autotools-ification or swig
> > bindings.
> 
> I'll be there tonight (but probably not next week).
> 

Ah, excellent!  For some reason, I thought you were out of town til
later in the week.  Welcome home =)

> I did some more integration work on my flight yesterday.  I copied
> Jim's HMM code to the wiigee-c directory, and then implemented the Java
> GestureModel class as gesturemodel.c.  (In the Java code, the GestureModel
> class is the one that calls into the Quantizer and HMM classes).  It
> compiles, but I don't have a good sense of how GestureModel is used, so
> I don't have any tests around it yet.  If we could try to flowchart the
> call chain tonight, I can try to implement more of it this week.  But,
> we'll see how things go with the swig bindings.
> 

I think that's a good goal, actually.  I'll be fighting autotools,
Ted's on swig, and you can continue making real progress, instead of
futzing (frustratedly) with the peripheral bits (autotools is so nice,
except when you're on the wrong end of it =) ).


> Also, I broke out some of quantizer.c into separate C files, so that we
> now have one C file for each struct (and where each struct is closely
> related to a Java class we're porting).  I also started to standardize
> the naming convention for now we construct and destroy these structs. 
> For example, quantizer_new() returns a pointer to a newly allocated
> struct quantizer, and quantizer_free() destroys it.  Similarly, we
> have hmm_new(), gesture_new(), observation_new(), etc.
> 
> The other file naming convention I introduced is having a standalone
> binary encapsulating a test suite for each struct.  For example,
> quantizer_test.c has a main() function that calls into quantizer.c to
> implement the unit tests, and I moved Jim's main() function from hmm.c
> to hmm_test.c.
> 
> The C files we have right now, in wiigee-c:
> 
>      util.c                 Random utility functions
> 
>      gesture.c              struct gesture (consumed by quantizer.c)
> 
>      observation.c          struct observation (returned by quantizer.c)
> 
>      quantizer.c            struct quantizer
> 
>      hmm.c                  struct HmmState
> 
>      gesturemodel.c         struct gesturemodel
> 
>      quantizer_test.c       quantizer.c unit tests
> 
>      hmm_test.c             hmm.c unit tests
> 
>      gesturemodel_test.c    gesturemodel.c unit tests (unimplemented;
>                             today it's just a "Hello world" program)
> 
> And, ofcourse, we can change any of this around if we want to do it
> another way instead.
> 

It's a huge improvement, and will make the next step much more
straightforward than it would have been otherwise.  I'd like to move
over to a bit more standard directory structure as part of the
autotools work (library code in lib/, test code in tests/, yadda yadda
yadda), but the unification stuff you did made this a lot easier.  I
wound up down a rathole with this again last night, so still haven't
made real progress.  Having people around to keep me focused will
probably be a big win in terms of real productivity.

I'd so rather be doing C right now, but the autotools stuff is key to
making this a releasable package, and you and Jim have been doing
great work on the actual libraries, so I'd rather not interfere there.

Look forward to seeing you guys tonight!
-- 
Josh Myer   650.248.3796
  josh at joshisanerd.com