From bizzaro at bc.edu  Mon Apr  5 10:21:07 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 1.
References: <199903311628.MAA24038@chimbo.neurobio.upr.clu.edu>
Message-ID: <3708C6D3.DBE475CA@bc.edu>

Hi Humberto!

(I think your clock is set to last Wedneday.)

Humberto Ortiz Zuazaga wrote:

> Yes, this is good.  Installing a display locus (from wherever, more on this
> later) should register the locus as able to display a certain set of DTDs, or
> an analysis locus can register the type of analysis performed and the input
> and output formats it handles.  Once registered, the workspace can find these
> locally and dispatch them immediately.

Yes.  Although it may be best that loci do not register themselves, that they
are only registered when the app broker requests registration.

> The app broker locus can also be queried at run time to find display loci or
> analysis loci meeting certain requirements.  Perhaps the workspace could ask
> the app broker to find source for a widget to display frobnicated sequences.
> This source could then be downloaded and registered locally.

I imagined that making a connection to an app broker anywhere, will allow the
registration of all accessible (and allowed) loci.

The largest of all app brokers, which I have been calling the "Hub", which is on
an Internet server and registers all other analysis app brokers on the Internet.

The local app broker, which I have been calling the "Techie" or "loci database",
resides on the user's machine and registers all analysis apps via URL (to get a
limited set of loci) or via the Hub (to get all loci on the Internet).  Now that
you mention it, Techie is really the local app broker.

There is also a CORBA broker to be made, which is local too, but the CORBA apps
are considered remote to Loci.

> I could set up my app broker to only accept source loci from "trusted"
> sources, or to only send my data to trusted analysis loci.  If I were really
> paranoid, I could turn off the app broker, and only run locally registered
> loci.

Ya, Das ist gut.

> Is the locus database different from the app broker, or can they be merged?

As mentioned above, the locus database is really the _local_ app broker.

> The trick then is how the app broker finds out about loci at remote sites.

Of course you mean command-line analysis loci (which can return a GUI).  Really,
the same way it finds out about local loci.  PAOS should make the connections
seamless, so Loci "thinks" all loci are local (with the exception of security
issues).


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr  5 10:53:45 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3.
References: <199903311823.OAA24194@chimbo.neurobio.upr.clu.edu>
Message-ID: <3708CE79.54D431A3@bc.edu>

Humberto Ortiz Zuazaga wrote:

> > Hmmmm.  Either way, we're still talking about transferring a script.
> 
> Perhaps not.  Say I'm doing an analisis on a locus that returns multiple
> alingments.  I get my results back with the url for a multiple sequence
> viewer, but I already have one installed from a trusted source.  I won't need
> to get a new one.

I agree.  The local app broker should keep a cache of viewers, perhaps a
permanent repository if the source is trusted.  (Hmmm!)  There is no need to
keep downloading the same information, especially if it is large.

So maybe the remote app brokers can say, "Here is the XML for the biodata and
workflow.  Oh, and here is where you can get the GUI IF you need it."

An alternative might have been for the local app broker to tell the remote app
broker that it has the right viewer.  But if you think about it, how would the
local app broker know what GUI the returning biodata would need.

> > I wasn't talking about anything that would require a DTD, just a marker to say
> > <thescript> </thescript>.
> 
> But that's what I mean.  What does <thescript> have to do with describing
> nucleotide sequences?

This has to do with embedding the GUI script.  The markers could be just like
those used to embed a script in HTML, like Javascript.  I wasn't talking about
biodata there.

> > Security is an issue for executing _any_ code from a remote source, whether or
> > not it happens to be in the same file as the XML.
> 
> Presumably, any loci shipped with the Locus distribution are safe.

But those from LOCI.SOMEURL.NET may not be.

> I say all loci should return results that say "This is valid bicml nucleotide
> sequence v4.2"
> 
> I don't want a locus to say "Best viewed with Internet Genome Explorer 10.3".

But you do want the remote app broker to suggest a viewer?

> No, I specifically think putting the UI code into the data stream is bad.
> After the first time I get the UI, why should I keep downloading it?  Imagine
> having to download netscape everytime you wanted to view a html file.

I get your point, although I hope our GUI scripts are never that big ;-)  In
some cases the GUI script will be as small as a Javascript.  In fact, in most
cases it should be that small.  This is why the GUI widgets will be very
high-level.

I have never heard complaints that Javascript is too much to download and that
they should be cached.  If we can make it that small, embedding the GUI should
be reasonable.  If we cannot, we should go with some system for determining
whether or not the GUI is needed.

> As a matter of fact, an analysis locus doesn't even have to publish the url
> for a display locus in every result, we can use the AppBroker (can we call her
> the Matchmaker instead? she facilitates the exchange of loci) to keep track of
> where to get a display locus for the results.

You mean the local app broker?  I was calling it Techie, but Matchmaker is
applicable to all app brokers.

> So if I write a new analysis locus and want to make it available to the
> community I can publish the location of the analysis locus (source or service)
> and the output formats.  Display loci publish the input formats they support,
> and the AppBroker can make sure your workspace has the appropriate display
> locus, or help you locate one

Yep.

> or find a translation locus that can do the
> conversion for you.

What conversion?  Are you talking about converting the biodata XML or the GUI? 
I suppose the former.


Ciao,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr  5 11:20:49 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3.
References: <199903311823.OAA24194@chimbo.neurobio.upr.clu.edu> <3708CE79.54D431A3@bc.edu>
Message-ID: <3708D4D1.39B50997@bc.edu>

"J.W. Bizzaro" wrote:
> 
> An alternative might have been for the local app broker to tell the remote app
> broker that it has the right viewer.  But if you think about it, how would the
> local app broker know what GUI the returning biodata would need.

I thought about it some more, and it might work like this:


  LocalAppBroker:   Here is biodata in LocusML 3.5.
                    I want to align these two nucleotide sequences.

  RemoteAppBroker:  I have nucleotide sequence aligner 2.7.
                    Let me check.
                    Okay.  That will require viewer 5.6.

  LocalAppBroker:   I don't have that.  Send it embedded in the LocusML.
 

If the local app broker (or user's installation) does have the right viewer...


  LocalAppBroker:   Here is biodata in LocusML 3.5.
                    I want to align these two nucleotide sequences.

  RemoteAppBroker:  I have nucleotide sequence aligner 2.7.
                    Let me check.
                    Okay.  That will require viewer 5.6.

  LocalAppBroker:   I have that.  Send just the results of the analysis.





Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hortiz at neurobio.upr.clu.edu  Tue Apr  6 09:45:20 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 1. 
In-Reply-To: Your message of "Mon, 05 Apr 1999 10:21:07 -0400."
             <3708C6D3.DBE475CA@bc.edu> 
Message-ID: <199904061345.JAA07514@chimbo.neurobio.upr.clu.edu>

> (I think your clock is set to last Wedneday.)

Err, no, our 56K line was down from Wed till Monday.  Good Thursday and Good 
Friday are national holidays in Puerto Rico.

> 
> Humberto Ortiz Zuazaga wrote:
> 
> > Yes, this is good.  Installing a display locus (from wherever, more on this
> > later) should register the locus as able to display a certain set of DTDs, 
> 
> Yes.  Although it may be best that loci do not register themselves, that they
> are only registered when the app broker requests registration.

Well, we've got a couple of different app brokers, but I think the local app 
broker should be notified when local loci are installed.  It's cheaper and 
simpler.  Remote loci can be queried on demand or polled, but it may be 
simpler as well to just broadcast a notice of availability when the locus is 
turned on. This notification can then be propagated among interested app 
brokers.

> > The trick then is how the app broker finds out about loci at remote sites.
> 
> Of course you mean command-line analysis loci (which can return a GUI).  Really,
> the same way it finds out about local loci.  PAOS should make the connections
> seamless, so Loci "thinks" all loci are local (with the exception of security
> issues).

Here's where I get lost.  I haven't read the PAOS documentation (shame on me), 
can someone summarize what PAOS can do in the context of App Brokers locating 
loci?

-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From rahul at photino.sid.rice.edu  Tue Apr  6 22:54:38 1999
From: rahul at photino.sid.rice.edu (Rahul Jain)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3.
In-Reply-To: <3708D4D1.39B50997@bc.edu>
Message-ID: <Pine.LNX.4.10.9904062150420.5573-100000@photino.sid.rice.edu>

On Mon, 5 Apr 1999, J.W. Bizzaro wrote:

> I thought about it some more, and it might work like this:
> 
> 
>   LocalAppBroker:   Here is biodata in LocusML 3.5.
>                     I want to align these two nucleotide sequences.
> 
>   RemoteAppBroker:  I have nucleotide sequence aligner 2.7.
>                     Let me check.
>                     Okay.  That will require viewer 5.6.
> 
>   LocalAppBroker:   I don't have that.  Send it embedded in the LocusML.

Hmmm... the way I see it, the last step is not necessary. The local app
broker or whatever should contact the Hub app broker and say I have data
in such and such format (use MIME for this?) could you please list the
available viewers? The user would then be presented with a list of viewers
and would choose to download the viewer, save to disk, etc. Sorta like the
way Netscape does it.

-- 
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ {  Rahul -<>- Jain   } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-jain@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.210000101.23.50110101.042
   (c)1996-1999, All rights reserved. Disclaimer available upon request.

From bizzaro at bc.edu  Tue Apr  6 23:34:39 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3.
References: <Pine.LNX.4.10.9904062150420.5573-100000@photino.sid.rice.edu>
Message-ID: <370AD24F.A592DA67@bc.edu>

Rahul Jain wrote:

> >   LocalAppBroker:   I don't have that.  Send it embedded in the LocusML.
> 
> Hmmm... the way I see it, the last step is not necessary. The local app
> broker or whatever should contact the Hub app broker and say I have data
> in such and such format (use MIME for this?) could you please list the
> available viewers? The user would then be presented with a list of viewers
> and would choose to download the viewer, save to disk, etc. Sorta like the
> way Netscape does it.

That's a good point.

Netscape does deal with the same problem and uses MIME.

I do like the idea that the skeleton locus is a "browser" that browses LocusML
(as Netscape browses HTML) with GUI scripts attached (as Javascript is attached
to HTML).  The effect is that the GUI itself is being browsed and is transient.

I just like that idea.  I think it's pretty clever.

The alternative is to download the GUI script via link (as Humberto mentioned),
which is more like running a Java applet than a Javascript.

The big question is how complex will the GUI be?

Regarding MIME, Loci will have to deal with unknown datatypes, just as Netscape
does.  So Loci can present the user with a dialog box with Specify Viewer, Get
Viewer, Save To Disk, Cancel.  If for example, the user chooses Get Viewer, Loci
will have to contact an IAB or MAB (Hub).

Maybe it is best to take the beaten path and use Netscape as a model.

But what about binaries?  When Netscape asks if you want to get a viewer, it
gets a binary program.  For Loci we were talking about a Python script.  That'd
sure help with portability issues.  But if we are now talking about a
once-in-a-while situation where a new viewer is needed, could we just have
binary viewers downloadable and skip the script?

I'm looking for a model that would give us a clear-cut case for doing something
different.  It seems we could once again go either way.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Tue Apr  6 23:57:02 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3.
References: <Pine.LNX.4.10.9904062150420.5573-100000@photino.sid.rice.edu> <370AD24F.A592DA67@bc.edu>
Message-ID: <370AD78E.7DAECB88@bc.edu>

Maybe we can keep the polished GUI as a script, and if Loci needs a new viewer
it can get a transient GUI script and check for the binary widgets on the local
Loci installation.

If some binary widgets are not present, the user can be prompted about
downloading _them_ from whatever source.

This way the local installation of Loci will have a collection of small,
versatile and modular binary widgets, not a collection of large viewers that may
not be used.

As opposed to making all of the viewers binary (the traditional way of doing
this sort of thing) and static, scripted viewers will allow incredible
flexibility in the design of GUI loci.  Imagine writing a viewer that combines
sequence and structure widgets in the same view.  This would be much simpler
using the approach of "micro scripts, mega widgets" than writing a compiled
executable from scratch.

I'm not saying that anyone suggested all binary viewers.  But going with a
viewer that is large enough to need a separate downloading, is not much
different.

How small can we make these GUI scripts?  How large will our GUI megawidget
library have to be?


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hortiz at neurobio.upr.clu.edu  Wed Apr  7 14:05:23 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3. 
In-Reply-To: Your message of "Tue, 06 Apr 1999 23:34:39 -0400."
             <370AD24F.A592DA67@bc.edu> 
Message-ID: <199904071805.OAA14676@chimbo.neurobio.upr.clu.edu>

> Rahul Jain wrote:
> 
> > >   LocalAppBroker:   I don't have that.  Send it embedded in the LocusML.
> > 
> > Hmmm... the way I see it, the last step is not necessary.
> 
> That's a good point.
> 
> Netscape does deal with the same problem and uses MIME.

Gnome has another html browser called Express, designed to be expanded with 
plugins, it looks a little like what we're talking about. 
http://www.cse.unsw.edu.au/~conradp/express/

When I first proposed my idea, I was in fact thinking of some kind of MIME 
like typing of the data stream.

The problem I see with MIME is how to handle multiparts, especially of 
different types.  I've been looking at the XML specifications, and it does 
look like namespaces can be used for what we want.  In order to encode all the 
information we want, we may have to do some tricks.

namespaces allow you to associate a label like

bicml:

to a URI like

http://bioinformatics.org/loci/

and have entity names be prepended with the URI.  You can also set up a 
default namespace for an xml file.

Specifically, I propose that we set up our xml files so that the labels and 
uri encode each of the little languages we want to use:

<?xml version="1.0"?>
 <!-- both namespace prefixes are available throughout -->
 <bicml1:stuff xmlns:bicml1='http://bioinformatics.org/loci/bicml/v1.0/'
          xmlns:nucseq1='http://bioinformatics.org/loci/bicml/nucleotide-sequen
ce-ml/v1.0/'>
     <bicml1:name>Some file of stuff</bicml1:name>
     <nucseq1:name>My new sequence</nucseq1:name>
     <nucseq1:sequence>ACGT</nucseq1:sequence>
 </bicml1:stuff>

so nucseq1:name is different from bicml1:name, and nucseq1 is an abbreviation 
for http://bioinformatics.org/loci/bicml/nucleotide-sequence-ml/v1.0/, note 
that the definition of namespaces does not say anything about any content at 
the page http://bioinformatics.org/loci/bicml/nucleotide-sequence-ml/v1.0/, 
only that it uses the actual string used in the uri part in order to decide if 
two names are the same.

I think we should at least put a description of the file format we use at the 
references URL, but in fact it isn't necessary: see the file format used in 
gnumeric for an example (the file is compressed, use zless or rename and 
uncompress it first).

We could use the uri part of the namespace as a kind of MIME type, that 
included the sublanguage and version of a file format.

The BICML language per se could specify how to package things together in sets 
or lists (multiple sequences, sequence + structure; then each sublanguage 
could deal with a smaller domain, like a single sequcence.

The human readable description at the uri could also contain information about 
where to get a browser, but the actual uri could be passed to the appbroker to 
query about display loci.

> But what about binaries?  When Netscape asks if you want to get a viewer, it
> gets a binary program.  For Loci we were talking about a Python script.  That'd
> sure help with portability issues.  But if we are now talking about a
> once-in-a-while situation where a new viewer is needed, could we just have
> binary viewers downloadable and skip the script?

When I was writing the proposal, I thought it wold be neat to have a file type 
like "multifile python module" that contained the source to a viewer, we could 
also have a type like "i386/libc6/rpm" for a viewer.  The app broker can 
return a list like

python - ftp://bar.baz/pub/viewer.py
compressed-multifile-python-tarfile - ftp://bar.baz/pub/fancy-viewer.tar.gz
i386/libc6/rpm - ftp://rpmfind.net/libc6/i386/viewer1.0-2.rpm

and the user can select which one he wants to retreive.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From bizzaro at bc.edu  Thu Apr  8 09:49:41 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:07 2006
Subject: [Pipet Devel] Another XML proposal - Part 3.
References: <199904071805.OAA14676@chimbo.neurobio.upr.clu.edu>
Message-ID: <370CB3F5.2ACA432C@bc.edu>

Humberto Ortiz Zuazaga wrote:
> 
> Gnome has another html browser called Express, designed to be expanded with
> plugins, it looks a little like what we're talking about.
> http://www.cse.unsw.edu.au/~conradp/express/

I actually wrote to this guy about helping with Loci.  I put his last e-mail to
me at the bottom of this message.

Since no one from Grail replied to my message (surprisingly), we may want to
take a look at Express.

Humberto, I like the proposal you gave.  It's good to see the discussion of some
of the low-level mechanics.

But I still have one question for you, and I'm not sure you have answered it
yet:

    Do you think there should be a layer of Python that sits between the
    skeleton locus (or locus browser) and the low-level code that will
    complete the viewer.

    What in fact are you calling a "viewer"?  Is it the browser + script +
    megawidgets, as I've been saying, or do you think the user will be
    downloading self-contained executable programs, as Netscape does?

Well, that's more than one question.

> 
> When I was writing the proposal, I thought it wold be neat to have a file type
> like "multifile python module" that contained the source to a viewer, we could
> also have a type like "i386/libc6/rpm" for a viewer.  The app broker can
> return a list like
> 
> python - ftp://bar.baz/pub/viewer.py
> compressed-multifile-python-tarfile - ftp://bar.baz/pub/fancy-viewer.tar.gz
> i386/libc6/rpm - ftp://rpmfind.net/libc6/i386/viewer1.0-2.rpm
> 
> and the user can select which one he wants to retreive.

Good idea.  But these aren't executables, are they?


Jeff
bizzaro@bc.edu


------------message from Conrad Parker-------------------------


On Thu, Nov 12, 1998 at 09:39:16PM -0400, J.W. Bizzaro wrote:
> Conrad,
> 
> Are you still developing Express?  I noticed that the Web site
> hasn't changed in some 6 months.

yes, I'd still like to though I haven't worked on it in a while.

> 
> Do you have any plans on joining the Mnemonic Project?

no, I have different (just leaner) design goals. But their work looks
promising.

> 
> I am the coordinator for the TULIP Project, a GNU application
> for DNA and protein analyses.
> 
>   http://www.uml.edu/Dept/Chem/UMLBIC/Apps/TULIP/
> 
> TULIP will be highly modular, very much plug and play for
> the analysis algorithms.  Part of this plan for modularity,
> is the use of an XML called, "Bioinformatic Sequence Markup
> Language," or BSML.  We hope to use BSML as the language
> of communication between modules and the user.  Check out
> these links for more info on BSML:
> 
>   http://www.oasis-open.org/cover/xml.html#xml-bsml
>   http://visualgenomics.com/sbir/rfc.htm
> 
> Since BSML works in a "browser" environment, we would like
> to have a specialized BSML-browser as a central part of
> TULIP.

ok, I've had a quick read of the BSML spec and the TULIP homepage ...

> A question I have for you is, would you like to help transform
> Express into a BSML browser for TULIP and be a part of the
> TULIP development team?  If not, could we use the Express code
> to make one ourselves? (I would prefer the former ;-) )

I'm planning on making Express handle XML applications nicely, though I haven't
looked into it much yet. Insofar as my contribution involves writing a
browser which can support various XML applications, yes I'd like to be involved
with TULIP :) Beyond that I don't think I can help much - my knowledge of
biochemistry doesn't extend too much beyond high school and brief encounters in
studying information theory and genetic algorithms :)

