[Pipet Devel] executing a network script

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> If I stick this into dom, I have been referring to things basically as
> their tag with _node appended, so this would translate into a variable
> called 'piper_node_node' (where it had previously been 'locus_node'),
> which is really ugly :-)

Hmmm.  Is the appending of "_node" something that DOM requires or something
that you came up with?

>     I agree with both of you that executing a partial network will be
> really tricky, especially at the beginning. My thought was to try and
> have the dl "check" the work-flow-diagram/network and look for things
> like needing input that is not in the diagram, and then returning an
> error to the front before submitting to the bl. This will probably be
> some work and not be perfect at the beginning, but we can try to work
> through it and see what kind of errors we get from different weird
> work flow diagrams.

The biggest problem is the selection and submission of non-contiguous sections
of a network (e.g., selecting 2 nodes that are separated by one unselected
node in the middle).  While ctrl-button1 click in the UI will/can allow this,
we wouldn't want this submitted to be executed.

>     The bigger issue here is that I think Jeff and Jean-Marc have two
> different ideas about what a "network" is. It seems like (from my
> little experience using Overflow before it seg-faults on me :-) in
> Overflow a network is always the entire workspace (in Loci terms). It
> kind of models it like this since a network is like the main function
> in a C program and the nodes are like functions it calls (am I right
> on this?). While in Loci it seems like Jeff was thinking that not
> every node inside of workspaces would necessarily be part of the
> network (only those that were selected). The Loci way seems more
> flexible, but is definately more of a pain.

I think what I've been calling a "network" or "workflow diagram" is more like
an Overflow "subnet".  We do need a consistent terminology.

>     What Jean-Marc said above seems to be what I was thinking about
> doing in the dl, is to turn only the submitted (selected) nodes into
> the network that is submitted to the bl. I'm not sure if this helps
> take care of the issue of workspace=network versus workspace !=
> network to everyone's satisfaction?

But they still need to be contiguous.  It's a complex problem we can work on
at a later point in the development.

>     Along these lines, I was also curious. What are the plans for
> trying to integrate the Overflow GUI with the Loci GUI? Will the
> Overflow GUI be a "composite locus" that can be loaded up? Can we make
> C Gtk/Gnome talk with python Gtk/Gnome (ie. transfer the control of
> the gui to the Overflow GUI when a user clicks inside the composite
> locus holding the Overflow GUI)? I was just curious how this was going
> to work.

Bzzzzt.  Of course Jean-Marc can do what he likes with his own GUI, but piper
will have multiple UI's that function differently (some of them won't even be
graphical).  And each will have to construct a PL network in a manner
consistent with the UI's own style (not to mention, in a manner that will WORK
with the PL).  So, we can't embed Overflow into every UI.

For my Pied (Gnome) UI, I want to make a workspace widget for the PL that
looks and works like the workspace for the BL (i.e., looks and work like
Loci).  It'll be in Python/Gtk.

BTW, the UI interfaces with the PL only through the DL and BL, not directly. 
Correct?

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+