[Pipet Devel] Re: Overflow/Loci/GMS collaboration

[Jean-Marc Valin]

"J.W. Bizzaro" a écrit :
> > 1) Wrap all Overflow as a Loki/GMS node
> > 2) Use Overflow's core and implement the missing functionnalities.
> 
> If we chose 2), what would we use GMS's core for?  I'd like to hear Jarl's
> thoughts on Overflow's core.  GMS may provide the missing functionality for
> Overflow, and merging C and C++ shouldn't be all THAT difficult.  I was
> thinking about 1), but sure, we should consider 2) as well.

OK, let's talk about 2) (I consider 1 to be trivial). All our nodes are classes
and the code that's ran is in the getOutput method. Maybe it's possible to call
the GMS functions from there. Again, the main reason I'd like 2) is speed: not
having to call an executable for a sum, logical and, even an FFT. 

> Okay, here's one: Overflow runs from a batch file created by the GUI, right?

No (well you can do it, but you don't have to). When you use vflow to run the
"program", vflow starts another thread, without needing to write XML to disk.
You can modify the program while it's running, but it won't affect it until you
restart it. I think it would be technically feasable to have the modifications
take effect right now, by having a special node that "encapsulates" a Network
(we already have what it takes to do that). That is, in Overflow a Network (set
of connected nodes) is a subclass of the Node class (and thus can be used as a
simple node). 

> Loci's design (and I think GMS's too) lets the core work while the user
> continues to operate the GUI.  This is necessary for Internet-distributed
> nodes running on large datasets, because there can be a very long delay before
> anything is returned.


> So, Loci would allow the user to execute a node and THEN start adding
> connections...or even change connections at a later time.  Loci does this by
> making a 'dynamic batch file', which really has to be a database (since we are
> using XML, we were going to use an XML database).

I'm not sure I understand what you mean here?

> How does Overflow start an executable as a node?  You have to feed it a
> command-line statement, right?  I mentioned already that I have a neat way to
> generate a command-line statement by connecting nodes :-)  GMS/Jarl seems to
> have developed a good system for wrapping executables.  Have you seen it?
> That's one way I think GMS complements Overflow, another is GMS's use of
> CORBA.

You can have a set of nodes that generate a command line in Overflow, then feed
that command-line (string) to the "Exec" node.

> I like how Overflow uses XML.  Looking at some of your XML files, it seems we
> were thinking along the same line.  For example, here is a Loci XML script
> that tells the core what connections to make ('front' is the GUI and 'middle'
> is the core):

Is the "program" in Loci stored as a script? The way it works in Overflow, is
that the XML is simply storing a set of objects: Networks, Nodes and Links. It
stores how the nodes are connected together (XML was just a convenient way to
serialize our objects). Another thing you need to know about Overflow. It works
using a "pull" on the nodes. That is, you first ask the last node for its
output. Then this node asks for the value of each of its input nodes. These
nodes do the same until everything is calculated. If, for some reason a value is
unused, it is not calculated. 

> I guess what we end up doing depends upon how much you and Dominic want to
> change in Overflow.  As for 1), this requires the least amount of work for you
> guys.  But if you're willing to take on new features and paradigms, I'm
> thrilled to hear it :-)

Dominic has a couple things he wants in Overflow (or anything it becomes):
Asynchronus events, multi-thread stuff (partially implemented), ... (Dominic,
anything I forgot?)


> I like the sound of that.  You know, Loci uses icons to represent nodes, and
> some of the icons (will) look like those seen on a GUI desktop: folders,
> trash, documents, etc.  And we're following the Xerox/Apple model in many
> cases: Drag-and-drop a node from a folder onto the desktop, double-click on an
> icon to open a windowlet (little window that stays with the icon and in Loci),
> etc.  PLUS WE HAVE A PLAN FOR GRAPHICAL THEMES: The user can choose desktop
> colors (and wallpaper when the canvas gets that item), icon styles, symbol
> (goes under the icon to represent node class) styles that can be
> mixed-and-matched with icons, plus Gtk themes that can be applied to Loci
> widgets alone.  The way I planned it, Loci COULD substitute for a user's
> desktop.

Sounds cool! I'm not really a GUI guy. The vflow GUI is about the best I can do
(I actually learnind GTK/GNOME while writing it).

> As for a scientific application, Brad, myself and many others involved with
> Loci are computational biologists who hope to use this for scientific
> research.  Hmmmm....There really are many, many more ideas that we've had, but
> we'll get to those in time :-)

I use Overflow for speech processing/recognition and Dominic uses it for image
processing and robot behaviours. I'll probably also write a real-time music
effect processor... when I have time.

Regards,
	Jean-Marc

-- 
Jean-Marc Valin
Universite de Sherbrooke - Genie Electrique
valj01 at gel.usherb.ca