However, I am planning on XML support for mathematics (MathML) as I am working
on a symbolic computation program which is currently console based (and as yet
unreleased). It would be a good test of XML support to be able to test with
both MathML and BSML applications.

As for using the Express code ... of course you're free to (it's GPL'd after
all!) but it wouldn't be much use to you - at the moment it's not much more
than a container for the gtk-xmhtml widget, with a history list.

> 
> The insentive for you is that a BSML browser for biological
> analyses would be very unique, and maybe even more of a
> challenge than an HTML browser :-)
> 
> What do you think?

cool :) looking at your developer's page, if Jay Painter is working on the
BSML implementation then it should probably be ok for me to just do the web
browser support (which will of course give networking etc).

Now for some ideas :) ...

My main project this year (and the reason express hasn't moved much) is AUBE, a
sound synthesis/sequencing/processing system. You can find out more about it
at:

        http://www.cse.unsw.edu.au/~conradp/aube

AUBE processes sound streams in real time, and gets its power from being able
to connect up many different modules in arbitrary ways.

The reason I mention it is because its architecture is similar to your ideas
for TULIP. In particular, looking at your ideas for GCL (do you have an
implementation yet?) it looks like the way you want to be able to connect up
components (tools) is similar to the way aube works - however aube's system is
currently entirely graphical (ie. you can connect up various components, but
not load/save the state of connections). I am looking at using XML to handle
this information, as it can save parameters of each component more cleanly than
a scripting language could.

So, if you'd like to save yourself some coding you can use the system I've got
going with aube, including some widgets for selecting inputs and connecting up
components. I'll soon be adding an overview widget for editing the whole graph
of connections

From bizzaro at bc.edu  Wed Apr 14 02:38:06 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:08 2006
Subject: [Pipet Devel] XML for GUI
Message-ID: <371437CD.13EE7A12@bc.edu>

Locians,

Following up on some thoughts of using XML to describe the GUI of the viewers
(which is in some ways an older idea), I came across James Henstridge's
GLADE-XML GUI generators.

If you don't know what GLADE is, it's a GTK GUI builder, sort of like Delphi but
without the editor.  It actually uses XML as a file format for saving projects,
so the XML describes GUI's.

James has a Python module, which is actually part of PyGTK.  You may want to
look at it:

    http://bioinformatics.org/loci/pyglade-0.5.12.tar.gz

He also has a C library to generate GUI's at runtime from a binary:

    ftp://ftp.daa.com.au/pub/james/gnome/libglade-0.0.3.tar.gz

Either one could be useful to us.  A viewer's controls I imagine can be
specified this way.  But note that this is a change from the idea of downloading
a Python GUIscript to call GUImegawidgets.  (The GUImegawidgets may still be
used in some cases though.)

Actually, if we make it so that Loci doesn't need to download various viewers,
our need for something like RPM becomes less certain.  Maybe we can use a simple
database.  Does anyone know of a simple GPL database in Python?

Another use of XML (yes, another one), would be to describe vector graphics
(drawn by GILT?).  Does anyone know of an existing XML to describe vector
graphics?


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From mrn at supermta.hg.med.umich.edu  Wed Apr 14 07:31:17 1999
From: mrn at supermta.hg.med.umich.edu (Matthew R. Nelson)
Date: Fri Feb 10 19:18:08 2006
Subject: [Pipet Devel] XML for GUI
References: <371437CD.13EE7A12@bc.edu>
Message-ID: <99041407370000.26490@mrnlinux.hg.med.umich.edu>

On Wed, 14 Apr 1999, J.W. Bizzaro wrote:

>Another use of XML (yes, another one), would be to describe vector graphics
>(drawn by GILT?).  Does anyone know of an existing XML to describe vector
>graphics?

Yes.  Killustrator, the vector drawing program for KDE and the KOffice
application suite, uses XML as its native file format, as do many of the
KOffice components, including KWord, the word processor.  The home page
can be found at

http://koffice.kde.org/
http://wwwiti.cs.uni-magdeburg.de/~sattler/killustrator.html

Matt
----------------------------------------------------------------------------
Matthew R. Nelson
Dept. of Human Genetics             http://www-personal.umich.edu/~ticul/
University of Michigan              email: ticul@umich.edu
4711 Medical Science II             phone: (734) 763-8090 or 647-3151
Ann Arbor, MI  48109-0618           fax:   (734) 763-5477
----------------------------------------------------------------------------

From jabbo at mindless.com  Thu Apr  1 09:53:20 1999
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:26 2006
Subject: [Pipet Devel] check this out
References: <3703C7C3.4890C1DB@bc.edu>
Message-ID: <99Apr1.145523est.131732@gateway.macroint.com>

Never heard of Dia until now?!?  It's been around for quite some time; I
have been using it to explain schemas and network layouts (eg. firewalls
& routing) to people for months.  

It spits out XML (though the files are gzipped, I'm going to hack in an
option to store them uncompressed one of these days) and at one point I
tried to write a parser to convert SQL scripts to dia class diagrams. 
Alas, that was taking a wee bit longer than we had to spare...

Almost done with the application, just tweaking some Javascript garbage
and fixing the security.  From this weekend onwards I should have a lot
more time to work on Tulip.

-- 

     "Your superior intellect is no match for our puny weapons!"

                                   --synaptiK

From bizzaro at bc.edu  Thu Apr  1 14:23:47 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] check this out
Message-ID: <3703C7C3.4890C1DB@bc.edu>

It pays to read Freshmeat.

Here is a program called "Dia" that draws diagrams, like what we want to do with
the Work Flow Diagram on the Benchtop:

    http://www.lysator.liu.se/~alla/dia/

It is GTK+ and GPL!


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--

From bizzaro at bc.edu  Thu Apr  1 20:50:45 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] check this out
References: <3703C7C3.4890C1DB@bc.edu> <99Apr1.145523est.131732@gateway.macroint.com>
Message-ID: <37042275.47FF9AB1@bc.edu>

Tim wrote:
> 
> Never heard of Dia until now?!?  It's been around for quite some time; I
> have been using it to explain schemas and network layouts (eg. firewalls
> & routing) to people for months.

Nope.  Sorry.  It must have escaped me somehow.  Me bad.

I have been trying to keep track of new GTK+ programs, but there are so many of
them.

> 
> It spits out XML (though the files are gzipped, I'm going to hack in an
> option to store them uncompressed one of these days) and at one point I
> tried to write a parser to convert SQL scripts to dia class diagrams.
> Alas, that was taking a wee bit longer than we had to spare...

I am curious about modifying Dia to be our WFD.  Do you think that is a good
idea?

> 
> Almost done with the application, just tweaking some Javascript garbage
> and fixing the security.  From this weekend onwards I should have a lot
> more time to work on Tulip.
> 

I look forward to it :-)


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--

From justin at ukans.edu  Thu Apr  1 23:00:56 1999
From: justin at ukans.edu (Justin Bradford)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] genentech
Message-ID: <Pine.OSF.4.03.9904012139430.16609-100000@busboy.sped.ukans.edu>

I pretty sure I'm going to be accepted for an internship at Genentech this
summer, working in the biocomputing division. In the interview, the
director of this division was asking a lot of questions about Loci, and
seems very interested. 

Basically, they develop bioinformatic tools and client/middleware
interface software so the researchers can easily access these
bioinformatic tools and databases from easy-to-use interfaces over the
network.

Sound familiar?

So far they've basically been doing Perl/CGI access just using netscape.
They are wanting to start making use of Java applets to make better
interfaces, too.

I was having some trouble explaining the Loci design to him, but we're
basically doing the same thing. Well, except that the Loci design is
substantially more powerful, flexible, easier to use, and provides better
client views. After we're done writing it, of course ;)

I have a friend who used to work out there, and he tells me they have some
absolutely brilliant people in the biocomputing/bioinformatics division
(although they're probably doing development on the bioinformatic
tools rather than the interface/network stuff). Given the overlap and
general interest they showed towards the Loci concept, it might not be too
big of a stretch to get genentech interested in the project. Or, at least,
maybe I can attract a few developers there.

They have a cross-platform concern, too, with Windows and MacOS, and
probably some unix, desktops. Has anyone heard about a GTK port to MacOS?

Anyway, just some idle speculation...

Justin Bradford
justin@ukans.edu

P.S. I'll actually get around to setting up CVS, SSH, etc. on the new
server this weekend. I promise. Any thing else we need on it?

P.S.S. Thanks J.W. for starting this project. It played a big part in this
getting (probably) this internship.

From finklesk at Op.Net  Thu Apr  1 23:04:15 1999
From: finklesk at Op.Net (greg waltz)
Date: Fri Feb 10 19:18:27 2006
Subject: bio (Re: [Pipet Devel] new stuff up)
In-Reply-To: <37006470.39DFE0B2@bc.edu>
Message-ID: <Pine.SUN.3.96.990401225506.3008A-100000@monet.op.net>


On Tue, 30 Mar 1999, J.W. Bizzaro wrote:

> Also, I posted some developer bios.  Let me know if you have anything to
> change.  I don't have any bio for Greg...Hey Greg!
> 

woah, sorry. i've been busy. if you need to get in touch with me
specifically, try
emailing me directly instead of through the list. that way your message
stands out. i don't mean to be weird about it, it's just that i am on
several mailing lists and i don't read 3/4 of the mail that i get. i only
read a few random things and whatever subjects that i'm involved in.

with that said, here's the bio: i'm a computer enigineer at villanova
university and i write the almost-but-not-yet-3d-modeler, mg^2.

is that all the info you want?

sorry for the late reply. later

From rahul at photino.sid.rice.edu  Thu Apr  1 23:16:06 1999
From: rahul at photino.sid.rice.edu (Rahul Jain)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] genentech
In-Reply-To: <Pine.OSF.4.03.9904012139430.16609-100000@busboy.sped.ukans.edu>
Message-ID: <Pine.LNX.4.10.9904012208580.7231-100000@photino.sid.rice.edu>

On Thu, 1 Apr 1999, Justin Bradford wrote:

> I pretty sure I'm going to be accepted for an internship at Genentech this
> summer, working in the biocomputing division. In the interview, the
> director of this division was asking a lot of questions about Loci, and
> seems very interested. 

Cool, congratulations!

> They have a cross-platform concern, too, with Windows and MacOS, and
> probably some unix, desktops. Has anyone heard about a GTK port to MacOS?

No, but it'll be trivial to port it to MacOS X :).

> P.S. I'll actually get around to setting up CVS, SSH, etc. on the new
> server this weekend. I promise. Any thing else we need on it?

Joe would be nice, and jed if it's not already on there. Thanks.

-- 
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ {  Rahul -<>- Jain   } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-jain@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.210000101.23.50110101.042
   (c)1996-1999, All rights reserved. Disclaimer available upon request.

From bizzaro at bc.edu  Fri Apr  2 06:17:53 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] genentech
References: <Pine.OSF.4.03.9904012139430.16609-100000@busboy.sped.ukans.edu>
Message-ID: <3704A761.43204D22@bc.edu>

Justin Bradford wrote:
> 
> I pretty sure I'm going to be accepted for an internship at Genentech this
> summer, working in the biocomputing division.

Congratulations!  I know you'll be a great asset to them, as you are to us.

> In the interview, the
> director of this division was asking a lot of questions about Loci, and
> seems very interested.

That's good, I think.

> 
> Basically, they develop bioinformatic tools and client/middleware
> interface software so the researchers can easily access these
> bioinformatic tools and databases from easy-to-use interfaces over the
> network.
> 
> Sound familiar?

A little ;-)

> 
> So far they've basically been doing Perl/CGI access just using netscape.
> They are wanting to start making use of Java applets to make better
> interfaces, too.
> 
> I was having some trouble explaining the Loci design to him, but we're
> basically doing the same thing. Well, except that the Loci design is
> substantially more powerful, flexible, easier to use, and provides better
> client views. After we're done writing it, of course ;)

We're trying.  I'm beginning to think that our time spent thinking and
rethinking the design of Loci has been very beneficial, even though nothing has
been written.  Had we just jumped in and started coding, there were be less of a
difference between Loci and other concoctions.

But of course, vaporware is vaporware ;-)

> 
> I have a friend who used to work out there, and he tells me they have some
> absolutely brilliant people in the biocomputing/bioinformatics division
> (although they're probably doing development on the bioinformatic
> tools rather than the interface/network stuff). Given the overlap and
> general interest they showed towards the Loci concept, it might not be too
> big of a stretch to get genentech interested in the project. Or, at least,
> maybe I can attract a few developers there.

I have no problems with the prospect that a business might get involved.  Harry
Mangalam also mentioned that NCGR might be interested in extending Loci (see Feb
27 e-mail from Harry).  We are licensing Loci as LGPL rather than GPL so that it
can be extended with proprietary programs.  (This does bring up the issue of
using _some_ GPL code in Loci...as with Dia...I'm concerned that we can't have
any GPL code, that it has to be all LGPL.)

Red Hat, for example, was responsible for most of the GNOME development, and it
didn't matter that it was a business.  It is up to a company to use the GNU
license, and by doing so they are disclaiming their "rights" to make the
software closed and proprietary at some point in the future (the GPL and LGPL
are indelible).

> 
> They have a cross-platform concern, too, with Windows and MacOS, and
> probably some unix, desktops. Has anyone heard about a GTK port to MacOS?
> 

I agree with Rahul that a MacOS 10 port would be simpler than the Windows port,
which already exists.  Of course because OS 10 is UNIX-based (it uses the Mach
kernel).

> P.S. I'll actually get around to setting up CVS, SSH, etc. on the new
> server this weekend. I promise. Any thing else we need on it?

I have the RPM's for SSH2 already there.  This is the directory where I like to
archive RPM's:

    /usr/opt/arc/RPMS/

You'll find them there.  As for myself, I will be installing BigBrother (Web
stats) and Mailman (list server).

> 
> P.S.S. Thanks J.W. for starting this project. It played a big part in this
> getting (probably) this internship.

You're very welcome!  This news has made my day, really.  Let me know how it
turns out.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--

From hjm at cx408397-a.irvn1.occa.home.com  Fri Apr  2 12:01:57 1999
From: hjm at cx408397-a.irvn1.occa.home.com (Harry Mangalam)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] genentech
In-Reply-To: <3704A761.43204D22@bc.edu>
Message-ID: <Pine.LNX.4.10.9904020831410.23369-100000@cx408397-a.irvn1.occa.home.com>

Hi All,

2 comments and a disclosure :)

Just a word of caution about ssh2 - it's INCOMPATIBLE with most version 1
ssh's and may cause a lot of problems (I have to use ssh1 to get to a number
of hosts and while I have both on my system, it's one more thing to handle).

Re: NCGR - I've been pretty quiet over this last few weeks writing some of
the user and SQL interface to GeneX (the Gene Expression database that NCGR
is sponsoring).  Hopefully this will be made available on a GPL basis
(almost all the componenent parts are either GPL or otherwise unencumbered
for Academic use (tho perhaps not for Genentech use - not that it should
make any difference to a Genentech)), but at any rate, it's up to NCGR and
UCI as to how it will be released.

NCGR may indeed contribute to the Loci project in either programming support
or direct $, but again, it's trying to survive as a bioinformatics
non-profit (which has some interesting problems associated with it).  They
know about Loci, but they have their fingers in a lot of pies right now and
are trying to get a solid infrastructure up and running.  Those of you
starting to look for a nice place to work could do a whole lot worse than NCGR -
terrific location (Santa Fe, NM), VERY nice, smart people, decent salaries
(especially compared to living standards/cost-of-living), decent endowment
and some good people running things.  Their biz plan is pretty good too.  If
I wasn't locked here because of spousal considerations (at least until
tenure and grant situation improves), I'd be there now.

And in the interests of full disclosure, ;) I myself have started a bioinfo
consulting .com which imposes another set of constraints on what I can
contribute (because of who pays for what development and what I want to 'get
out of my own work' (strange how rigid ideals get surprisingly flexible when
you have kids and a mortgage :)).  I'm trying to munge my biz model to
include and encourage OpenSource, but despite the success of RH, Caldera,
and others, it's not always a workable solution.

There's also the OpenSource, but non-GPL model that .coms like Sendmail and
Scriptics have used and it looks currently that I may be forced into using
their model for the time being.

Cheers,
Harry


On Fri, 2 Apr 1999, J.W. Bizzaro wrote:

