guppi/python integration and other hacking news

[Jon Trowbridge <trow emccta com>]

Here is a quick update on the progress that I've made since releasing
0.33.[12].

------------------
Python Integration
------------------

I've taken a few small steps towards embedding python in guppi.

(1) I've created the shell of the infrastructure required to have a
    Python Interaction Window (like the existing Guile Interaction
    Window).  There is now a python-server directory in guppi3/src on
    CVS, which is basically a copy of guile-server with all of the
    guile bits hacked out.  The problem is that none of the necessary
    python bits have been put in.  Hopefully someone who actually
    knows about embedding python can help me with that.

(2) In my work on the replacement data model, I've switched to using
    auto-generated guile bindings.  For someone who knows what they
    are doing, it shouldn't be too hard to auto-generate python
    bindings from the same specifications file.  Eventually all of
    guppi's guile bindings will be auto-generated --- so we'll always
    be able to keep guile and python (and anything else we care to
    add) in sync.  Again, volunteers are encouraged to step forward.

--------------
New Data Model
--------------

In other guppi hacking news, I'm working on the new data model at a
feverish pace.  I've been meaning to write out a summary of just what
the hell I'm talking about when I make these oblique references to a
"new data model", but writing something coherent seems like it would
take too much time away from coding... so I'll settle for something
incoherent.

In fact, I'm going to give you the ultimate cop-out hacking update:
something that is both incoherent *and* recycled.  This is extracted
from a private e-mail I sent a friend of mine a few days ago:

> I've started hacking on an improved data model, which should be pretty
> cool.  The old model was quite primitive and very oriented towards
> simple linear arrays.  I'm setting up something much more general,
> that will support N-dimensional arrays, images, struct-like data, and
> hopefully all sorts of stuff that I haven't thought of yet.
>
> I'm also setting it up to use pluggable back-end implementations.
> Guppi provides a shallow abstraction layer for different data types,
> which can be connected to different implementations.  Of course Guppi
> will provide "default" implementations, which should be sufficient for
> doing basic stuff.  But if you have some super-optimized image
> processing library that is specially tuned for your fancy hardware,
> you can use that library for Guppi's image objects and operations.  It
> will just be a question of writing some fairly simple wrappers and
> sticking them in a loadable module.  And different objects can be
> linked to different implementations: so even though two different
> image objects might show the same interface to Guppi, they could be
> two different data structures using two different libraries, each
> optimized for the specific type of processing that needs to be done on
> that image.
>
> It should be nice.  And it also gets me off the hook of having to
> write really good code for a lot of operations.  If anyone says
> "Guppi's X sucks compares to library Y", I can simply respond that
> the person should write implementation wrappers for library Y and use it
> instead of whatever ships with Guppi. :-)

To tie in with the python theme at the beginning of this update, the
new model's N-dimensional array type is designed to be easily
integrated with Numerical Python's N-dim array --- so after just a bit
more infrastructure is completed, everyone's existing Numerical Python
programs should automatically become perfectly good Guppi scripts.

-JT

-- 
COMINT secret | Jam Echelon! http://www.echelon.wiretapped.net | NSA explosives
assassin terrorist car bomb tactical bin laden waco white house nuclear clinton