[Pipet Devel] executing a network script

J.W. Bizzaro bizzaro at geoserve.net
Thu May 4 17:37:33 EDT 2000


Brad Chapman wrote:
> 
>     My overall point is that I just think 'node' is taken up by the
> tools we are using and we should think up something else to describe
> our smallest elements. This will make the code easier to read and
> understand, IMO. I dug using locus, but I don't know how people feel
> about that now. Node was a Overflow term, right?

Node is an Overflow term, yes.  And I don't know if Jean-Marc wants to change
it.  Do you have to turn Overflow/PL nodes into DOM nodes as well, or is that
just for BL nodes?  If it's just for BL nodes, we could continue to call each
a "locus", meaning "location", which is what BL nodes are.

We could also use "bl_node" and "pl_node", but that might again cause
problems.

> Agreed, the error checking should all occur in the dl when it is
> getting it ready for sending to the bl. This way, the bl should be
> able to "count" on having a network definition that is complete and
> ready to run. This will also decrease the time between when a bad
> network is submitted and when it it run.

The way piper will work reminds me so much of writing a BASIC program:

  * You have 2 modes: program editing and program running
  * When editing, BASIC (some versions) will point out errors:

                 "SYNTAX ERROR"

  * Typing "RUN" will send the program to the interpreter
  * The interpreter can return errors as well:

                 "SYNTAX ERROR IN LINE 100"

For piper, the UI is the editing environment, the DL checks for errors in the
script, the BL runs the script, and the PL is the low-level implementation of
the script.

> It just seems like that you both have such similar designs, that there
> isn't some kind of meeting place where we can have some code re-use?
> It just seems like the sooner we are able to get Overflow running
> under Piper the way it is now stand-alone, the sooner we can make
> better use of our resources and not have to be coding separate UIs and
> all of that. I'm just trying to think of ways that we can do that
> sooner, rather than later. I was kind of interested to hear
> Jean-Marc's thoughts on this as well, and how he thinks we can
> expedite the process of getting all of our programs together. So I was
> just trying to brainstorm ideas along those lines :-)

We can get the Overflow GUI running under Pied (my Gnome GUI) by making Python
bindings to the Overflow GUI or by using Bonobo.  I think both approaches
would be more work than what I had in mind: Make a widget that is a Loci
workspace modified to build Overflow subnets.  Then there's LOTS of code reuse
:-)

I have nothing against the Overflow GUI.  It's very nice.  It is just that it
works differently enough from the Loci GUI that embedding it would be
confusing to users and result in a higher learning curve.

> The idea right now is that the UI only talks to the dl, and the only
> way it can talk through it is through the streaming XML dialog "API."
> Everything that the UI can currently talk to the dl about (and how to
> do it) is documented in doc/comProtocols.txt in the loci module in
> cvs. I need to talk some time to clean this documentation up and make
> it more readible (I'll redo it in latex or something), but what we
> have so far is there. Input on problems/suggestions for the interface
> would be super :-)

Great.  I'll take a look.

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




More information about the Pipet-Devel mailing list