/Justin Bradford wrote:
/> 
/> I pretty sure I'm going to be accepted for an internship at Genentech this
/> summer, working in the biocomputing division.
/
/Congratulations!  I know you'll be a great asset to them, as you are to us.
/
/> In the interview, the
/> director of this division was asking a lot of questions about Loci, and
/> seems very interested.
/
/That's good, I think.
/
/> 
/> Basically, they develop bioinformatic tools and client/middleware
/> interface software so the researchers can easily access these
/> bioinformatic tools and databases from easy-to-use interfaces over the
/> network.
/> 
/> Sound familiar?
/
/A little ;-)
/
/> 
/> So far they've basically been doing Perl/CGI access just using netscape.
/> They are wanting to start making use of Java applets to make better
/> interfaces, too.
/> 
/> I was having some trouble explaining the Loci design to him, but we're
/> basically doing the same thing. Well, except that the Loci design is
/> substantially more powerful, flexible, easier to use, and provides better
/> client views. After we're done writing it, of course ;)
/
/We're trying.  I'm beginning to think that our time spent thinking and
/rethinking the design of Loci has been very beneficial, even though nothing has
/been written.  Had we just jumped in and started coding, there were be less of a
/difference between Loci and other concoctions.
/
/But of course, vaporware is vaporware ;-)
/
/> 
/> I have a friend who used to work out there, and he tells me they have some
/> absolutely brilliant people in the biocomputing/bioinformatics division
/> (although they're probably doing development on the bioinformatic
/> tools rather than the interface/network stuff). Given the overlap and
/> general interest they showed towards the Loci concept, it might not be too
/> big of a stretch to get genentech interested in the project. Or, at least,
/> maybe I can attract a few developers there.
/
/I have no problems with the prospect that a business might get involved.  Harry
/Mangalam also mentioned that NCGR might be interested in extending Loci (see Feb
/27 e-mail from Harry).  We are licensing Loci as LGPL rather than GPL so that it
/can be extended with proprietary programs.  (This does bring up the issue of
/using _some_ GPL code in Loci...as with Dia...I'm concerned that we can't have
/any GPL code, that it has to be all LGPL.)
/
/Red Hat, for example, was responsible for most of the GNOME development, and it
/didn't matter that it was a business.  It is up to a company to use the GNU
/license, and by doing so they are disclaiming their "rights" to make the
/software closed and proprietary at some point in the future (the GPL and LGPL
/are indelible).
/
/> 
/> They have a cross-platform concern, too, with Windows and MacOS, and
/> probably some unix, desktops. Has anyone heard about a GTK port to MacOS?
/> 
/
/I agree with Rahul that a MacOS 10 port would be simpler than the Windows port,
/which already exists.  Of course because OS 10 is UNIX-based (it uses the Mach
/kernel).
/
/> P.S. I'll actually get around to setting up CVS, SSH, etc. on the new
/> server this weekend. I promise. Any thing else we need on it?
/
/I have the RPM's for SSH2 already there.  This is the directory where I like to
/archive RPM's:
/
/    /usr/opt/arc/RPMS/
/
/You'll find them there.  As for myself, I will be installing BigBrother (Web
/stats) and Mailman (list server).
/
/> 
/> P.S.S. Thanks J.W. for starting this project. It played a big part in this
/> getting (probably) this internship.
/
/You're very welcome!  This news has made my day, really.  Let me know how it
/turns out.
/
/
/Jeff
/-- 
/J.W. Bizzaro                  mailto:bizzaro@bc.edu
/Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
/
/I have always appreciated your ability to ________, whenever
/there has been a blank to fill.
/--
/

Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com 


From bizzaro at bc.edu  Fri Apr  2 13:54:01 1999
From: bizzaro at bc.edu (bizzaro@bc.edu)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] pictures
Message-ID: <37051249.A5545C1F@bc.edu>

Hello.

I was hoping to get a pictures of all of us for the Development page.  Send me a
pic via e-mail.  I have something in place of your pic that maybe you
won't...well, check it out:

    http://129.63.144.25/loci/devel.html

:-)


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--

From bizzaro at bc.edu  Fri Apr  2 14:37:59 1999
From: bizzaro at bc.edu (bizzaro@bc.edu)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] gui's for command-line progs
Message-ID: <37051C97.E4E637CD@bc.edu>

Locians,

I have seen a few programs that let you make a simple GUI front end for
command-line programs.  A good one, of course, would even have a "wizard" to
help you.  Here is one:

    http://www.fortunecity.com/skyscraper/java/714/ggui/

There was another one called "Gufe", but it seems to have disappeared.

I would like to have something like this for configuring Loci to work with
command-line programs.  A wizard would be helpful for even the author of a
program.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--

From Kenneth_Marx at uml.edu  Sat Apr  3 10:36:19 1999
From: Kenneth_Marx at uml.edu (Kenneth A. Marx)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] genentech
References: <Pine.OSF.4.03.9904012139430.16609-100000@busboy.sped.ukans.edu> <3704A761.43204D22@bc.edu>
Message-ID: <37063573.580F5566@uml.edu>

J.W. Bizzaro wrote:

> Justin Bradford wrote:
> >
> > I pretty sure I'm going to be accepted for an internship at Genentech this
> > summer, working in the biocomputing division.
>
> Congratulations!  I know you'll be a great asset to them, as you are to us.
>
> > In the interview, the
> > director of this division was asking a lot of questions about Loci, and
> > seems very interested.
>
> That's good, I think.
>
> >
> > Basically, they develop bioinformatic tools and client/middleware
> > interface software so the researchers can easily access these
> > bioinformatic tools and databases from easy-to-use interfaces over the
> > network.
> >
> > Sound familiar?
>
> A little ;-)
>
> >
> > So far they've basically been doing Perl/CGI access just using netscape.
> > They are wanting to start making use of Java applets to make better
> > interfaces, too.
> >
> > I was having some trouble explaining the Loci design to him, but we're
> > basically doing the same thing. Well, except that the Loci design is
> > substantially more powerful, flexible, easier to use, and provides better
> > client views. After we're done writing it, of course ;)
>
> We're trying.  I'm beginning to think that our time spent thinking and
> rethinking the design of Loci has been very beneficial, even though nothing has
> been written.  Had we just jumped in and started coding, there were be less of a
> difference between Loci and other concoctions.
>
> But of course, vaporware is vaporware ;-)
>
> >
> > I have a friend who used to work out there, and he tells me they have some
> > absolutely brilliant people in the biocomputing/bioinformatics division
> > (although they're probably doing development on the bioinformatic
> > tools rather than the interface/network stuff). Given the overlap and
> > general interest they showed towards the Loci concept, it might not be too
> > big of a stretch to get genentech interested in the project. Or, at least,
> > maybe I can attract a few developers there.
>
> I have no problems with the prospect that a business might get involved.  Harry
> Mangalam also mentioned that NCGR might be interested in extending Loci (see Feb
> 27 e-mail from Harry).  We are licensing Loci as LGPL rather than GPL so that it
> can be extended with proprietary programs.  (This does bring up the issue of
> using _some_ GPL code in Loci...as with Dia...I'm concerned that we can't have
> any GPL code, that it has to be all LGPL.)
>
> Red Hat, for example, was responsible for most of the GNOME development, and it
> didn't matter that it was a business.  It is up to a company to use the GNU
> license, and by doing so they are disclaiming their "rights" to make the
> software closed and proprietary at some point in the future (the GPL and LGPL
> are indelible).
>
> >
> > They have a cross-platform concern, too, with Windows and MacOS, and
> > probably some unix, desktops. Has anyone heard about a GTK port to MacOS?
> >
>
> I agree with Rahul that a MacOS 10 port would be simpler than the Windows port,
> which already exists.  Of course because OS 10 is UNIX-based (it uses the Mach
> kernel).
>
> > P.S. I'll actually get around to setting up CVS, SSH, etc. on the new
> > server this weekend. I promise. Any thing else we need on it?
>
> I have the RPM's for SSH2 already there.  This is the directory where I like to
> archive RPM's:
>
>     /usr/opt/arc/RPMS/
>
> You'll find them there.  As for myself, I will be installing BigBrother (Web
> stats) and Mailman (list server).
>
> >
> > P.S.S. Thanks J.W. for starting this project. It played a big part in this
> > getting (probably) this internship.
>
> You're very welcome!  This news has made my day, really.  Let me know how it
> turns out.
>
> Jeff
> --
> J.W. Bizzaro                  mailto:bizzaro@bc.edu
> Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
>
> I have always appreciated your ability to ________, whenever
> there has been a blank to fill.
> --

To all:

I'm glad to see this enterprise succeeding and Justin getting a job............Ken
Marx




From bizzaro at bc.edu  Sat Apr  3 19:18:38 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] The Loci Project
Message-ID: <3706AFDE.798AF609@bc.edu>

Hello Grail developers!

The Loci Project developers have been seriously discussing the use of Grail in
our project.  Let me tell you a bit about the project.

Loci is a framework for connecting various "computational biology" programs
together via Python and XML.  We are using a Python workflow and object server
called "PAOS", by Carlos Maltzahn, who has joined us.  And Loci will provide a
highly graphical front end to command-line programs by using James Henstridge's
PyGTK and PyGNOME bindings.

A "locus" is any tool in Loci, either graphical or analytical.  Each "GUI locus"
will essentially be an XML browser, but not a generic browser requiring XSL's. 
We are working on our own DTD's for the description of biomolecular data, and
the GUI "loci" will be made to display those.

But this is where it gets real fun.  The XML (called LocusML) will not only
describe the biological data but embed a Python script to make the GUI.  So each
GUI locus is a skeleton (written in C-GTK or PyGTK) that can read a Python
script that calls on C-GTK "biowidgets" and PyGTK widgets.  The result is a
browser that can run applets in its window.

Sound familiar?

PAOS really becomes important because we plan to have command-line programs and
databases reside on servers distributed throughout the Internet.  What happens
is a Loci user requests an analysis of some data, PAOS sends the request to the
appropriate server, the command-line program performs the analysis, the server
sends the analysis back BUT also attaches the appropriate GUI for
display/visualization, and finally the GUI locus is brought up to display the
GUI (applet) and the analysis.

I can't stress enough how VERY unique and complex this project is.  So rather
than starting from scratch, we know we should make use of other programs that
match certain parts of Loci.  Of course Grail is something like the GUI locus,
with the exception that the locus uses XML and PyGTK.  But I did just see a
message on this list about someone wanting to switch Tkinter for PyGTK ;-)

The project has obviously just begun.  We have more than one dozen "biohackers"
that have been helping hammer out the design and are ready to begin coding.  If
some Grail developers would like to take Grail in this new direction, we would
be ecstatic!

The Loci Project is the first project of an upstart scientific organization
called "The Open Lab".  The Lab is Internet-based and developing open-source
software, in addition to carrying out computational biology research.  It is
unfunded at the time, but that may change since we have routes to fund
scientific projects.

For more information on Loci, please visit our (incomplete) Web site:

    http://129.63.144.25/loci/

and the mailing list archive:

    http://toaster.sped.ukans.edu/tulip-list/

If you would like to help implement Loci, PLEASE contact me (Jeff):

    bizzaro@bc.edu


Thank you!
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Sat Apr  3 19:40:59 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] about the last message
Message-ID: <3706B51B.89602E07@bc.edu>

Locians,

I found out that the Grail project is now officially over.  They just released
version 0.6 and have "changed the license" the allow derivative works.

As we mentioned on this list, Grail is 100% Python and reads Python scripts to
make applets in the browser window.  This is very much like our plan for GUI
loci.

I am inviting the Grail developers to join, because there appears to be some
interest in continuing the development in some direction.  Of course it would be
most beneficial for us to get the authors to help implement their own (very
impressive) program.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/

I have always appreciated your ability to ________, whenever
there has been a blank to fill.
--

From bizzaro at bc.edu  Sun Apr  4 00:25:57 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] Re: intro
References: <Pine.GSO.3.96.990403232752.25594A-100000@sbskiena>
Message-ID: <3706F7E5.1A758BFB@bc.edu>

Hi Barry!

barry cohen wrote:
> 
> Hi.
> 
> I just ran across the Loci page, and like what's there.

I'm happy to hear it.

> I'm
> doing computational biology (PhD program) at SUNYSB. (My
> advisor and I have a paper at Recomb99 next week on a topic
> in combinatorial chemistry. It's on my web page
> www.cs.sunysb/~bcohen.)

Lucky guy.  I wish I were going ;-)

Is your Ph.D. in Computational Biology or Computer Science?

> 
> I'd like to help with development of your project, but
> am not in a position to make a time commitment right now.

We'd like to have you help.  Don't worry about the time commitment.  We are
taking things very slowly, but we want many others to join so that we can get
more accomplished: Many hands make for light work.

> I do most of my coding in C/C++ under NT.

Okay.  I used to program in Windows too.

> I have a Linux
> installation on my machine, but have gotten used to a
> graphical interface, and have been waiting for one to
> stabilize under Linux.

Well, I'm a big GTK/GNOME advocate.  It's not entirely stable, as far as Linux
is concerned, but probably more stable than Windows.

> 
> Perhaps you could give some feedback about how best
> to get up to speed on the state of development --
> i.e., framework discusssion and coding -- of Loci.

Most definitely take a look at the mailing list archive, especially the more
recent e-mails: 

http://toaster.sped.ukans.edu/tulip-list/ 

You will also want to be on the list, so send an e-mail to this address: 

    majordomo@busboy.sped.ukans.edu 

with this text in the body of the message: 

    subscribe tulip-list 

If you want to find out more about the GUI tools we're using, check out this
site:

    http://www.uml.edu/Dept/Chem/BICGroup/PyGTools/

Do you want an account our Linux server?


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr  5 09:49:36 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] about the last message
References: <3706B51B.89602E07@bc.edu> <370A00AD.C5A7BC40@uml.edu>
Message-ID: <3708BF70.603D0625@bc.edu>

"Kenneth A. Marx" wrote:

> Locians,
> 
> I believe there is a company formed by the early Grail developers that is marketing
> the Grail package. So, I don't know whether Jeff is referring to that or to the
> internal development within Oak Ridge that may in fact have ended.............Ken
> Marx

We may be talking about two different programs.  The Grail I was talking about
is a Web browser sponsored by the Corporation for National Research Initiatives
(CNRI):

    http://www.cnri.reston.va.us/about_cnri.html

What is the Oak Ridge Grail?


Jeff
bizzaro@bc.edu

From David.Lapointe at umassmed.edu  Mon Apr  5 09:55:51 1999
From: David.Lapointe at umassmed.edu (Lapointe, David)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] about the last message
Message-ID: <93307F07DE63D211B2F30000F808E9E525D758@edunivexch02.umassmed.edu>

The Oak Ridge GRAIL is a neural net program (actually several versions) for
finding coding regions in dna sequences.

See http://compbio.ornl.gov/ for Grail and other tools.

David

> What is the Oak Ridge Grail?


> Jeff
> bizzaro@bc.edu

From Kenneth_Marx at uml.edu  Mon Apr  5 10:04:13 1999
From: Kenneth_Marx at uml.edu (Kenneth A. Marx)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] about the last message
References: <3706B51B.89602E07@bc.edu> <370A00AD.C5A7BC40@uml.edu> <3708BF70.603D0625@bc.edu>
Message-ID: <3708C2DD.18D543B2@uml.edu>

J.W. Bizzaro wrote:

> "Kenneth A. Marx" wrote:
>
> > Locians,
> >
> > I believe there is a company formed by the early Grail developers that is marketing
> > the Grail package. So, I don't know whether Jeff is referring to that or to the
> > internal development within Oak Ridge that may in fact have ended.............Ken
> > Marx
>
> We may be talking about two different programs.  The Grail I was talking about
> is a Web browser sponsored by the Corporation for National Research Initiatives
> (CNRI):
>
>     http://www.cnri.reston.va.us/about_cnri.html
>
> What is the Oak Ridge Grail?
>
> Jeff
> bizzaro@bc.edu

Locians,

Yes, we are talking about two different GRAILS.  GRAIL from Oak Ridge is a
bioinformatics package that was one of the first to incorporate a suite of tools for
gene identigfication. There is a company, spun off from Oak Ridge, that maintains and
extends GRAIL. I don't know much more. Sorry to have confused anyone...........Ken





From bizzaro at bc.edu  Mon Apr  5 11:26:20 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] server name
Message-ID: <3708D61C.28B7491F@bc.edu>

FYI,

The server now has a DNS entry for

    bioinformatics.org

We don't have to type the IP anymore.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From Kenneth_Marx at uml.edu  Tue Apr  6 08:40:13 1999
From: Kenneth_Marx at uml.edu (Kenneth A. Marx)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] about the last message
References: <3706B51B.89602E07@bc.edu>
Message-ID: <370A00AD.C5A7BC40@uml.edu>

J.W. Bizzaro wrote:

> Locians,
>
> I found out that the Grail project is now officially over.  They just released
> version 0.6 and have "changed the license" the allow derivative works.
>
> As we mentioned on this list, Grail is 100% Python and reads Python scripts to
> make applets in the browser window.  This is very much like our plan for GUI
> loci.
>
> I am inviting the Grail developers to join, because there appears to be some
> interest in continuing the development in some direction.  Of course it would be
> most beneficial for us to get the authors to help implement their own (very
> impressive) program.
>
> Jeff
> --
> J.W. Bizzaro                  mailto:bizzaro@bc.edu
> Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
>
> I have always appreciated your ability to ________, whenever
> there has been a blank to fill.
> --

Locians,

I believe there is a company formed by the early Grail developers that is marketing
the Grail package. So, I don't know whether Jeff is referring to that or to the
internal development within Oak Ridge that may in fact have ended.............Ken
Marx





From hortiz at neurobio.upr.clu.edu  Thu Apr  8 13:54:26 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] What about viewers? 
In-Reply-To: Your message of "Thu, 08 Apr 1999 09:49:41 -0400."
             <370CB3F5.2ACA432C@bc.edu> 
Message-ID: <199904081754.NAA20674@chimbo.neurobio.upr.clu.edu>

>     Do you think there should be a layer of Python that sits between the
>     skeleton locus (or locus browser) and the low-level code that will
>     complete the viewer.
> 
>     What in fact are you calling a "viewer"?  Is it the browser + script +
>     megawidgets, as I've been saying, or do you think the user will be
>     downloading self-contained executable programs, as Netscape does?

We can define a viewer like this:

viewer locus: a program that uses the Benchtop API to display a bicml entity 
in a Benchtop (gnome?) canvas.

OR

external viewer: a standalone program (binary, interpreted script, ...) that 
can display a bicml entity in a window.

I think we should have the capability of using both.  That way we can just 
steal viewers wholesale (like NCBI's Cn3D structure viewer).  If we could find 
a way of wrapping up a standalone program so that it displays inside a 
Benchtop canvas it would be even more awesome (compose a figure with the 
sequence and structure on the same "page").  Some window manager panels like 
FvwmGoodStuff, and the Siag spreadsheet can "swallow" X Window apps like this. 
 Siag can even print spreadsheets with embedded apps.

OK, so native viewer loci should display on the benchtop, with full 
interactivity.  At first, I guess these must be python scripts, perhaps using 
some Locus-megawidget library.  If we can export some kind of API to the 
benchtop, perhaps they could even be written in other languages.

External viewers would not have the ability to display on the bechtop, or be 
composited into figures, but would instead interact with the user in their own 
window, and be responsible for printing etc.  Note that external viewers must 
be able to understand and display a bicml entity, but we could use some kind 
of translation locus to wrap an external viewer that read CML in a BICML -> 
CML translator.

A "swallowed" external viewer could display on the benchtop, and interact with 
the user, but might look "bolted on" instead of publication quality.

> > The app broker can
> > return a list like
> > 
> > python - ftp://bar.baz/pub/viewer.py
> > compressed-multifile-python-tarfile - ftp://bar.baz/pub/fancy-viewer.tar.gz
> > i386/libc6/rpm - ftp://rpmfind.net/libc6/i386/viewer1.0-2.rpm
> > 
> > and the user can select which one he wants to retreive.
> 
> Good idea.  But these aren't executables, are they?

Wht not?  As long as it can display a bicml entity, it's a viewer.  If it 
can't interact directly with the benchtop, it's an external viewer.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From bizzaro at bc.edu  Thu Apr  8 18:10:46 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] What about viewers?
References: <199904081754.NAA20674@chimbo.neurobio.upr.clu.edu>
Message-ID: <370D2965.7C0BD312@bc.edu>

