From bizzaro at bc.edu Tue Dec 8 17:47:56 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:05 2006
Subject: [Pipet Devel] using XML
Message-ID: <366DAC92.38C222C3@bc.edu>
There is one very nice feature of using XML as a protocol, that I haven't
mentioned yet: Standard XML (like BSML or CML) is viewable via Web
browser...it will someday be almost as common as HTML. So, if TULIP uses BSML
and CML, then TULIP tool communication over the Web via HTTP (to browsers or
other tools) will be rather simple. Imagine a TULIP tool that may only run on
an SGI, and that tool being able to communicate with other TULIP tools on a
Linux box, simply via HTTP. (Of course, you may argue that you can set up
tools across a network many other ways, but you can't without an account,
etc...this is the whole reason why the Web is so popular.)
Here is my argument for using XML with TULIP:
Premise:
(1) All complex communication requires a structured protocol
(2) TULIP ought to have a protocol that is established
(3) TULIP ought to have a protocol that is language-independent
(4) " " " " " " " " platform-independent
(5) XML is an established, language-independent, and platform-independent
structured protocol...plus it is (inter)net-workable, as I wrote above.
Conclusion:
TULIP ought to use XML.
If anyone has a better idea, let me know. I think XML was developed for our
kind of problem.
Sure, all communication via stdio and ASCII will be slower than with other
options, but when the tools all run on the same machine, we won't know the
difference...we're not talking about the constant updating of information
anyway; it will be requested only when the user presses some button...like a
Web browser.
But don't miss this point I made once before: TULIP tools may behave like
browsers by using XML, but they won't just display hypertext; that's HTML's
job. We can use BSML and CML to make some very non-Web-browser type
interfaces, that are very interactive.
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From hinsen at cnrs-orleans.fr Wed Dec 9 10:09:16 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:05 2006
Subject: [Pipet Devel] using XML
In-Reply-To: <366DAC92.38C222C3@bc.edu> (bizzaro@bc.edu)
References: <366DAC92.38C222C3@bc.edu>
Message-ID: <199812091509.QAA14820@dirac.cnrs-orleans.fr>
> There is one very nice feature of using XML as a protocol, that I haven't
> mentioned yet: Standard XML (like BSML or CML) is viewable via Web
> browser...it will someday be almost as common as HTML. So, if TULIP uses BSML
Wait and see... In principle this should be possible, but a browser
that can display any XML file for which an XSL stylesheet exists
is not going to be a simple program, and not likely to be available
very soon. The XSL definition isn't even ready yet as far as I know.
It remains to be seen what XML support the next browser generation
will provide.
But I totally agree in principle: lots of people will produce lots
of tools for XML, so we would be stupid not to profit from that!
> Linux box, simply via HTTP. (Of course, you may argue that you can set up
> tools across a network many other ways, but you can't without an account,
> etc...this is the whole reason why the Web is so popular.)
More and more programs are using the Web as a kind of user interface.
I suspect this won't be enough for all aspects of TULIP, but it's
a nice option where applicable. The main limitation is data manipulation,
which is either limited to forms or requires Java or JavaScript, and
that's a big mess.
I expect the main use of XML in TULIP to be data storage - one format
that all tools understand, and which many non-TULIP tools will soon
understand as well. As far as communication between tools requires
passing complex data structures, XML fits the bill. But let's not
overdo it; there's no point in sending an XML document where a
five-character command line argument would be sufficient!
> But don't miss this point I made once before: TULIP tools may behave like
> browsers by using XML, but they won't just display hypertext; that's HTML's
> job. We can use BSML and CML to make some very non-Web-browser type
> interfaces, that are very interactive.
Which reminds me: perhaps we can steal browser-type code from Grail!
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 hinsen at cnrs-orleans.fr Thu Dec 10 07:49:15 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:05 2006
Subject: [Pipet Devel] using XML
In-Reply-To: <366EE386.AE3CEA3F@bc.edu> (bizzaro@bc.edu)
References: <366DAC92.38C222C3@bc.edu> <199812091509.QAA14820@dirac.cnrs-orleans.fr> <366EE386.AE3CEA3F@bc.edu>
Message-ID: <199812101249.NAA26286@dirac.cnrs-orleans.fr>
> My mistake. I saw the screenshot of MMTK, and I thought that it had its own
> GUI. Is that VMD or something displaying the molecule?
Right. And I am happy enough with VMD for display, especially for
producing publication-quality images (via POVRay). But I don't see
much hope for interactive manipulation via VMD any time soon, and
for quick visualization jobs it's a bit slow.
Ideally there would be a "molecular visualization widget" with all of
VMD's visualization features, using OpenGL for speed. It would be
suitable for inclusion into GUIs (Tk and/or GTK) and provide all the
callback hooks necessary to implement interactive manipulation of
structures.
That's for all of you who don't know what to do in their spare time!
> > Which reminds me: perhaps we can steal browser-type code from Grail!
>
> I thought of that. Grail is written in Python. Plus there is a nice HTML
> widget for GNOME. But again, the tools don't have to look like Web browsers to
> use XML, do they?
No, but for some aspects (e.g. an on-line manual) a traditional browser
is just fine.
Anyway, after all these theoretical discussions, how about something
more concrete: a TULIP wish list. What kinds of operations would
everyone like to see implemented? I must confess that this is still
rather unclear to me.
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 bizzaro at bc.edu Thu Dec 31 16:52:07 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:05 2006
Subject: [Pipet Devel] some news on XML
Message-ID: <368BF207.BE14608@bc.edu>
Here is a news item on XML that you might find interesting:
http://www.news.com/News/Item/0%2C4%2C30429%2C00.html?dd.ne.tx.fs2.1231
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From bizzaro at bc.edu Wed Dec 9 15:54:30 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:05 2006
Subject: [Pipet Devel] using XML
References: <366DAC92.38C222C3@bc.edu> <199812091509.QAA14820@dirac.cnrs-orleans.fr>
Message-ID: <366EE386.AE3CEA3F@bc.edu>
Thanks Konrad, for all the feedback!
Konrad Hinsen wrote:
> There's nothing to port, MMTK does not deal with user interfaces. MMTK
> is just the library for the computational stuff. I'd like to see TULIP
My mistake. I saw the screenshot of MMTK, and I thought that it had its own
GUI. Is that VMD or something displaying the molecule?
> evolve as a complement of MMTK. MMTK handles operations on
> macromolecular structures, but there will be non-structural operations
> as well, which should be implemented in a similar kind of low-level
> library. And then there would be the end-user programs on top of all
> that, which is where GTK comes into play. So TULIP would be both for
> end users and for developers. Or perhaps it might be better to
> separate these two tasks and use different names - but that's not an
> urgent decision.
Hmmm. A non-graphical, operations library for TULIP. I haven't considered
that. We'll keep that in mind!
> But I totally agree in principle: lots of people will produce lots
> of tools for XML, so we would be stupid not to profit from that!
Yes!
> a nice option where applicable. The main limitation is data manipulation,
> which is either limited to forms or requires Java or JavaScript, and
> that's a big mess.
...for an HTML browser. Maybe we can go beyond simple text and forms with our
tools. However, we must not make XML code that incompatible with the big XML
projects, like XML in a Web browser.
> passing complex data structures, XML fits the bill. But let's not
> overdo it; there's no point in sending an XML document where a
> five-character command line argument would be sufficient!
For a non-interactive, non-core tool, a command line argument will be passed, by
user request, to this tool. I think the main role of XML is in formatting the
data that is *returned*. So, instead of this program printf-ing plain text as
the output, it adds a few XML markers. This is why I think XML is so simple.
It doesn't require any new functions or routines...just a few more print
statements :-)
> Which reminds me: perhaps we can steal browser-type code from Grail!
>
I thought of that. Grail is written in Python. Plus there is a nice HTML
widget for GNOME. But again, the tools don't have to look like Web browsers to
use XML, do they?
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From jabbo at mindless.com Thu Dec 3 13:15:12 1998
From: jabbo at mindless.com (Tim)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] free space for project details!
References: <199811260813.JAA27781@beagle.bmc.uu.se>
<3666A98C.D5B45AE4@bc.edu> <13926.40059.290327.682131@beagle.bmc.uu.se> <3666DE46.88E80CFF@bc.edu>
Message-ID: <3666D530.80CD5C3C@mindless.com>
Hey, I just had an idea. www.lowrent.org is hosting sites for open
source projects. Perhaps a website there with pointers to
already-finished stuff, related projects, and people working on tulip
woud be neat?
I believe all that has to be done is the project originator fills out
this form:
http://lowrent.org/apply.shtml
and they forward mail adressed to, say, "tulip@lowrent.org" to your
address, and hand you 5 MB of space (more than enough for some text,
screenshots, and some pages with pointers to ftp site) at
lowrent.org/tulip/ to describe the project, bugs, current status, etc.
Anyways, the reason I noticed this is that someone wrote a flag parser
and had their site hosted at lowrent. Either that or because ml.org
died, either way.
--
"Every man is guilty of all the good he didn't do."
--Voltaire
From bizzaro at bc.edu Thu Dec 3 13:53:58 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] Thomas joins!
References: <199811260813.JAA27781@beagle.bmc.uu.se>
<3666A98C.D5B45AE4@bc.edu> <13926.40059.290327.682131@beagle.bmc.uu.se>
Message-ID: <3666DE46.88E80CFF@bc.edu>
Konrad, Jay, Tim,
Thomas Sicheritz, from Uppsala University in Sweden, will be joining the TULIP
development team. He created the "Molecular Linux" Web site.
Thomas,
I will send you the first e-mail's that Konrad and I sent to each other, plus
the last few e-mails. We've been discussing the use of CML, the Chemical Markup
Language, by Peter Murray Rust. We would like to use an XML for structure info.
Jeff
bizzaro@bc.edu
Thomas.Sicheritz@molbio.uu.se wrote:
>
> Hej Jeff,
>
> > Just wondering if you got my last e-mail. If you want to contribute to
> > TULIP, I'll put you on the mailing list and send you some of the latest
> > messages.
>
> Sorry for not replying ... right now I have a mess in my mailbox ..
>
> Sure - I'd love to help with this project - please put me on the list and
> give me some background information.
>
> 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 ...
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From bizzaro at bc.edu Thu Dec 3 14:39:01 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] free space for project details!
References: <199811260813.JAA27781@beagle.bmc.uu.se>
<3666A98C.D5B45AE4@bc.edu> <13926.40059.290327.682131@beagle.bmc.uu.se> <3666DE46.88E80CFF@bc.edu> <3666D530.80CD5C3C@mindless.com>
Message-ID: <3666E8D5.5A7916F8@bc.edu>
Tim,
Thanks. I'll look it over. I was hoping to get a dedicated server set up at
UMass Lowell for TULIP, something like "tulip.bicgroup.org" or
"tulip.bicgroup.uml.edu". The BIC Group, by the way, is a research center there
that is made up of researchers from many different places, yours truly being one
of them :-)
Jeff
bizzaro@bc.edu
Tim wrote:
>
> Hey, I just had an idea. www.lowrent.org is hosting sites for open
> source projects. Perhaps a website there with pointers to
> already-finished stuff, related projects, and people working on tulip
> woud be neat?
>
> I believe all that has to be done is the project originator fills out
> this form:
>
> http://lowrent.org/apply.shtml
>
> and they forward mail adressed to, say, "tulip@lowrent.org" to your
> address, and hand you 5 MB of space (more than enough for some text,
> screenshots, and some pages with pointers to ftp site) at
> lowrent.org/tulip/ to describe the project, bugs, current status, etc.
>
> Anyways, the reason I noticed this is that someone wrote a flag parser
> and had their site hosted at lowrent. Either that or because ml.org
> died, either way.
>
> --
>
> "Every man is guilty of all the good he didn't do."
>
> --Voltaire
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From bizzaro at bc.edu Thu Dec 3 16:31:16 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] free space for project details!
References: <199811260813.JAA27781@beagle.bmc.uu.se>
<3666A98C.D5B45AE4@bc.edu> <13926.40059.290327.682131@beagle.bmc.uu.se> <3666DE46.88E80CFF@bc.edu> <3666D530.80CD5C3C@mindless.com>
Message-ID: <3667031E.27E5FEE1@bc.edu>
I checked out the site Tim. It looks like an option we'll keep in mind.
Right now TULIP is on the UMass Lowell server, and I have pretty good access
to it...It's running DEC UNIX on an Alpha with Netscape's server.
Do you guys think the URL is rather long? I think so.
As I mentioned, I want to hook up a sever at Lowell that is pretty much
dedicated to TULIP. The great advantage of this is, of course, I will not be
restricted regarding CGI, etc., and I will be able to set up a mailing list
using "majordomo".
I'd love to have "tulip.org", but that's taken by some church :-) Check it out.
By the way, I would like to get an idea as to how much time we are each able
to put into TULIP next semester, or first half of '99. Choose one below:
A whole lot: >10 hours per week
Quite a bit: 7-9 "
Here and there: 4-6 "
Very little: <1-3 "
The problem I have is that I am at the end of the second year of my Ph.D.
program, which is the toughest time of all. This means I have a research
proposal to write in January, oral exams in June, plus cumulative exams each
month...and I have to take a course in quantum chemistry and continue with my
research an teach! So, for the next seven months, I will be in the "here and
there" category, and maybe even "very little". I would love nothing more than
to work full time on this, but we all know this won't put food in our mouths ;-)
Jeff
bizzaro@bc.edu
Tim wrote:
>
> Hey, I just had an idea. www.lowrent.org is hosting sites for open
> source projects. Perhaps a website there with pointers to
> already-finished stuff, related projects, and people working on tulip
> woud be neat?
>
> I believe all that has to be done is the project originator fills out
> this form:
>
> http://lowrent.org/apply.shtml
>
> and they forward mail adressed to, say, "tulip@lowrent.org" to your
> address, and hand you 5 MB of space (more than enough for some text,
> screenshots, and some pages with pointers to ftp site) at
> lowrent.org/tulip/ to describe the project, bugs, current status, etc.
>
> Anyways, the reason I noticed this is that someone wrote a flag parser
> and had their site hosted at lowrent. Either that or because ml.org
> died, either way.
>
> --
>
> "Every man is guilty of all the good he didn't do."
>
> --Voltaire
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From Thomas.Sicheritz at molbio.uu.se Fri Dec 4 05:12:09 1998
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] free space for project details!
In-Reply-To: <3667031E.27E5FEE1@bc.edu>
References: <199811260813.JAA27781@beagle.bmc.uu.se>
<3666A98C.D5B45AE4@bc.edu>
<13926.40059.290327.682131@beagle.bmc.uu.se>
<3666DE46.88E80CFF@bc.edu>
<3666D530.80CD5C3C@mindless.com>
<3667031E.27E5FEE1@bc.edu>
Message-ID: <13927.45608.210389.549379@beagle.bmc.uu.se>
J.W. Bizzaro writes:
> By the way, I would like to get an idea as to how much time we are each able
> to put into TULIP next semester, or first half of '99. Choose one below:
>
> A whole lot: >10 hours per week
> Quite a bit: 7-9 "
> Here and there: 4-6 "
> Very little: <1-3 "
>
> The problem I have is that I am at the end of the second year of my Ph.D.
> program, which is the toughest time of all. This means I have a research
> proposal to write in January, oral exams in June, plus cumulative exams each
> month...and I have to take a course in quantum chemistry and continue with my
> research an teach! So, for the next seven months, I will be in the "here and
> there" category, and maybe even "very little". I would love nothing more than
> to work full time on this, but we all know this won't put food in our mouths ;-)
So I thuoght my last Ph.D stud. year is the toughest ...
I haven't got the general overview yet and I don't know exactly how I am
going to make myself usefull ...
I guess everything from "very little" to "Here and there" depending on my
other projects ...
Could you give me a short outline over "what's done",
"what's planned/decided" and "what would be nice to have" ...
How are the different language modules communicating with the python core ?
( In my case - how would I glue tcl/tk/expect modules to the core ?)
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 Dec 4 07:18:12 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Fwd: [Pipet Devel] free space for project details!]
Message-ID: <3667D304.6B45C3EF@bc.edu>
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
-------------- next part --------------
An embedded message was scrubbed...
From: Thomas.Sicheritz@molbio.uu.se
Subject: Re: [Pipet Devel] free space for project details!
Date: Fri, 4 Dec 1998 11:12:09 +0100 (MET)
Size: 3368
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19981204/111b0bcc/attachment.mht
From bizzaro at bc.edu Sun Dec 6 22:59:51 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] updated model
Message-ID: <366B52B7.A006F76C@bc.edu>
Guys:
Tom brought to my attention that we have very little background information
posted for the TULIP project. I did have "some thoughts" on the Web site, but I
took it off before Tim and Tom joined, because it was getting a little
outdated. I will write something new shortly to answer his questions and those
that others may have about the project. As Tom suggested: (1) What's done, (2)
what's decided, and (3) what's to come.
Konrad:
Tom also asked how someone might add TULIP tools that are not written in Python
or C, say Tcl. We have of course recently discussed how tools might be added in
a CGI-like fashion using XML. But you mentioned that you have experience mixing
various languages directly with Python--by linking them with C? Could you
please write a paragraph for us describing how calls to various languages from
Python is done (you're the Python expert here ;-)?
Quoting Konrad:
> No problem. I am using Fortran routines called from Python regularly.
> The only complication is that C/Fortran linking is machine dependent,
> which makes automatic installation difficult (but not impossible).
Tom:
We will only use Python and C for the *core* distribution of TULIP. This is to
keep it as simple as possible. When we say that any language can be added, we
mean it is added on top of the core. We also want to keep the GUI consistent,
so we will only endorse the use of GTK/GNOME. I think there are many excellent
reasons for using this widget set. There are Python-GTK and Python-GNOME
bindings by James Henstridge, so any language that can work with Python can work
with GTK/GNOME.
Guys:
We also need a list of core TULIP tools that need to be ported to TULIP and/or
developed. Describe some tools for me that *you* think should be in a
bioinformatics/modelling package.
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From bizzaro at bc.edu Mon Dec 7 01:15:52 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] GUI widget set
Message-ID: <366B7298.1AEADEC0@bc.edu>
Guys,
It just occured to me that you may not all agree regarding the use of the GTK
widget set. In fact, Konrad and Thomas (sorry if you don't like being called
Tom) have used Ousterhout's Tk widget set: Konrad used Python/Tkinter in MMTK
and Thomas used Tcl/Tk in BioWish and GRS.
If any of you think we should reconsider our choice widget sets, please speak
up. I might be willing to switch to Tk if I find the reasons compelling. In
any case, I don't want anyone to walk away from the project over this.
Pleeeeeeeeeeease don't go! :-)
What are the pros and cons of each? This is what I think:
Tk GTK
========== =============
Pro: Multiplatform Con: UNIX only for now
Con: Tkinter requires Tcl Pro: Bindings to many languages are being
made
Con: Rather large and slow Pro: Python/GTK seems faster
Con: Looks like old Motif Pro: Modern look and Theme-able
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From Thomas.Sicheritz at molbio.uu.se Mon Dec 7 03:58:46 1998
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] updated model
In-Reply-To: <366B5186.955E27A1@bc.edu>
References: <366B5186.955E27A1@bc.edu>
Message-ID: <13931.31950.756556.671759@beagle.bmc.uu.se>
J.W. Bizzaro writes:
>
> We will only use Python and C for the *core* distribution of TULIP.
> This is to keep it as simple as possible. When we say that any language
> can be added, we mean it is added on top of the core. We also want to
> keep the GUI consistent, so we will only endorse the use of GTK/GNOME.
> I think there are many excellent reasons for using this widget set.
> There are Python-GTK and Python-GNOME bindings by James Henstridge, so
> any language that can work with Python can work with GTK/GNOME.
So the other language modules are going to communicate with the core via
e.g. XML ?
> We also need a list of core TULIP tools that need to be ported to TULIP
> and/or developed. Describe some tools for me that *you* think should be
> in a bioinformatics/modelling package.
I can tell about some tools needed for sequence analysis ...
P=port D=develop
high priority:
* P/D basic sequence format conversions (readseq)
* P sequence alignment (clustalw)
* P/D colored alignment viewer/editor, like seaview
* P setting up and maintain sequence databases like SWISS, EMBL
* P local blast service
* D interface to www blast
* D/P tools to manage blast results
* P Sequence retrieval System (SRS)
* P phylogenetic tools FREE: ( PHYLIP package, Tools from Lyon)
not quite so high priority:
* D simple database engine and interface for ??? LabResults/Sequences ...
* D phylogenetic tools PAY: - integration of PAUP*
* D/P Primer picking
* D/P integration of Sequence assembly programs, like STADEN, Phred&Phrap
* D management of genome sequences
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 Mon Dec 7 04:15:47 1998
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] GUI widget set
In-Reply-To: <366B7298.1AEADEC0@bc.edu>
References: <366B7298.1AEADEC0@bc.edu>
Message-ID: <13931.39177.408898.128661@beagle.bmc.uu.se>
J.W. Bizzaro writes:
> Guys,
>
> It just occured to me that you may not all agree regarding the use of
> the GTK widget set. In fact, Konrad and Thomas (sorry if you don't like
> being called Tom)
thats ok ... :-)
> have used Ousterhout's Tk widget set: Konrad used
> Python/Tkinter in MMTK and Thomas used Tcl/Tk in BioWish and GRS.
>
> If any of you think we should reconsider our choice widget sets, please
> speak up. I might be willing to switch to Tk if I find the reasons
> compelling. In any case, I don't want anyone to walk away from the
> project over this. Pleeeeeeeeeeease don't go! :-)
I have no experience at all with GTK ...
- but I like the GNU idea - which is only covered by Python and GTK ...
> What are the pros and cons of each? This is what I think:
>
> Tk GTK
> ========== =============
> Pro: Multiplatform Con: UNIX only for now
Most of the Sequence Analysis tools are for UNIX only ...
> Con: Tkinter requires Tcl Pro: Bindings to many languages are being made
> Con: Rather large and slow Pro: Python/GTK seems faster
> Con: Looks like old Motif Pro: Modern look and Theme-able
What's wrong with Motif, No-one considering SunOS OpenWindows widgets :-)
I mostly agree with this list - the core should have a rather fast widget set.
- what is necessary is that people can easily add their own modules written in
Tcl/Tk , perlTK, Vibrant, Motif e.t.c.
It would be nice to have a interpreter for both perl and tcl in the core
distribution (not the core) .. (shared, loadable libraries ???)
My opinion: stay with Python/GTK ...
-with tcl/tk it would not be a real GNU project ... would it ?
-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 hinsen at cnrs-orleans.fr Mon Dec 7 08:33:01 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] GUI widget set
In-Reply-To: <366B7298.1AEADEC0@bc.edu> (bizzaro@bc.edu)
References: <366B7298.1AEADEC0@bc.edu>
Message-ID: <199812071333.OAA18056@dirac.cnrs-orleans.fr>
> It just occured to me that you may not all agree regarding the use of the GTK
> widget set. In fact, Konrad and Thomas (sorry if you don't like being called
> Tom) have used Ousterhout's Tk widget set: Konrad used Python/Tkinter in MMTK
> and Thomas used Tcl/Tk in BioWish and GRS.
I used Tk because it was the only reasonable choice when I started
my project, and also because it was easier to get started with
(more examples etc.). But I also found out about its disadvantages,
and I have no problem with trying something else. I don't have much
personal experience with GTK yet, but I am impressed by its use
in other programs.
> Tk GTK
> ========== =============
> Pro: Multiplatform Con: UNIX only for now
> Con: Tkinter requires Tcl Pro: Bindings to many languages are being
> made
> Con: Rather large and slow Pro: Python/GTK seems faster
> Con: Looks like old Motif Pro: Modern look and Theme-able
I find Tk's look quite acceptable, but I agree that it's large and
slow. I don't like writing Tcl code at all, but I don't mind linking
with Tcl as long as all I interact with is Python!
The most serious issue could be the multiplatform support. Personally
I am happy with Unix, but I know that more and more people are forced
to use Windows, even if they don't like it. It would be good to know
how GTK is going to develop. Does anyone have insider information on this?
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 hinsen at cnrs-orleans.fr Mon Dec 7 08:36:03 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] free space for project details!
In-Reply-To: <3667031E.27E5FEE1@bc.edu> (bizzaro@bc.edu)
References: <199811260813.JAA27781@beagle.bmc.uu.se>
<3666A98C.D5B45AE4@bc.edu> <13926.40059.290327.682131@beagle.bmc.uu.se> <3666DE46.88E80CFF@bc.edu> <3666D530.80CD5C3C@mindless.com> <3667031E.27E5FEE1@bc.edu>
Message-ID: <199812071336.OAA21048@dirac.cnrs-orleans.fr>
> Do you guys think the URL is rather long? I think so.
I don't care for the moment. Once the project goes public a good
URL becomes relevant, but by then the whole Internet might have
changed ;-)
> By the way, I would like to get an idea as to how much time we are each able
> to put into TULIP next semester, or first half of '99. Choose one below:
>
> A whole lot: >10 hours per week
> Quite a bit: 7-9 "
> Here and there: 4-6 "
> Very little: <1-3 "
For me it's oscillating between "very little" and "here and there"!
> The problem I have is that I am at the end of the second year of my Ph.D.
> program, which is the toughest time of all. This means I have a research
Obviously you are an optimist: you expect it to get better later ;-)
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 Mon Dec 7 09:18:08 1998
From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] GUI widget set
In-Reply-To: <199812071333.OAA18056@dirac.cnrs-orleans.fr>
References: <366B7298.1AEADEC0@bc.edu>
<199812071333.OAA18056@dirac.cnrs-orleans.fr>
Message-ID: <13931.56853.764339.642274@beagle.bmc.uu.se>
Konrad Hinsen writes:
> I used Tk because it was the only reasonable choice when I started
> my project, and also because it was easier to get started with
> (more examples etc.). But I also found out about its disadvantages,
> and I have no problem with trying something else. I don't have much
> personal experience with GTK yet, but I am impressed by its use
> in other programs.
I tested Motif :-( and sticked to Tcl/Tk ... most because its very easy to
start and to extend.
But I can imagine testing something else too ... after all the GIMP's basic
model has some similarities to TULIP - and the GIMP made REALLY progress
.. so why not ?
> The most serious issue could be the multiplatform support. Personally
> I am happy with Unix, but I know that more and more people are forced
> to use Windows, even if they don't like it. It would be good to know
> how GTK is going to develop. Does anyone have insider information on this?
I cannot imagine "high throughput sequence analysis" on a Mac or a Windows
platform ... on the other hand, for small lab applications both of them are
ok.
Craig Setera (setera@infonet.isl.net) has a port of GTK+GIMP for win95 -
currently needing a X-server for win95, but according to his page this is
just
"a stop-gap until the in-progress native port of GTK and the
GIMP are completed."
http://members.xoom.com/setera/gimp/gimpw32.html
So maybe until basic TULIP is running, GTK is allready ported to the
other OS?
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 hinsen at cnrs-orleans.fr Mon Dec 7 10:39:46 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] updated model
In-Reply-To: <366B5186.955E27A1@bc.edu> (bizzaro@bc.edu)
References: <366B5186.955E27A1@bc.edu>
Message-ID: <199812071539.QAA24388@dirac.cnrs-orleans.fr>
> Konrad:
>
> Tom also asked how someone might add TULIP tools that are not written in Python
> or C, say Tcl. We have of course recently discussed how tools might be added in
> a CGI-like fashion using XML. But you mentioned that you have experience mixing
> various languages directly with Python--by linking them with C? Could you
Direct linking requires that
1) the code to be included uses a library approach, i.e. has callable
subroutines, as opposed to an executable with its own user interface
2) the code is written in a low-level compiled language (C, C++, Fortran,
Pascal, perhaps others).
Another general class of code that is easy to integrate from Python
are the classical Unix-style command line tools (whatever language
they are written in), i.e. programs that read from standard input
and write their results to standard output.
Programs with an interactive (but non-graphic) interface can be
integrated via PyExpect, but I have little personal experience with
that approach. With graphical interfaces I see no reasonable solution
at all.
> Tom:
>
> We will only use Python and C for the *core* distribution of TULIP. This is to
> keep it as simple as possible. When we say that any language can be added, we
We might consider C translations (via f2c) of Fortran tools as well.
If people want the extra performance given by a real Fortran compiler,
they can always get the Fortran code and take care of the installation
themselves.
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 bizzaro at bc.edu Mon Dec 7 13:43:36 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] updated model
References: <366B5186.955E27A1@bc.edu> <199812071539.QAA24388@dirac.cnrs-orleans.fr>
Message-ID: <366C21CB.7DC63D5@bc.edu>
Konrad Hinsen wrote:
> Another general class of code that is easy to integrate from Python
> are the classical Unix-style command line tools (whatever language
> they are written in), i.e. programs that read from standard input
> and write their results to standard output.
This is the class for which I would use a CGI/XML approach. I think most
analysis algorithms are not, nor need to be, interactive. For the most part,
simple algorithms can read from stdin or a file and write to stdout or a file.
Thomas wrote:
> So the other language modules are going to communicate with the core via
> e.g. XML ?
Yes, this is one approach. The other is to link languages to Python via C.
If someone is willing, the best approach would be to use Python to begin with
:-) I think this is something we need to keep working on. The key technical
issue here is how can we make TULIP language-independent?
Konrad Hinsen wrote:
> Programs with an interactive (but non-graphic) interface can be
> integrated via PyExpect, but I have little personal experience with
> that approach.
Yes, we will consider the case for which PyExpect can be used. But for the
core TULIP tools, we should have everything in Python or C, with a strong
emphasis on Python: The only situations where C should be used are (1) for
compute-intensive routines, and (2) custom GTK widgets (otherwise, I would
like to use the standard Python-GTK widget bindings).
Konrad Hinsen wrote:
> With graphical interfaces I see no reasonable solution
> at all.
But even graphical programs can utilize stdin and stdout. If they can do
that, we have communication.
Konrad Hinsen wrote:
> We might consider C translations (via f2c) of Fortran tools as well.
> If people want the extra performance given by a real Fortran compiler,
> they can always get the Fortran code and take care of the installation
> themselves.
Konrad, you mentioned that you can link Fortran and C, and then wrap the C in
Python. Is that right? Can you give us some details?
Thomas wrote:
> But I can imagine testing something else too ... after all the GIMP's basic
> model has some similarities to TULIP - and the GIMP made REALLY progress
> .. so why not ?
Yes, I actually used to say that on the Web site. Interesting you should
notice that. And I too have heard of the GIMP being ported to Windows.
Konrad wrote:
> The most serious issue could be the multiplatform support. Personally
> I am happy with Unix, but I know that more and more people are forced
> to use Windows, even if they don't like it. It would be good to know
> how GTK is going to develop. Does anyone have insider information on this?
TULIP is meant to be extremely graphical and easy to use, much like the Mac.
This is because most molecular biologists (in my opinion) are not the type to
want to work with cryptic commands. I think this need by molecular biologists
for graphical applications led to the ubiquity of Macs in the lab. I don't
know about where you guys work, but all we have in the labs here are Macs. I
therefore believe a port to the Mac may be more important than a port to Windows.
Regarding how we will make the transition from UNIX to Mac or Windows, we
probably all agree that Python is the key: The more Python we use over the
binary stuff, the easier our port will be. As far as GTK is concerned, I too
think that it may be a matter of time before it is ported to Windows and Mac.
So, by the time TULIP is ready, we may already have GTK on these platforms.
By the way, Konrad, what do you think we need for structural analysis in the
*core* distribution of TULIP...the most important tools that may be accessed
by other tools?
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From bizzaro at bc.edu Mon Dec 7 17:10:35 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] GNOME canvas
Message-ID: <366C523A.34241E64@bc.edu>
Guys, below is a description by Miguel de Icaza of the GNOME Canvas widget,
which is modeled after the Tk Canvas. I think Konrad and Thomas will be
pleased that GTK/GNOME has a familiar component. Jeff
Canvas
GNOME provides a Canvas widget, patterned after Tk's excellent canvas. This
widget simplifies the programming of applications that need control over
graphical components. The most noticeable feature of the GNOME Canvas is that
it provides a flicker-free drawing area where high-level objects can be
inserted and manipulated. Basic zoom and scroll facilities are also a part of
the canvas.
The high-level objects inserted into the canvas behave like regular widgets.
They can receive X events, they can grab the focus, and they can grab the
mouse just like a regular widget. As with their Tk counterparts, the GNOME
Canvas items can have their properties changed at runtime with a Tk-like
configuration mechanism.
The GNOME Canvas ships with a number of items derived from the GnomeCanvasItem
object: lines, rectangles, ellipses, arrows, polylines and a generic widget
container to embed GTK+ widgets within a canvas. The Canvas framework is
designed to be very extensible. As proof of this extensibility, the GNOME
spreadsheet is implemented on top of the base canvas engine, with additional
functionality provided by spreadsheet-specific CanvasItems.
Note that the current Canvas uses Gdk primitives (a thin wrapper over Xlib
primitives) to draw, so it is limited in the quality and range of special
effects that can be provided with it, which bring us to the next step in
Canvas technology.
Raph Levien is working on an advanced rendering engine for the Canvas. It was
originally developed as a stand-alone widget within his Type1 outline font
editor, gfonted. As of the time of this writing, work on integrating the
engine into the Canvas is getting underway.
Features of this engine include:
Anti-aliased rendering of all items
Alpha transparency
Items for vector and bezier paths
Items for RGB and RGB plus alpha images
Vector operations, including clip (intersect), union, difference and
stroke layout
PostScript Type1 font loading and rendering
The engine's design goal is to support almost all of the PostScript imaging
model with the addition of alpha transparency. As such, it is expected to be
an excellent starting point for high-powered graphics applications.
In spite of the ambitious goal of keeping the display up to date with entirely
anti-aliased and alpha-composited items, performance is surprisingly
good--comparable in fact to the Xlib-primitive-based canvas engine.
His code is expected to be merged into the main Canvas sometime soon.
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From hinsen at cnrs-orleans.fr Tue Dec 8 05:58:27 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:10 2006
Subject: [Pipet Devel] updated model
In-Reply-To: <366C21CB.7DC63D5@bc.edu> (bizzaro@bc.edu)
References: <366B5186.955E27A1@bc.edu> <199812071539.QAA24388@dirac.cnrs-orleans.fr> <366C21CB.7DC63D5@bc.edu>
Message-ID: <199812081058.LAA22400@dirac.cnrs-orleans.fr>
> > Another general class of code that is easy to integrate from Python
> > are the classical Unix-style command line tools (whatever language
> > they are written in), i.e. programs that read from standard input
> > and write their results to standard output.
>
> This is the class for which I would use a CGI/XML approach. I think most
I am not quite sure what you mean by that. XML can be used only between
programs that understand XML, so very probably none of the existing
analysis programs that we want to include. And CGI is a technique used
for Web servers.
> analysis algorithms are not, nor need to be, interactive. For the most part,
> simple algorithms can read from stdin or a file and write to stdout or a file
Sure, but if the authors of the programs decided that a curses-based
user interface would be nicer, we have to live with that!
> Yes, we will consider the case for which PyExpect can be used. But for the
> core TULIP tools, we should have everything in Python or C, with a strong
> emphasis on Python: The only situations where C should be used are (1) for
> compute-intensive routines, and (2) custom GTK widgets (otherwise, I would
> like to use the standard Python-GTK widget bindings).
Obviously. That's the easy case. What we need to worry about is legacy
code that we want to reuse.
> But even graphical programs can utilize stdin and stdout. If they can do
> that, we have communication.
Yes, *if* they do!
> Konrad, you mentioned that you can link Fortran and C, and then wrap the C in
> Python. Is that right? Can you give us some details?
There isn't much to say about this; you just write a normal C module
for Python that happens to call Fortran routines. The difficulties
are
1) You must know how to call Fortran routines from C. Under Unix
this is fairly standardized, the only difference being that some
Fortran compilers add an underscore to the subroutine names and
others don't. I don't know the situation for other platforms.
2) You must know how to link Fortran routines to a C program.
This is very machine dependent; usually it comes down to linking
with the Fortran standard library, but its name is different for
each system. There may also be machine-dependent restrictions,
for example it seems to be impossible to use Fortran code in
shared libraries under DEC Unix.
Many public-distribution packages avoid these issues by including a C
translation of the Fortran code (via f2c), examples are the LAPACK and
FFTPACK routines in NumPy. Users who want petter performance and know
their system well enough can then substitute the real Fortran code.
I suggest the same approach for TULIP, it avoids so much trouble...
> for graphical applications led to the ubiquity of Macs in the lab. I don't
> know about where you guys work, but all we have in the labs here are Macs. I
All I have is Unix; I haven't yet seen a Mac in the building I work in!
> therefore believe a port to the Mac may be more important than a port to Windows.
OK, so what's the situation of GTK for the Mac?
> By the way, Konrad, what do you think we need for structural analysis in the
> *core* distribution of TULIP...the most important tools that may be accessed
> by other tools?
I don't really know what people *need*; I don't want to suppose that
my needs are typical. But I do have Python implementations of most
common structural analysis techniques, and can easily add more. Most
techniques I know deal with comparing different conformations of the
same protein, or of two closely related proteins.
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 bizzaro at bc.edu Tue Dec 8 11:40:46 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] updated model
References: <366B5186.955E27A1@bc.edu> <199812071539.QAA24388@dirac.cnrs-orleans.fr> <366C21CB.7DC63D5@bc.edu> <199812081058.LAA22400@dirac.cnrs-orleans.fr>
Message-ID: <366D568E.2ADA1CBB@bc.edu>
Konrad Hinsen wrote:
>
> I am not quite sure what you mean by that. XML can be used only between
> programs that understand XML, so very probably none of the existing
> analysis programs that we want to include. And CGI is a technique used
> for Web servers.
We are obviously seeing things differently. I am not talking about algorithms
that plug into TULIP with *no* modification whatsoever. (That would be where we
need PyExpect.) I am assuming (1) most algorithms run through once, (2) they
communicate via stdin/stdout, and (3) the source code is available and can be
modified by us or by the author. And considering this is the situation, these
algorithms can be changed from outputting plain text to outputting text with XML
markers. *IF* they do this, we can make the core tools read XML, and tada! we
have communication.
It seems you and Thomas are considering tools not only with various languages
but with various GUI's, that can be added to TULIP without modification. Unless
you have something else in mind, it will take Expect to do this...only if there
is stdin/stdout communication. Otherwise, as you said Konrad, there may be no
reasonable solution for these whatsoever ;-)
> I don't really know what people *need*; I don't want to suppose that
> my needs are typical. But I do have Python implementations of most
> common structural analysis techniques, and can easily add more. Most
> techniques I know deal with comparing different conformations of the
> same protein, or of two closely related proteins.
Well, I don't work with the most common tools either. I can take a quess at
what might be nice...some tools that allow someone to see a 3D structure,
manipulate it, and point out some residues maybe? Anything else?
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From hinsen at cnrs-orleans.fr Tue Dec 8 12:30:10 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] updated model
In-Reply-To: <366D568E.2ADA1CBB@bc.edu> (bizzaro@bc.edu)
References: <366B5186.955E27A1@bc.edu> <199812071539.QAA24388@dirac.cnrs-orleans.fr> <366C21CB.7DC63D5@bc.edu> <199812081058.LAA22400@dirac.cnrs-orleans.fr> <366D568E.2ADA1CBB@bc.edu>
Message-ID: <199812081730.SAA25728@dirac.cnrs-orleans.fr>
> We are obviously seeing things differently. I am not talking about algorithms
> that plug into TULIP with *no* modification whatsoever. (That would be where we
> need PyExpect.) I am assuming (1) most algorithms run through once, (2) they
No need for Expect; you can simply use a bidirectional pipe. Expect
becomes necessary only for programs that require interactive input in
a way that is not compatible with stdio. I could well imagine
that we won't need Expect at all!
> communicate via stdin/stdout, and (3) the source code is available and can be
> modified by us or by the author. And considering this is the situation, these
If we have the code and are allowed to modify it, then we can just as
well integratre it into Python properly, without any communications
overhead. Writing and parsing XML is slow!
> It seems you and Thomas are considering tools not only with various languages
> but with various GUI's, that can be added to TULIP without modification. Unless
Yes, as a worst case. Maybe we should keep the discussion more
pragmatic and consider specific examples for each case; if we
can't find an example, we might just as well forget about it...
> Well, I don't work with the most common tools either. I can take a quess at
> what might be nice...some tools that allow someone to see a 3D structure,
> manipulate it, and point out some residues maybe? Anything else?
Interactive manipulation is the hardest part... Lots of GUI programming...
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 bizzaro at bc.edu Tue Dec 8 14:09:10 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] updated model
References: <366B5186.955E27A1@bc.edu> <199812071539.QAA24388@dirac.cnrs-orleans.fr> <366C21CB.7DC63D5@bc.edu> <199812081058.LAA22400@dirac.cnrs-orleans.fr> <366D568E.2ADA1CBB@bc.edu> <199812081730.SAA25728@dirac.cnrs-orleans.fr>
Message-ID: <366D78A7.43FC2E5E@bc.edu>
Konrad Hinsen wrote:
> No need for Expect; you can simply use a bidirectional pipe. Expect
> becomes necessary only for programs that require interactive input in
> a way that is not compatible with stdio. I could well imagine
> that we won't need Expect at all!
There are four classes of TULIP tools:
Non-core TULIP tools can be of three classes:
(1) Non-interactive tools
* Any language
* Modification may be needed
* Communication via stdio, pipes, and XML
(2) Interactive tools - Type 1
* Written in Python/C
* Should use GTK/GNOME widget set
* Communication as Python modules
(3) Interactive tools - Type 2
* Any language
* Modification may be needed
* Communication via Expect/PyExpect and XML
Core TULIP tools will be of only one class:
(4) Interactive tools - Type 1
* Written in Python/C
* Must use GTK/GNOME widget set
* Communication as Python modules
I though Expect worked with stdio? Doesn't it? Thomas, you've worked with it
quite a bit, right? Am I wrong?
> If we have the code and are allowed to modify it, then we can just as
> well integratre it into Python properly, without any communications
> overhead. Writing and parsing XML is slow!
"We" is the key. I don't want to modify every non-core tool myself. I want
something simple that the non-core tool authors can figure out. I think we
agree that CORBA is about 10 times more difficult to implement than an I/O
resembling HTML...Can anyone think of something simpler than HTML/XML?
This current discussion is of course about two classes of non-core TULIP tools
mentioned above (1 and 3). For core TULIP tools, we will do the work
ourselves and do it "properly" with Python.
> Yes, as a worst case. Maybe we should keep the discussion more
> pragmatic and consider specific examples for each case; if we
> can't find an example, we might just as well forget about it...
Forget about what, the whole TULIP project or GUI's with no modifications? ;-)
> Interactive manipulation is the hardest part... Lots of GUI programming...
Do you think we can use parts of the MMTK, and port it to GTK?
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From hinsen at cnrs-orleans.fr Wed Dec 9 09:54:45 1998
From: hinsen at cnrs-orleans.fr (Konrad Hinsen)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] updated model
In-Reply-To: <366D78A7.43FC2E5E@bc.edu> (bizzaro@bc.edu)
References: <366B5186.955E27A1@bc.edu> <199812071539.QAA24388@dirac.cnrs-orleans.fr> <366C21CB.7DC63D5@bc.edu> <199812081058.LAA22400@dirac.cnrs-orleans.fr> <366D568E.2ADA1CBB@bc.edu> <199812081730.SAA25728@dirac.cnrs-orleans.fr> <366D78A7.43FC2E5E@bc.edu>
Message-ID: <199812091454.PAA17392@dirac.cnrs-orleans.fr>
> There are four classes of TULIP tools:
...
Looks good.
> I though Expect worked with stdio? Doesn't it? Thomas, you've worked with it
> quite a bit, right? Am I wrong?
Expect goes beyond stdio, it simulates a Unix terminal. This is for
programs that don't simply read from stdio, but require more precise
control over input.
To give an example: telnet. You can't just write "telnet this.machine < text"
and expect the text to be sent as commands to another machine. But
you can do something similar with Expect.
> "We" is the key. I don't want to modify every non-core tool myself. I want
> something simple that the non-core tool authors can figure out. I think we
Sounds good, but it means we have to convince them that they should
do it!
> agree that CORBA is about 10 times more difficult to implement than an I/O
> resembling HTML...Can anyone think of something simpler than HTML/XML?
Plain text, for simple cases. If some program needs nothing else than
a file name, for example, XML would be overkill.
> > Yes, as a worst case. Maybe we should keep the discussion more
> > pragmatic and consider specific examples for each case; if we
> > can't find an example, we might just as well forget about it...
>
> Forget about what, the whole TULIP project or GUI's with no modifications? ;-)
Forget about the case for which we can't find an example!
> > Interactive manipulation is the hardest part... Lots of GUI programming...
>
> Do you think we can use parts of the MMTK, and port it to GTK?
There's nothing to port, MMTK does not deal with user interfaces. MMTK
is just the library for the computational stuff. I'd like to see TULIP
evolve as a complement of MMTK. MMTK handles operations on
macromolecular structures, but there will be non-structural operations
as well, which should be implemented in a similar kind of low-level
library. And then there would be the end-user programs on top of all
that, which is where GTK comes into play. So TULIP would be both for
end users and for developers. Or perhaps it might be better to
separate these two tasks and use different names - but that's not an
urgent decision.
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 yahoo.com Mon Dec 21 16:02:43 1998
From: jabbo at yahoo.com (tim)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] updated model
References: <366B5186.955E27A1@bc.edu>
Message-ID: <98Dec21.160155est.131733@gateway.macroint.com>
(I'm back in touch with the world -- sorry for the absence)
tools needed:
-- device driver for Linux, FreeBSD, etc for ABI sequencers (not sure
about this)
-- "fuzzy" CLIPS-style inference engine for "expert" per-base
decision-assistance
-- a tutorial
that's what my father said when I asked him what people want in a
replacement for GCG-Wisc. (he has worked on the molecular genetics of
childhood cancer for 20 years) In fact, the second item -- assistance in
recognizing which type of NA a base is even when it looks like the peaks
in the chromatogram could go either way -- is what he stated was missing
in most commercial packages today. Basically, his conclusion was that
many people dislike GCG and would switch if a better alternative was
available (esp. one which could be extended/customized).
Me personally, I'm still trying to understand all of this
comparison-matrix stuff for searching. But it is very challenging (i.e.
cool) and hopefully will be a good excuse for having written a simple
parser-tokenizer for raw base-by-base sequences. Speaking of
challenging, I have become a bit stumped with GTK.
I still don't entirely understand how GTK is designed -- if the GTK
gurus on this project were willing to offer some assistance, I might
progress beyond simple "Sign your timecard today!" boxes that I run from
cron twice a month. ;-) Part of this is that I'm a crappy C programmer
and haven't applied myself to the tutorial, but when I follow along with
the tutorial, I feel like I'm just going through the motions, rather
than figuring out what's being designed.
I also realized that (and this is probably irrelevant to TULIP, but
still) I need someone academic and respected to goon for me if I am
going to hold a real job yet stay involved in protein folding / nucleic
acid folding for real. If anyone on this list knows such a person at
UVM, Middlebury, Dartmouth, or UNH, please let me know; this is really
important to me personally.
My mailbox is full of TULIP messages -- I will now go read them.
ps. What does that stand for?
--
"We all enter this world in the same way:
naked; screaming; soaked in blood.
But if you live your life right, that kind of thing
doesn't have to stop there." --Dana Gould
From bizzaro at bc.edu Mon Dec 21 21:33:33 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:11 2006
Subject: [Fwd: [Pipet Devel] updated model]
Message-ID: <367F04FD.63D8923A@bc.edu>
Message from Tim...
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
-------------- next part --------------
An embedded message was scrubbed...
From: tim
Subject: Re: [Pipet Devel] updated model
Date: Mon, 21 Dec 1998 16:02:43 -0500
Size: 3321
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19981222/65d78ee1/attachment.mht
From bizzaro at bc.edu Mon Dec 28 06:34:02 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] Re: hi, it's Tim
References: <368717F0.D7A33284@hsc.usc.edu>
Message-ID: <36876CAA.B87F5F7D@bc.edu>
> First, since someone interested in this project has likely worked on visual
> representations of algorithms, a nice idea for the "to-do" list would be "find
> code that looks like what we're trying to do".
I have been accumulating links to other bioinformatics programs. I sent some of
these to the team before you joined, so I'll have to send it again soon. I have
been particularly interested in examples of any sort that use Python and GTK,
for obvious reasons, but they are pretty rare for now.
>
> Second, I'm sending my half-assed version of Codon to you for posting as soon
> as I get back to Burlington. It sucks, but will take a file of base pairs and
> turn them into strings of AA's (broken into pieces at the stop codons). If I
> can find out how the ABI sequencers feed their data to the colorful little
> "genomics" programs out there, Codon can be an interface widget. More
> importantly, if it works okay in that context and we have stuff to build up
> around it, then we can spit out some useful code and get users (and thus
> feedback). So look in your mailbox around January 3rd or 4th, I will tarball
> up all the stuff I have been using to work on Codon (not much!) and hopefully
> you can post it on the website.
Great. If you got the gist of the new model by reading my recent e-mail about
collaborating with the EMBOSS project, we have a client-server model, and
complex analyses will go on the server-side. What you may call trivial could go
on the client-side, with the visualization tools.
> (It would be neat if we set up a web code browser.)
Yes. I've been thinking the CGI model will allow us to have a rather static
interface to some of the server-side tools. But this would be in *addition* to
the dynamic client-side interfaces, not a substitute (see my list of tools
below).
>
> Opinion: There needs to be less design talk and more componentry for the
> project or it will never mature into anything. A lot of this stuff can be
> retrofitted (i.e. if we realize "oh shit, this is a lousy data representation"
> then the major version number gets incremented and some parser code gets
> rewritten -- big deal). So from now on I'm just going to send in pieces of
> code that do useful things, even trivial things, and hope that a big enough
> pile of useful widgets accumulates.
In other words, "less talk, more action!" :-) Our talk so far hasn't focused at
all on data visualization; it's been just about all on tool communication. I
think I have a much clearer picture as to what we need to do regarding this.
The next step is to build a list, not of analysis tools, but of dynamic
client-side interfaces. EMBOSS will take care of the big analysis tools for
us. For now, here is a brief list of some dynamic "loci" I've been thinking
of. Please feel free to add to this:
(1) Benchtop/workspace. GUI representation of all data objects
(files, documents, graphs) and possibly various loci. Also
may be used for automation of analyses (recall GCL?).
(2) File translation interface: to read in various DNA/protein
document formats and convert them to XML. Also may be used
to query databases and sort/compile documents.
(3) Sequence visualization/editing tool: to manipulate DNA/protein
sequences
(4) Sequence comparison tool: to show multiple sequences aligned
or translated. May also perform some functions of (6)
(5) 3D visualization tool: to display molecules as 3D structures, with
emphasis on a schematic/cartoon representation.
(6) Graphing tool: to display plots against sequences and to make simple
graphs. Some may argue this isn't needed, but I need it for my
programs, so others may too ;-)
(7) HTML browser implementation: separate from the other tools, this
would be a way for anyone with a browser to access analysis loci.
The best approach may be for each of us to pick a single tool to concentrate
on. And remember, most of these tools will be XML browsers of a sort.
We should also make a list of "trivial" analysis/conversion tools for the
client-side.
> -- device driver for Linux, FreeBSD, etc for ABI sequencers (not sure
> about this)
Device driver? Hmmm. This could be a third-party add-on; it wouldn't be used
by enough people to put it in the core.
> -- "fuzzy" CLIPS-style inference engine for "expert" per-base
> decision-assistance
> - assistance in recognizing which type of NA a base is even when
> it looks like the peaks in the chromatogram could go either way
Hmmm. I haven't put much thought into chromatograph analyses, but it would be
useful to many experimentalists...and we want to target experimentalists in this
project too.
> -- a tutorial
Yes.
> I still don't entirely understand how GTK is designed -- if the GTK
> gurus on this project were willing to offer some assistance, I might
> progress beyond simple "Sign your timecard today!" boxes that I run from
> cron twice a month. ;-) Part of this is that I'm a crappy C programmer
> and haven't applied myself to the tutorial, but when I follow along with
Only Jay is a GTK guru, and we haven't heard from him in a while. We are
otherwise all pretty new to it. I would, though stress learning Python/GTK over
C/GTK. I want the client-side loci to be 90% Python and 10% C (0% if
possible). Yes, it can be done. Here is the Web site for Python/GTK:
http://www.daa.com.au/~james/pygtk/
Also, look into the GLADE/gIDE projects. There seems to be some work toward a
Python/GTK code generator for these...We'll see. For now, it is C/GTK.
GLADE: http://glade.pn.org/
gIDE: http://gide.pn.org/
> I also realized that (and this is probably irrelevant to TULIP, but
> still) I need someone academic and respected to goon for me if I am
> going to hold a real job yet stay involved in protein folding / nucleic
> acid folding for real. If anyone on this list knows such a person at
> UVM, Middlebury, Dartmouth, or UNH, please let me know; this is really
> important to me personally.
I don't know anyone at those locations. Anybody else here that can help Tim?
> My mailbox is full of TULIP messages -- I will now go read them.
> ps. What does that stand for?
"The Loci Project" -> T.L.P. -> TULIP. It was "The Lowell Package" when I
started, but I want it to be a bit less "local," no pun intended ;-)
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--
From bizzaro at bc.edu Tue Dec 29 18:05:05 1998
From: bizzaro at bc.edu (J.W. Bizzaro)
Date: Fri Feb 10 19:18:11 2006
Subject: [Pipet Devel] info on Python-GTK development
Message-ID: <36896021.37BB453F@bc.edu>
Guys,
I now have a Web page that provides developers with information on using the GTK
widgets with Python. Since we would like TULIP/Loci to be written mainly in
Python with GTK, this information should be useful to all of us:
http://www.uml.edu/Dept/Chem/BICGroup/PyGTools/
Happy new year!
Jeff
--
J.W. Bizzaro Phone: 617-552-3905
Boston College mailto:bizzaro@bc.edu
Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/
--