From hortiz at neurobio.upr.clu.edu Wed Sep 1 10:10:35 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] PSB 2000 In-Reply-To: Your message of "Tue, 31 Aug 1999 23:11:07 GMT." <37CC610B.D84420C4@bc.edu> Message-ID: <199909011410.KAA03272@chimbo.neurobio.upr.clu.edu> > GOING TO PSB 2000 > > Please update this list as needed. Not this year, I won't even make it to Neuroscience in Miami this year, and I've gone every year for the last 6 or 7. I may be changing jobs next year, and my future employer's told me I can go on more trips (I like recomb). -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From stein at fmppr.fmnh.org Wed Sep 1 13:08:20 1999 From: stein at fmppr.fmnh.org (JES) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] PSB 2000 References: <37B2B7C9.566D465@bc.edu> <37B2F9ED.481F9176@fmnh.org> <37B300B7.DBD7DFE5@bc.edu> <37CC610B.D84420C4@bc.edu> Message-ID: <37CD5D84.C28986C1@fmnh.org> "J.W. Bizzaro" wrote: > > $670 per ticket (I think that's from Chicago) > INCLUDES RENTAL CAR! So, if Locians want to sightsee the area via car, we should be generous with food and drink for your brother? :) -j -------------------------- Jennifer Steinbachs, PhD Computational Biologist Dept. of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 email: stein@fmnh.org -------------------------- From bizzaro at bc.edu Wed Sep 1 19:30:20 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] PSB 2000 References: <37B2B7C9.566D465@bc.edu> <37B2F9ED.481F9176@fmnh.org> <37B300B7.DBD7DFE5@bc.edu> <37CC610B.D84420C4@bc.edu> <37CD5D84.C28986C1@fmnh.org> Message-ID: <37CDB70C.B33FA5FC@bc.edu> JES wrote: > > "J.W. Bizzaro" wrote: > > > > > $670 per ticket (I think that's from Chicago) > > INCLUDES RENTAL CAR! > > So, if Locians want to sightsee the area via car, we should be generous > with food and drink for your brother? :) Yeah, if we can all fit in one car :-) But it looks like very few will be going. :-P Jeff -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From bizzaro at bc.edu Wed Sep 1 19:36:54 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] PSB 2000 list Message-ID: <37CDB896.B28AB80F@bc.edu> GOING TO PSB 2000 YES MAYBE NO NO REPLY ---------------------------------------------------------------------- Bizzaro Junier Williams Triche Van Domselaar St. Onge Harrison Cohen Steinbachs Rice Sicheritz Zuazaga Lapointe Hinsen Villa Beck Mangalam Bradford Marx Jain de Lahondes Please update this list as needed. :-) Jeff -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From bizzaro at bc.edu Wed Sep 1 20:24:05 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] screenshot and snapshot Message-ID: <37CDC3A5.EECFC11E@bc.edu> Locians, Attached is the latest screenshot of the workspace. Notice the new 'desktop' look and feel. Recall that I used to have boxes surrounding the icon and text. Although this screenshot doesn't show it, I will have the flowchart-style boxes be part of the icon and not be shapes drawn by the canvas. This desktop L&F led me to an interesting solution to a problem I have been trying to deal with. (This doesn't appear on the screenshot.) You may recall that early screenshots showed a 'toolbox' in a windowpane adjacent to the workspace. The toolbox contained optional loci TO BE PLACED on the workspace. But I soon realized we would have had a problem organizing the toolbox loci for ease of selection. I then thought of using some sort of a menu or list to select loci from. However, I'm not very fond of long lists and cascading menus. My most recent idea is to split the toolbox up and put the numerous loci into several other loci. Yes, make loci that contain other loci. So, as the GUI has been functioning, you would double-click on one of these 'container loci' and a 'windowlet' would drop down with a (short) list of loci contained therein. The container loci would appear when starting the workspace, akin to folders and drives on a Mac desktop. The cute part is, you can connect a container to the end of a workflow diagram and have it automatically store the resulting data. A snapshot of the hardly-functional workspace can be found in the usual place: http://bioinformatics.org/loci/download/snapshots/ PLEASE GIVE ME SOME FEEDBACK! :-) Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: loci-screenshot-19990901.gif Type: image/gif Size: 14281 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/19990902/37b67ff2/loci-screenshot-19990901.gif From bizzaro at bc.edu Thu Sep 2 07:05:50 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] CORBA documentation Message-ID: <37CE5A0E.1104CA6D@bc.edu> Your homework assignment for tonight, class, is to become expert CORBA programmers. You may want to read this GNOME-CORBA documentation on the Web: http://developer.gnome.org/doc/guides/corba/ And there is some ORBit documentation, mentioned earlier: http://www.sanger.ac.uk/Users/birney/orbit-html/book1.htm Good luck. There will be a quiz tomorrow morning. Class dismissed. Mr. B -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From justin at ukans.edu Fri Sep 3 16:37:38 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] CORBA documentation In-Reply-To: <37CE5A0E.1104CA6D@bc.edu> Message-ID: > Good luck. There will be a quiz tomorrow morning. Class dismissed. Ok, here's a question: How do we use ORBit from Python? A. Use ILU's Python bindings, which will communicate with ORBit via IIOP (but [possibly, as I am not completely versed in ORBit and barely at all in ILU] loses the advantage of ORBit's shortcuts when two processes on the same machine are communicating via it [where ORBit would otherwise skip the demarshalling process and use shared mem {rather than IIOP}]) B. Write a C extension for Python to wrap ORBit functions (and Gnorba and Goad) using pretty much a direct mapping of Python onto the corresponding ORBit function. C. Write a C extension for Python to wrap ORBit usually a nice, elegant, Python-esque representation of the whole component thing. I like option C, with A used as an interim solution. Justin From justin at ukans.edu Fri Sep 3 17:41:59 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] CORBA documentation In-Reply-To: Message-ID: > C. Write a C extension for Python to wrap ORBit usually a nice, elegant, > Python-esque representation of the whole component thing. This URL is the Python Language Mapping to CORBA being developed by the distributed objects in Python special interest group. http://www.python.org/sigs/do-sig/corbamap.html It's used in Fnorb (and I think ILU, as well). They're also planning to submit this to the OMG for standardization. I'll get something started, and then put it in CVS. Justin From bizzaro at bc.edu Fri Sep 3 20:32:45 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] CORBA documentation References: Message-ID: <37D068AD.142FA75E@bc.edu> Justin Bradford wrote: > > Ok, here's a question: > How do we use ORBit from Python? > > A. Use ILU's Python bindings, which will communicate with ORBit via IIOP > (but [possibly, as I am not completely versed in ORBit and barely > at all in ILU] loses the advantage of ORBit's shortcuts when two > processes on the same machine are communicating via it [where ORBit > would otherwise skip the demarshalling process and use shared mem > {rather than IIOP}]) > B. Write a C extension for Python to wrap ORBit functions (and Gnorba and > Goad) using pretty much a direct mapping of Python onto the > corresponding ORBit function. > C. Write a C extension for Python to wrap ORBit usually a nice, elegant, > Python-esque representation of the whole component thing. > > I like option C, with A used as an interim solution. I like C, since it is 'nice and elegant' ;-) I did notice that there are other Python-CORBA options and wondered if they could be used while the ORBit bindings were being worked on. From what I have seen of bindings development, it could take a year before the ORBit bindings are very usable. So, yeah, option A may be good for the interim, and maybe even Fnorb. Cheers. Jeff -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From bizzaro at bc.edu Fri Sep 3 20:37:11 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:49 2006 Subject: [Pipet Devel] CORBA documentation References: Message-ID: <37D069B7.BF92751B@bc.edu> Justin Bradford wrote: > > I'll get something started, and then put it in CVS. Do you mean using that CORBA map to make the ORBit bindings? Cool. Justin got an 'A' on the quiz, class. :-) Jeff -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From justin at ukans.edu Fri Sep 3 21:39:11 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] CORBA documentation In-Reply-To: <37D068AD.142FA75E@bc.edu> Message-ID: > I did notice that there are other Python-CORBA options and wondered if they > could be used while the ORBit bindings were being worked on. From what I have > seen of bindings development, it could take a year before the ORBit bindings are > very usable. So, yeah, option A may be good for the interim, and maybe even > Fnorb. I'm not sure why it would take a year. It doesn't look that complicated. But, yes, using ILU or Fnorb would allow us to talk to the ORBit at the core of gnome, if necessary, albeit slower and more memory intensive. Additionally, since both Fnorb and ILU seem to be using the same bindings I mentioned in the other mail, it should just be a matter of swapping "import ilu" with "import orbit" (well, probably a little more work, but it definitely won't require a substantial rewrite). justin From bizzaro at bc.edu Sat Sep 4 00:43:52 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] CORBA documentation References: Message-ID: <37D0A388.67CE3D06@bc.edu> Justin Bradford wrote: > > I'm not sure why it would take a year. It doesn't look that complicated. That's good to hear. > But, yes, using ILU or Fnorb would allow us to talk to the ORBit at the > core of gnome, if necessary, albeit slower and more memory intensive. > > Additionally, since both Fnorb and ILU seem to be using the same bindings > I mentioned in the other mail, it should just be a matter of swapping > "import ilu" with "import orbit" (well, probably a little more work, but > it definitely won't require a substantial rewrite). And will we (you) be the first to work on Python-ORBit bindings? James Henstridge (Python-GNOME developer) mentioned to me that he might like to get involved. How about I set up a 'python-orbit' mailing list? :-P Jeff -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From justin at ukans.edu Sat Sep 4 04:28:34 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] CORBA documentation In-Reply-To: <37D0A388.67CE3D06@bc.edu> Message-ID: > And will we (you) be the first to work on Python-ORBit bindings? Besides searching, I've also asked on comp.lang.python and the orbit mailing list, and I have not found any other project to do this. So, yeah, I think we're first. > James Henstridge (Python-GNOME developer) mentioned to me that he might > like to get involved. How about I set up a 'python-orbit' mailing list? Sure. I had expected that these bindings would eventually work their way into the gnome-python distribution anyway. Justin From bizzaro at bc.edu Sun Sep 5 14:28:42 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] CORBA documentation References: Message-ID: <37D2B65A.6E7DA057@bc.edu> A couple questions before we make a mailing list and announcements: (1) Name == 'PyORBit'? (2) License == GNU LGPL? Cheers. Jeff Justin Bradford wrote: > > > And will we (you) be the first to work on Python-ORBit bindings? > > Besides searching, I've also asked on comp.lang.python and the orbit > mailing list, and I have not found any other project to do this. > So, yeah, I think we're first. > > > James Henstridge (Python-GNOME developer) mentioned to me that he might > > like to get involved. How about I set up a 'python-orbit' mailing list? > > Sure. I had expected that these bindings would eventually work their way > into the gnome-python distribution anyway. > > Justin > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel -- +--------------------------------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Bioinformatics Research, Development & Resources | | | | http://bioinformatics.org/ | +--------------------------------------------------+ From justin at ukans.edu Sun Sep 5 19:44:37 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] CORBA documentation In-Reply-To: <37D2B65A.6E7DA057@bc.edu> Message-ID: > A couple questions before we make a mailing list and announcements: > > (1) Name == 'PyORBit'? > (2) License == GNU LGPL? Looks good to me. Justin From bizzaro at bc.edu Mon Sep 6 07:02:29 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] [Fwd: [Pipet Devel] Re: SV: Meta-Application again...] Message-ID: <37D39F45.FAB3E9FF@bc.edu> >From Svanberg Liss... -------------- next part -------------- An embedded message was scrubbed... From: Svanberg Liss Subject: [Pipet Devel] Re: SV: Meta-Application again... Date: Mon, 6 Sep 1999 12:38:05 +0200 Size: 2833 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990906/84f375d1/attachment.mht From bizzaro at bc.edu Mon Sep 6 07:25:33 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] Re: SV: Meta-Application again... References: <40DEF2EE1151D311BC520050047B4145018978@195-66-34-2.itv.se> Message-ID: <37D3A4AD.D77B4ACE@bc.edu> Svanberg Liss wrote: > > I don't think that I may call myself a Gnome developer, but I am a > programmer, and I have been following Gnome a while. > ( I've been working on a clipboard for Gnome, but I havn't released it yet, > since it contains some incompabilities with Bonobo. ) Ahhh. Okay. > In an "earlier life" I was a biology student, if that matters... Well, the first EXTENSION to Loci will be for bioinformatics. We want the CORE distribution to be general-purpose (non-bioinformatics) and data-type independent. This way, Loci can be extended to do many things and suit a larger audience. BUT, the vast majority on this list are interested in bioinformatics applications, and I am a bioinformaticist. Thus we will keep our needs in mind during development. > I really am interested in developing Loci, I just don't know how much time I > will be able to spend with it... > (I'm allready working on two projects which take much of my time.) "Many hands make for light work." (Does anyone know where that comes from, BTW?) Nearly everyone tells me that they have little time to spare, and I can't expect anyone to give up food to become a Loci developer :-) Any help you can offer would be wonderful. > First of all, I need to have a working copy (of loci) running at home. > ( This might take some time, since I dont have any realiable internet > connections... :( Heh heh. I can tell you think the project is further along than it really is. The infrastructure (connection between the GUI and the GNOME components like ORBit) doesn't exist, but we are working on it. (This is where we need the most help.) Something that is beginning to look like a GUI (the 'Workbench' or 'Workspace') exists and is written using the gnome-python bindings (by James Henstridge). It currently needs gnome-python 1.0.3 or better, and gnome-libs 1.0.10 or better. This is where we keep the snapshots: http://bioinformatics.org/loci/download/snapshots/ The tarball is called 'loci-core'. Try the latest. > Secondly, I need some extra time to examine the code, unless you allready > has put togeather some "inside the code" document?s... Again, we're not that far along :-/ > But why not. Let's sign up! :) Great. Would you like a shell account (with CVS access)? > ps. Is there any LOCI-FAQ about compiling loci? No FAQ, but the Workbench is in Python, which of course is an interpreted scripting language. If you can get gnome and gnome-python compiled, you should be able to run it. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 6 12:10:29 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract Message-ID: <37D3E775.FF367993@bc.edu> Locians, I going to submit the following abstract for the Open Source/Open Science conference, ASAP. Please comment on any corrections needed. Regarding names, listed are those who have contributed to the DESIGN of Loci over the months. This does not include other forms of contribution, otherwise the list would be much longer. ------------- THE LOCI PROJECT J.W. Bizzaro*, Justin Bradford, Humberto Ortiz Zuazaga, Gary Van Domselaar, Alan J. Williams, Rahul Jain & Tim Triche, Jr. *To whom correspondence should be addressed The Open Lab 28 Pope Street Hudson, MA 01749 Abstract Loci is a network-distributed system of clients and servers ("loci") for data processing. Client types include programs that process data (perform analysis, translation and visualization). (These loci are not part of the system but come as extensions, making Loci independent of data-type and thus general-purpose.) Other clients include control structure (e.g., if and while) and graphical user interface (GUI) loci. All loci are represented as nodes in a graphical "Work Flow Diagram" (WFD) and joined by lines that depict network connections. The system therefore provides a workspace for connecting and combining loci to form a graphical scripting language. The network-distributed nature of Loci deals with large datasets in a unique way: GUI loci reside on a local workstation while compute-intensive data-processing loci execute remotely on high-performance computers. The joining of loci across the Internet can also be used to form world-wide collaboratives and bring an infinitely extensible set of loci to the user. Numerous development tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and so on. More information can be found at http://bioinformatics.org/loci/ ------------- Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Tue Sep 7 02:47:04 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] CORBA documentation References: <37D2B65A.6E7DA057@bc.edu> Message-ID: <37D4B4E8.681EB121@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > A couple questions before we make a mailing list and announcements: > > (1) Name == 'PyORBit'? > (2) License == GNU LGPL? ORBithon sounds cooler than pyorbit, but sounds more like a dance-music marathon than python-orbit bindings. I believe LGPL now stands for the GNU Lesser Public License. From http://www.gnu.org/copyleft/lesser.html [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] -- gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From gvd at redpoll.pharmacy.ualberta.ca Tue Sep 7 02:53:46 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract References: <37D3E775.FF367993@bc.edu> Message-ID: <37D4B67A.E9963596@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Locians, > > I going to submit the following abstract for the Open Source/Open Science > conference, ASAP. Please comment on any corrections needed. Regarding names, > listed are those who have contributed to the DESIGN of Loci over the months. > This does not include other forms of contribution, otherwise the list would be > much longer. No changes. > > ------------- > THE LOCI PROJECT > > J.W. Bizzaro*, Justin Bradford, Humberto Ortiz Zuazaga, Gary Van Domselaar, > Alan J. Williams, Rahul Jain & Tim Triche, Jr. > > *To whom correspondence should be addressed > > The Open Lab > 28 Pope Street > Hudson, MA 01749 > > Abstract > > Loci is a network-distributed system of clients and servers ("loci") for data > processing. Client types include programs that process data (perform analysis, > translation and visualization). (These loci are not part of the system but > come as extensions, making Loci independent of data-type and thus > general-purpose.) Other clients include control structure (e.g., if and while) > and graphical user interface (GUI) loci. All loci are represented as nodes > in a graphical "Work Flow Diagram" (WFD) and joined by lines that depict > network connections. The system therefore provides a workspace for connecting > and combining loci to form a graphical scripting language. The > network-distributed nature of Loci deals with large datasets in a unique way: > GUI loci reside on a local workstation while compute-intensive data-processing > loci execute remotely on high-performance computers. The joining of loci > across the Internet can also be used to form world-wide collaboratives and > bring an infinitely extensible set of loci to the user. Numerous development > tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and > so on. > > More information can be found at http://bioinformatics.org/loci/ > ------------- > > Jeff > -- > +----------------------------+ > | J.W. Bizzaro | > | jeff@bioinformatics.org | > | | > | THE OPEN LAB | > | Open Source Bioinformatics | > | | > | http://bioinformatics.org/ | > +----------------------------+ > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Tue Sep 7 08:06:44 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] PyORBit (was: CORBA documentation) References: <37D2B65A.6E7DA057@bc.edu> <37D4B4E8.681EB121@redpoll.pharmacy.ualberta.ca> Message-ID: <37D4FFD4.99DAF9D2@bc.edu> Gary Van Domselaar wrote: > > ORBithon sounds cooler than pyorbit, but sounds more like a dance-music > marathon than python-orbit bindings. Exactly. Or the name of a theater that would hold dance performances :-) > I believe LGPL now stands for the GNU Lesser Public License. From > http://www.gnu.org/copyleft/lesser.html > > > [This is the first released version of the Lesser GPL. It also counts > as the successor of the GNU Library Public License, version 2, hence > the version number 2.1.] > That's right. The name change is for 2 reasons: (1) Richard Stallman wants developers to migrate from the LGPL to the regular GPL, and so the word 'lesser' is used in a derogatory way to discourage use (I'm serious; I did some reading about this). The license even has a clause to allow license change ONLY TO THE GPL. (2) "It's not just for libraries anymore." The LGPL serves an attractive purpose for many developers: Binary-only software can link to LGPL-licensed software by the terms of the LGPL. This is not the case with the GPL. But Stallman would rather not encourage binary-only software in any way, and so he is backstepping on the LGPL. However, if commercial acceptance is important (as with large libraries like GTK+ and GNOME, which are LGPL'd), then so is the availability of the 'lesser' version of the GPL. Otherwise, IMO, developers might go with a BSD-type license for libraries. Loci is LGPL'd. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From David.Lapointe at umassmed.edu Tue Sep 7 10:22:03 1999 From: David.Lapointe at umassmed.edu (Lapointe, David) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] rfc for loci web pages Message-ID: <93307F07DE63D211B2F30000F808E9E501644DE0@edunivexch02.umassmed.edu> There is a Perl-Gimp module for just that purpose. See a recent issue of The Perl Journal > -----Original Message----- > From: Gary Van Domselaar [mailto:gvd@redpoll.pharmacy.ualberta.ca] > Sent: Friday, August 27, 1999 6:46 PM > To: pipet-devel@bioinformatics.org > Subject: Re: [Pipet Devel] rfc for loci web pages > > > and use 1/4-sized backgrounds. (But 219 images?! That's a lot of > > resizing.) Then the browser would only be downloading ~10 > kB in graphics for > > each page. Most modems will do that in 2 seconds. I used > the GIMP to reduce > > the backgrounds, BTW. > > may be a prob. I'm pretty sure you can run gimp from command > line. It may > be possible to write a script (script-fu?) to resize the backgrounds. > > > > > Check out the huge graphics that VA Linux just put up on their site: > > > > http://www.valinux.com/ > > > > For some reason, downloading the VA pages takes a lot of > processing power from > > my CPU. > > > > Yeah mine too. From that perspective, I think our pages are pretty > efficient :-) > There are only 5 or 6 colors in that image, ie very few transitions so RLE compresses the image temendoulsy. GIFs are great for that. The background image is 1700 x 1300 David Lapointe, Ph.D. Research Computing Manager 6-5141 "What we obtain too cheap, we esteem too lightly." - T. Paine From hortiz at neurobio.upr.clu.edu Tue Sep 7 10:23:07 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract In-Reply-To: Your message of "Mon, 06 Sep 1999 16:10:29 GMT." <37D3E775.FF367993@bc.edu> Message-ID: <199909071423.KAA17653@chimbo.neurobio.upr.clu.edu> > I going to submit the following abstract for the Open Source/Open Science > conference, ASAP. > THE LOCI PROJECT > > J.W. Bizzaro*, Justin Bradford, Humberto Ortiz Zuazaga, Gary Van Domselaar, > Alan J. Williams, Rahul Jain & Tim Triche, Jr. You're too kind, or really really sneaky, trying to embarrass us into doing more work. I don't feel worthy of being an author. > Numerous development > tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and > so on. How about, "Loci will be based on open data standards such as XML, and build on the Gnome user interface tools and CORBA."? -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From Alan at MolBio.org Tue Sep 7 12:15:19 1999 From: Alan at MolBio.org (Alan J. Williams) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract In-Reply-To: <37D3E775.FF367993@bc.edu> Message-ID: On Mon, 6 Sep 1999, J.W. Bizzaro wrote: > ------------- > THE LOCI PROJECT > > J.W. Bizzaro*, Justin Bradford, Humberto Ortiz Zuazaga, Gary Van Domselaar, > Alan J. Williams, Rahul Jain & Tim Triche, Jr. As Humberto pointed out, your either all too kind or trying to guilt me into being more active; probably a little of both. I just ordered "Learning Python" as well as the new GTK/Gnome book; about time to get more involved despite it being dissertation cruch time. > > *To whom correspondence should be addressed > > The Open Lab > 28 Pope Street > Hudson, MA 01749 > > > Abstract > > Loci is a network-distributed system of clients and servers ("loci") for data > processing. Client types include programs that process data (perform analysis, > translation and visualization). (These loci are not part of the system but > come as extensions, making Loci independent of data-type and thus > general-purpose.) Other clients include control structure (e.g., if and while) > and graphical user interface (GUI) loci. All loci are represented as nodes > in a graphical "Work Flow Diagram" (WFD) and joined by lines that depict > network connections. The system therefore provides a workspace for connecting Do the lines really depict network connections or rather data "pipes" which may or may not be accross a network? > and combining loci to form a graphical scripting language. The > network-distributed nature of Loci deals with large datasets in a unique way: > GUI loci reside on a local workstation while compute-intensive data-processing > loci execute remotely on high-performance computers. The joining of loci > across the Internet can also be used to form world-wide collaboratives and > bring an infinitely extensible set of loci to the user. Numerous development > tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and > so on. As someone else pointed out, this last part should be a little more descriptive. You may want to distiguish between the language/tools for the core of loci and the language-independence for the extensions. > > More information can be found at http://bioinformatics.org/loci/ > ------------- Otherwise it looks good. -Alan -------------------------------------------------------------------- Alan Williams Where observation is concerned, Alan@MolBio.org chance favors the prepared mind. http://www.MolBio.org/cv/ -- Louis Pasteur -------------------------------------------------------------------- ** University of California, Botany Department, Riverside ** From bizzaro at bc.edu Tue Sep 7 12:56:26 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] rfc for loci web pages References: <93307F07DE63D211B2F30000F808E9E501644DE0@edunivexch02.umassmed.edu> Message-ID: <37D543BA.71082B81@bc.edu> "Lapointe, David" wrote: > > There is a Perl-Gimp module for just that purpose. See a recent issue of The > Perl Journal Too late :-/ 220+ images took me a couple hours. But the images were nice to look at :-) > There are only 5 or 6 colors in that image, ie very few transitions so RLE > compresses the image temendoulsy. GIFs are great for that. The background > image is 1700 x 1300 I guess so, but something on those pages drives Navigator nutty. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Tue Sep 7 13:04:52 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract References: <199909071423.KAA17653@chimbo.neurobio.upr.clu.edu> Message-ID: <37D545B4.1D0B5379@bc.edu> Humberto Ortiz Zuazaga wrote: > > You're too kind, or really really sneaky, trying to embarrass us into doing > more work. I don't feel worthy of being an author. Maybe a little of both ;-) Seriously, the current design comes from many months of everyone on that list discussing how Loci might work, even if much of the time I'm trying to explain myself (in such a case, my ideas were only sketchy and writing about it brought out the parts that were unclear). Plus, all of the ideas (and work to come ;-) about CORBA and DOM come from you guys. > > Numerous development > > tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and > > so on. > > How about, "Loci will be based on open data standards such as XML, and build > on the Gnome user interface tools and CORBA."? D'Oh! The deadline was today, and I submitted last night :-/ Sorry. That's not a critical change to you, is it? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From hortiz at neurobio.upr.clu.edu Tue Sep 7 13:07:42 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract In-Reply-To: Your message of "Tue, 07 Sep 1999 17:04:52 GMT." <37D545B4.1D0B5379@bc.edu> Message-ID: <199909071707.NAA29770@chimbo.neurobio.upr.clu.edu> > Humberto Ortiz Zuazaga wrote: > > > Numerous development > > > tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and > > > so on. > > > > How about, "Loci will be based on open data standards such as XML, and build > > on the Gnome user interface tools and CORBA."? > > D'Oh! The deadline was today, and I submitted last night :-/ Sorry. That's > not a critical change to you, is it? Not really, but I think your phrasing might scare people, and we're not currently using all that, just Python and gnome-python, right? -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From bizzaro at bc.edu Tue Sep 7 13:18:47 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract References: Message-ID: <37D548F7.FB0D8F5C@bc.edu> "Alan J. Williams" wrote: > > As Humberto pointed out, your either all too kind or trying to guilt me > into being more active; probably a little of both. I just ordered > "Learning Python" as well as the new GTK/Gnome book; about time to get > more involved despite it being dissertation cruch time. Of course I don't want to coerce anyone into working on Loci, especially if you have to work on your dissertation. Even if you don't do anymore, I'll still give you credit. > Do the lines really depict network connections or rather data "pipes" > which may or may not be accross a network? (Even though I just submitted the abstract, these comments will be helpful for writing the poster.) That's something that we have to work out. I imagined that they would all be 'network-based' data pipes, if that makes any sense. So, if the GUI and the analysis program both reside on the user's computer, the connection will just loop back. URI: locus://localhost:555/blablabla This way, Loci never has to distinguish between a remote locus and a local one: everything works via TCP/IP, Internet socket/port, or whatever. But you guys are more familiar with this sort of thing. Maybe there's a major flaw in that idea. > > and combining loci to form a graphical scripting language. The > > network-distributed nature of Loci deals with large datasets in a unique way: > > GUI loci reside on a local workstation while compute-intensive data-processing > > loci execute remotely on high-performance computers. The joining of loci > > across the Internet can also be used to form world-wide collaboratives and > > bring an infinitely extensible set of loci to the user. Numerous development > > tools used include Python, GTK+ and the GNOME environment: CORBA, DOM, XML and > > so on. > > As someone else pointed out, this last part should be a little more > descriptive. You may want to distiguish between the language/tools > for the core of loci and the language-independence for the extensions. Good point. If I don't put it in the abstract, it'll certainly go on the poster. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Tue Sep 7 13:32:54 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] abstract References: <199909071707.NAA29770@chimbo.neurobio.upr.clu.edu> Message-ID: <37D54C46.F0603F37@bc.edu> Humberto Ortiz Zuazaga wrote: > > > D'Oh! The deadline was today, and I submitted last night :-/ Sorry. That's > > not a critical change to you, is it? > > Not really, but I think your phrasing might scare people, and we're not > currently using all that, just Python and gnome-python, right? Just Python and Gnome for now. I'd like to describe Loci as it WILL BE someday. But you're right, I should say what state the program is currently in...but probably not in the abstract. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Tue Sep 7 13:25:50 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] SV: [Pipet Devel] abstract Message-ID: <40DEF2EE1151D311BC520050047B41450189E4@195-66-34-2.itv.se> > > Do the lines really depict network connections or rather data "pipes" > > which may or may not be accross a network? > > (Even though I just submitted the abstract, these comments will be helpful for > writing the poster.) > > That's something that we have to work out. I imagined that they would all be > 'network-based' data pipes, if that makes any sense. So, if the GUI and the > analysis program both reside on the user's computer, the connection will just > loop back. URI: If you are using CORBA connections, you need not to worry about such things. At least ORBit uses local domain sockets ( == mem mapped ) if both end connections reside on the same machine. :) I think mico does this too, but I'm not sure. > This way, Loci never has to distinguish between a remote locus and a local one: > everything works via TCP/IP, Internet socket/port, or whatever. But you guys > are more familiar with this sort of thing. Maybe there's a major flaw in that > idea. Has anybody been checking out some multicast technlogy that could be useful to loci? Since loci should be general - purpose and network wide, you might end up at least sometime with a large number of loci that works with the same data. Using TCP/IP in such an application would be very inefficient. And unfortunately, the CORBA standard does not support multicasting. It would at least be very hard to inplement it. :( Cheers // Liss From David.Lapointe at umassmed.edu Tue Sep 7 13:30:13 1999 From: David.Lapointe at umassmed.edu (Lapointe, David) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] PSB 2000 Message-ID: <93307F07DE63D211B2F30000F808E9E501644DE4@edunivexch02.umassmed.edu> I won't be going. David Lapointe > > GOING TO PSB 2000 > > > > Please update this list as needed. From bizzaro at bc.edu Tue Sep 7 13:47:40 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] SV: [Pipet Devel] abstract References: <40DEF2EE1151D311BC520050047B41450189E4@195-66-34-2.itv.se> Message-ID: <37D54FBC.7EC82D4D@bc.edu> Svanberg Liss wrote: > > If you are using CORBA connections, you need not to worry about such things. > At least ORBit uses local domain sockets ( == mem mapped ) if both end > connections reside on the same machine. :) > I think mico does this too, but I'm not sure. Right, I have been forgetting that CORBA manages networking. Maybe the abstract should read, "...joined by lines that dipict CORBA connections" ? > Has anybody been checking out some multicast technlogy that could be useful > to loci? > Since loci should be general - purpose and network wide, you might end up at > least sometime with a large number of loci that works with the same data. Hmmm... > Using TCP/IP in such an application would be very inefficient. > And unfortunately, the CORBA standard does not support multicasting. It > would at least be very hard to inplement it. :( There are a number of issues that are specific to large datasets like those in bioinformatics. We just haven't worked them all out yet. I'm going to leave it to you guys to recommend what you think is best. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Tue Sep 7 13:56:29 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] PSB 2000 list Message-ID: <37D551CD.70494D91@bc.edu> GOING TO PSB 2000 YES MAYBE NO NO REPLY ---------------------------------------------------------------------- Bizzaro Junier Williams Triche Van Domselaar St. Onge Harrison Cohen Steinbachs P. Rice Sicheritz Zuazaga Jain Hinsen Villa Marx Beck Lapointe Mangalam Bradford de Lahondes D. Rice Dang, it's not going to be much of a Loci meeting. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From Thomas.Sicheritz at molbio.uu.se Wed Sep 8 04:19:08 1999 From: Thomas.Sicheritz at molbio.uu.se (Thomas.Sicheritz@molbio.uu.se) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] PSB 2000 list In-Reply-To: <37D551CD.70494D91@bc.edu> References: <37D551CD.70494D91@bc.edu> Message-ID: <14294.7164.589483.504167@beagle.bmc.uu.se> J.W. Bizzaro writes: > GOING TO PSB 2000 > YES MAYBE NO NO REPLY > ---------------------------------------------------------------------- > Bizzaro Junier Williams Triche > Van Domselaar St. Onge Harrison Cohen > Steinbachs P. Rice Sicheritz > Zuazaga Jain > Hinsen Villa > Marx Beck > Lapointe Mangalam > Bradford > de Lahondes > D. Rice > Unfortunatley, I have no time to visit PSB. Halv of the summer got wasted on reinstalling and reconfiguring our systems after script-kiddies infection - and I had to move my dissertation a couple of months ... :-( How is it going on the phylogenetic front ? Any news ? c ya -thomas -- Sicheritz Ponten Thomas E. Linnaeus Centre for Bioinformatics 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 Wed Sep 8 06:34:08 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] PSB 2000 list References: <37D551CD.70494D91@bc.edu> <14294.7164.589483.504167@beagle.bmc.uu.se> Message-ID: <37D63BA0.F7B46ECD@bc.edu> Thomas.Sicheritz@molbio.uu.se wrote: > > Unfortunatley, I have no time to visit PSB. Hej Thomas. Sorry to hear that. > Halv of the summer got wasted on reinstalling and reconfiguring our systems > after script-kiddies infection - and I had to move my dissertation a couple > of months ... :-( Jeez. You have quite a bit of cracker activity over there, don't you? > How is it going on the phylogenetic front ? > Any news ? I suppose you're still on the PyPhy mailing list. Of course Jeff Chang just joined and I think is waiting to get some of his code incorporated into PyPhy. Rick Ree is back from China, and he's looking into Python/C++ bindings for some phylogenetics code he's got. I don't know what activity there has been on the code in CVS. Will you continue to work on PyPhy? Cheerios. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From hortiz at neurobio.upr.clu.edu Wed Sep 8 16:05:40 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:50 2006 Subject: [Pipet Devel] XDDB, a xml database Message-ID: <199909082005.QAA03128@chimbo.neurobio.upr.clu.edu> Not GPL, but maybe worth a look http://www.bowerbird.com.au/XDBM/ A database for xml documents. -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From bizzaro at bc.edu Fri Sep 10 09:21:58 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] ANNOUNCE: Python/ORBit Bindings Message-ID: <37D905F6.2E5C3C09@bc.edu> ANNOUNCING PyORBit: Python/ORBit Bindings PyORBit is a project to create Python bindings for ORBit, a fast, lightweight CORBA ORB used by the GNOME Desktop for application and component interaction (similar to Microsoft's COM). These bindings will be distributed under the GNU LGPL license. PyORBit will follow the proposed OMG Python bindings to insure compliance and compatibility, but we will also consider non-standard, optional extensions to improve performance and add features, if necessary. Version 0.0.1 of PyORBit is already available thanks to Michael Robinson's contribution of his Python/ORBit bindings. This initial implementation should be functional for simple interfaces (assuming it compiles for you). However, this version is considered a developers-only release, as the structure and layout of later PyORBit releases will likely change to some degree. Regardless, bug reports and patches are welcome. PyORBit is coordinated by Justin Bradford . Source and a developer's mailing list can be found at: http://bioinformatics.org/pyorbit/ The PyORBit project is hosted by The Open Lab, a non-profit organization established to promote research collaborations and free-software development in the scientific field of bioinformatics. http://bioinformatics.org/ Cheers. Jeff From bizzaro at bc.edu Sun Sep 12 16:52:15 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] more on corba Message-ID: <37DC127F.1939F346@bc.edu> Linux World has an introduction to CORBA in 2 parts. Here's part 1: http://www.linuxworld.com/linuxworld/lw-1999-09/lw-09-corba_1.html Of particular relevance to our interests, the demo uses the ILU Python/CORBA system. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 13 16:41:04 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] LOCI '99 meeting Message-ID: <37DD6160.386025B6@bc.edu> Greetings. Talking to Ken Marx and getting Gary's schedule, it looks like the informal meeting about Loci will TENTATIVELY be Date: Thursday, September 16 Time: 2-4 pm OR 3-5 pm (depending on location) Location: UMass Worcester, David Lapointe's home or Boston College I need confirmation from David and Gary about time and location. Ken will be in Worcester around noon on that day, and this is where David works, so the UMass Worcester location seems best. But then I'd have to get Gary from Boston to Worcester. For anyone else, it is not important that you travel any distance for this, since it'll be pretty short. But if you happen to be in the Boston area, let me know. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Mon Sep 13 18:13:47 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] LOCI '99 meeting In-Reply-To: <37DD6160.386025B6@bc.edu> from "J.W. Bizzaro" at Sep 13, 99 08:41:04 pm Message-ID: <199909132213.QAA09303@redpoll.pharmacy.ualberta.ca> > Date: Thursday, September 16 > Time: 2-4 pm OR 3-5 pm (depending on location) > Location: UMass Worcester, David Lapointe's home or Boston College > I'm afraid I will need transportation out to Worcestor, otherwise its fine. --Gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at bc.edu Mon Sep 13 22:27:47 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] XDDB, a xml database References: <199909082005.QAA03128@chimbo.neurobio.upr.clu.edu> Message-ID: <37DDB2A3.133EE335@bc.edu> Humberto Ortiz Zuazaga wrote: > > Not GPL, but maybe worth a look > > http://www.bowerbird.com.au/XDBM/ > > A database for xml documents. Yeah, it's QPL. Go figure why people like TrollTech's license so much. AFAIK, QPL is a 'free for non-commercial use' license, which is incompatible with the GPL (GPL doesn't restrict commercial use). As Humberto said, it'd make for a good reference. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Tue Sep 14 23:00:28 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] [Fwd: isectd 1.0 - middleware daemon for client/server, dist. processing, & multi-tier programming] processing, & multi-tier programming] Message-ID: <37DF0BCC.F0B7CD57@bc.edu> I don't know if this is of any interest to us. -------------- next part -------------- An embedded message was scrubbed... From: freshd@freshmeat.net Subject: isectd 1.0 - middleware daemon for client/server, dist. processing, & multi-tier programming Date: 14 Sep 1999 03:38:15 GMT Size: 1269 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990915/904e6176/attachment.mht From bizzaro at bc.edu Fri Sep 17 22:40:35 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] [Fwd: Poster/Demo at Open Source/Open Science 99] Message-ID: <37E2FBA3.2B663E01@bc.edu> FYI, this comes from the organizers of the Open Source/Open Science 99 conference. -------------- next part -------------- An embedded message was scrubbed... From: "Sean R. McCorkle" Subject: Poster/Demo at Open Source/Open Science 99 Date: Fri, 17 Sep 1999 15:57:59 -0400 (EDT) Size: 3131 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990918/3c12fb3d/attachment.mht From justin at ukans.edu Sat Sep 18 00:18:30 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] [Fwd: Poster/Demo at Open Source/Open Science 99] In-Reply-To: <37E2FBA3.2B663E01@bc.edu> Message-ID: > FYI, this comes from the organizers of the Open Source/Open Science 99 > conference. Great, it was accepted! Is there anything you need us to do for the poster/presentation? When is the conference? We might be able to fake some of the more advanced stuff for presentation purposes. Justin From bizzaro at bc.edu Sat Sep 18 23:13:47 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] [Fwd: pypvm 0.8.5 - Provides an interface to the Parallel Virtual Machine to Python] Machine to Python] Message-ID: <37E454EB.DEB1D30F@bc.edu> Hmm. -------------- next part -------------- An embedded message was scrubbed... From: freshd@freshmeat.net Subject: pypvm 0.8.5 - Provides an interface to the Parallel Virtual Machine to Python Date: 19 Sep 1999 00:23:59 GMT Size: 1102 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990919/7b05d1e8/attachment.mht From bizzaro at bc.edu Sat Sep 18 23:32:20 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] software find References: <37B9BA00.76F2B404@fmnh.org> Message-ID: <37E45944.101160B4@bc.edu> Jennifer, Sorry for the late reply. I can't recall having seen ARB before, but thanks for the link. Cheers. Jeff JES wrote: > > Greetings all... > > I have this recently-acquired spiffy Intel box (running Linux of course) > and I need something to run on it... > > I've been downloading and trying to compile stuff to give this machine a > little workout. > > I discovered something nifty :) I thought I had seen reference to this > package somewhere on this list, but I can't seem to find it in my > collection of messages (apologies if this is a double posting). > > http://www.mikro.biologie.tu-muenchen.de/ > http://www.mikro.biologie.tu-muenchen.de/pub/ARB/ > > A little bit more tweaking and I might have it functional. > > Cheers, > -j > -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Sun Sep 19 00:06:52 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] [Fwd: Poster/Demo at Open Source/Open Science 99] References: Message-ID: <37E4615C.EFF9C5D2@bc.edu> Justin Bradford wrote: > > Is there anything you need us to do for the poster/presentation? David, Gary, Ken and I met this past week at "LOCI '99" to discuss (1) the components of Loci to be written up as sections of a formal publication (in the journal Bioinformatics) or poster (for this conference), and (2) funding for Loci. I will post some more information about the meeting shortly. But one major component we couldn't write much about is "object passing and locus communication", since I am pretty much leaving it up to you and a few others to work out the details. I suppose much of what has been posted to this list a few months back may be usable. Could somebody in the know please write something on this topic: one paragraph for the poster and a few paragraphs for the paper? I'd appreciate it. > When is the conference? We might be able to fake some of the more > advanced stuff for presentation purposes. The conference is Saturday, October 2nd, at Brookhaven National Lab on Long Island. (For those who haven't been following recent discussions, we will have a poster at this conference, and I posted the abstract here about a week ago.) I would also like to demo the Workspace, but that won't require the infrastructure to be in place. I think just a blurb about the "advanced stuff" would be fine for the poster. The paper will of course require more. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bcohen at cs.sunysb.edu Sun Sep 19 12:48:57 1999 From: bcohen at cs.sunysb.edu (barry cohen) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] open source conference In-Reply-To: <199909191600.MAA04409@bioinformatics.org> Message-ID: Sorry I haven't been contributing to Loci. But I have been following the development. And I'm planning to be at the open source conf at BNL. So if I can be of use there, let me know. Otherwise, I'll look forward to meeting people. barry cohen ps I've been doing some Python coding; so perhaps I could take on some modest task. From bizzaro at bc.edu Sun Sep 19 20:05:35 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] loci-config, a modest task? References: Message-ID: <37E57A4F.62F1EB2C@bc.edu> barry cohen wrote: > > ps I've been doing some Python coding; > so perhaps I could take on some modest > task. I think we should start on a configuration program for Loci: 'loci-config'. This would be a program that runs separately from the others and is used to (1) set preferences, (2) help with installation and (3) launch the other programs. And since it will be the launching 'Loci', it should be named 'loci' (or be symlinked from 'loci') and be the first program executed. I would like it to be written in Python/GTK/GNOME, but it doesn't HAVE TO use Python. The preferences manager would... (1) Set Workspace theme (pixmap or solid color) (2) Set locus colors (right now, black on white or white on black) (3) Set locus scale (the size of loci can be scaled up x1-5) (4) Set GTK widget theme (pixmap or solid color) Regarding themes, they are actually specified in a 'gtkrc' file. We will have preconfigured gtkrc files, so we don't have to worry about writing to them. We would just allow for selection between those available. So, we should have a directory where the gtkrc files are stored, like this: gtkthemes/ workspace/ theme1.gtkrc theme2.gtkrc ... widgets/ theme1.gtkrc theme2.gtkrc ... And the user can select theme1.gtkrc, etc. The preference settings should be stored in two places, as is common for UNIX systems: (1) in the Loci installation directory, maybe... /usr/lib/loci-core-0.0.1/locirc and (2) in the user's directory: ~/.locirc or ~/.loci/locirc ? We also want this configuration program to manage installation. So the installation manager would... (1) Check for the presence of libraries required to run Loci. (I think this should be done every time Loci starts.) (2) Manage the installation/removal of individual loci/locuses. NOTE: INSTALLATION REQUIRES ROOT ACCESS Installation management is very much akin to installing RPMs. There had been some talk about using RPM itself, and all we may need to do is make a wrapper for RPM. Typically, Loci will not be transporting programs across the Internet, but just the GUI represented as XML. If the user wants to get something like an analysis program and install it on his own computer, that should be done in the traditional fashion: Get the tarball (or RPM) and install it. This would mean setting it up so that it is accessible by others that use the computer, which in turn means the sys admin needs to install it. Finally, the config program should lauch the rest of Loci. Why? As I mentioned above, loci-config will check for library dependencies and installed loci. This will assure that Loci starts up properly and knows what locuses are available (to the local user and to remote users). So I think this config program will start up with a dialog box containing a graphic, some text about what config is doing, and a progress bar (see how The GIMP starts up): +---------------------------+ | | | THE LOCI PROJECT | | (pretty pic) | | | | checking libraries... | | | | ############### 80% | +---------------------------+ And then when done checking everything, the user (or sys admin) can choose (via button) from the 3 options: +---------------------------+ | | | THE LOCI PROJECT | | (pretty pic) | | | | | | [Pref] [Inst] [Launch] | | | +---------------------------+ Any takers for working on this program? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Sun Sep 19 20:21:31 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] loci-config, a modest task? References: <37E57A4F.62F1EB2C@bc.edu> Message-ID: <37E57E0B.7212B783@bc.edu> "J.W. Bizzaro" wrote: > > This would be a program that runs separately from the others and is used to (1) > set preferences, (2) help with installation and (3) launch the other programs. > > +---------------------------+ > | | > | THE LOCI PROJECT | > | (pretty pic) | > | | > | | > | [Pref] [Inst] [Launch] | > | | > +---------------------------+ I think the 'preferences manager' and 'installation manager' should also (like the rest of Loci) be separate programs. Therefore, loci-config will be a relatively small program. But loci-config should be able to 'talk' to the install manager (or part of it) and do a CHECK on the installation BEFORE it gets to the dialog box with 3 buttons. Clicking on the 'Install' button, OTOH, brings up a GUI for doing install/uninstall. So the install manager is 2 programs: (1) Checks installation (done everytime loci-config starts) (2) Facilitates change in installation (done when click on 'Install' button) Am I making sense? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Sun Sep 19 20:43:33 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] ORBit module for Perl released Message-ID: <37E58334.614D7AB2@bc.edu> This comes from the Gnotices Web page: Posted by Owen Taylor on Sunday September 19, @08:11PM I've made an initial release of dynamic Perl bindings for ORBit available. They are available here. ftp://ftp.gnome.org/pub/otaylor/ Though far from complete, they pretty useable already. here is also a GNOME::GNORBA module there for using CORBA::ORBit within GNOME. The nifty thing about CORBA::ORBit is that you don't need to to create the stubs/skeletons as a separate step. You can either point it directly at an IDL file that it will parse directly, or it can it can get the information from an interface repository. (Not the ORBit IR, yet.) It is also very compact in terms of the amount of code necessary to implement clients and servers. CORBA::ORBit will work out of the box with the Gtk:: Perl module, and an example of this is included. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From hortiz at neurobio.upr.clu.edu Mon Sep 20 11:04:40 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] loci-config, a modest task? In-Reply-To: Your message of "Mon, 20 Sep 1999 00:05:35 GMT." <37E57A4F.62F1EB2C@bc.edu> Message-ID: <199909201504.LAA30729@chimbo.neurobio.upr.clu.edu> > barry cohen wrote: > > > > ps I've been doing some Python coding; > > so perhaps I could take on some modest > > task. > > I think we should start on a configuration program for Loci: 'loci-config'. > This would be a program that runs separately from the others and is used to (1) > set preferences, (2) help with installation and (3) launch the other programs. There's a gnome library for configuration settings called gconf in the gnome cvs tree, info available at: http://freshmeat.net/appindex/1999/09/19/937789683.html -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From David.Lapointe at umassmed.edu Mon Sep 20 11:33:21 1999 From: David.Lapointe at umassmed.edu (Lapointe, David) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] Neuroinformatics funding Message-ID: <93307F07DE63D211B2F30000F808E9E501644E1B@edunivexch02.umassmed.edu> This is from NIH, however it may have a place in LOCI. Interesting the emphasis on *tools*. 1> Neuroinformatics funding: Neuroinformatics combines neuroscience and informatics research (databases, graphical interfaces, querying approaches, information retrieval, data visualization and manipulation, data integration and analysis, simulation tools, and electronic collaboration) for understanding brain structure and function. NIH is soliciting research proposals for development of neuroinformatics tools. Letters of intent are due 15Aug99, 01Apr00, and 01Oct00, with proposals due 20Oct99, 11Jul00, and 11Jan01. PAR-99-138, . [FOA, 11Aug99.] NIH is also offering Institutional Mentored Research Scientist Development Awards (K12) in neuroinformatics and also support for short courses and short-term Education Grants in Neuroinformatics Research. Letters of intent are due 15Aug99, 01Apr00, and 01Oct00, with proposals due 20Oct99, 11Jul00, and 11Jan01. PAR-99-136 and PAR-99-137 <.../08069910.htm>. David Lapointe, Ph.D. Research Computing Manager 6-5141 "What we obtain too cheap, we esteem too lightly." - T. Paine From bizzaro at bc.edu Tue Sep 21 22:50:38 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] [Fwd: [pygtk] glade python code generator] Message-ID: <37E843FE.52BD51C@bc.edu> -------------- next part -------------- An embedded message was scrubbed... From: James Henstridge Subject: [pygtk] glade python code generator Date: Wed, 22 Sep 1999 09:45:39 +0800 (WST) Size: 1766 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990922/2d4c9e3c/attachment.mht From bizzaro at bc.edu Tue Sep 21 22:38:29 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] server's back Message-ID: <37E84125.8F82FC01@bc.edu> Greetings. We had a small glitch, but everything is back up and running. My apologies. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Wed Sep 22 14:14:36 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:51 2006 Subject: [Pipet Devel] ORBit module for Perl released References: <37E58334.614D7AB2@bc.edu> Message-ID: <37E91C8C.5A5A5A5D@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > This comes from the Gnotices Web page: > > Posted by Owen Taylor on Sunday September 19, @08:11PM > > I've made an initial release of dynamic Perl bindings for ORBit available. > They are available here. > > ftp://ftp.gnome.org/pub/otaylor/ > I wonder if the bioperl group is aware of this? I noticed in their bitsjournal publication (http://www.bitsjournal.com/bioperl.html) that the bioperlians have this to say about CORBA: __________ The Bioperl modules presented here certainly reflect the strengths and limitations of Perl. Thus, there are not very many functions for graphical output of bio-object data. It is therefore likely that Bioperl objects, specialized for text parsing and analysis, could collaborate with objects implemented in other languages (such as Java) that provide graphical displays of the results. A commonly used strategy involves a Perl CGI script that configures a Java applet for web browsers (example). More complex relationships are possible through technologies such as CORBA that can mediate interactions between objects in different languages(Pope 1997). We are encouraged in this regard by the ongoing CORBA-Perl project (Schuller 1997) and we have developed connections with a CORBA-related effort in the bioinformatics community known as the Life Sciences Research Domain Task Force within the OMG (Life Science Research Group 1997). ____________ --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Wed Sep 22 15:43:12 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] ORBit module for Perl released References: <37E58334.614D7AB2@bc.edu> <37E91C8C.5A5A5A5D@redpoll.pharmacy.ualberta.ca> Message-ID: <37E93150.12DBDF8E@bc.edu> Gary Van Domselaar wrote: > > I wonder if the bioperl group is aware of this? I noticed in their > bitsjournal publication (http://www.bitsjournal.com/bioperl.html) that > the bioperlians have this to say about CORBA: Hmmm. It makes me wonder if they are aware of Perl/GTK ;-) It's amusing that so many bioinformaticists believe they are trapped in a world with only two languages: Perl and Java. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Wed Sep 22 17:49:12 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] [Fwd: Poster/Demo at Open Source/Open Science 99] Message-ID: <37E94ED8.A381D99B@bc.edu> This is PART of the correspondence I've had with the OSOS guys, FYI. -------------- next part -------------- An embedded message was scrubbed... From: "Sean R. McCorkle" Subject: Re: Poster/Demo at Open Source/Open Science 99 Date: Wed, 22 Sep 1999 15:59:29 -0400 (EDT) Size: 6042 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990922/21cf0172/attachment.mht From bizzaro at bc.edu Wed Sep 22 18:21:49 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Re: Poster/Demo at Open Source/Open Science 99 References: <199909221959.PAA04245@hgp2.bio.bnl.gov> Message-ID: <37E9567D.C11145D@bc.edu> "Sean R. McCorkle" wrote: > Thats an omission in the schedule which I'm going to correct right now. > There certainly will be time to set up on saturday morning. Great. Thank you. > Many apologies for inconveniencing you, because we're really looking forward > to your participation. This whole affair has been a real learning > experience for us. We're hoping to hold another conference again, and > it will definitely be a multi-day meeting, at a hotel, with much more > reasonable schedules and better planning (based on this years experiences). > However, I hope that THIS one will be a good experience for all. I'm sorry to have appeared so critical. I looked at the schedule and felt a bit overwhelmed. The line up of speakers is quite impressive and makes me wonder if anyone was left out at all ;-) I can't help but think that the next OSOS meeting will be somewhat anticlimactic (been there, done that). But I look forward to it nonetheless :-) > Again, we're looking forward to meeting you in person. And you too. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Wed Sep 22 21:32:40 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage Message-ID: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> Locians, During my visit to Boston, Jeff and i talked quite a bit about Loci and how, at its core, it will essentially be framework for data management and data processing. This led me to thinking about how Loci will store data. I dont think this aspect of the loci core has been very thoroughly addressed. Does anyone have any ideas on how we might implement data storage for Loci? I'm no database expert, so I'm a little hesitant to suggest how we should go about it, but it does seem important to me that loci should be able to store analysis results in a relational database (Informax's VectorNTI uses a relational database to store its data). This would facilitate the construction of customized, sharable databases. In keeping with Loci's philosophy of not adopting specific data formats, it seems to me that Loci should probably not adopt a single database, but rather have the capability to interface with any of the popular databases, such as oracle, sql, mysql, etc. PHP has this capability, and is one of the biggest reasons why it is so successful. What do y'all think? Regards, --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From dlapointe at mediaone.net Wed Sep 22 22:19:52 1999 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] YATTLA Message-ID: <99092222421900.00499@celery> That's Yet Another Thing To Look At!! This is from a dialogue on bionet.metabolic-reg 'Univeral format for storing pathways and models'. Gene Selkov ( at ANL) has a node-based graphical tool for constructing metabolic pathways. You might want to look at it. I thought it was interesting in the context of loci. http://www.xnet.com/~selkovjr/ElectricArc/ -- .david David Lapointe Do Not Attribute To Malice That Which Can Be Attributed To Stupidity From bizzaro at bc.edu Wed Sep 22 23:58:42 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> Message-ID: <37E9A572.F1FE3A87@bc.edu> Gary Van Domselaar wrote: > > I dont think this aspect of the loci core has been very thoroughly > addressed. Does anyone have any ideas on how we might implement data > storage for Loci? In early conversations, we realized the need to split the data into two basic types according to how they would be managed: (1) Data kept (as XML?) on the filesystem: mostly for storage; data are not being passed via the Loci system (2) Data kept as (CORBA) objects: data that are being passed via Loci Alan then proposed the concept of pluggable/modular 'data managers'. A DM would manage data of any specific type and is pretty much synonymous to what I have been calling a 'translator', which converts data from one format to another, plus the underlying infrastructure (what will actually be handled by CORBA). Here is an excerpt from Alan's e-mail on June 1 (this is in the archive; GST refers to General Sequence Toolkit): --------------- [snip] I am loosly defining the "Data Manager" or DM as the interface and backend or server side code for managing bioinformatics data of various types. Some of the design goals for the DM: 1) Allow for extendibility (ie DM plugins) 2) Simple, general, but sufficient interface 3) Minimize transfere of un-needed data 4) Allow for relocation of data 5) Allow for read only access 6) Enable wrappers for common non-xml, non-gst data sets (ie genbank) 7) Allow multi user access 8) The interface should not assume anything regarding the data except that it is in an XML format. 9) Enable network transparency 10) Simple and robust xreferencing 11) ??? In the most basic sense, GST would not have a DM but rather a DM interface to DM plug-ins. Some examples: 1) Genbank/Entrez DM would consist of a local plug-in that provide the program with read only access to NCBI's databases over the internet. The non-xml genbank entries would automatically be wrapped/converted into xml by the DM. 2) Intranet Oracle or AceDB database DM would consist of a local plug-in (as well as a server for the plug-in possibly). The plug-in would handle the network transparency as well as wrapping/converting the data to xml. 3) A file system DM would consist of a plugin for GST as well as a server for the plug-in. Transfere of data from the file system to GST would be handled by a socket b/w the plugin and the server. When a user starts up GST, if a filesystem DM for his/her personal GST directory is not running, one is automatically started. If the user is on another computer, they can still access their personal GST directory as long as the file system DM is running on the same computer as the personal GST directory tree. [snip] --------------- There is very little difference between what Alan is talking about here (except we are using CORBA and leaning away from making our own bio-XML), and in fact much of the most recent design for Loci comes from Alan's description of the GST. > I'm no database expert, so I'm a little hesitant to > suggest how we should go about it, but it does seem important to me that > loci should be able to store analysis results in a relational database > (Informax's VectorNTI uses a relational database to store its data). Hmmm. That is providing (1) there are numerous analysis results to be stored and 'related', and (2) the user needs to store the results this way. Are you suggesting this as an option or as a standard way of storing everything? > This > would facilitate the construction of customized, sharable databases. In > keeping with Loci's philosophy of not adopting specific data formats, it > seems to me that Loci should probably not adopt a single database, but > rather have the capability to interface with any of the popular > databases, such as oracle, sql, mysql, etc. PHP has this capability, and > is one of the biggest reasons why it is so successful. Right. I think that is exactly what Alan was suggesting with the data manager proposal. But again, I'm not sure everything has to be put in some database. What do you guys think? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Sep 23 00:11:04 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] YATTLA References: <99092222421900.00499@celery> Message-ID: <37E9A857.17E5D11D@bc.edu> Thanks, David. I'm going to add that to my list of programs that produce (or work with) flow diagrams of a sort. BTW, here is the list: http://www.isldsi.com/clementine.htm http://www.isldsi.com/_borders/Image53.gif http://www.legomindstorms.com/program/tips_tricks/tips_orgprog.html http://lcs.www.media.mit.edu/people/fredm/projects/cricket/logoblocks/index.html http://www.lego.com/dacta/robolab/rcxprograms.htm http://www.daimi.au.dk/CPnets/intro/ http://www.lysator.liu.se/~alla/dia/ http://www.visio.com/products/understand/basics.html http://www.visio.com/products/standard/versatile/smartshapes.html http://24.1.97.22/gmd/tps/treepsfm.html http://www.damer.com/pictures/elixir/products/shirt1m.jpg http://www.digital.com/info/fuse/images/clas_screen.gif http://products.ics.com/builders/icsbxprouibrowser.jpg http://www.gxsnmp.org/gallery/netmap2.jpg http://www.xnet.com/~selkovjr/ElectricArc/ Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Sep 23 00:43:28 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> Message-ID: <37E9AFF0.399BDA57@bc.edu> "J.W. Bizzaro" wrote: > > But again, I'm not sure everything has to be put in some database. > What do you guys think? Ah! A 'container locus' is a database! Container loci contain multiple loci, which can in reality be in a database. Ureeka! Look at how Visio puts objects in a pane (green background) on the left: http://www.visio.com/products/understand/images/maingraph.gif And the same with Logo Blocks: http://lcs.www.media.mit.edu/people/fredm/projects/cricket/logoblocks/bluedot.gif Since objects need to be categorized (Logo Blocks has selection buttons underneath the pane to switch between categories), Loci will have one 'container locus' per category (of the user's choosing), which is a locus whose 'windowlet' is a list of the loci contained therein. And container loci can be add to, subtracted from, created and destroyed by the user, ultimately making a very flexible system. (I wrote about this a few weeks ago.) But making the container a relational database too makes the 'Loci way' MUCH MORE POWERFUL than anything else I've heard of! Cool idea, Gary. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Thu Sep 23 00:58:16 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> Message-ID: <37E9B368.85408A11@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Gary Van Domselaar wrote: > > > > I dont think this aspect of the loci core has been very thoroughly > > addressed. Does anyone have any ideas on how we might implement data > > storage for Loci? > > In early conversations, we realized the need to split the data into two basic > types according to how they would be managed: > > (1) Data kept (as XML?) on the filesystem: mostly for storage; data > are not being passed via the Loci system > > (2) Data kept as (CORBA) objects: data that are being passed via Loci That makes sense. > > Alan then proposed the concept of pluggable/modular 'data managers'. A DM would > manage data of any specific type and is pretty much synonymous to what I have > been calling a 'translator', which converts data from one format to another, > plus the underlying infrastructure (what will actually be handled by CORBA). > Here is an excerpt from Alan's e-mail on June 1 (this is in the archive; GST > refers to General Sequence Toolkit): Yes, I remember reading this. My understanding was that the DM was designed to extract data from existing databases, then convert the information to a format appropriate for further analysis. I wasnt sure that the concept had been extended to inputing (and maintaining) data from a new or existing database. _________ > > 2) Intranet Oracle or AceDB database DM would consist of a local > plug-in (as well as a server for the plug-in possibly). The plug-in > would handle the network transparency as well as wrapping/converting > the data to xml. Here Alan mentions a plug-in interface to oracle and AceDB, but doesnt really address the issue of data storage vs data extraction. > > I'm no database expert, so I'm a little hesitant to > > suggest how we should go about it, but it does seem important to me that > > loci should be able to store analysis results in a relational database > > (Informax's VectorNTI uses a relational database to store its data). > > Hmmm. That is providing (1) there are numerous analysis results to be stored > and 'related', and (2) the user needs to store the results this way. Are you > suggesting this as an option or as a standard way of storing everything? I think it depends on the nature of the data processing and analysis that the end-user wishes to perform. If someone just wants an answer and a pretty picture, then there is nothing to gain by storing the result in a relational database. If, however, the researcher is working on a large project, they may very well want to have the results stored in a database, so that they can later query the database for interesting patterns, irregularities, etc. So I guess it would be an option, just one that I think is very important. > > > This > > would facilitate the construction of customized, sharable databases. In > > keeping with Loci's philosophy of not adopting specific data formats, it > > seems to me that Loci should probably not adopt a single database, but > > rather have the capability to interface with any of the popular > > databases, such as oracle, sql, mysql, etc. PHP has this capability, and > > is one of the biggest reasons why it is so successful. > > Right. I think that is exactly what Alan was suggesting with the data manager > proposal. So then, for clarity, if Loci were to allow for database storage of analysis results, it would be implemented as a DM output option, with the various available database interfaces as DM-plug-ins? Regards --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From gvd at redpoll.pharmacy.ualberta.ca Thu Sep 23 01:08:27 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> <37E9AFF0.399BDA57@bc.edu> Message-ID: <37E9B5CB.C18EF6CF@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Ah! A 'container locus' is a database! Container loci contain multiple loci, > which can in reality be in a database. Ureeka! > > Since objects need to be categorized (Logo Blocks has selection buttons > underneath the pane to switch between categories), Loci will have one 'container > locus' per category (of the user's choosing), which is a locus whose 'windowlet' > is a list of the loci contained therein. And container loci can be add to, > subtracted from, created and destroyed by the user, ultimately making a very > flexible system. (I wrote about this a few weeks ago.) But making the > container a relational database too makes the 'Loci way' MUCH MORE POWERFUL than > anything else I've heard of! Cool idea, Gary. Geez, I was just thinking about data storage, not loci storage. But I'll take credit for your genius anyday ;-) So now, who wants to tackle this can of worms? Alan sure seems to know his stuff when it comes to data management ;-) -- gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Thu Sep 23 01:49:03 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> <37E9AFF0.399BDA57@bc.edu> <37E9B5CB.C18EF6CF@redpoll.pharmacy.ualberta.ca> Message-ID: <37E9BF4F.304BC02B@bc.edu> Gary Van Domselaar wrote: > > Geez, I was just thinking about data storage, not loci storage. What's the difference? All data are loci, and all loci (interfaces - not programs) are data. If data can be stored, then so can loci. Remember: We will be representing everything graphically, and all graphics (GUIs, diagrams, etc.) will be kept as XML (biodata will remain format-independent, but we can still use XML headers or whatever). All we have to do then is manage XML objects: it'll make no difference if the object is a GUI component or a reference to a program (actual programs will be referenced, not directly managed by Loci). Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Thu Sep 23 01:52:48 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> <37E9AFF0.399BDA57@bc.edu> <37E9B5CB.C18EF6CF@redpoll.pharmacy.ualberta.ca> <37E9BF4F.304BC02B@bc.edu> Message-ID: <37E9C030.B761FA71@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Gary Van Domselaar wrote: > > > > Geez, I was just thinking about data storage, not loci storage. > > What's the difference? All data are loci, and all loci (interfaces - not > programs) are data. If data can be stored, then so can loci. I concur. Capital idea! --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From gvd at redpoll.pharmacy.ualberta.ca Thu Sep 23 02:06:14 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> <37E9AFF0.399BDA57@bc.edu> <37E9B5CB.C18EF6CF@redpoll.pharmacy.ualberta.ca> <37E9BF4F.304BC02B@bc.edu> Message-ID: <37E9C356.DFB541C0@redpoll.pharmacy.ualberta.ca> There is a python database special interest group that have produced a python DB-API specification. From http://starship.python.net/crew/amk/writing/DB-API.html __________ ...the Database SIG produced a specification for a consistent interface to relational databases -- the DB-API. Thanks to this specification, there's only one interface to learn. Porting code to use a different database product is much simpler, often requiring the change of only a few lines. __________ The DB-SIG homepage can be found at http://www.python.org/sigs/db-sig/ --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Thu Sep 23 02:18:18 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> <37E9B368.85408A11@redpoll.pharmacy.ualberta.ca> Message-ID: <37E9C62A.C968BDDA@bc.edu> Gary Van Domselaar wrote: > > Yes, I remember reading this. My understanding was that the DM was > designed to extract data from existing databases, then convert the > information to a format appropriate for further analysis. I wasnt sure > that the concept had been extended to inputing (and maintaining) data > from a new or existing database. Hmmm. I only assumed DMs would handle both input and output. Alan will have to correct me if I'm wrong. Hello...Alan? > I think it depends on the nature of the data processing and analysis > that the end-user wishes to perform. If someone just wants an answer and > a pretty picture, then there is nothing to gain by storing the result in > a relational database. Exactly. > If, however, the researcher is working on a large > project, they may very well want to have the results stored in a > database, so that they can later query the database for interesting > patterns, irregularities, etc. So I guess it would be an option, just > one that I think is very important. Sure. Again, I think container loci should act as databases. Anything that includes query operations and not just storage (like AceDB) should be considered a processor locus and not a container. Containers won't include a query mechanism, so they must be connected to one: CONTAINER ------> PROCESSOR ------> CONTAINER ^ Processor is used to query the container database. The results are placed in a new container. More sophisticated databases will expect some data with the query, so they will be connected like this: DATA ------> PROCESSOR ------> CONTAINER ^ For example, processor takes sequence (data) and finds multiple alignments, which are stored in a container. > So then, for clarity, if Loci were to allow for database storage of > analysis results, it would be implemented as a DM output option, with > the various available database interfaces as DM-plug-ins? Yes, but so that we don't confuse anyone, Data Manager == Data Translator (converter) We are not defining another locus type. Whether my idea of a Data Translator becomes more like Alan's idea of a Data Manager or visa versa, I don't know. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Sep 23 02:33:02 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <199909230132.TAA08563@redpoll.pharmacy.ualberta.ca> <37E9A572.F1FE3A87@bc.edu> <37E9B368.85408A11@redpoll.pharmacy.ualberta.ca> <37E9C62A.C968BDDA@bc.edu> Message-ID: <37E9C99E.C68EDAE@bc.edu> "J.W. Bizzaro" wrote: > > Yes, but so that we don't confuse anyone, > > Data Manager == Data Translator (converter) > > We are not defining another locus type. Whether my idea of a Data Translator > becomes more like Alan's idea of a Data Manager or visa versa, I don't know. Let me clarify something. Although DMs/DTs will allow for pluggability and data format independence for the DATA TO BE PROCESSED, we will still have ONE data format for the very basic operations (infrastructure) of Loci (e.g., GUIs) and ONE database (or other type of program) for managing this. Since our infrastructure data will be in XML, we are looking for an XML database. You may have noticed some messages posted to the list about XML databases. Justin mentioned he was considering making one if we did not find one compatible with the LGPL license. :-) Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Thu Sep 23 10:43:55 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage Message-ID: <40DEF2EE1151D311BC520050047B4145018B61@195-66-34-2.itv.se> > Sure. Again, I think container loci should act as databases. Anything that > includes query operations and not just storage (like AceDB) should be considered > a processor locus and not a container. > > Containers won't include a query mechanism, so they must be connected to one: > > CONTAINER ------> PROCESSOR ------> CONTAINER > ^ > Processor is used to > query the container > database. The results > are placed in a new > container. Just some information so that you don't redo a lot of work: ( In case you allready knew all this, then please just forget that I mentioned it again :) The 'CONTAINER' mentioned abowe seems to be exactly the same as GNOME::Storage. ... perhaps with a small exeption... GNOME::Storage has been constructed with a filesystem in mind, and not a loci, so there is no "Connect storage with storage" = make an external storage to appear inside another storage. However, this is not really a problem. If you wan't this feature, then you'll just add a LOCI::Storage wich inherites from GNOME::Storage and adds the "link storage" (or whatever) method. ( Or wait. The Gnome developers will probably add this feature someday. :) Data in a GNOME::Storage are represented with GNOME::Stream objects, and they may contain whatever you prefer. // Liss From bizzaro at bc.edu Thu Sep 23 16:45:21 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] [Fwd: Poster/Demo at Open Source/Open Science 99] Message-ID: <37EA9161.C023E758@bc.edu> -------------- next part -------------- An embedded message was scrubbed... From: "Sean R. McCorkle" Subject: Re: Poster/Demo at Open Source/Open Science 99 Date: Thu, 23 Sep 1999 08:57:53 -0400 (EDT) Size: 1478 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19990923/ace9f120/attachment.mht From bizzaro at bc.edu Thu Sep 23 16:47:32 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Merck Gene Index Message-ID: <37EA91E4.9C9A4526@bc.edu> Greetings. Does anyone have experience with the Merck Gene Index? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Thu Sep 23 20:41:51 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Tools for parsing XML with Python Message-ID: <199909240041.SAA11763@redpoll.pharmacy.ualberta.ca> Hey kids, I found this while looking for a GPL XML database manager: Tools for parsing XML with Python: http://www.stud.ifi.uio.no/~lmariusg/download/python/xml/index.html It may be worth a look. Still no sign of a GPL XML database manager... Regards, --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at bc.edu Mon Sep 27 07:34:38 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Loci and data storage References: <40DEF2EE1151D311BC520050047B4145018B61@195-66-34-2.itv.se> Message-ID: <37EF564E.43751415@bc.edu> Svanberg Liss wrote: > > Just some information so that you don't redo a lot of work: > ( In case you allready knew all this, then please just forget that I > mentioned it again :) Thanks, I had not heard of GNOME::Storage before. I'll take a look at it, as it may be useful to us. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 27 08:08:58 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Tools for parsing XML with Python References: <199909240041.SAA11763@redpoll.pharmacy.ualberta.ca> Message-ID: <37EF5E5A.196F2206@bc.edu> When I wrote to the BioXML mailing list about an XML database, Guy Hulbert gave this reply: > Because this fills your database with blobs, so why use a database at all ? > You'd be better off, performance-wise, storing the XML docs in the file system > and just use the database to manage the file store (I worked as a sysadmin for > a product that did just this for scanned images). This causes me think about the operation of 'container loci'. Recall that they can contain other loci and act as a database. Well, I'm not a database expert, but I think we want a system that will manage loci as files on the filesystem. This is why: Loci will not be of any particular data format (as I've tried to stress recently). This will avoid any substantial 'import and translation' function that will require the Loci system to (1) spend time and space on large datasets and (2) lock Loci into a one-of-a-kind data format. But it will also give us a neat way of 'opening' loci: The 'container loci' can merely be set to read from/write to a certain directory on the filesystem, and the directories will serve to separate locus categories. So, for example, the user can put all GenBank docs for Dictyostelium under the directory ~/loci/containers/Dictyostelium/ and then set one container locus to point to that directory. So, the container locus will be a number of programs in one: (1) Standard locus (2) Database (3) File manager And will serve as 'dead storage' for loci. But if we really want to solve the '2 terabyte document problem' (for genome analyses, as an example) that Jim Freeman brought up to me a few weeks ago, we can't duplicate everything that goes from dead storage to active use. Therefore, loci (treated as files) will have to either remain in place or be moved to another directory, and NOT duplicated. I'd like to get some feedback about this from you guys. Cheers. Jeff Gary Van Domselaar wrote: > > Hey kids, > > I found this while looking for a GPL XML database manager: > > Tools for parsing XML with Python: > > http://www.stud.ifi.uio.no/~lmariusg/download/python/xml/index.html > > It may be worth a look. Still no sign of a GPL XML database manager... > > Regards, > > --gary -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Mon Sep 27 08:47:08 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] Tools for parsing XML with Python Message-ID: <40DEF2EE1151D311BC520050047B4145018B98@195-66-34-2.itv.se> > When I wrote to the BioXML mailing list about an XML database, Guy Hulbert gave > this reply: > > > Because this fills your database with blobs, so why use a database at all ? > > You'd be better off, performance-wise, storing the XML docs in the file system > > and just use the database to manage the file store (I worked as a sysadmin for > > a product that did just this for scanned images). This confuses me a bit. Are you saying that you don't need a DB, or that you don't want to store the contents of the DB in a DB-specific manner? ( I believe that you wan't to be able to send queries to the DB such as " give me all interfaces/objects/applications that can preform this operation upon this kind of data "? Isn't that a DB? ) > This causes me think about the operation of 'container loci'. Recall that they > can contain other loci and act as a database. Well, I'm not a database expert, > but I think we want a system that will manage loci as files on the filesystem. > This is why: Loci will not be of any particular data format (as I've tried to > stress recently). This will avoid any substantial 'import and translation' > function that will require the Loci system to (1) spend time and space on large > datasets and (2) lock Loci into a one-of-a-kind data format. But it will also > give us a neat way of 'opening' loci: The 'container loci' can merely be set to > read from/write to a certain directory on the filesystem, and the directories > will serve to separate locus categories. So, for example, the user can put all > GenBank docs for Dictyostelium under the directory Hmm. There is a Gnome project called the Gnome-DB ( you didn't expect that name, did you? :) http://www.chez.com/rmoya/gnome-db/index.html and it has got a DB-engine that uses raw files. I have not examined it yet ( save that I have read their homepage ) so I don't know much about it, but it might be worth a look. > And will serve as 'dead storage' for loci. But if we really want to solve the > '2 terabyte document problem' (for genome analyses, as an example) that Jim > Freeman brought up to me a few weeks ago, we can't duplicate everything that > goes from dead storage to active use. Therefore, loci (treated as files) will > have to either remain in place or be moved to another directory, and NOT > duplicated. > > I'd like to get some feedback about this from you guys. If you pass around CORBA objects, that "represents" the actual file, you will not need to duplicate the file. ( GNOME::Stream is a very good candidate! :) In either case, passing around a file "reference", instead of reading directly from the file, seems to be the obvious solution. // Liss ps. GNOME::Storage / GNOME::Stream, dwells inside the bonobo package, in case that you didn't find them. There are a lot of goodies in that package, that might be of interest to loci. From lisss at ydab.se Mon Sep 27 08:54:34 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] More: Loci and data storage Message-ID: <40DEF2EE1151D311BC520050047B4145018B99@195-66-34-2.itv.se> Some documentation about bonobo ( GNOME::Stream/ GNOME::Storage and more ) that arrieved recently. > If anyone is interested, there is a beta release of bonobo-doc > on http://www.stud.enst.fr/~lacage/linux/corba/book1.html > Comments are wellcome. // Liss From hortiz at neurobio.upr.clu.edu Mon Sep 27 11:24:18 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:52 2006 Subject: [Pipet Devel] A bsd licenced xml database Message-ID: <199909271524.LAA00805@chimbo.neurobio.upr.clu.edu> Saw this on freshmeat. http://www.dbxml.org/ -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From hortiz at neurobio.upr.clu.edu Mon Sep 27 11:42:49 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] More: Loci and data storage In-Reply-To: Your message of "Mon, 27 Sep 1999 14:54:34 +0200." <40DEF2EE1151D311BC520050047B4145018B99@195-66-34-2.itv.se> Message-ID: <199909271542.LAA00850@chimbo.neurobio.upr.clu.edu> > Some documentation about bonobo ( GNOME::Stream/ GNOME::Storage and more ) > that arrieved recently. > > > If anyone is interested, there is a beta release of bonobo-doc > > on http://www.stud.enst.fr/~lacage/linux/corba/book1.html > > Comments are wellcome. Bonobo is definitely something we need. It is gnome's model for embedding components into documents. Right now it is used to embed guppi plots into gnumeric spreadsheets. It specifically provides for the kind of user interaction we want to have in loci: click on a plot in gnumeric and alter the x axis. It does this using CORBA as the base model. The documentation looks very promising, and since this will be a standard part of gnome, it's something we can really leverage. Unfortunately I can't get it to build on my machine! I've spent the better part of two weeks trying to get bonobo, guppi and goose, and gnumeric built to test it. It doesn't work on redhat 5.2 with updated gnome rpms, or the stock 6.0. I think the new rpms on ftp.gurulabs.com will be better, but haven't had a chance to test them yet. You still need to compile bonobo, goose, guppi and gnumeric from cvs to get the bonobo support. I'll post a summary when I get this working. If someone already has this set up, please post a recipe for us to follow. -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From hortiz at neurobio.upr.clu.edu Mon Sep 27 12:29:57 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python In-Reply-To: Your message of "Mon, 27 Sep 1999 12:08:58 GMT." <37EF5E5A.196F2206@bc.edu> Message-ID: <199909271629.MAA00941@chimbo.neurobio.upr.clu.edu> > When I wrote to the BioXML mailing list about an XML database, Guy Hulbert gave > this reply: > > > Because this fills your database with blobs, so why use a database at all ? > > You'd be better off, performance-wise, storing the XML docs in the file system > > and just use the database to manage the file store (I worked as a sysadmin for > > a product that did just this for scanned images). No, an xml databse is to avoid filling a database with blobs. It instead uses the xml tags to set up the fields for a database automagically. We also want the database to be able to efficiently answer queries like "show me all the transmembrane domains of the following proteins". > but I think we want a system that will manage loci as files on the filesystem. > This is why: Loci will not be of any particular data format (as I've tried to > stress recently). This will avoid any substantial 'import and translation' > function that will require the Loci system to (1) spend time and space on large > datasets and (2) lock Loci into a one-of-a-kind data format. But it will also > give us a neat way of 'opening' loci: The 'container loci' can merely be set to > read from/write to a certain directory on the filesystem, and the directories > will serve to separate locus categories. So, for example, the user can put all > GenBank docs for Dictyostelium under the directory > > ~/loci/containers/Dictyostelium/ > > and then set one container locus to point to that directory. We'll need a number of features, including a container for files. This kind of container is the simplest to set up, and requires the least amount of effort on the biologists part to understand. We'll also want containers that can parse fasta format files, genbank files etc. Another simple container is a list of links, where a xml file contains a list of references to other loci. > And will serve as 'dead storage' for loci. But if we really want to solve the > '2 terabyte document problem' (for genome analyses, as an example) that Jim > Freeman brought up to me a few weeks ago, we can't duplicate everything that > goes from dead storage to active use. Therefore, loci (treated as files) will > have to either remain in place or be moved to another directory, and NOT > duplicated. This is a separate issue: loci needs a way to reference objects without copying them. So if I have a file with the genbank entry for X5559999 already on my hard drive, I can include this in an analysis by refering to (say) file:~/loci/containers/genbank/x5559999. This scheme should be able to handle live network queries as well (with a URI like genbank:x5559999?). In the best possible world, asking for x5559999 should retreive it from genbank the first time, then cache it and transparently refer to the local copy for every subsequent reference until it expires from the loci cache. This is where we really need a database, to keep track of the source and current location of any locus. The database may also serve as primary storage for localy defined loci, where loci is used here in it's most general form, refering to sequence data, results, programs, user interfaces, etc. A third kind of "file" we need to deal with is a compund document, say a figbuilder page with a multiple sequence alignment and a 3D structure. If we wanted to send this figure to a colaborator we could send it as a database containing the figure elements, as a gzip'ed tar file with the individual xml files, or as a single xml file containing all the required data and layout. In any case, while we build this figure, the pieces may come from different sources: several genbank sequences cached in the DM, two ascii files with sequence info in a "container directory", the standard loci for sequence alignment editor and PDB structure viewer, etc. Then clicking on the "export for collaborator" button would build a file we can mail or publish by bringing together all the data, or perhaps just the data that's local leaving the exported file with references to the standard items (genbank ID's, standard loci, PDB entrys). What's a bonobo compound document (i.e., a guppi figure in a gnumeric spreadsheet) look like anyway? Does anyone know? -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From bizzaro at bc.edu Mon Sep 27 13:12:45 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python References: <40DEF2EE1151D311BC520050047B4145018B98@195-66-34-2.itv.se> Message-ID: <37EFA58D.A0B80AFD@bc.edu> Svanberg Liss wrote: > > This confuses me a bit. Are you saying that you don't need a DB, or that you > don't want to store the contents of the DB in a DB-specific manner? We need a DB. I'm just saying that the elements stored in the DB are really separate files on a filesystem. So, the DB would behave something like a file manager or even a file system. > ( I believe that you wan't to be able to send queries to the DB such as " > give me all interfaces/objects/applications that can preform this operation > upon this kind of data "? > Isn't that a DB? ) Yes. We want to be able to do that. But I think our database should allow for a query mechanism to be plugged in as a separate locus. I alluded to this a little earlier. Here is how a query would be set up: DATABASE LOCUS -----> QUERY LOCUS -----> DATA LOCUS > Hmm. > There is a Gnome project called the Gnome-DB ( you didn't expect that name, > did you? :) > http://www.chez.com/rmoya/gnome-db/index.html > > and it has got a DB-engine that uses raw files. I have not examined it yet ( > save that I have read their homepage ) so I don't know much about it, but it > might be worth a look. That should be worth looking into. > If you pass around CORBA objects, that "represents" the actual file, you > will not need to duplicate the file. > ( GNOME::Stream is a very good candidate! :) EXACTLY! > In either case, passing around a file "reference", instead of reading > directly from the file, seems to be the obvious solution. YES! :-) Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 27 13:18:33 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] A bsd licenced xml database References: <199909271524.LAA00805@chimbo.neurobio.upr.clu.edu> Message-ID: <37EFA6E9.CB2EF67B@bc.edu> Humberto Ortiz Zuazaga wrote: > > Saw this on freshmeat. > > http://www.dbxml.org/ Thanks. This was posted before, BTW ;-) A BSD-licensed program would be compatible with the LGPL, so dbXML is probably our only viable option at this time...unless we make our own DB, if it would be simple enough and if Loci would need something very unique. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Mon Sep 27 13:06:29 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python Message-ID: <40DEF2EE1151D311BC520050047B4145018BA6@195-66-34-2.itv.se> > What's a bonobo compound document (i.e., a guppi figure in a gnumeric > spreadsheet) look like anyway? Does anyone know? A compund document is usually a GNOME::Storage where each compund part is a GNOME::Stream and can be found inside the storage. What a GNOME::Storage really are when it's stored on disk ( if it's even possible to store it on disk ) is application dependent. I should guess that it typically will be a directory. To store a compund document requires that each component has declared an interface that is called GNOME::Persist. These interfaces contains methods that are able to store a component's data in a GNOME::Storage ( among other things ). So, when you wan't to store a compund document, you typically create ( or finds ) a GNOME::Storage, and then you tell the different components of the document to store themselves into your storage. Since there exists GNOME::Persist interfaces that are designed to store data directly on disk, or into a stream, things might be different in reality. A compund document *may* as an example be a number of files shattered around the net, or it might be one single (probably binary) file. // Liss From bizzaro at bc.edu Mon Sep 27 13:21:15 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] More: Loci and data storage References: <199909271542.LAA00850@chimbo.neurobio.upr.clu.edu> Message-ID: <37EFA78B.C9A2E9AE@bc.edu> Humberto Ortiz Zuazaga wrote: > > Bonobo is definitely something we need. It is gnome's model for embedding > components into documents. Right now it is used to embed guppi plots into > gnumeric spreadsheets. > > It specifically provides for the kind of user interaction we want to have in > loci: click on a plot in gnumeric and alter the x axis. It does this using > CORBA as the base model. > > The documentation looks very promising, and since this will be a standard part > of gnome, it's something we can really leverage. I agree. > Unfortunately I can't get it to build on my machine! I've spent the better > part of two weeks trying to get bonobo, guppi and goose, and gnumeric built to > test it. It doesn't work on redhat 5.2 with updated gnome rpms, or the stock > 6.0. Wow, that is strange. > I think the new rpms on ftp.gurulabs.com will be better, but haven't had a > chance to test them yet. You still need to compile bonobo, goose, guppi and > gnumeric from cvs to get the bonobo support. There's a big push now to come out with Gnome 1.0.50 (1.0.40 is a beta release), and I think they'll have RPMs for just about everything. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 27 13:42:27 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python References: <199909271629.MAA00941@chimbo.neurobio.upr.clu.edu> Message-ID: <37EFAC83.A24E7FA8@bc.edu> Humberto Ortiz Zuazaga wrote: > > No, an xml databse is to avoid filling a database with blobs. It instead uses > the xml tags to set up the fields for a database automagically. We also want > the database to be able to efficiently answer queries like "show me all the > transmembrane domains of the following proteins". Again, I think we need a database that can facilitate queries of just about any kind. So, for example: DATABASE LOCUS -----> "Show me all the transmembrane -----> DATA LOCUS domains of the proteins in the DB." > We'll need a number of features, including a container for files. This kind of > container is the simplest to set up, and requires the least amount of effort > on the biologists part to understand. Yep. > We'll also want containers that can > parse fasta format files, genbank files etc. This would depend on the query mechanism (locus) used. But the DB should be generic enough to handle just about anything. > Another simple container is a > list of links, where a xml file contains a list of references to other loci. This may just be a matter of implementation: The DB is a list of links to files on the file system? > This is a separate issue: loci needs a way to reference objects without > copying them. So if I have a file with the genbank entry for X5559999 already > on my hard drive, I can include this in an analysis by refering to (say) > file:~/loci/containers/genbank/x5559999. This scheme should be able to handle > live network queries as well (with a URI like genbank:x5559999?). Yes, this would be the case for both data (e.g., protein structure) and processor (e.g., find lowest energy conformation of protein via molecular dynamics). > In the best possible world, asking for x5559999 should retreive it from > genbank the first time, then cache it and transparently refer to the local > copy for every subsequent reference until it expires from the loci cache. This > is where we really need a database, to keep track of the source and current > location of any locus. The database may also serve as primary storage for > localy defined loci, where loci is used here in it's most general form, > refering to sequence data, results, programs, user interfaces, etc. I couldn't have said it better myself. We want _minimal_ transfer of information. > A third kind of "file" we need to deal with is a compund document, say a > figbuilder page with a multiple sequence alignment and a 3D structure. If we > wanted to send this figure to a colaborator we could send it as a database > containing the figure elements, as a gzip'ed tar file with the individual xml > files, or as a single xml file containing all the required data and layout. This is something that will take a lot of thought. I called this compound document a 'composite locus', meaning you can turn a an entire section of a Workflow Diagram (containing loci) into a single locus. But when that composite locus is sent to someone else, do we send just the links or the actual data/processor? If we send just the links and one locus resides (links to actual data/processor) on the sender's computer, that data/processor has to be accessible to the recipient via link, otherwise the data/processor has to be sent in its entirety. But this is what you wrote below. > In any case, while we build this figure, the pieces may come from different > sources: several genbank sequences cached in the DM, two ascii files with > sequence info in a "container directory", the standard loci for sequence > alignment editor and PDB structure viewer, etc. Then clicking on the "export > for collaborator" button would build a file we can mail or publish by bringing > together all the data, or perhaps just the data that's local leaving the > exported file with references to the standard items (genbank ID's, standard > loci, PDB entrys). Ditto. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 27 13:52:22 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python References: <40DEF2EE1151D311BC520050047B4145018BA6@195-66-34-2.itv.se> Message-ID: <37EFAED6.6FD78521@bc.edu> Hmmm. So this is all Bonobo? Does Gnome-DB make use of Bonobo? *sigh* you can see why we're using Gnome as the foundation for Loci :-) Jeff Svanberg Liss wrote: > > > What's a bonobo compound document (i.e., a guppi figure in a gnumeric > > spreadsheet) look like anyway? Does anyone know? > > A compund document is usually a GNOME::Storage where each compund part is a > GNOME::Stream and can be found inside the storage. > What a GNOME::Storage really are when it's stored on disk ( if it's even > possible to store it on disk ) is application dependent. I should guess that > it typically will be a directory. > > To store a compund document requires that each component has declared an > interface that is called GNOME::Persist. > These interfaces contains methods that are able to store a component's data > in a GNOME::Storage ( among other things ). > So, when you wan't to store a compund document, you typically create ( or > finds ) a GNOME::Storage, and then you tell the different components of the > document to store themselves into your storage. > > Since there exists GNOME::Persist interfaces that are designed to > store data directly on disk, or into a stream, things might be different in > reality. A compund document *may* as an example be a number of files > shattered around the net, or it might be one single (probably binary) file. > > // Liss > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Mon Sep 27 14:16:20 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python Message-ID: <40DEF2EE1151D311BC520050047B4145018BA7@195-66-34-2.itv.se> > > In the best possible world, asking for x5559999 should retreive it from > > genbank the first time, then cache it and transparently refer to the local > > copy for every subsequent reference until it expires from the loci cache. This > > is where we really need a database, to keep track of the source and current > > location of any locus. The database may also serve as primary storage for > > localy defined loci, where loci is used here in it's most general form, > > refering to sequence data, results, programs, user interfaces, etc. > > I couldn't have said it better myself. We want _minimal_ transfer of > information. Sounds like you want "virtual distributed memory" instead of CORBA ;) // Liss From lisss at ydab.se Mon Sep 27 14:16:44 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] SV: [Pipet Devel] Tools for parsing XML with Python Message-ID: <40DEF2EE1151D311BC520050047B4145018BA8@195-66-34-2.itv.se> > Hmmm. So this is all Bonobo? Does Gnome-DB make use of Bonobo? *sigh* you can > see why we're using Gnome as the foundation for Loci :-) Well, they says so... But since I havn't looked at the code yet ( I cannot download it from them ) I cannot know if they *should use when they are ready* or *are using* bonobo... ;) Actually, bonobo is a bit more than just compund documents. If loci would be based upon bonobo, I think a working release would require only a way to store persistant *connections* between CORBA objects. ( Preferably with a GUI :) Later on we could add support to dynamically create connections between CORBA objects. ( So you would store "object A should be connected to an object that can do B" instead of "object A should be connected to object B" ) This might sound little, but I think it will require enough work, and it would *really* improve any operating system. ( And then, we could of course add new features not found in bonobo :) Bonobo allows you to do a lot of "magic" with various objects, but it allso requires you to write programs that uses the objects. Loci could give the end-user the possibility to use these objects directly, and this soley is more than it sounds like. // Liss From hortiz at neurobio.upr.clu.edu Mon Sep 27 15:07:25 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] SV: [Pipet Devel] Tools for parsing XML with Python In-Reply-To: Your message of "Mon, 27 Sep 1999 20:16:44 +0200." <40DEF2EE1151D311BC520050047B4145018BA8@195-66-34-2.itv.se> Message-ID: <199909271907.PAA01426@chimbo.neurobio.upr.clu.edu> > Later on we could add support to dynamically create connections between > CORBA objects. > ( So you would store "object A should be connected to an object that can do > B" instead of "object A should be connected to object B" ) This is exactly how I want loci to work. Generic connections are not currently implemented in bonobo, but seem to be part of the gnome framework. This is quoted from the GNOME components white paper: http://developer.gnome.org/doc/whitepapers/Components/gnome-corba.html "In addition to exporting the API, GNOME is generating a list of standard interfaces that other applications can be written to. For example, the interface Desktop::Editor defines an interface to an editor. This means that an application (such as a Mail client or an IDE program) that is developed using these interfaces can decouple itself from a specific implemenation of the interface. The user can select its favorite implementation of the Desktop::Editor interface, and this tool will integrate with the rest of the system." > Bonobo allows you to do a lot of "magic" with various objects, but it allso > requires you to write programs that uses the objects. Loci could give the > end-user the possibility to use these objects directly, and this soley is > more than it sounds like. I like the way you think. Let's extend bonobo, and make loci into a scriptable GUI for manipulating components visually, then we can implement bioinformatics tools as a specific instance. Visual Python anyone? I just hope bonobo and the gnome component model stabilize soon. All this stuff is too damn complicated still. -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From hortiz at neurobio.upr.clu.edu Mon Sep 27 15:16:10 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Tools for parsing XML with Python In-Reply-To: Your message of "Mon, 27 Sep 1999 19:06:29 +0200." <40DEF2EE1151D311BC520050047B4145018BA6@195-66-34-2.itv.se> Message-ID: <199909271916.PAA01487@chimbo.neurobio.upr.clu.edu> > > What's a bonobo compound document (i.e., a guppi figure in a gnumeric > > spreadsheet) look like anyway? Does anyone know? Found bonobo documentation on the subject at: http://www.stud.enst.fr/%7elacage/linux/corba/bonobo-storage-streams-and-stores .html Now to track down libefs. -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From bizzaro at bc.edu Mon Sep 27 15:33:15 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] SV: [Pipet Devel] Tools for parsing XML with Python References: <199909271907.PAA01426@chimbo.neurobio.upr.clu.edu> Message-ID: <37EFC67B.2D328184@bc.edu> Humberto Ortiz Zuazaga wrote: > > ...make loci into a scriptable > GUI for manipulating components visually, then we can implement bioinformatics > tools as a specific instance. Yes! Loci: Visual Project Management for Distributed Data Processing Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Sep 27 15:45:32 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] SV: [Pipet Devel] Tools for parsing XML with Python References: <40DEF2EE1151D311BC520050047B4145018BA8@195-66-34-2.itv.se> Message-ID: <37EFC95C.553A9649@bc.edu> Svanberg Liss wrote: > > Actually, bonobo is a bit more than just compund documents. > If loci would be based upon bonobo, I think a working release would require > only a way to store persistant *connections* between CORBA objects. > ( Preferably with a GUI :) Right. I'm working on the GUI, but you guys will have to help with the CORBA and Bonobo stuff. > Later on we could add support to dynamically create connections between > CORBA objects. > ( So you would store "object A should be connected to an object that can do > B" instead of "object A should be connected to object B" ) David, Gary and I spoke a bit about making the GUI connections between loci. Loci should be able to tell the user what can be connected to what. For example, you wouldn't feed a PDB file (directly) to a DNA seq aligner. So, objects or object types should have very specific IDs, and a locus should be able to say, 'I need input from locus type XXXXXXXXX'. If you try to connect locus type YYYYYYYYY as input, you'll get an error message. Does Bonobo/CORBA give us just that or will we have to define IDs for every locus or locus type? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Mon Sep 27 15:46:25 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] SV: [Pipet Devel] SV: [Pipet Devel] Tools for parsing XML with Python Message-ID: <40DEF2EE1151D311BC520050047B4145018BA9@195-66-34-2.itv.se> > David, Gary and I spoke a bit about making the GUI connections between loci. > Loci should be able to tell the user what can be connected to what. For > example, you wouldn't feed a PDB file (directly) to a DNA seq aligner. So, > objects or object types should have very specific IDs, and a locus should be > able to say, 'I need input from locus type XXXXXXXXX'. If you try to connect > locus type YYYYYYYYY as input, you'll get an error message. Does Bonobo/CORBA > give us just that or will we have to define IDs for every locus or locus type? Mmm, yes to some extent. Gnome ( or bonobo ) is based upon an interface called GNOME::Unknown. An unknown can be refcounted, shut down :), or queried. The interesting part is the query, ( and the concept is shamelessy stolen from Microsoft of all places ;) You *don't* query an unknown about what it is. Instead, you query it for functionality. Say that someone sends you an unknown. You has been sent it as a container, so you suspect that it is a storage. If you want to use it as a storage, then you query it about "are you a storage?" and, if it is, it will return a GNOME::Storage ( that is just a different reference to the same object ) The queries is of the kind object.query_interface("IDL:GNOME/Storage:1.0"), that is, the ID's are strings and not numbers - slower, but more flexible. However, GNOME::Storage completely lacks a method to enumerate what kind of functionality it supports. By the way. All GNOME:: objects inherite from GNOME::Unknonwn. // Liss From bizzaro at bc.edu Wed Sep 29 05:27:14 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Bonobo 0.4 release Message-ID: <37F1DB72.5922BFB1@bc.edu> This comes from the Gnome Web site: -------------- The Bonobo component and compound document system has been released. This is a library for developers interested in writing reusable components and small components that can be used to create complex documents. Hello guys, I have just released the first public version of Bonobo (bonobo-0.4), the GNOME component system and compound document system. Bonobo has been on development for about ten months and it is almost ready. This release is still an alpha version of the code, but it will enable people to try out Bonobo and some of the GNOME applications that depend on Bonobo (the PDF file viewer, the Gnumeric Bonobo extensions, the new file manager and a few other toys). Keep in mind that the API *will* change, I will try to keep the API changes well documented though. Availability ftp://ftp.gnome.org/pub/GNOME/sources/bonobo/bonobo-0.4.tar.gz What does Bonobo 0.4 provide The GNOME component foundation based on the GNOME::Unknown CORBA interface. Component can be graphical and non-graphical. The Bonobo framework for building new components using the Gtk object system. Structured Storage interfaces for loading/saving compound documents. The interfaces for visual component embedding, both simple rectangle-based embeddings (GtkWidget embedding) as well as arbitrarly-shaped components. Still left to do We could use the help of various people to help improve various things in Bonobo: API documentation layout should be improved as well as adding introductory pieces to various Bonobo pieces. A web page tracking down the development and carrying out information about Bonobo as well as a software map for Bonobo-based components. Upcoming Changes I am expecting to provide control support for the next Bonobo version (ie, creating components that have a single view) as well as providing a way to load/save their state using properties (you can see the interface in idl/gnome-control.idl). The Shaped components and the Views might have an API change to make them more sensible, it is sort of hacked right now. Bounding box support for the arbitrarly shaped components as well as activation/deactivation for those. The Bonobo Team The Bonobo core team is: Dietmar Maurer (libefs hacker) Elliot Lee (CORBA guardian angel). Ettore Perazzoli (Bonobo hacking device #2). Federico Mena (Bonobo helper). Matt Loper (Persistent hacker). Michael Meeks (Bonobo and component hacker) Miguel de Icaza (main designer/implementor) Nat Friedman (Bonobo hacking device) Bonobo components/GUI is: Chris Lahey (Audio/ulaw). Richard Hestilow (Bonobo dialog hacker) Bonobo maintainers: Miguel de Icaza (miguel@kernel.org) Nat Friedman (nat@nat.or) Mailing lists gnome-components-list@gnome.org To subscribe, send mail to gnome-components-list-request@gnome.org and in the body of the message put the word "subscribe". Archive of the mailing list is available at http://www.gnome.org/mailing-lists/archives/gnome-components-list/ Enjoy! Miguel. -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From lisss at ydab.se Wed Sep 29 09:21:49 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] RE: ref counting in Bonobo Message-ID: <40DEF2EE1151D311BC520050047B4145018C44@195-66-34-2.itv.se> > I was wondering about the implications of the ref counting routines in the > Unknown interface. If I have a remote client that's holding a reference > to an object in a server, and the client crashes, what happens? > > I've heard that Microsoft is trying to implement distributed garbage > collection in COM+ 2.0. And I mean full mark-and-sweep type garbage > collection. It's hard to imagine making that work. > > Do Bonobo client programs explicitly call ref and unref on server objects, > or is this all handled transparently by Gnome? There is nothing wrong with refcounting, as long as you can exiplictly kill an object. This is a problem with COM. If a client crashes, you cannot relese the object, because only the one that refcounted the object may release it. ( This is at least what I've been told :) I don't see why this should be a problem in bonobo. ( Of course I can see why, I mean that it's possible to solve the problem without so much effort! :) The refcounts are not bound to a specific client in bonobo, so it should be possible to write something that pings various clients to see if they are alive, and if not releases the object they have been bound to. Or one that allows the sysadmin to release objects. In the case of containers/containees this would not even require any strange extra applications, because both container and containee has got callbacks that the remote application should call when something happens. If the "client" on the other side has died, CORBA will throw a system exeption. The "server" catches the exeption, realizes that something is funny about the "client", it then releases itself ( and thereby decoupling itself from the "client" ). The only real problem appears to be the interfaces ( GNOME::Storage / GNOME::Stream ) that has no callbacks. On the other side, none of those objects are supposed to stay alieve for a prolonged time, are they? // Liss From miguel at gnu.org Wed Sep 29 14:25:26 1999 From: miguel at gnu.org (Miguel de Icaza) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] Re: ref counting in Bonobo In-Reply-To: <40DEF2EE1151D311BC520050047B4145018C44@195-66-34-2.itv.se> (message from Svanberg Liss on Wed, 29 Sep 1999 15:21:49 +0200) References: <40DEF2EE1151D311BC520050047B4145018C44@195-66-34-2.itv.se> Message-ID: <199909291825.NAA28451@erandi.nuclecu.unam.mx> > The only real problem appears to be the interfaces ( GNOME::Storage / > GNOME::Stream ) that has no callbacks. On the other side, none of those > objects are supposed to stay alieve for a prolonged time, are they? They are refcounted as well.