Humberto,

I think we agree on the whole concept of a viewer: that there are internal and
external viewers.  It is important for the growth of Loci that it can be
expanded with viewers that do not follow the Loci standard of Python-GTK scripts
running in a "browser" (skeleton locus) and communicating with the Benchtop. 
Yes, the minimal requirement would be that it can manage the "LocusML" ;-)

I once used an analogy to basketball players passing around a ball.  The players
are the loci, the ball is the locusml, and maybe the path the ball takes is
PAOS.  I think when we're talking about internal and external viewers, it's like
a player from another team joins in.  He may not be on the team, but as long as
he can pass a ball, he is accepted.

What I have been discussing in these latter messages, is the internal viewer.  I
think we have to focus on that, and as things progress, we can look at how
others can implement external viewers.  You see, to manage this large project
more easily, I have defined a Loci "core" as being this pure, homogenous system
of basic tools.  I don't care if someone wants to add a Perl, or Java, or Tom
program at some point.  We do need to make sure it is possible.  But I want us
to develop this homogenous system to begin with.  This will define Loci.  If we
start with a mixture of languages and systems, it may be too much of a tower of
babel for us to manage and convince others that it is a standard they should
follow.

I was hoping primarily to connect command-line programs together and give them a
GUI.  I understand the need to allow other GUI programs to work with Loci.  But
I think the result would be a "bolted on" look, to quote someone I know ;-)  I
like the idea of a swallowed executable.  But I do think that anything that does
not maintain the look and feel of the Loci interface should be frowned upon by
us.  There are very good reasons to support a consistent L&F, the best one is
that users would be confused if presented with something very different each
time a window pops up.

Besides, if an external viewer is a self-contained executable with its own GUI
and printing capabilities, the reason for plugging into Loci becomes highly
diminished, especially if it can't communicate with the FigBuilder either.

> viewer locus: a program that uses the Benchtop API to display a bicml entity
> in a Benchtop (gnome?) canvas.

The viewer locus will display boxes on the Work Flow Diagram and figure in both
its own window and the FigBuilder window.

> external viewer: a standalone program (binary, interpreted script, ...) that
> can display a bicml entity in a window.

Yep.

> I think we should have the capability of using both.  That way we can just
> steal viewers wholesale (like NCBI's Cn3D structure viewer).

After the core is developed and well defined, this may be important for the
growth of Loci.

> If we could find
> a way of wrapping up a standalone program so that it displays inside a
> Benchtop canvas it would be even more awesome (compose a figure with the
> sequence and structure on the same "page").

I suppose by "Benchtop canvas" you mean any Loci canvas that can show locusml. 
The way I've been defining it is the canvas that displays the WFD and
drag-and-drop representations of documents, etc.

> Some window manager panels like
> FvwmGoodStuff, and the Siag spreadsheet can "swallow" X Window apps like this.
>  Siag can even print spreadsheets with embedded apps.

I'd like to look into this.

> 
> OK, so native viewer loci should display on the benchtop, with full
> interactivity.  At first, I guess these must be python scripts, perhaps using
> some Locus-megawidget library.  If we can export some kind of API to the
> benchtop, perhaps they could even be written in other languages.

Not as part of the core, but eventually.  You can see that there is no clear
line between internal and external viewers.  I would define a "core viewer" as
being a C-GTK locusml browser that can display C-GTK and PyGTK megawidgets using
a Python script.  Anything else is non-core.

> 
> External viewers would not have the ability to display on the bechtop, or be
> composited into figures, but would instead interact with the user in their own
> window, and be responsible for printing etc.  Note that external viewers must
> be able to understand and display a bicml entity, but we could use some kind
> of translation locus to wrap an external viewer that read CML in a BICML ->
> CML translator.
>
> A "swallowed" external viewer could display on the benchtop, and interact with
> the user, but might look "bolted on" instead of publication quality.

Yes, some of the many ways it seems we could make external (non-core) viewers.

> Wht not?  As long as it can display a bicml entity, it's a viewer.  If it
> can't interact directly with the benchtop, it's an external viewer.

Or external to a greater degree ;-)


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Thu Apr  8 18:53:28 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:27 2006
Subject: [Pipet Devel] RPM for the local app broker?
Message-ID: <370D3368.2276FFD6@bc.edu>

Humberto wrote:
>
> When I was writing the proposal, I thought it wold be neat to have a file type
> like "multifile python module" that contained the source to a viewer, we could
> also have a type like "i386/libc6/rpm" for a viewer.  The app broker can
> return a list like
> 
> python - ftp://bar.baz/pub/viewer.py
> compressed-multifile-python-tarfile - ftp://bar.baz/pub/fancy-viewer.tar.gz
> i386/libc6/rpm - ftp://rpmfind.net/libc6/i386/viewer1.0-2.rpm
> 
> and the user can select which one he wants to retreive.

This brings up an interesting thought: How about using RPM or a modified version
of it for our locus database (managed by the local app broker).

If you think about it, we need some system to

    (1) Install new loci
    (2) Upgrade old loci
    (3) Remove loci
    (4) Check version numbers
    (5) Check dependencies
    (6) and store all sorts of info on the loci

That sounds like RPM to me.

Now, I'm thinking that we could actually use RPM, but there would be two
problems:

    (1) RPM installs etc. under root
    (2) Not every UNIX system uses RPM, in fact only about half of the Linux
systems

But what if we modified it (it's GPL) to install etc. in the user's directory?

Another advantage to RPM is that it compresses the package, which will make it
easier to download those pesty viewers.  So we'll define...

    i386/libc6/locus - ftp://locusfind.net/libc6/i386/viewer1.0-2.locus

Oh yeah, and we can use the RPM-to-HTML rpmfind database for browsing loci
available on the Web.


So, WHAT DA YA THINK?


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Thu Apr  8 19:13:14 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] What about viewers?
References: <199904081754.NAA20674@chimbo.neurobio.upr.clu.edu> <370D2965.7C0BD312@bc.edu>
Message-ID: <370D380A.7E6030F2@bc.edu>

"J.W. Bizzaro" wrote:
> 
> I would define a "core viewer" as
> being a C-GTK locusml browser that can display C-GTK and PyGTK megawidgets using
> a Python script.

You know, we can really makes things simple for the locus developer by having a
"locus browser".  As I mentioned once before, the browser would have all of the
code required to communicate using the Loci infrastructure.  It really only
needs a Python script to call on the megawidgets.

    Viewer = Browser + pyscript + megawidgets;

I'm also thinking that we can provide the browser with buttons, like a Web
browser:

    Back
    Forward
    Save
    Print

Any others?

What I'm calling "Back" and "Forward" though does not change the view in the
browser's window, it moves the user back and forth along the workpath (shown on
the WFD), popping up the appropriate viewer.  I want one browser per view.  I
really never liked the fact that HTML browsers make you scroll up and down, and
you lose the page when you select a link.  This leaves one feeling a bit
disoriented.  I think the way I'd like to manage viewers and the WFD will be
considerable less disorienting.

Another feature for the browser is a standard control panel that the developer
can use as a place for custom controls.  These can be written into the
megawidgets and placed via pyscript.

Any other thoughts?


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hinsen at cnrs-orleans.fr  Fri Apr  9 04:53:26 1999
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] RPM for the local app broker?
In-Reply-To: <370D3368.2276FFD6@bc.edu> (bizzaro@bc.edu)
References: <370D3368.2276FFD6@bc.edu>
Message-ID: <199904090853.KAA02922@chinon.cnrs-orleans.fr>

> Now, I'm thinking that we could actually use RPM, but there would be two
> problems:
> 
>     (1) RPM installs etc. under root
>     (2) Not every UNIX system uses RPM, in fact only about half of the Linux
> systems
> 
> But what if we modified it (it's GPL) to install etc. in the user's directory?

No need to modify anything; RPM can install any file anywhere.
And it should work on any Unix system. In fact, the RPM-based Linux
distributions could be the most difficult cases, because any
Loci use of RPM would have to be compatible with the general system
installation!

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

From Thomas.Sicheritz at molbio.uu.se  Fri Apr  9 07:27:44 1999
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] RPM and RECOMB99
In-Reply-To: <370D3368.2276FFD6@bc.edu>
References: <370D3368.2276FFD6@bc.edu>
Message-ID: <14093.57544.756968.229617@beagle.bmc.uu.se>

J.W. Bizzaro writes:
 > Now, I'm thinking that we could actually use RPM, but there would be two
 > problems:
 > 
 >     (1) RPM installs etc. under root
 >     (2) Not every UNIX system uses RPM, in fact only about half of the Linux
 > systems
 > 
 > But what if we modified it (it's GPL) to install etc. in the user's directory?

What about debians package manager ? - debian is the only true GNU Linux
distribution - and the "alien" script can switch between rpm/deb/tar/cpio

 > Oh yeah, and we can use the RPM-to-HTML rpmfind database for browsing loci
 > available on the Web.
sounds almost like an onliner ...  is it possible to use python for
perl-like oneliners ?


======================================================================
= RECOMB99
==========
Now i have finaly managed to get my poster out of the #$#%# printer...
- in one hour I am catching  plane to the bioinformatics meeting in
Lyon/france ... how many Loci'ers am I going to see there ?

I am staying at:
Le Meridien, part Dieu
129 Rue Servient-part-dieu

- but most of the time I'll be nailed to my poster 
(Title: Comparative Analysis of Genomic Architectures) 


Lets try to meet and compile a loci_french_wine_db.py module :-)

c ya
-thomas


-- 
Sicheritz Ponten Thomas E.  Department of Molecular Biology
blippblopp@linux.nu         BMC, Uppsala University
BMC:  +46 18 4714214        BOX 590 S-751 24 UPPSALA Sweden
Fax   +46 18  557723        http://evolution.bmc.uu.se/~thomas
Molecular Tcl:   http://evolution.bmc.uu.se/~thomas/tcl
Molecular Linux: http://evolution.bmc.uu.se/~thomas/mol_linux

	De Chelonian Mobile ... The Turtle Moves ...

From bizzaro at bc.edu  Fri Apr  9 09:28:13 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] RPM for the local app broker?
References: <370D3368.2276FFD6@bc.edu> <199904090853.KAA02922@chinon.cnrs-orleans.fr>
Message-ID: <370E006D.A17A85E6@bc.edu>

Konrad Hinsen wrote:
>
> > But what if we modified it (it's GPL) to install etc. in the user's directory?
> 
> No need to modify anything; RPM can install any file anywhere.

I meant to say that RPM can only install when it is run by root.  If the user
does not have access to the root account, he cannot use RPM to put anything
anywhere, not even in his own directory.

So this is the question: Do we want loci (locuses) to be installed by the user
in the user's directory, or do we want installation to _require_ a root account?

The first case is acceptable for UNIX; anyone can execute programs in their own
account.  But if we use RPM, it would have to be changed to allow this.  BTW,
does Debian allow user installs?

In the second case, we would not have to change RPM.

> And it should work on any Unix system. In fact, the RPM-based Linux
> distributions could be the most difficult cases, because any
> Loci use of RPM would have to be compatible with the general system
> installation!

There probably won't be any conflicts with the Linux installations, but it could
be a "mess" having half of the rpm's be Loci widgets rather than programs.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Fri Apr  9 09:38:23 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] RPM and RECOMB99
References: <370D3368.2276FFD6@bc.edu> <14093.57544.756968.229617@beagle.bmc.uu.se>
Message-ID: <370E02CF.588A7F8C@bc.edu>

Thomas.Sicheritz@molbio.uu.se wrote:
> 
> What about debians package manager ? - debian is the only true GNU Linux
> distribution - and the "alien" script can switch between rpm/deb/tar/cpio

I have never used the "DPM".  I have heard that it is better than RPM.  Does
anyone else have thoughts on DPM vs. RPM?

>  > Oh yeah, and we can use the RPM-to-HTML rpmfind database for browsing loci
>  > available on the Web.
> sounds almost like an onliner ...  is it possible to use python for
> perl-like oneliners ?

Have you seen rpm2html?  It's pretty amazing.  I don't know if debian has
something like this:

    http://rpmfind.net/linux/RPM/

I'd love to use this for Loci.

What would be even nicer, which I have heard of, is a system that uses RPM and
an online database to check if your installation needs to be updated.  It then
gets all the RPMS for you and installs them.

> ======================================================================
> = RECOMB99
> ==========
> Now i have finaly managed to get my poster out of the #$#%# printer...
> - in one hour I am catching  plane to the bioinformatics meeting in
> Lyon/france ... how many Loci'ers am I going to see there ?

Not me, I'm sorry to say.  Maybe next year.  How about Konrad or Raynald?


Vive Le France!
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Fri Apr  9 12:54:09 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] RPM for the local app broker?
References: <370D3368.2276FFD6@bc.edu> <199904090853.KAA02922@chinon.cnrs-orleans.fr> <370E006D.A17A85E6@bc.edu>
Message-ID: <370E30B1.4931FEB3@bc.edu>

"J.W. Bizzaro" wrote:
> 
> I meant to say that RPM can only install when it is run by root.  If the user
> does not have access to the root account, he cannot use RPM to put anything
> anywhere, not even in his own directory.

Good news!

I just tried a few things with RPM.  You can change what RPM considers the root
directory (/) to any other directory and use a database other than the "main"
one at /var/lib/rpm/packages.rpm.  These flags are used to do this:

    --root
    --dbpath

The user can otherwise "run" RPM without the root account.  The flags will let
him set up an RPM installation wherever he wants it.

So it looks like we _can_ use RPM _unmodified_!  I would, however, like to use
the extension ".locus" rather than ".rpm" for the loci packages.

And maybe we can someday have a URL: locusfind.net :-)


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Fri Apr  9 18:14:39 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] home pages
Message-ID: <370E7BCF.E9866053@bc.edu>

If anyone would like a personal home page on theopenlab, let me know.

mkdir under your home directory called "html-public".

chmod of the directory to "drwxrwxr-x".

Don't go hog wild on the disk space please.


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hortiz at neurobio.upr.clu.edu  Mon Apr 12 14:16:44 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] What about viewers? 
In-Reply-To: Your message of "Thu, 08 Apr 1999 18:10:46 -0400."
             <370D2965.7C0BD312@bc.edu> 
Message-ID: <199904121816.OAA15694@chimbo.neurobio.upr.clu.edu>

> > viewer locus: a program that uses the Benchtop API to display a bicml entity
> > in a Benchtop (gnome?) canvas.
> 
> The viewer locus will display boxes on the Work Flow Diagram and figure in both
> its own window and the FigBuilder window.

I was a little confused about the WorkBench.  I thought figures were displayed 
in the Benchtop.

If I understand you correctly, there are three requirements for display loci:

present a control in the WFD on the Benchtop

present a figure in the FigBuilder

present a GUI in it's own window

bizzaro@bc.edu said:
> You know, we can really makes things simple for the locus developer by
> having a "locus browser".  As I mentioned once before, the browser
> would have all of the code required to communicate using the Loci
> infrastructure.  It really only needs a Python script to call on the
> megawidgets.

>     Viewer = Browser + pyscript + megawidgets; 

So this would make the design like so:

Workbench = Browser + Benchtop + FigBuilder

browser = code to handle display, benchtop controls, export to figbuilder.

display locus = plugin for browser code to manage specific LocusML entities

We could colapse this further by making the browser == figbuilder.

So all loci display directly on the figbuilder canvas, using loci display API, 
and present controls on the benchtop using loci control API.

Megawidgets could be provided that are written to the locus API, and are 
controlable with the benchtop API, providing programmers with building blocks 
for new display loci.

Since the benchtop must have some way of controling a locus interactively, we 
can use this same mechanism to script a locus.

A locus that conforms to the display API and the control API, can now become a 
megawidget.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From jabbo at mindless.com  Mon Apr 12 16:11:39 1999
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] AMMP & 3D veiwers (Greg & SooHaeng)
References: <37128A1A.EEC4AEB2@bc.edu>
Message-ID: <3712537B.A05E0ED0@mindless.com>

Hey, good call.  I was just looking at this today... it's in C (not C++)
and that's what got me interested in it.  Eeeerie...

My project at work is running late (Oracle is fun like that, and it's
always helpful when the specifications change two days before you're
supposed to release it), but I got *some* work done on the Glade layout
for my little translator program.  I will post the code to the mailing
list as soon as it's done, hopefully Wednesday, and perhaps the
experienced old hands -- Humberto, Harry, etc. -- can point out all the
ways in which I have demonstrated my incompetence.

ps.  Does anyone know of an old-style C++ preprocessor that generates C
code as its output, like it was when C++ was first introduced?  I think
I may be able to pick apart chunks of VTK in this fashion...

-- 
    "Indeed, it would not be an exaggeration to describe 
     the history of the computer industry for the past
     decade as a massive attempt to keep up with Apple."
                                  -- Byte, 12/94

From bizzaro at bc.edu  Mon Apr 12 17:49:09 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] What about viewers?
References: <199904121816.OAA15694@chimbo.neurobio.upr.clu.edu>
Message-ID: <37126A55.2A15DEB0@bc.edu>

Humberto Ortiz Zuazaga wrote:
> 
> I was a little confused about the WorkBench.  I thought figures were displayed
> in the Benchtop.

I think you mean "Workspace".  Workspace = Benchtop + FigBuilder (+ maybe any
GUI locus like viewers and editors)

> If I understand you correctly, there are three requirements for display loci:

("Viewer loci")

> present a control in the WFD on the Benchtop

Present at least enough information so that the WFD can make a control interface
with boxes, etc.

> present a figure in the FigBuilder

Yes.

> present a GUI in it's own window

If we are talking about a Viewer GUI locus rather than an Editor GUI locus, the
GUI == the figure + some extra buttons, etc. (or simply the "GUImegawidgets").

But the purpose of the FigBuilder is to _combine_ figures.  Otherwise, the
viewers will display the parts of a figure relating only to the data being
viewed (e.g., sequence, structure).

> So this would make the design like so:
> 
> Workbench = Browser + Benchtop + FigBuilder

or Workspace = (Viewers, which contain Browsers + Editors) + Benchtop +
FigBuilder

The glossary though just says Benchtop + FigBuilder.

> browser = code to handle display, benchtop controls, export to figbuilder.

Pretty much anything that would be in common between viewers.  But like a "Web
browser".

> display locus = plugin for browser code to manage specific LocusML entities

I haven't given this part a name, but it is Pythonscript + GUImegawidgets.

> We could colapse this further by making the browser == figbuilder.

I think you mean Viewer == FigBuilder (Browser is part of the Viewer).  As I
mentioned above, they will both display figures, but the Viewers will display
one figure.  The FigBuilder will display many and be a place to put text
comments, etc., like a vector drawing program.

