From bizzaro at bc.edu Sat Nov 21 00:30:32 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:05 2006 Subject: [Pipet Devel] ExpectPy & Fnorb Message-ID: <36564FF8.86D83F82@bc.edu> Konrad and Jay, Here are the sites for the Expect and CORBA Python modules: ExpectPy http://www1.shore.net/~arcege/python/ExpectPy/ Fnorb (CORBA) http://www.dstc.edu.au/Fnorb/ 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 Sat Nov 7 17:30:07 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:09 2006 Subject: [Pipet Devel] Stuff References: <363DFA76.27DE9124@bc.edu> <199811031959.UAA16350@dirac.cnrs-orleans.fr> <363F9E8F.A076AA0A@bc.edu> <199811051307.OAA19954@dirac.cnrs-orleans.fr> Message-ID: <3644C9EF.87DA444@bc.edu> Hello Konrad. Thank you for your willingness to add to the TULIP project! I have made some modifications to the TULIP home page. I hope you won't mind if I add your name to the developer's list. By the way, Jay Painter will be joining the developer team. He tells me he developed a substantial part of the GTK graphics library plus the GNOME e-mail client called "Balsa." He has a degree in biochemistry plus one in computer science and one in physics. This is his home page: http://www.serv.net/~jpaint/ He seems to be willing to work at a fast pace on this. He wrote to me about some ideas he has about implementing the concept, and he says he will write something this weekend. His original messages are attached. > > > behave in a similar fashion. It can be an application, > > but it can provide standard "widgets" that can be called > > Let's better say "modules", because that's what it is! > At least for computational code. The user interface is > indeed best structured as a set of widgets; plugging them > together is then a trivial exercise. > Sure, that's correct. I was calling them widgets from a GUI builder's point of view. > > Hopefully. I don't really know the traditions in that field; many > people in computational chemistry are very secretive, to the extent > that even the publications don't contain a complete description of the > methods. It may be around 50/50. I have come across some algorithms that are liberally shared. The important thing is that they can become GNU GPL licensed, if they are to be distributed with TULIP. > > Another problem is licensing; if the resulting collection has a > different set of conditions for each submodule, people won't be > willing to use it for fear of legal problems. > Again, we need to be sure the core is GNU. I think we can package pluggable algorithms under separate licenses, as long as it is clear what the licenses are. > > The first step should be an evaluation of what people use most > in the existing commercial packages. > Yes. I know someone (Tom Graf of BU and Harvard) who gives seminars on GCG use at least once a week. I will contact him to see if he will be an advisor/evaluator. Jeff -- 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 -------------- Date: Fri, 6 Nov 1998 12:26:34 -0800 (PST) Subject: TULIP Hi there, It just so happens that I actually have a biochem degree and have some interest in this. I'm also a huge Python fan, and have written XML parsers with the libxml Python module. Anyways, I'm sure I can help out with this. ----------------------------------------------------------------------- Jay Painter -- jpaint@serv.net -- jpaint@gimp.org -- jpaint@real.com http://www.serv.net/~jpaint -------------- next part -------------- Date: Sat, 7 Nov 1998 02:05:50 -0800 (PST) Subject: Re: TULIP > I checked out your home page, and I see that you are > involved in Balsa and some other GNOME/GTK projects. > To what extent are you involved in these? I was the origional Balsa author, but I don't work on it much anymore. I also wrote about 7-8% of GTK, wich doesn't seem like much now but at the time it was a much higher % > I started with Linux at RedHat 4.0, which is not > as far back as some guys go. I've been making a > transition to Linux programming from Windows, and > I'm sticking with Linux because of its versatility > with scientific programming. I started using it in '93 when I was working a the Hanford Nuclear Reservation doing computational thermo. > Where did you get your degree in biochemistry? Have > you written any biochem apps? I got my degree at Western Wash. University. I was working on NMR/protein structure. Well, actually it was just an excuse for learning how to spell 'protein' correctly, and hit on the students in the Biology department ;) I had to think of another degree to get because I already had two in Physics and CS. > By the way, the other developer for this project > is Konrad Hinsen. He is a Ph.D. in physics working > in computational biophysics in France. You may have > come across his "Scientific Python" Web site, where > he posted some science modules of his own. I'll have to look at it. > Since neither Konrad nor I have quite yet mastered > GTK+ and GNOME, I think your help will be quite > valuable. Thanks! I've got that covered. I want to impliment a threaded messaging system where we don't use Python bindings for GTK, but we instead impliment the interface as a Python-C module running in a Python thread. I'll start working on how to pass messages to and from the UI running in C in one thread to the other threads. The other threads could launch parsers, modules that do fast computation, etc; and best of all this would be highly scriptable. I'll try to come up with a prototype application working like this this weekend. From bizzaro at bc.edu Sat Nov 7 20:23:28 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:09 2006 Subject: [Pipet Devel] developers page Message-ID: <3644F290.CB9EE2EE@bc.edu> Konrad & Jay, I expanded the Web site for TULIP. Among other things, I added a page about the developers (us). Some information is missing, and maybe some is wrong. Let me know what to change, and if you are happy with the "project areas" you are considered to be in charge of. http://www.uml.edu/Dept/Chem/UMLBIC/Apps/TULIP/devel.html 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 Sat Nov 7 20:28:00 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:09 2006 Subject: [Pipet Devel] developers page Message-ID: <3644F3A0.4AB30886@bc.edu> Konrad & Jay, I expanded the Web site for TULIP. Among other things, I added a page about the developers (us). Some information is missing, and maybe some is wrong. Let me know what to change, and if you are happy with the "project areas" you are considered to be in charge of. http://www.uml.edu/Dept/Chem/UMLBIC/Apps/TULIP/devel.html 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 Fri Nov 20 22:43:59 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:09 2006 Subject: [Pipet Devel] links Message-ID: <365636FF.C92DCB02@bc.edu> Konrad and Jay, I did some searching for applications that might be helpful for us to take a look at. Below are links to sites about algorithms that may be incorporated into TULIP and some projects that might parallel TULIP to some extent: The following four sites have GNU GPL licensed tools. If the core distribution of TULIP is to be all GPL, we need to look for tools that are also GPL. Software from the Eddy Lab http://www.genetics.wustl.edu/eddy/software/ The Sanger Centre : Dynamite http://www.sanger.ac.uk/Software/Dynamite/ SCRate http://www.mrc-lmb.cam.ac.uk:80/genomes/jong/SC_rate.html The Sanger Centre : Wise2 http://www.sanger.ac.uk/Software/Wise2/ The following are tools that are not GPL, but they are free, and the source code is available. So, the authors may be willing to make it GPL. If not, we can put them in a separate distribution. FETCH http://ind5.mrc-lmb.cam.ac.uk/fetch_home.html The Babel Home Page http://mercury.aichem.arizona.edu/babel.html Cn3D Home Page http://www.ncbi.nlm.nih.gov/Structure/cn3d.html Democritos Home Page http://www.seqnet.dl.ac.uk/CBMT/democ/HOME.html The Sanger Centre : Dotter [not GPL???] http://www.sanger.ac.uk/Software/Dotter/ NJplot http://pbil.univ-lyon1.fr/software/njplot.html tacg Version 2 - Documentation http://hornet.bio.uci.edu/~hjm/projects/tacg/tacg2.main.html The following are some projects that provide rather large packages for DNA and protein analyses. They may not be directly competing with TULIP, but they may give us some ideas. FASTA ftp://ftp.virginia.edu/pub/fasta/ Geanfammer home page : genome analysis and protein family maker http://www.mrc-lmb.cam.ac.uk/genomes/geanfammer.html SEALS Home Page http://www.ncbi.nlm.nih.gov/Walker/SEALS/index.html SeqPUP http://iubio.bio.indiana.edu/IUBio-Software+Data/molbio/seqpup/ The following are some Java-based packages, tools, and links to tools. Many bioinformaticists believe Java is _the_ language for the job, but others (as myself) tend to disagree. The advantages TULIP has over Java are that the compute-intensive stuff can be compiled, making TULIP much faster, and TULIP will be language independent (see next e-mail). Base4 Java Bioinformatics Links http://telomere.base4.com/html/java_list.html Javascript, Java and CORBA http://bioinformatics.weizmann.ac.il/comp/java_info.html Java-based Molecular Biology Work Bench http://www.embl-heidelberg.de/~toldo/JaMBW.html Neomorphic Software, Inc.'s Java Demos http://www.neomorphic.com/demo/ bioWidget Consortium http://www.biowidgets.org/ BioObjects: CORBA in Bioinformatics http://sunny.ebi.ac.uk/BioObjects/ CBIL bioWidgets for Java(tm) http://www.cbil.upenn.edu/bioWidgets/ AppLab Homepage http://industry.ebi.ac.uk/applab/ So far, I have found _no_large_bioinformatics_package_with_GNU_GPL_code_! 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 Fri Nov 20 23:50:39 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:10 2006 Subject: [Pipet Devel] modifications to the program model Message-ID: <3656469F.52F07EDD@bc.edu> Konrad and Jay, I have thought about some modifications to the programming model for TULIP. I would still like the primary language of TULIP to be Python and the GUI toolkit to be GTK/GNOME. However, this alone would restrict all tools for TULIP to be written in either C or Python. >From my experience, more than about 50% of the algorithms (written by others) that we might want to implement are written in FORTRAN. And then there are many others written in Perl, Java, and even Pascal. To deal with this, we may want to use two very powerful modules/tools for tying together different languages: Expect and CORBA. Below I pasted something I just put up on the TULIP Web site: TULIP tools can comminicate with each other in three ways, each having a different degree of integration with the core and, for new tools, requiring a different amount of modification: High-Level Communication Via BSML and ExpectPy. ExpectPy can handle IO between two tools, wich can be largely in the BSML format. This type of communication may be best for non-core algorithms, written in any language, because it will require the least amount of modification to the code, and they won't have to be wrapped in Python. (Expect can even be used on compiled, binary-only algorithms) Low-Level Communication Via Fnorb (CORBA). Fnorb will allow for better communication between tools, meaning more control. This will, however, require modification to the code of non-core tools and require these tools to be coded in a CORBA-friendly language. Lowest-Level Communication Via Python. One tool can be a Python module to another. This way, methods can be called directly. This type of communication may be best for the core TULIP tools. Let me know what you think. Somehow, I'm expecting, "CORBA sucks!" or the like :-) Also, check out what I wrote about using a "Glyphic Command Language" for the workspace: http://www.uml.edu/Dept/Chem/UMLBIC/Apps/TULIP/model.html (bottom of the page) 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 Mon Nov 23 15:42:30 1998 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Fri Feb 10 19:18:10 2006 Subject: [Pipet Devel] links In-Reply-To: <365636FF.C92DCB02@bc.edu> (bizzaro@bc.edu) References: <365636FF.C92DCB02@bc.edu> Message-ID: <199811232042.VAA23296@dirac.cnrs-orleans.fr> > I did some searching for applications that might be helpful for us to > take a look at. Below are links to sites about algorithms that may be Thanks, that's a useful list to have! > So far, I have found _no_large_bioinformatics_package_with_GNU_GPL_code_! No surprise, GPL isn't really common in the scientific world. > to be GTK/GNOME. However, this alone would restrict all tools for > TULIP to be written in either C or Python. No, just in languages that are linkable with C, i.e. almost all! > From my experience, more than about 50% of the algorithms (written > by others) that we might want to implement are written in FORTRAN. 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). > Pascal. To deal with this, we may want to use two very powerful > modules/tools for tying together different languages: Expect and > CORBA. Below I pasted something I just put up on the TULIP Web site: Expect is a bit of a kludge, but I agree that it can be useful for really weird programs (i.e. Pascal or Java, or binary-only distributions). CORBA would be useful if there were programs with CORBA support that we want to call, but I'd be surprised if that were the case! Modifying these programs to use CORBA sounds like an extremely unpleasant task. > Low-Level Communication Via Fnorb (CORBA). Fnorb will allow for > better communication between tools, meaning more control. This Fnorb has one problem: it is not free for everyone, just for non-commercial use. > Also, check out what I wrote about using a "Glyphic Command Language" > for the workspace: > > http://www.uml.edu/Dept/Chem/UMLBIC/Apps/TULIP/model.html > (bottom of the page) An interesting idea. Unfortunately I know much too little about the applications we are aiming at to judge how useful it would be! Could you give some fictitious example? 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 Nov 23 16:59:31 1998 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:10 2006 Subject: [Pipet Devel] links References: <365636FF.C92DCB02@bc.edu> <199811232042.VAA23296@dirac.cnrs-orleans.fr> Message-ID: <3659DA9E.BA9295DC@bc.edu> Konrad Hinsen wrote: > > No, just in languages that are linkable with C, i.e. almost all! > 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). Great! I'm glad to hear you have experience with that; we'll need it. Automatic installation on various platforms will not be easy especially considering all of the libraries we will be using! > Expect is a bit of a kludge, but I agree that it can be useful for > really weird programs (i.e. Pascal or Java, or binary-only > distributions). Exactly. I was considering (1) weird languages and (2) binary-only, especially for non-core tools that someone may want to sell or have the code kept hidden. > CORBA would be useful if there were programs with > CORBA support that we want to call, but I'd be surprised if that were > the case! Modifying these programs to use CORBA sounds like an > extremely unpleasant task. I think CORBA is becoming much more popular now. GNOME is a good example, which uses ORBit...GNU(?) CORBA. But, if you think it is not necessary, we will hold off on it. > Fnorb has one problem: it is not free for everyone, just for > non-commercial use. I did not know that. Hmmmm. That rules that out. > > > Also, check out what I wrote about using a "Glyphic Command Language" > > for the workspace: > > An interesting idea. Unfortunately I know much too little about the > applications we are aiming at to judge how useful it would be! > Could you give some fictitious example? Well, I was considering it for the workspace, which I see as virtual laboratory benchtop where you can organize your equipment (tools) and specimens (data). It won't matter what the tools and data are, GCL is just a way to organize them and generate a flow-chart for the experiment (analysis). The important features of GCL are (1) being able to form an input dialog with a tool. For example, "SEQUENCEALIGNER--ALIGN--SEQ-(to)-DATABASE". You see, this can be represented as 4 glyphs on the benchtop. And if you represent all 4 together as a single glyph, you can then start forming classic UNIX-like redirects and pipes, etc. In other words, you can do more than one thing with a single "line" of commands. It may be just kind of cute for one-shot analyses, but if you have an analysis that will take days, why not have TULIP go ahead and do something else when it finishes at 3:00AM Saturday morning? :-) Jeff -- J.W. Bizzaro Phone: 617-552-3905 Boston College mailto:bizzaro@bc.edu Department of Chemistry http://www.uml.edu/Dept/Chem/Bizzaro/ --