I also want viewers to be transient (they will pop up and disappear along the
workpath).  The FigBuilder can stay open so that the final product (the figure)
can be worked on all the way through the workpath of the user's project.

> So all loci display directly on the figbuilder canvas, using loci display API,
> and present controls on the benchtop using loci control API.

Yes.  But "display API" == Viewer API.  I just don't want to add "display" as
another term, when it means the same thing to us as "view".

> Megawidgets could be provided that are written to the locus API, and are
> controlable with the benchtop API, providing programmers with building blocks
> for new display loci.

By "locus API", do you mean "Viewer API"?  If so, that is correct.

> Since the benchtop must have some way of controling a locus interactively, we
> can use this same mechanism to script a locus.

Do you mean script the workflow?  That's right.  And PAOS is "the mechanism".

> A locus that conforms to the display API and the control API, can now become a
> megawidget.

The Browser conforms to the Viewer API and control API.  I guess the other parts
of the Viewer (Pythonscript + megawidgets) use the Viewer API, if you are
calling them a "locus".  Any high-level repackaging (other than with the Browser
itself) of megawidgets can be called a "megawidget", if this is what you are
talking about.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr 12 18:43:13 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] GILT for viewers and FigBuilder
Message-ID: <37127701.8D3552CF@bc.edu>

Locians,

Building upon our repository of smaller projects that can be incorporated into
Loci, here is some information on the "GILT" project:

    http://www.vicksburg.com/~phoenix/main.html

GILT is a vector drawing program based on The GIMP and OpenGL.

We need a vector drawing engine for the viewers and the FigBuilder.  In the case
of the viewers, it may be easier to turn a vector drawing program into a "Locus
ML browser" than to turn an HTML browser into one.

Here is a screenshot:

    http://www.vicksburg.com/~phoenix/GILT3.html

I am also pretty happy with the choice of RPM for the AppBrokers and Dia for the
Benchtop.  All of these are GPL.

Any other candidates?


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr 12 18:56:48 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] GILT for viewers and FigBuilder
References: <37127701.8D3552CF@bc.edu>
Message-ID: <37127A30.128E6D2F@bc.edu>

Just thinking,

The importance of GUImegawidgets becomes diminished if we can write Python
scripts to control a vector drawing program like GILT.

I personally would prefer small Python GUIscripts to large binary
GUImegawidgets.  But some binary widgets may still be required.

This does not affect our plan for the AppBrokers and RPM, because we can still
download the GUI as Humberto suggested, and we will need to keep track of
versions.


Jeff
bizzaro@bc.edu


"J.W. Bizzaro" wrote:
> 
> Locians,
> 
> Building upon our repository of smaller projects that can be incorporated into
> Loci, here is some information on the "GILT" project:
> 
>     http://www.vicksburg.com/~phoenix/main.html
> 
> GILT is a vector drawing program based on The GIMP and OpenGL.
> 
> We need a vector drawing engine for the viewers and the FigBuilder.  In the case
> of the viewers, it may be easier to turn a vector drawing program into a "Locus
> ML browser" than to turn an HTML browser into one.
> 
> Here is a screenshot:
> 
>     http://www.vicksburg.com/~phoenix/GILT3.html
> 
> I am also pretty happy with the choice of RPM for the AppBrokers and Dia for the
> Benchtop.  All of these are GPL.
> 
> Any other candidates?
> 
> Jeff
> --
> J.W. Bizzaro                  mailto:bizzaro@bc.edu
> Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
> --

-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr 12 20:04:42 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] AMMP & 3D veiwers (Greg & SooHaeng)
Message-ID: <37128A1A.EEC4AEB2@bc.edu>

Greg and SooHaeng,

If you have been following some of our recent discussions, you know that we will
not be making stand-alone programs.  Our molecule viewer will be like a plug-in
to the Loci Browser.

What we need then is a plug-in engine for drawing molecules in OpenGL.  I know
that SooHaeng has DND, which will draw some simple molecule representations. 
Greg has experience with OpenGL.  What we are missing are some more elaborate
representations.

I found a GPL program that does some very nice representations, but it has no
real GUI.  It's called, "Another Molecular Mechanics Program":

    http://asterix.jci.tju.edu/ammp.html

Can we make this a plug-in to the Loci Browser?  I would like help with this,
Greg and SooHaeng.

SooHaeng, parts of AMMP might be useful for DND too.

Greg, I need your help with an OpenGL trick:

    Can a 3D object be represented as a line drawing?  I don't mean wireframe.
    I mean take a raytraced object and draw a black-and-white cartoon, like
    black ink on white paper.  So, hard edges and "horizons" are drawn as lines.

I wrote to the author of AMMP to see if he would like to help too.  It is
actually an old program, around since 1993 or earlier.


Cheers,
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Mon Apr 12 21:27:41 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] AMMP & 3D veiwers (Greg & SooHaeng)
References: <37128A1A.EEC4AEB2@bc.edu> <3712537B.A05E0ED0@mindless.com>
Message-ID: <37129D8D.FF6AFE80@bc.edu>

Tim wrote:
> 
> Hey, good call.  I was just looking at this today... it's in C (not C++)
> and that's what got me interested in it.  Eeeerie...

Hi Tim.  Did you see it on Freshmeat too? :-)  There are some very nice GPL
programs out there, but you have to dig around for them.

> My project at work is running late (Oracle is fun like that, and it's
> always helpful when the specifications change two days before you're
> supposed to release it)

Are you working at or with Oracle?

> but I got *some* work done on the Glade layout
> for my little translator program.  I will post the code to the mailing
> list as soon as it's done, hopefully Wednesday, and perhaps the
> experienced old hands -- Humberto, Harry, etc. -- can point out all the
> ways in which I have demonstrated my incompetence.

Say Tim, do you want a Web site for your translator on theopenlab?  Does it have
a name (was it Codon)?

> ps.  Does anyone know of an old-style C++ preprocessor that generates C
> code as its output, like it was when C++ was first introduced?  I think
> I may be able to pick apart chunks of VTK in this fashion...

I don't, but I'm no guru.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From finklesk at Op.Net  Mon Apr 12 22:20:03 1999
From: finklesk at Op.Net (greg waltz)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] AMMP & 3D veiwers (Greg & SooHaeng)
In-Reply-To: <37128A1A.EEC4AEB2@bc.edu>
Message-ID: <Pine.SUN.3.96.990412221056.6310A-100000@monet.op.net>

On Mon, 12 Apr 1999, J.W. Bizzaro wrote:

> Greg and SooHaeng,
> 
> If you have been following some of our recent discussions, you know that we will
> not be making stand-alone programs.  Our molecule viewer will be like a plug-in
> to the Loci Browser.

ok. i'll go back and check the mail. did you decide how you want the
plug-in interface to be? ie. what we would have to supply ( init, draw
molecule, mode, etc.) and if we'd be using gmodule or something.

> 
> What we need then is a plug-in engine for drawing molecules in OpenGL.  I know
> that SooHaeng has DND, which will draw some simple molecule representations. 
> Greg has experience with OpenGL.  What we are missing are some more elaborate
> representations.
> 
> I found a GPL program that does some very nice representations, but it has no
> real GUI.  It's called, "Another Molecular Mechanics Program":
> 
>     http://asterix.jci.tju.edu/ammp.html
> 
> Can we make this a plug-in to the Loci Browser?  I would like help with this,
> Greg and SooHaeng.
> 

i'll take a look soon. i'll be busy from now until the second week of may
or so ( finals :P ).

> Greg, I need your help with an OpenGL trick:
> 
>     Can a 3D object be represented as a line drawing?  I don't mean wireframe.
>     I mean take a raytraced object and draw a black-and-white cartoon, like
>     black ink on white paper.  So, hard edges and "horizons" are drawn as lines.

probably, do you mean a bitmap representation? ( line art, half tone,
etc.) maybe you have an example picture?

opengl does more than just 3D, it performs alot of 2D functions. you could
probably write something like the gimp with it, but why would you want to?
anyway, opengl probably has something to do what you want or we can make
it do it.

later

From bizzaro at bc.edu  Tue Apr 13 10:47:37 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: GILT and Loci]
Message-ID: <37135909.4697AE6F@bc.edu>

The GILT author replied to my message:
-------------- next part --------------
An embedded message was scrubbed...
From: Ralf Engels <ralf.engels@informatik.uni-ulm.de>
Subject: Re: GILT and Loci
Date: Tue, 13 Apr 1999 12:29:51 +0200
Size: 3578
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990413/c9d44659/attachment.mht
From bizzaro at bc.edu  Tue Apr 13 10:49:48 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: GILT and Loci]
Message-ID: <3713598C.8C8ADFE7@bc.edu>

My message back to the GILT author:
-------------- next part --------------
An embedded message was scrubbed...
From: "J.W. Bizzaro" <bizzaro@bc.edu>
Subject: Re: GILT and Loci
Date: Tue, 13 Apr 1999 09:39:22 -0400
Size: 2975
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990413/e7fecd90/attachment.mht
From bizzaro at bc.edu  Tue Apr 13 10:50:54 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: The Loci Project]
Message-ID: <371359CE.46A343C0@bc.edu>

The AMMP author replies to my message (intro to Loci):
-------------- next part --------------
An embedded message was scrubbed...
From: robert w harrison <harrison@asterix.jci.tju.edu>
Subject: Re: The Loci Project
Date: Tue, 13 Apr 1999 09:49:40 -0400 (EDT)
Size: 2919
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990413/2e0c8c71/attachment.mht
From bizzaro at bc.edu  Tue Apr 13 10:51:38 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: The Loci Project]
Message-ID: <371359FA.3B017514@bc.edu>

My message back to the AMMP author:
-------------- next part --------------
An embedded message was scrubbed...
From: "J.W. Bizzaro" <bizzaro@bc.edu>
Subject: Re: The Loci Project
Date: Tue, 13 Apr 1999 10:46:33 -0400
Size: 2958
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990413/b936dddd/attachment.mht
From dave at arginine.umdnj.edu  Tue Apr 13 11:03:49 1999
From: dave at arginine.umdnj.edu (Dave Beck)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: The Loci Project]
In-Reply-To: <371359CE.46A343C0@bc.edu>; from J.W. Bizzaro on Tue, Apr 13, 1999 at 10:50:54AM -0400
References: <371359CE.46A343C0@bc.edu>
Message-ID: <19990413110349.A5900@arginine.umdnj.edu>

Jeff, I work with Dr. Harrison at Thomas Jefferson University.
FYI.

Quoting J.W. Bizzaro (bizzaro@bc.edu):
> The AMMP author replies to my message (intro to Loci):
> Return-Path: <harrison@asterix.jci.tju.edu>
> Received: from corot.bc.edu (corot.bc.edu [136.167.2.209])
> 	by moa.bc.edu (8.8.7/8.8.7) with ESMTP id JAA88656
> 	for <bizzaro@moa.bc.edu>; Tue, 13 Apr 1999 09:40:01 -0400
> Received: (from root@localhost)
> 	by corot.bc.edu (8.8.7/8.8.7) with X.500 id JAA96826
> 	for bizzaro@mail3.bc.edu; Tue, 13 Apr 1999 09:40:01 -0400
> Received: from asterix.jci.tju.edu (asterix.JCI.TJU.EDU [147.140.128.146])
> 	by corot.bc.edu (8.8.7/8.8.7) with ESMTP id JAA06194
> 	for <bizzaro@bc.edu>; Tue, 13 Apr 1999 09:40:00 -0400
> Received: (from harrison@localhost)
> 	by asterix.jci.tju.edu (8.9.3/8.9.3) id JAA17513;
> 	Tue, 13 Apr 1999 09:49:41 -0400 (EDT)
> Date: Tue, 13 Apr 1999 09:49:40 -0400 (EDT)
> From: robert w harrison <harrison@asterix.jci.tju.edu>
> To: "J.W. Bizzaro" <bizzaro@bc.edu>
> Subject: Re: The Loci Project
> In-Reply-To: <371284FA.ABA38EAE@bc.edu>
> Message-ID: <Pine.SGI.3.91.990413093430.17482A-100000@asterix.jci.tju.edu>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> The idea of incorparating ammp into loci is of some interest.  One 
> of the design goals of ammp was to develop a program that could be
> included in others without a big deal of fuss (i was originally thinking
> in terms of a front-end language, and AMMP was the "n-ad" interpreter
> sort of like the java virtual machine (well actually the idea was the
> ucsd pascal machine)).  This frontend has never been written, 
> but the ammp instruction set has settled into a slowly enough evolving
> form that this could be done.  Python is one of the languages i am evaluating
> as a frontend language (perl would also do, so would javascript, but 
> i suspect these are a little big and inefficient).
> 
> I can see where ammp would give loci needed new features, and can
> see where loci can help with ammp (sequence database interfacing is
> sort of crude and manual right now,  chemical or small molecule database
> interfacing would help with drug design and related sorts of problems).
> In fact anything to improve program visibility is a good idea because
> the NSF more or less requires that one demonstrate "impact" before
> they give you money to develop programs.
> 
> my only real concern right now is the degree of virtuality of the 
> project.  most of the web pages are either self-referential or under
> construction.  So it looks like the project is just starting.  
> 
> none the less this is interesting, and we should chat some more on it.
> 
> 
> 				rob
> 
> 					robert w. harrison
> 					robert.harrison@acm.org
> 					harrison@asterix.jci.tju.edu
> 					http://asterix.jci.tju.edu
> 					(215)-503-4592
> ********************************************************************************
> 
> Organic chemistry is the chemistry of carbon compounds.
> Biochemistry is the study of carbon compounds that crawl.
>                 -- Mike Adams
> 
> ********************************************************************************
> 


-- 
Dave Beck 
dave@arginine.umdnj.edu                 Sites of interest (set 4):
Computer Science and Biology            http://www.santafe.edu/projects/swarm/
Drexel University, Philadelphia PA      http://www.drexel.edu/

From hortiz at neurobio.upr.clu.edu  Tue Apr 13 11:14:34 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: The Loci Project] 
In-Reply-To: Your message of "Tue, 13 Apr 1999 10:51:38 -0400."
             <371359FA.3B017514@bc.edu> 
Message-ID: <199904131514.LAA18016@chimbo.neurobio.upr.clu.edu>


bizzaro@bc.edu said:
> We also have an archive, which is the best way to follow the design
> talks that have been underway:

>          http://toaster.sped.ukans.edu/tulip-list/ 

Please put a link to the archives on the Loci pages, I think it will attract 
more developers to see we are actually working on it.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From bizzaro at bc.edu  Tue Apr 13 11:31:35 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] [Fwd: The Loci Project]
References: <199904131514.LAA18016@chimbo.neurobio.upr.clu.edu>
Message-ID: <37136357.C451813C@bc.edu>

Attention Locians:

A press release for The Open Lab was just posted to

    http://freshmeat.net/

Check it out.  It's the first item on the front page!

Humberto Ortiz Zuazaga wrote:

> Please put a link to the archives on the Loci pages, I think it will attract
> more developers to see we are actually working on it.

I have a link to the archive on the Development page:

    http://bioinformatics.org/loci/devel.html

Unless you think it should go on index.html.


Ciao,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hortiz at neurobio.upr.clu.edu  Tue Apr 13 11:59:32 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] What about viewers? 
In-Reply-To: Your message of "Mon, 12 Apr 1999 17:49:09 -0400."
             <37126A55.2A15DEB0@bc.edu> 
Message-ID: <199904131559.LAA18222@chimbo.neurobio.upr.clu.edu>

> > I was a little confused about the WorkBench.  I thought figures were displayed
> > in the Benchtop.
> 
> I think you mean "Workspace".  Workspace = Benchtop + FigBuilder (+ maybe any
> GUI locus like viewers and editors)

OK, I sit down at the Workspace, and use the Benchtop to guide the analysis, 
using PAOS to control the actions of loci, both GUI loci and analysis loci.  
The ultimate product of an analysis workflow is a figure, displayed in the 
FigBuilder.  Intermediate results were presented by GUI loci (either in their 
own windows or in the "Viewer"), for review or editing.

> I think you mean Viewer == FigBuilder (Browser is part of the Viewer).  As I
> mentioned above, they will both display figures, but the Viewers will display
> one figure.  The FigBuilder will display many and be a place to put text
> comments, etc., like a vector drawing program.
> 
> I also want viewers to be transient (they will pop up and disappear along the
> workpath).  The FigBuilder can stay open so that the final product (the figure)
> can be worked on all the way through the workpath of the user's project.

An alternative is that selecting a figure in the FigBuilder enables editing 
and control of that particular figure. Instead of viewers opening and 
disapearing, all interaction with the user is through the FigBuilder.

> > Since the benchtop must have some way of controling a locus interactively, we
> > can use this same mechanism to script a locus.
> 
> Do you mean script the workflow?  That's right.  And PAOS is "the mechanism".

So I'm dense: I'll admit I still don't get paos.  I read the english 
translation of the article at

http://www.cs.colorado.edu/~carlosm/paos-english.html

but I thought PAOS was just a mechanism for persistent object storage in 
Python. I'll go do some more homework. So if I set a slider on the Benchtop to 
ktup=6, PAOS can communicate with the analysis locus and set the appropriate 
variable to the value I've chosen? What I want to be able to do is compose a 
new viewer or widget by taking an existing viewer or widget, and wrapping it 
up in some code to present a dialog in the benchtop, and pass control options 
back to the original widget perhaps after some preprocessing. Like subclassing 
a viewer.


-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From hortiz at neurobio.upr.clu.edu  Tue Apr 13 12:07:55 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:28 2006
Subject: [Pipet Devel] GILT for viewers and FigBuilder 
In-Reply-To: Your message of "Mon, 12 Apr 1999 18:56:48 -0400."
             <37127A30.128E6D2F@bc.edu> 
Message-ID: <199904131607.MAA18272@chimbo.neurobio.upr.clu.edu>


bizzaro@bc.edu said:
> The importance of GUImegawidgets becomes diminished if we can write
> Python scripts to control a vector drawing program like GILT.

> I personally would prefer small Python GUIscripts to large binary
> GUImegawidgets.  But some binary widgets may still be required. 

This is part of what I've been thinking about too. Provide a library of 
display routines that viewers can use. Make the viewers expose their drawing 
commands into the same API, so we can just say "display this sequence on the 
canvas", instead of "write an A at position 310, 415". This will allow people 
to build up more and more complicated viewers (MegaWidgets) by composing 
simpler ones.

Actually, this library could be used to display everything twice, intermediate 
 display in the viewer and final display in the figbuilder if we still go with 
the double display strategy.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From bizzaro at bc.edu  Tue Apr 13 13:01:26 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] What about viewers?
References: <199904131559.LAA18222@chimbo.neurobio.upr.clu.edu>
Message-ID: <37137866.84C1AEA4@bc.edu>

Humberto Ortiz Zuazaga wrote:

> OK, I sit down at the Workspace, and use the Benchtop to guide the analysis,
> using PAOS to control the actions of loci, both GUI loci and analysis loci.

Yes.  But I have been causing some confusion by saying that PAOS == Workflow
System (WFS).  Right now, all we have is PAOS, which is an active object
server.  It needs to be extended further to make a WFS.  At the bottom of this
message is a copy of what Carlos wrote about the WFS.

> The ultimate product of an analysis workflow is a figure, displayed in the
> FigBuilder.  Intermediate results were presented by GUI loci (either in their
> own windows or in the "Viewer"), for review or editing.

Pretty much...

A viewer is a type of GUI locus.
A viewer has a window.
The window is a "browser".
The browser displays graphics.
The graphics are generated by Python GUIscript
The GUIscript represents the biodata.
The biodata comes from the analysis.

> An alternative is that selecting a figure in the FigBuilder enables editing
> and control of that particular figure. Instead of viewers opening and
> disapearing, all interaction with the user is through the FigBuilder.

I suppose we can have one giant viewer (the FigBuilder), as long as it can be as
dynamic as I was planning on making the other viewers.  This just might be more
difficult.  For example, I thought a viewer would allow the rotation of a
protein in 3D.  This would be simpler if the viewer involved had nothing else
going on.  A static picture of this 3D protein would show up in the FigBuilder
when the user is finished making adjustments.

The FigBuilder maybe can handle all sorts of dynamic interactions happing at the
same time, but it would be (1) more difficult to make and (2) slower for the
user.

So, the way I imagined it, FigBuilder is for the static view of the final
product (the figure for publication).  The Viewer is for the dynamic
manipulation of an individual _part_ of the figure (you can put buttons, etc. on
the viewers too), so there may be many viewers.  (There may be many FigBuilders
if multiple publication figures are being worked on).  Editor is for the editing
of the biodata.  It will of course affect the figure in the viewer and the
FigBuilder.

FigBuilder == static
Viewer == dynamic

Do you think maybe each viewer should be a FigBuilder?  Do you think this would
be much more complicated?

> So I'm dense: I'll admit I still don't get paos.  I read the english
> translation of the article at
> 
> http://www.cs.colorado.edu/~carlosm/paos-english.html
> 
> but I thought PAOS was just a mechanism for persistent object storage in
> Python. I'll go do some more homework. So if I set a slider on the Benchtop to
> ktup=6, PAOS can communicate with the analysis locus and set the appropriate
> variable to the value I've chosen?

Yeah.  As I mentioned, PAOS will need to be extended to make a WFS.  See below.

> What I want to be able to do is compose a
> new viewer or widget by taking an existing viewer or widget, and wrapping it
> up in some code to present a dialog in the benchtop, and pass control options
> back to the original widget perhaps after some preprocessing. Like subclassing
> a viewer.

Passing via PAOS?  It should be doable.


There are more updated terms for what Carlos says below:

Gnome clients == Benchtop + FigBuilder
Tool Manager == The part of a viewer (or maybe a separate process) that
communicates via the WFS.

>From Carlos:

I totally agree that Paos shouldn't shuffle around real data. I see the
role of Paos as a coordination tool but not as a database management
system. I attached a GIF picture to this mail. This picture contains Gnome
clients, Paos server, and Tool Manager (excuse me if I introduce yet
another set of terms). Gnome clients and Tool Manager are Paos clients. A
Gnome client consists of a GCL editor and progress monitor, among other
things. A Tool Manager 

- parses XML data and forwards it to the actual tool, 
- turn the result of a tool into XML data and send it to another tool 
  manager
- sends status information to a Paos server (e.g. processing started or
  completed, or processing ran out of memory),
- receives notifications from a Paos server (e.g. "suspend", "abort",
  or status query),
- queries a Paos server about where to send results to,

The thin lines are communicating Python objects, the thick
lines communicate XML structures. Note that the destination of Tool
Manager can also be a Gnome client which is used to visualize results.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tulip-architecture.gif
Type: image/gif
Size: 3548 bytes
Desc: not available
Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/19990413/60022bbb/tulip-architecture.gif
From hortiz at neurobio.upr.clu.edu  Tue Apr 13 14:14:42 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] Viewers and the FigBuilder. 
In-Reply-To: Your message of "Tue, 13 Apr 1999 13:01:26 -0400."
             <37137866.84C1AEA4@bc.edu> 
Message-ID: <199904131814.OAA18583@chimbo.neurobio.upr.clu.edu>


bizzaro@bc.edu said:
> So, the way I imagined it, FigBuilder is for the static view of the
> final product (the figure for publication).  The Viewer is for the
> dynamic manipulation of an individual _part_ of the figure (you can
> put buttons, etc. on the viewers too), so there may be many viewers.
> (There may be many FigBuilders if multiple publication figures are
> being worked on).  Editor is for the editing of the biodata.  It will
> of course affect the figure in the viewer and the FigBuilder.

> FigBuilder == static
> Viewer == dynamic 

Sure, this works.  A viewer can fiddle with the figure, then export the final 
figure to the FigBuilder.  We could just export encapsulated postscript, or 
some kind of XML file for vector illustrations.  Export can happen 
automatically when the viewer closes.

I does make a viewer more complicated, we have to manage the dynamic display, 
and then display again for the figbuilder.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From hortiz at neurobio.upr.clu.edu  Tue Apr 13 14:48:39 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System 
In-Reply-To: Your message of "Tue, 13 Apr 1999 13:01:26 -0400."
             <37137866.84C1AEA4@bc.edu> 
Message-ID: <199904131848.OAA18653@chimbo.neurobio.upr.clu.edu>


bizzaro@bc.edu said:
> There are more updated terms for what Carlos says below:

> Gnome clients == Benchtop + FigBuilder

Carlos seems to mean any GUI locus.

> Tool Manager == The part of a
> viewer (or maybe a separate process) that communicates via the WFS. 

No, I think Tool Manager == analytical locus.

Carlos said:
> I totally agree that Paos shouldn't shuffle around real data. I see
> the role of Paos as a coordination tool but not as a database
> management system.

If PAOS won't shuffle data around, we'll need another mechanism for getting 
data into an analytical locus.  It will have to be able to contact remote loci:

I fire up my seqence editor, type in a few bases from my still wet autorad, 
and click on the blast button.

The sequence data will have to be transfered to the remote blast locus.

The python XML topic guide at:

http://www.python.org/topics/xml/xml.html

lists two proposals for an XML over HTTP RPC mechanism, this or something 
similar can be used as loci's "transfer" mechanism (in the sense transfer is 
used in the glossary). These particular proposals seem a little too low level 
(they define a XML for bytes and integers etc), but the basic idea of using 
XML to transfer data and specify a remote procedure call syntax seems like 
what we need.

-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From bizzaro at bc.edu  Tue Apr 13 14:50:23 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] Viewers and the FigBuilder.
References: <199904131814.OAA18583@chimbo.neurobio.upr.clu.edu>
Message-ID: <371391EF.3F21A5E3@bc.edu>

Humberto Ortiz Zuazaga wrote:
> 
> Sure, this works.  A viewer can fiddle with the figure, then export the final
> figure to the FigBuilder.  We could just export encapsulated postscript, or
> some kind of XML file for vector illustrations.  Export can happen
> automatically when the viewer closes.

Since discussions have recently lead to use of a vector drawing program like
GILT, I suppose we can define an XML/DTD for vector drawings.  So we have DTD's
for

    Figure data
    Biological data (a DTD for each: sequence, structure, phylogeny, etc.)
    Workflow data

and a Python GUIscript + GUImegawidgets.    

> I does make a viewer more complicated, we have to manage the dynamic display,
> and then display again for the figbuilder.

The figure can be dnd'd to the FigBuilder the first time, sending over the
figure XML.  When remanipulating the figure, the figure XML can be sent by
closing the viewer or pressing an "update" button.  So for buttons on the
viewer/browser, we can have

    Back
    Forward
    Update    <- to update figure in FigBuilder
    Print
    Save

And if the user double-clicks on part of the figure in the FigBuilder, that part
will be brought up in a viewer for manipulation.

BTW, to build upon the tradition of naming loci after things you find in the lab
(such as Benchtop), how about using the nickname "slide" for viewer (and
"collection slide" for FigBuilder).  These are nicknames; I'm not trying to
confuse anyone by renaming anything ;-)

P.S.  Robert Harrison, author of AMMP, says he will help us :-)


Asta la Vista,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Tue Apr 13 15:14:06 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System
References: <199904131848.OAA18653@chimbo.neurobio.upr.clu.edu>
Message-ID: <3713977E.2D2650C7@bc.edu>

Humberto Ortiz Zuazaga wrote:
> 
> bizzaro@bc.edu said:
> > There are more updated terms for what Carlos says below:
> 
> > Gnome clients == Benchtop + FigBuilder
> 
> Carlos seems to mean any GUI locus.
> 
> > Tool Manager == The part of a
> > viewer (or maybe a separate process) that communicates via the WFS.
> 
> No, I think Tool Manager == analytical locus.

Perhaps you are right :-)  There was some confusion early on that the Benchtop
communicated only with remote analysis loci.  It of course communicates with
viewers too.

In any case, all loci it seems will need a "Tool Manager" component for
communication.

> If PAOS won't shuffle data around, we'll need another mechanism for getting
> data into an analytical locus.  It will have to be able to contact remote loci:

>From and earlier message:

    PAOS -> for active communication about the internals of Loci
    XML  -> for archiving and translating bio data AND LOCI INTERNALS

But to make a complete WFS, I have been saying that we need an XML parser to go
along with PAOS.  Of course I want the WFS to be a seamless system.

> I fire up my seqence editor, type in a few bases from my still wet autorad,
> and click on the blast button.

call SeqViewer -> call SeqEditor -> type bases -> updated to SeqViewer -> close
SeqEditor (optional) -> at Seqviewer pull down menu with optional analyses
(known to local AppBroker) -> select Blast...

> The sequence data will have to be transfered to the remote blast locus.
> 
> The python XML topic guide at:
> 
> http://www.python.org/topics/xml/xml.html
> 
> lists two proposals for an XML over HTTP RPC mechanism, this or something
> similar can be used as loci's "transfer" mechanism (in the sense transfer is
> used in the glossary). These particular proposals seem a little too low level
> (they define a XML for bytes and integers etc), but the basic idea of using
> XML to transfer data and specify a remote procedure call syntax seems like
> what we need.

I'm not sure what transfer protocol PAOS uses over an Internet socket.  Carlos? 
But we may not be looking at HTTP.  So, probably something "similar".  PAOS
should be in control of this file transfer to some extent.


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From carlosm at moet.cs.colorado.edu  Tue Apr 13 15:50:29 1999
From: carlosm at moet.cs.colorado.edu (Carlos Maltzahn)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System
In-Reply-To: <3713977E.2D2650C7@bc.edu>
Message-ID: <Pine.GSU.4.05.9904131335120.7814-100000@moet.cs.colorado.edu>

    [Zuazaga]
    > http://www.python.org/topics/xml/xml.html
    > 
    > lists two proposals for an XML over HTTP RPC mechanism, this or something
    > similar can be used as loci's "transfer" mechanism (in the sense transfer is
    > used in the glossary). These particular proposals seem a little too low level
    > (they define a XML for bytes and integers etc), but the basic idea of using
    > XML to transfer data and specify a remote procedure call syntax seems like
    > what we need.
    
    [Bizarro] 
    I'm not sure what transfer protocol PAOS uses over an Internet
    socket.  Carlos?  But we may not be looking at HTTP.  So, probably
    something "similar".  PAOS should be in control of this file
    transfer to some extent.
    
The communication between Paos clients and server uses Python's pickle
module plus some optimizations. The pickle module lets you serialize
Python objects into strings so you can send them over the net. There is no
specified standard for the pickle protocol.

BTW, I'm interested to find out who on this list was able to run Paos and
play around with it a little bit. Let me know what your experience was.

Sorry for not contributing too much to this list lately. My defense is on
Friday and chaos reigns. :)

Carlos


From bizzaro at bc.edu  Tue Apr 13 16:22:23 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System
References: <Pine.GSU.4.05.9904131335120.7814-100000@moet.cs.colorado.edu>
Message-ID: <3713A77F.5272E07D@bc.edu>

Carlos Maltzahn wrote:
> 
> The communication between Paos clients and server uses Python's pickle
> module plus some optimizations. The pickle module lets you serialize
> Python objects into strings so you can send them over the net. There is no
> specified standard for the pickle protocol.

Part of PAOS's role in the WFS should be to keep track of the XML files being
transfered around (data ID's stored as objects?).  So when the transfer of
pickeled PAOS objects is made across the Net, the objects are unpickeled, and
the Internet AppBroker should get some indication as to where the XML is and how
to get it.

Can the XML's be attached to the pickeled PAOS objects when transferred?

> Sorry for not contributing too much to this list lately. My defense is on
> Friday and chaos reigns. :)

No problem.


Buh-bye,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From carlosm at moet.cs.colorado.edu  Tue Apr 13 16:43:07 1999
From: carlosm at moet.cs.colorado.edu (Carlos Maltzahn)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System
In-Reply-To: <3713A77F.5272E07D@bc.edu>
Message-ID: <Pine.GSU.4.05.9904131432240.8675-100000@moet.cs.colorado.edu>



Carlos 

On Tue, 13 Apr 1999, J.W. Bizzaro wrote:

    Carlos Maltzahn wrote:
    > 
    > The communication between Paos clients and server uses Python's pickle
    > module plus some optimizations. The pickle module lets you serialize
    > Python objects into strings so you can send them over the net. There is no
    > specified standard for the pickle protocol.
    
    Part of PAOS's role in the WFS should be to keep track of the XML files being
    transfered around (data ID's stored as objects?).  So when the transfer of
    pickeled PAOS objects is made across the Net, the objects are unpickeled, and
    the Internet AppBroker should get some indication as to where the XML is and how
    to get it.
    
    Can the XML's be attached to the pickeled PAOS objects when transferred?
    
Well, XML code is basically a string which you can attach to a Python
object. Then you serialize the Python object which embeds the XML string
into the serialized object like any other attribute value. To deserialize
serialized objects you just need to have the same Python class definition
that were used for the serialization. After deserialization you extract
the XML string by accessing the corresponding attribute.

So the answer is yes, if you can attach XML to objects _before_ they get
pickled. 

Carlos

From hortiz at neurobio.upr.clu.edu  Wed Apr 14 10:13:33 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System 
In-Reply-To: Your message of "Tue, 13 Apr 1999 13:50:29 CST."
             <Pine.GSU.4.05.9904131335120.7814-100000@moet.cs.colorado.edu> 
Message-ID: <199904141413.KAA20823@chimbo.neurobio.upr.clu.edu>

>     [Zuazaga]
>     > http://www.python.org/topics/xml/xml.html
>     > 
>     > lists two proposals for an XML over HTTP RPC mechanism,
>     
> The communication between Paos clients and server uses Python's pickle
> module plus some optimizations. The pickle module lets you serialize
> Python objects into strings so you can send them over the net. There is no
> specified standard for the pickle protocol.

I think we need to be careful, we should write our own pickling routines that 
serialize data as XML.  From what I understand of pickling, this shouldn't be 
a problem, but I want to make clear that ad-hoc protocols are not going to be 
fun.

-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From hinsen at cnrs-orleans.fr  Wed Apr 14 10:26:28 1999
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System
In-Reply-To: <199904141413.KAA20823@chimbo.neurobio.upr.clu.edu> (message from
	Humberto Ortiz Zuazaga on Wed, 14 Apr 1999 10:13:33 -0400)
References: <199904141413.KAA20823@chimbo.neurobio.upr.clu.edu>
Message-ID: <199904141426.QAA02673@chinon.cnrs-orleans.fr>

> > module plus some optimizations. The pickle module lets you serialize
> > Python objects into strings so you can send them over the net. There is no
> > specified standard for the pickle protocol.
> 
> I think we need to be careful, we should write our own pickling
> routines that serialize data as XML. From what I understand of
> pickling, this shouldn't be a problem, but I want to make clear that
> ad-hoc protocols are not going to be fun.

It's not as bad as it seems. The pickle protocol is in a sense documented
by Python's pickle module (which is very readable), and it is not going
to change (pickle files are used for archiving data in many applications).

Pickle data has the advantage of being compact and efficient, but also
the disadvantages of being neither "human reader friendly" nor easy to
process in other languages (because it is basically a text
representation of Python's internal data structures).

Which raises a problem: writing a pickler using another format is not
difficult, as long as the simple relation between the data layout
and Python's internal data structure remains. This however may not
be desirable, and then writing a general pickler (which can deal with
any kind of object) is probably not so easy.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

From carlosm at moet.cs.colorado.edu  Wed Apr 14 14:44:20 1999
From: carlosm at moet.cs.colorado.edu (Carlos Maltzahn)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] PAOS and the Work Flow System
In-Reply-To: <199904141426.QAA02673@chinon.cnrs-orleans.fr>
Message-ID: <Pine.GSU.4.05.9904141226020.11570-100000@moet.cs.colorado.edu>


Once we decided that a Python interpreter is always going to be available
in the Loci framework and that the format of Python pickle is not going to
change, it seems feasible to define Python-pickled stuff as a new XML data
type. I wouldn't call this an ad-hoc protocol because we are using two
fairly established ways to describe things.

But I might miss the point here because I have not followed the recent
discussions very well...

Carlos

On Wed, 14 Apr 1999, Konrad Hinsen wrote:

    > > module plus some optimizations. The pickle module lets you serialize
    > > Python objects into strings so you can send them over the net. There is no
    > > specified standard for the pickle protocol.
    > 
    > I think we need to be careful, we should write our own pickling
    > routines that serialize data as XML. From what I understand of
    > pickling, this shouldn't be a problem, but I want to make clear that
    > ad-hoc protocols are not going to be fun.
    
    It's not as bad as it seems. The pickle protocol is in a sense documented
    by Python's pickle module (which is very readable), and it is not going
    to change (pickle files are used for archiving data in many applications).
    
    Pickle data has the advantage of being compact and efficient, but also
    the disadvantages of being neither "human reader friendly" nor easy to
    process in other languages (because it is basically a text
    representation of Python's internal data structures).
    
    Which raises a problem: writing a pickler using another format is not
    difficult, as long as the simple relation between the data layout
    and Python's internal data structure remains. This however may not
    be desirable, and then writing a general pickler (which can deal with
    any kind of object) is probably not so easy.
    
    Konrad.
    -- 
    -------------------------------------------------------------------------------
    Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
    Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
    Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
    45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
    France                                   | Nederlands/Francais
    -------------------------------------------------------------------------------
    

From jabbo at mindless.com  Wed Apr 14 18:07:19 1999
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] cvs is up!
References: <371547FC.DF6E05A2@bc.edu>
Message-ID: <37151197.FD7D1A94@mindless.com>

Fuck Pharmacy, use cvsweb.  Here's my cvsweb.conf and the script, let me
know if you need help with it.  Best interface for CVS I've ever seen.

(our CVS tree is in /opt/cvs, for reference)

Also, *don't* run cvsweb.cgi under mod_perl, just in case you were
thinking of doing so.  It leaks memory like a sieve.  Finally, here's
the cvs manual, tar'd up and ready to stick on the website for easy
reference.

I finally crashed through a ton or so of shit on our project today. 
I'll send in my Codon package and (hopefully) some useful RPMs (Babel
1.6, 1.6, Codon) too.

Finally, did you get a chance to set up ssh?  I don't know what my
account name or password is on the machine (don't remember the IP
either) so if you could pass those on (maybe in a tarball or something,
just to obscure the text) that'd be great.  If ssh isn't set up I can
write you a script to run as root to do so.

-- 
     "They were called 'wonder workers' by an observer
      who caught one of them wondering what kind of a 
       wrench to use to hammer a screw into a brick."
                     --George Brown
-------------- next part --------------

-------------- next part --------------

From jabbo at mindless.com  Wed Apr 14 18:13:18 1999
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] cvs is up!
References: <371547FC.DF6E05A2@bc.edu>
Message-ID: <371512FE.F1B09212@mindless.com>

Oops.  I skillfully sent that message to the list, apologies all
around.  For some reason I thought I had replied only to Jeff.  Well,
the up side is that now everyone has their very own CVS manual... I
humbly beg your forgiveness(es).

Thousand pardons, all.

Anyways, command-line CVS is pretty easy once you get used to it. 
Checkout, commit, update, remove, and add are the only commands most
people will need.  So taking the time to build Pharmacy or figure out
jCVS is pretty much a waste.  Whereas the ability to dig through the CVS
tree and old diffs to find out where a bug came from is absolutely key,
and that is what CVSweb offers.  Muy bien.

If you think of CVS as a way to make the arrow of time point backwards
(state-of-the-code wise, at least) the utility of such a tool is
highlighted.

That's what I meant to say, at least in public.  Sorry for the language.

-- 
    "A supercomputer is a device for converting
     a CPU-bound problem into an I/O bound problem."

                            --Ken Batcher

From bizzaro at bc.edu  Wed Apr 14 21:59:24 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] cvs is up!
Message-ID: <371547FC.DF6E05A2@bc.edu>

Locians,

After many hours of pulling my hair out, I finally got the CVS server up and
running.

theopenlab is running CVS version 1.10.2.

Here is a quick tutorial:

You need to set your environment variable for CVSROOT.  Using bash, you do this:

    export CVSROOT=':pserver:username@bioinformatics.org:/home/cvs'

Of course username should be your login name.  It is the same as for your shell
account.

Then you can login by typing

    cvs login

The server will ask for your password, which is the same as for your shell
account.

Note that CVS is not interactive.  You will remain in your local shell.

I have a fake CVS repository (actually Imlib) for Loci.  The module name is
'loci'.  To "check it out" of the repository, you type

    cvs checkout loci

This will mkdir loci in your local pwd, so make sure you want Loci there.

If any changes are made, you can "commit changes" to the remote CVS repository
by typing

    cvs commit -m 'notes about change' filechanged.c

It is actually dang complicated, and if you don't know it by heart, read the
documentation.  Another option may be to use the client "pharmacy":

    http://home.earthlink.net/~nawalker/pharmacy.html


Enjoy,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hortiz at neurobio.upr.clu.edu  Thu Apr 15 12:07:56 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] [Zope-dev] ZServer design ideas: gneeral comments
Message-ID: <37160EDC.DD0B0EE7@neurobio.upr.clu.edu>

A tidbit I got from LWN, it discusses using XML to exchange (database)
objects between servers.

http://www.zope.org/pipermail/zope-dev/1999-April/000308.html

This apparently is being worked on for Zope.

From bizzaro at bc.edu  Thu Apr 15 12:58:21 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] project tree and names
Message-ID: <37161AAD.E653B700@bc.edu>

Locians,

I split Loci up into 7 independent projects, independent because they are pretty
much executable without the other components, and may in some cases be a set of
independent executables (as with the editors).  Each of the 7 projects can be a
module in the CVS.

The projects will be named loci-<whatever>, as has been the convention for large
systems like GNOME and KDE.  You will notice below that I have changed some
names (again, and maybe to your annoyance :-).  I would like to make the
"laboratory names" prominent for different components, especially for those the
user will interact with directly.

I abbreviated some names, like inst == instrument (any editor), spec == specimen
(biodata and all display components).  Other nicknames are slide (viewer/browser
locus) as in microscope slide, and stage (figure builder) as in microscope
stage.  I have also renamed AppBroker to Locus Server, which I think could be
the same program for both local and remote installations.

Any comments or questions?


loci-insts          (biodata editors)

    inst-na1d       (nucleic acid seq editor)
    inst-aa1d       (amino acid seq editor)
    inst-aa2d       (amino acid motif editor)
    inst-3d         (3d molecule editor)
    inst-phy        (phylogeny editor)

loci-benchtop       (workspace)

    wfd             (work flow diagram)
    spec-mngr       (biodata manager)
    locus-mngr      (locus manager)

loci-slide          (biodata browser)

    spec-iface      (biodata GUI)
    spec-image      (biodata image)
    spec-data       (biodata)

loci-stage          (figure builder)

loci-locuserv       (application broker)

loci-locuswrap      (locus wrapper)

    wrap-gui        (GUI locus wrapper)
    wrap-cl         (command-line locus wrapper)

loci-ibuild         (biodata GUI builder)


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Thu Apr 15 18:36:22 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] misc
Message-ID: <371669E6.1CA49953@bc.edu>

Encryption:

When we brought up the idea of Internet collaboratories that use Loci, some time
ago, the topic of encryption came up.  This may be important for corporations
who want to protect their data (although The Open Lab opposes this, but it is
nonetheless a desired feature).  FreeS/WAN is GPL software for encrypted, secure
(if there is such a thing) TCP/IP communication:

    http://www.xs4all.nl/~freeswan/

ssh and cvs:

Does anyone know if and how cvs might use ssh?  Justin is setting up ssh now.

Mailing lists:

I would like to make 3 mailing lists on theopenlab server, using Mailman.  Each
list will cover a large part of Loci, maybe several modules each:

    instruments (1 module, loci-instruments)
      inst-na1d
      inst-aa1d
      inst-aa2d
      inst-3d
      inst-phy

    imaging (3 modules)
      loci-slides
      loci-stages
      loci-ibuild

    infrastructure (4 modules)
      loci-servers
      loci-locusml (not mentioned last time)
      loci-wrappers
      loci-benchtop

Whew!  We've got a lot of work ahead :-)

I will make a pipet-devel mailing list a bit later.  For now, we will continue
to use the one at UKansas (this one).


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From hortiz at neurobio.upr.clu.edu  Fri Apr 16 10:22:17 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] misc 
In-Reply-To: Your message of "Thu, 15 Apr 1999 18:36:22 -0400."
             <371669E6.1CA49953@bc.edu> 
Message-ID: <199904161422.KAA29064@chimbo.neurobio.upr.clu.edu>


bizzaro@bc.edu said:
> Does anyone know if and how cvs might use ssh?  Justin is setting up
> ssh now. 

>From the cvs man page:

       -x     Encrypt  all  communication  between the client and
              the server.  As  of  this  writing,  this  is  only
              implemented when using a Kerberos connection.

rsync can use ssh (rsync -e ssh), and can be run as a server: samba and 
jitterbug are distributed via anonymous rsync as well as cvs.

http://rsync.samba.org/

They just fixed a security but in rsync, redhat has new packages on the 
updates site.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From hortiz at neurobio.upr.clu.edu  Fri Apr 16 10:24:55 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] misc 
In-Reply-To: Your message of "Thu, 15 Apr 1999 18:36:22 -0400."
             <371669E6.1CA49953@bc.edu> 
Message-ID: <199904161424.KAA29079@chimbo.neurobio.upr.clu.edu>


bizzaro@bc.edu said:
> I would like to make 3 mailing lists on theopenlab server, using
> Mailman.  Each list will cover a large part of Loci, maybe several
> modules each: 

Mailman is real nice, but can we keep just one list for now? Just move the 
tulip-list to theopenlab. I think at this point in development we still need 
everyone to listen and contribute. Later, once the design stabilises, perhaps 
we can split off into separate groups.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz@neurobio.upr.clu.edu


From carlosm at moet.cs.colorado.edu  Fri Apr 16 11:42:24 1999
From: carlosm at moet.cs.colorado.edu (Carlos Maltzahn)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] misc 
In-Reply-To: <199904161424.KAA29079@chimbo.neurobio.upr.clu.edu>
Message-ID: <Pine.GSU.4.05.9904160939560.18745-100000@moet.cs.colorado.edu>


I agree - if you look at other projects, e.g. Python, it took them years
until the amount of activity justified separate mailing lists. 

Carlos 

On Fri, 16 Apr 1999, Humberto Ortiz Zuazaga wrote:

    
    bizzaro@bc.edu said:
    > I would like to make 3 mailing lists on theopenlab server, using
    > Mailman.  Each list will cover a large part of Loci, maybe several
    > modules each: 
    
    Mailman is real nice, but can we keep just one list for now? Just move the 
    tulip-list to theopenlab. I think at this point in development we still need 
    everyone to listen and contribute. Later, once the design stabilises, perhaps 
    we can split off into separate groups.
    -- 
    Humberto Ortiz Zuazaga
    Bioinformatics Specialist
    Institute of Neurobiology
    hortiz@neurobio.upr.clu.edu
    
    
    

From bizzaro at bc.edu  Fri Apr 16 12:12:14 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] misc
References: <199904161424.KAA29079@chimbo.neurobio.upr.clu.edu>
Message-ID: <3717615E.BF0E26F@bc.edu>

Humberto Ortiz Zuazaga wrote:
> 
> bizzaro@bc.edu said:
> > I would like to make 3 mailing lists on theopenlab server, using
> > Mailman.  Each list will cover a large part of Loci, maybe several
> > modules each:
> 
> Mailman is real nice, but can we keep just one list for now? Just move the
> tulip-list to theopenlab. I think at this point in development we still need
> everyone to listen and contribute. Later, once the design stabilises, perhaps
> we can split off into separate groups.

Fine.  One mailing list for now.  I was just thinking ahead :-)


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Sun Apr 18 05:17:10 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:29 2006
Subject: [Pipet Devel] EVERYONE: new mailing lists!
Message-ID: <3719A316.635B1EC3@bc.edu>

Locians,

I have Mailman set up on the server.

I have a new list for Loci on the server.  PLEASE SUBSCRIBE!  And we will phase
out the "tulip" list.  Go here:

    http://bioinformatics.org/mailman/listinfo/pipet-devel/

I also have a list for general discussions about The Open Lab.  If you are at
all interested in what else might be happening at the Lab, please subscribe.  Go
here:

    http://bioinformatics.org/mailman/listinfo/theopenlab/


Thank you, and I'll see you on the other side :-)
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From jabbo at mindless.com  Sun Apr 18 09:53:43 1999
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Re: ssh is on the server and running
References: <Pine.OSF.4.03.9904171922380.26520-100000@busboy.sped.ukans.edu> <371940C9.9235AFE7@bc.edu>
Message-ID: <3719E3E7.42793FB2@mindless.com>

Feh!  I tried SSH'ing into bioinformatics.org and got:

Connection closed by remote host.

D'oh!

-- 
    "Lisp has all the visual appeal of oatmeal
       with fingernail clippings mixed in." 

                                 --Larry Wall

From jabbo at mindless.com  Sun Apr 18 09:54:14 1999
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Re: ssh is on the server and running
References: <Pine.OSF.4.03.9904171922380.26520-100000@busboy.sped.ukans.edu> <371940C9.9235AFE7@bc.edu>
Message-ID: <3719E406.931ECE52@mindless.com>

Reason why I'm pissed is that I was going to send in Codon and Babel
RPMs!

-- 
    "Lisp has all the visual appeal of oatmeal
       with fingernail clippings mixed in." 

                                 --Larry Wall

From justin at ukans.edu  Sun Apr 18 23:18:18 1999
From: justin at ukans.edu (Justin Bradford)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] ssh problems
Message-ID: <Pine.OSF.4.03.9904182216440.26520-100000@busboy.sped.ukans.edu>

I've added the hosts.allow entry, but I still don't have any trouble
connecting. However, I'm using ssh2. I compiled it with version 1
compatibility. Maybe there's a second daemon I need to start?

Justin

From hjm at cx408397-a.irvn1.occa.home.com  Mon Apr 19 09:00:01 1999
From: hjm at cx408397-a.irvn1.occa.home.com (Harry Mangalam)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] ssh problems
In-Reply-To: <Pine.OSF.4.03.9904182216440.26520-100000@busboy.sped.ukans.edu>
Message-ID: <Pine.LNX.4.10.9904190555080.5437-100000@cx408397-a.irvn1.occa.home.com>

Cassandra here (no one listens to me).  I think I grumpily mentioned before
that ssh2 is incompatible with ssh1, even WITH the version 1 compatibility
(it's only compatible with the very latest version 1).

So either all clients have to erun out and get version 2 clients (which will
not work with most version 1 servers, so you'll have to maintain 2 clients)
or back your sshd down to version 1.

Ahhh, security..

hjm


On Sun, 18 Apr 1999, Justin Bradford wrote:

/I've added the hosts.allow entry, but I still don't have any trouble
/connecting. However, I'm using ssh2. I compiled it with version 1
/compatibility. Maybe there's a second daemon I need to start?
/
/Justin
/

Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com 


From justin at ukans.edu  Mon Apr 19 14:53:00 1999
From: justin at ukans.edu (Justin Bradford)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Re: [Pipet Devel] ssh problems
In-Reply-To: <Pine.LNX.4.10.9904190555080.5437-100000@cx408397-a.irvn1.occa.home.com>
Message-ID: <Pine.OSF.4.03.9904191350020.6065-100000@busboy.sped.ukans.edu>

On Mon, 19 Apr 1999, Harry Mangalam wrote:
> Cassandra here (no one listens to me).  I think I grumpily mentioned before
> that ssh2 is incompatible with ssh1, even WITH the version 1 compatibility
> (it's only compatible with the very latest version 1).

I forgot about that sorry.

> So either all clients have to erun out and get version 2 clients (which will
> not work with most version 1 servers, so you'll have to maintain 2 clients)
> or back your sshd down to version 1.

Well, I have both on, now, and I recompile v2 so it was aware of v1.
Supposedly, the v2 daemon will recognize v1 clients and start the v1
server to handle them.

So, everyone try again. If that doesn't work, I'll just scrap v2.

Justin



_______________________________________________
pipet-devel maillist  -  pipet-devel@bioinformatics.org
http://bioinformatics.org/mailman/listinfo/pipet-devel

From hjm at cx408397-a.irvn1.occa.home.com  Mon Apr 19 17:30:06 1999
From: hjm at cx408397-a.irvn1.occa.home.com (Harry Mangalam)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] ssh problems
In-Reply-To: <371B9518.AEBB0183@bc.edu>
Message-ID: <Pine.LNX.4.10.9904191428050.6984-100000@cx408397-a.irvn1.occa.home.com>

No problem.  Just wanted to complain about something.. :)
And sure - I agree, ssh2 seems to be LOADS better than v1 - that's why I got
into it almost immediately (to my later disgust..)

Thanks for the note.

hjm

On Mon, 19 Apr 1999, J.W. Bizzaro wrote:

/Hi Harry!
/
/Sorry about that.  I do remember you said not to use ssh2, but Justin is trying
/to get them both working.  I think it is safe to say that eventually ssh2 will
/be preferred over ssh1.
/
/BTW, we have a new mailing list:
/
/    http://bioinformatics.org/mailman/listinfo/pipet-devel
/
/
/Cheers,
/Jeff
/
/
/Harry Mangalam wrote:
/> 
/> Cassandra here (no one listens to me).  I think I grumpily mentioned before
/> that ssh2 is incompatible with ssh1, even WITH the version 1 compatibility
/> (it's only compatible with the very latest version 1).
/> 
/> So either all clients have to erun out and get version 2 clients (which will
/> not work with most version 1 servers, so you'll have to maintain 2 clients)
/> or back your sshd down to version 1.
/> 
/> Ahhh, security..
/> 
/> hjm
/> 
/> On Sun, 18 Apr 1999, Justin Bradford wrote:
/> 
/> /I've added the hosts.allow entry, but I still don't have any trouble
/> /connecting. However, I'm using ssh2. I compiled it with version 1
/> /compatibility. Maybe there's a second daemon I need to start?
/> /
/> /Justin
/> /
/> 
/> Cheers,
/> Harry
/> 
/> Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
/
/-- 
/J.W. Bizzaro                  mailto:bizzaro@bc.edu
/Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
/--
/

Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com 


From bizzaro at bc.edu  Mon Apr 19 18:23:13 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] more GPL command-line software
Message-ID: <371BACD1.69D972C0@bc.edu>

(If you are still on the TULIP list, please switch to the Loci list.)

Locians,

Sean Eddy (Washington U) has been developing GPL, command-line, bioinformatics
programs for several years now:

    http://www.genetics.wustl.edu/eddy/software/

I just wrote to see if he will join the project.  In any case, we may want to
implement some of these programs (on top of the Loci core).


I'll be back,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--

From bizzaro at bc.edu  Tue Apr 20 00:19:05 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Gee Todo,
Message-ID: <371C0039.81CA5A6B@bc.edu>

It looks like the Loci mailing list isn't in Kansas anymore.

Even though half of the Loci developers haven't left yet.

(I couldn't resist :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oz2.jpg
Type: image/jpeg
Size: 13773 bytes
Desc: not available
Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/19990420/4447010c/oz2.jpg
From justin at ukans.edu  Tue Apr 20 00:39:07 1999
From: justin at ukans.edu (Justin Bradford)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Gee Todo,
In-Reply-To: <371C0039.81CA5A6B@bc.edu>
Message-ID: <Pine.OSF.4.03.9904192334520.2444-100000@busboy.sped.ukans.edu>

On Tue, 20 Apr 1999, J.W. Bizzaro wrote:

> It looks like the Loci mailing list isn't in Kansas anymore.
> 
> Even though half of the Loci developers haven't left yet.
> 
> (I couldn't resist :-)

Yeah, I've been cross-posting lately.
However, we could subsribe each of the lists to each other.
That way, a post from either gets sent to both...

Or, we could just move them, except that might screw up some procmail
recipes.

Anyway, here's the current list of subscribers:

justin@ukans.edu
bizzaro@bc.edu
hinsen@cnrs-orleans.fr
jabbo@mindless.com
Thomas.Sicheritz@molbio.uu.se
david.lapointe@umassmed.edu
rahul@photino.sid.rice.edu
carlosm@moet.cs.colorado.edu
lahondes@pasteur.fr
hjm@cx408397-a.irvn1.occa.home.com
pmr@sanger.ac.uk
tulip-list-archive@toaster.sped.ukans.edu
dave@arginine.umdnj.edu
finklesk@Op.Net
mrn@supermta.hg.med.umich.edu
hortiz@neurobio.upr.clu.edu
mrios@altavista.net
jbizzaro@figment.colonial.net
bcohen@cs.sunysb.edu
Kenneth_Marx@uml.edu
yoo@octane.korea.ac.kr
harrier@asterix.jci.tju.edu
gregoire@starlab.net


And these two are alternate email addresses. I had majordomo set-up to
allow these people to post from these, as well as their address above
(but they still just get one copy of each post). I'm not sure how mailman
works, so I don't know if it will do this.

carlosm@mroe.cs.colorado.edu
thomas@evolution.bmc.uu.se



justin





From bizzaro at bc.edu  Sun Apr 18 04:31:57 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] test
Message-ID: <3719987D.A3618ECF@bc.edu>

test

-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From hortiz at neurobio.upr.clu.edu  Sun Apr 18 20:39:27 1999
From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Confirm problems with ssh.
Message-ID: <199904190039.UAA13039@chimbo.neurobio.upr.clu.edu>

I can confirm problems with ssh on theopenlab:

[zuazaga@aleph zuazaga]$ slogin -V
SSH Version 1.2.26 [i686-unknown-linux], protocol version 1.5.

[zuazaga@aleph zuazaga]$ slogin -l humberto bioinformatics.org
Connection closed by remote host.

I suspect /etc/host.allow or deny rules. ssh uses tcpd style access controls.

try putting sshd:ALL:allow in /etc/hosts.allow


From justin at ukans.edu  Sun Apr 18 23:18:18 1999
From: justin at ukans.edu (Justin Bradford)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] ssh problems
Message-ID: <Pine.OSF.4.03.9904182216440.26520-100000@busboy.sped.ukans.edu>

I've added the hosts.allow entry, but I still don't have any trouble
connecting. However, I'm using ssh2. I compiled it with version 1
compatibility. Maybe there's a second daemon I need to start?

Justin



From justin at ukans.edu  Mon Apr 19 14:53:00 1999
From: justin at ukans.edu (Justin Bradford)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Re: [Pipet Devel] ssh problems
In-Reply-To: <Pine.LNX.4.10.9904190555080.5437-100000@cx408397-a.irvn1.occa.home.com>
Message-ID: <Pine.OSF.4.03.9904191350020.6065-100000@busboy.sped.ukans.edu>

On Mon, 19 Apr 1999, Harry Mangalam wrote:
> Cassandra here (no one listens to me).  I think I grumpily mentioned before
> that ssh2 is incompatible with ssh1, even WITH the version 1 compatibility
> (it's only compatible with the very latest version 1).

I forgot about that sorry.

> So either all clients have to erun out and get version 2 clients (which will
> not work with most version 1 servers, so you'll have to maintain 2 clients)
> or back your sshd down to version 1.

Well, I have both on, now, and I recompile v2 so it was aware of v1.
Supposedly, the v2 daemon will recognize v1 clients and start the v1
server to handle them.

So, everyone try again. If that doesn't work, I'll just scrap v2.

Justin




From bizzaro at bc.edu  Mon Apr 19 18:23:13 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] more GPL command-line software
Message-ID: <371BACD1.69D972C0@bc.edu>

(If you are still on the TULIP list, please switch to the Loci list.)

Locians,

Sean Eddy (Washington U) has been developing GPL, command-line, bioinformatics
programs for several years now:

    http://www.genetics.wustl.edu/eddy/software/

I just wrote to see if he will join the project.  In any case, we may want to
implement some of these programs (on top of the Loci core).


I'll be back,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Mon Apr 19 23:35:30 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Re: phylogenetic gui using pygnome
References: <Pine.LNX.3.96.990419212840.29088A-100000@oeb.harvard.edu>
Message-ID: <371BF602.EE26DC38@bc.edu>

Hi Rick!

Rick Ree wrote:
> 
> Hi, I noticed your openlab entry on freshmeat the other day, and also that
> the pygtk tools website is hosted by you.  I've been working on some
> graphical ui tools for viewing/manipulating phylogenetic trees using
> python and pygtk/pygnome, and have an almost-beta prototype application
> that allows click-and-drag branch swapping, branch rotation, etc. a la
> MacClade.  It's more proof-of-concept than anything else.  Are any of your
> group interested in phylogenies?

Certainly.  We are actually trying to implement phylogenetics into Loci.  We'll
be defining an XML/DTD for it too.

The two guys on the Loci team who have the most interest in phylogenetics are
Thomas Sicheritz (Thomas.Sicheritz@molbio.uu.se) and Tim Triche
(jabbo@mindless.com).  At the very bottom of this message is a reply to Tim from
Thomas.  This may give you some idea about Thomas's interest.

> I've just briefly perused the TULIP/Loci
> list archives, and it seems like a lot of hardcore molecular/structural
> biochem stuff, but nothing regarding phylogenies.

I know someone who would say we talk too much about sequence and not enough
about structure :-)  We're trying to cover all the bases.  And I mean all. 
Although the "core" of Loci will be very basic, the design allows for
practically anything to be added.  (Phylogeny support will be in the core.)

> I believe in the open source model, especially when it comes to scientific
> software toolkits, and started on this project after being fed up with
> closed-source phylogenetic applications that only ran on Macs and/or
> Windows.

I know what you mean.  Try finding anything like DNASTAR or MacVector for UNIX.

> Unfortunately, being a grad student in organismal biology, I
> don't have huge amounts of time to spend writing code.

Just about everyone who is now helping with Loci has told me the same thing ;-)

> But, if you have
> any interest in adding my (alpha-level) python package to your projects
> list, let me know!

Absolutely!

You're welcome to have your own account and Web site for your program.

If you want your code to be used in Loci, we should still put it in a separate
place while both are being developed (do you want a cvs module?).  Since Loci
won't include any stand-alone bioinfo GUI apps (it's hard to explain right now),
we will have to look into making a Loci version of your program later.

BTW, where can we go to check it out?

If you would like to be involved in Loci, please join the mailing list
(pipet-devel):

    http://bioinformatics.org/mailman/listinfo/pipet-devel/

And here is the list for The Open Lab:

    http://bioinformatics.org/mailman/listinfo/theopenlab/

I'll post this message to both lists.

(message from Thomas below!)

Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


Tim writes:
 > 
http://www.inxight.com/Inxight_Corporate_Web_Site/Edu_Org_Program/Intro_to_Program.html
 > 
 > Take a look at this tool...  looks like it could be useful for browsing
 > phylogenetic trees.

Hmm ... :-) ... it looks quite fun ... (look at the spider phylogeny)
We could adapt the rotating/zooming idea to the python phylogentic tool
(pyphy or phypy .. or physpampy ?) 
Actually I really like the idea ... phylogenetic reconstructions tend to get 
large amounts of taxa - which is not easy to see in one window.
I have to write a treeviewer module for my (hopefully) last bigger project
(phylogenomics) in my thesis. I thought I would hack it in Tcl/Tk but with
some help from other loci'ers I could try it in python.

There is no good treeviewing program for all platforms (read: nothing for
Linux and Solaris which doesn't need 8bpp color mode)
I always had some problems to code treeparsing scripts and beeing able to
represent them in a "good" way on the screen (trifurcation, distances etc.)
I could need some help here ... 

I started on some smaller versions where the branches or taxa labels (in my
case SWISSPROT ID's) are linked to yank (sequence retrieval), SWISSPROT
database, blast and clustalw - which should be connected/linked from the
whole genome map/sequence ... that seems to fit perfectly into the LOCI
way of thinking.


From bizzaro at bc.edu  Tue Apr 20 04:32:33 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] expect for Python
Message-ID: <371C3BA1.8F2BB361@bc.edu>

Locians,

Guess what I think is our best candidate for wrapping various command-line
"instruments" (analysis loci)?

You might have heard of "Expect", which is written for Tcl by Don Libes.  Tim
O'Mally wrote a "poor man's Expect" as a Python module.

exploop.py requires eventloop.py.  Both are attached, if anyone wants to play
around with them.


Enjoy,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--
-------------- next part --------------

From Thomas.Sicheritz at molbio.uu.se  Tue Apr 20 04:29:01 1999
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] Re: phylogenetic gui using pygnome
In-Reply-To: <371BF602.EE26DC38@bc.edu>
References: <Pine.LNX.3.96.990419212840.29088A-100000@oeb.harvard.edu>
	<371BF602.EE26DC38@bc.edu>
Message-ID: <14108.14120.306374.480891@beagle.bmc.uu.se>

 > Rick Ree wrote:
 > > 
 > > Hi, I noticed your openlab entry on freshmeat the other day, and also that
 > > the pygtk tools website is hosted by you.  I've been working on some
 > > graphical ui tools for viewing/manipulating phylogenetic trees using
 > > python and pygtk/pygnome, and have an almost-beta prototype application
 > > that allows click-and-drag branch swapping, branch rotation, etc. a la
 > > MacClade.  It's more proof-of-concept than anything else.  Are any of your
 > > group interested in phylogenies?

 > Certainly.  We are actually trying to implement phylogenetics into Loci.  We'll
 > be defining an XML/DTD for it too.
 > 
 > The two guys on the Loci team who have the most interest in phylogenetics are
 > Thomas Sicheritz (Thomas.Sicheritz@molbio.uu.se) and Tim Triche
 > (jabbo@mindless.com).  At the very bottom of this message is a reply to Tim from
 > Thomas.  This may give you some idea about Thomas's interest.

Great - I am currently working on a basic treestructure in python - but if
Rick has the basic tools + the viewing/editing set ... and like to share it 
to theopenlab, I'll be VERY glad ! (I'd rather go directly on the
viewing/editing/manipulating part instead of messing around with treenode
parsing ...)

My current outline is:
* treenode class, reading/parsing NEWICK(phylip) and NEXUS(Paup) tree
  format
* allow for trifurcations !!! (very important, IMHO - most of UNIX tree
  programs can't handle multibranching nodes)
* basic tree manipulation like changing outgroup/nodes, fonts, Taxa names
  directly in the canvas, color-grouping by species/kingdoms
* parsing of rich NEXUS files with additional taxonomy information
  or direct linking to EMBL/SWISS/GenBank, NCBI's taxonomy browser, KEGG etc.
* different views (unrooted, cladogram, phylogram, fishview etc.)
* 2 displays - (whole tree and selected portion)
* colored alignment viewer/editor (?la seaview)
* basic picture editing tools like xpaint

This just happens to be closely related to my next project :-)
- so I can spend a lot of time with that.
If we get the basic structure working - then the rest should be rather easy 
(there is nothing new, just ideas and features from different existing
programs)

Rick - could you contact me directly ?

c ya
-thomas
-- 
Sicheritz Ponten Thomas E.  Department of Molecular Biology
blippblopp@linux.nu         BMC, Uppsala University
BMC:  +46 18 4714214        BOX 590 S-751 24 UPPSALA Sweden
Fax   +46 18  557723        http://evolution.bmc.uu.se/~thomas
Molecular Tcl:   http://evolution.bmc.uu.se/~thomas/tcl
Molecular Linux: http://evolution.bmc.uu.se/~thomas/mol_linux

	De Chelonian Mobile ... The Turtle Moves ...



From Thomas.Sicheritz at molbio.uu.se  Tue Apr 20 04:37:44 1999
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] expect for Python
In-Reply-To: <371C3BA1.8F2BB361@bc.edu>
References: <371C3BA1.8F2BB361@bc.edu>
Message-ID: <14108.15073.269121.951531@beagle.bmc.uu.se>

J.W. Bizzaro writes:
 > Locians,
 > 
 > Guess what I think is our best candidate for wrapping various command-line
 > "instruments" (analysis loci)?
 > 
 > You might have heard of "Expect", which is written for Tcl by Don Libes.  Tim
 > O'Mally wrote a "poor man's Expect" as a Python module.
 > 
 > exploop.py requires eventloop.py.  Both are attached, if anyone wants to play
 > around with them.

I use the expect a lot in our analyses - what is missing in the python
version ? 
Whats the difference to the expect wrapper expy-0.4a.tar.gz  ?

c ya
-thomas
-- 
Sicheritz Ponten Thomas E.  Department of Molecular Biology
blippblopp@linux.nu         BMC, Uppsala University
BMC:  +46 18 4714214        BOX 590 S-751 24 UPPSALA Sweden
Fax   +46 18  557723        http://evolution.bmc.uu.se/~thomas
Molecular Tcl:   http://evolution.bmc.uu.se/~thomas/tcl
Molecular Linux: http://evolution.bmc.uu.se/~thomas/mol_linux

	De Chelonian Mobile ... The Turtle Moves ...



From bizzaro at bc.edu  Tue Apr 20 05:08:27 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:30 2006
Subject: [Pipet Devel] expect for Python
References: <371C3BA1.8F2BB361@bc.edu> <14108.15073.269121.951531@beagle.bmc.uu.se>
Message-ID: <371C440B.E78A68AC@bc.edu>

Thomas.Sicheritz@molbio.uu.se wrote:
> 
> I use the expect a lot in our analyses - what is missing in the python
> version ?

It's obviously a heck of a lot smaller.  And I think Expect-Tcl is compiled C. 
But you probably already know this.

> Whats the difference to the expect wrapper expy-0.4a.tar.gz  ?

>From python.org:

"This refinement of mitch chapman's version [expy] uses a python-based
eventloop, instead of relying on an event loop from an extension, like tkinter."


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Wed Apr 21 14:04:27 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] Description of AMMP
Message-ID: <371E132B.30CA2860@bc.edu>

>From Robert Harrison, for the list:
-------------- next part --------------
An embedded message was scrubbed...
From: my (rwh) mail alias <harrier@asterix.jci.tju.edu>
Subject: Description of AMMP
Date: Wed, 21 Apr 1999 12:37:41 -0400 (EDT)
Size: 6703
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990421/0bef8a35/attachment.mht
From bizzaro at bc.edu  Wed Apr 21 15:11:33 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] another example
Message-ID: <371E22E5.32117245@bc.edu>

"Spock" is a molecule modeler with a secondary structure (protein) editor:

    http://quorum.tamu.edu/spock/sslarge.gif


Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Thu Apr 22 12:53:36 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] more on AMMP
Message-ID: <371F5410.D390317C@bc.edu>

robert w harrison wrote:

> I wasn't sure wether integrating or replicating ammp code was the
> best approach.  Either is fine with me.

I was thinking about something in-between.  We could, as Loci is designed to do,
write a simple wrapper for AMMP and leave it untouched.  But I think it would be
more beneficial if we made a derivative of AMMP that could take better advantage
of Loci, and visa versa.

Loci is also in need of some OpenGL modeling code, which I think can come from
AMMP and be made part of the Loci core.


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Fri Apr 23 03:23:50 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] Sketch (Greg!)
Message-ID: <37202006.23AD75A5@bc.edu>

Sketch is a Python/C/Tk vector drawing program.  It is at release 0.5.5, but the
good news is the soon to be developed 0.7 version will use PyGTK:

    http://www.online.de/home/sketch/

Of course I'm still looking for something that will fill the roll of the slides
(viewers) and stages (figure builders).  This must be a drawing program at it's
core.  So far you may recall I have looked contacted the authors of GILT and
tgif.  The authors had no time to help.  XFIG and GYVE are other options, of
which only GYVE is GTK.   But Sketch is the only one in Python.

This brings up a question for any imaging experts out there:  Would it be more
than trivial to create layers of images so that we can place 2D over 3D, or visa
versa?  I've seen this done with The GIMP, and many games do this.  But what
about mixing image types, like OpenGL and non-OpenGL?

Greg has a very nice OpenGL modeller called mg^2:

    http://www.op.net/~finklesk/download.html

Greg, have you considered using layers and/or combining 2D with 3D?


I shall return,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Fri Apr 23 22:35:09 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] JPEG 2000
Message-ID: <37212DDD.6E94715A@bc.edu>

Just a tidbit, JPEG 2000 will be a very versatile graphics format that _may_ go
a long way toward replacing JPEG, GIF, and other raster formats:

    http://www.zdnet.com/zdnn/stories/news/0,4586,2245956,00.html

Perhaps an optional format for image export in Loci?


Ciao,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Sat Apr 24 14:54:50 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] CORBA 3.0 POSTMORTEM
Message-ID: <3722137A.9F0ED11A@bc.edu>

This article speculates that OMG will use Java as the "middle tier" for CORBA:

    http://www.objectwatch.com/issue19.htm    (about 1/5th down the page)

Interesting.  I have seen a lot of Java/CORBA projects lately.


BTW, where's Carlos?


Cheers,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Sun Apr 25 07:13:01 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] News from Bioinformatics
Message-ID: <3722F8BD.2FD1FA6E@bc.edu>

Hi guys.

I set up a news posting program on the server.  It allows anyone with the
correct return address to e-mail news items, and they are automatically inserted
into the page.  Check out the main page:

    http://bioinformatics.org/

This gives me an idea.  I was thinking of having news items in the jounral
(JOTOL), but we could have unedited items on the main page, and have sort of a
Slashdot for bioinformatics.

If you would like to submit a news item that relates to the field of
bioinformatics, please send it to me.  Or, if you'd like to be able to mail in
your own items, let me know.

News posted could be about any research, breakthroughs, programs, organizations,
companies, products.  It doesn't even matter to me if it is an advertisement.

The site of course has just been put together. We get about 20 unique hits a
day, and with interesting news items, we should get more.


Aloha,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--


From bizzaro at bc.edu  Wed Apr 28 15:04:09 1999
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:31 2006
Subject: [Pipet Devel] pyphy and mailing list
Message-ID: <37275BA9.5F39D04@bc.edu>

Salutations.

Thomas and Rick are developing a collection of Python + GTK modules for
phylogenetics.  It is called "pyphy" and is of course hosted by TOL.

If you'd like to join the mailing list, go to this page:

    http://bioinformatics.org/mailman/listinfo/pyphy

The Web site will be at this URL:

    http://bioinformatics.org/pyphy/


Buh-bye,
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro@bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--