From lauris at ariman.ee Mon May 15 07:19:50 2000 From: lauris at ariman.ee (Lauris Kaplinski) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci In-Reply-To: <3882CA4E.8D13A122@geoserve.net> Message-ID: Hello, Just some months ago we were talking about sodipodi and SVG "widgets" in Loci. While sodipodi tends to be rather "heavyweight" drawing program, I found that there is "lightweight" SVG display routine in Nautilus, developed by Raph Levien, which is used to display SVG icons. So maybe you are interested in cooperating with Nautilus people. Also you may want to keep eye on DIA, which has customized SVG format for its objects, suitable for drawing "connections" - the thing you were interested. Best wishes and nice Loci Lauris Kaplinski From jarl at casema.net Mon May 15 06:48:35 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: Message-ID: <391FD603.7F5ACCB4@casema.net> > So maybe you are interested in cooperating with Nautilus people. Hooking Piper into Nautilus sounds pretty good! From bizzaro at geoserve.net Mon May 15 17:31:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: Message-ID: <39206C9A.9C0F2AF5@geoserve.net> Lauris Kaplinski wrote: > > Just some months ago we were talking about sodipodi and SVG "widgets" in > Loci. Hi Lauris. I remember :-) > While sodipodi tends to be rather "heavyweight" drawing program, I > found that there is "lightweight" SVG display routine in Nautilus, > developed by Raph Levien, which is used to display SVG icons. So maybe you > are interested in cooperating with Nautilus people. I saw Miguel demonstrate a Bonobo SVG object when he gave a talk in Boston a few months ago, but I don't know exactly what he used. We'll take a look at the Nautilus SVG routine. Loci/Piper can have multiple user interfaces in multiple languages, but we may be able to use the SVG routine (I suppose in C) for any number of our interfaces. > Also you may want to keep eye on DIA, which has customized SVG format for > its objects, suitable for drawing "connections" - the thing you were > interested. Yes, we considered Dia early on in the project. The user interface I'm writing now handles connections a little more "quick and dirty" than Dia does, which may be all we need (i.e., we don't need to make pictures of the interface, only what is contained within it). > Best wishes and nice Loci Thank you! Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From lauris at ariman.ee Mon May 15 17:59:54 2000 From: lauris at ariman.ee (Lauris Kaplinski) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci In-Reply-To: <39206C9A.9C0F2AF5@geoserve.net> Message-ID: On Mon, 15 May 2000, J.W. Bizzaro wrote: > > While sodipodi tends to be rather "heavyweight" drawing program, I > > found that there is "lightweight" SVG display routine in Nautilus, > > developed by Raph Levien, which is used to display SVG icons. So maybe you > > are interested in cooperating with Nautilus people. > > I saw Miguel demonstrate a Bonobo SVG object when he gave a talk in Boston a > few months ago, but I don't know exactly what he used. It was probably Gill - a Raph Leviens pet project, out of which sodipodi evolved... Gill is actually quite ambitious - i.e. implemented as display engine listening to DOM tree. But unfortunately DOM is still changing target (even the standard), so Raph have some difficulties keeping pace... Regards, Lauris From jarl at casema.net Tue May 16 03:26:34 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: <39206C9A.9C0F2AF5@geoserve.net> Message-ID: <3920F82A.F2106B@casema.net> > I saw Miguel demonstrate a Bonobo SVG object when he gave a talk in Boston a > few months ago, but I don't know exactly what he used. SVG? > We'll take a look at the Nautilus SVG routine. Loci/Piper can have multiple > user interfaces in multiple languages, but we may be able to use the SVG > routine (I suppose in C) for any number of our interfaces. I aint really sure if what I'm about to say is obvious, but what if nautulus supports to embed a bonobo component, what if we were to do some coding to add support for this to the definition or brokering layer. I skip the user interface because of functionality re-use. Keeps coding new UI more easy. I've been browsing bonobo some time ago, and I think hooking this quite simple, but I do not know whether there's Python bindings for this, for bonobo and for the gtk_plug widgets. gtk_socket support would be nice, but isn't needed. Problem might be if bonobo requiers gtk to operate. > Yes, we considered Dia early on in the project. The user interface I'm > writing now handles connections a little more "quick and dirty" than Dia does, > which may be all we need (i.e., we don't need to make pictures of the > interface, only what is contained within it). Jeff: maybe you could explain the basic structure of the souces of the UI? I didn't dare reading Python sources yet :) From bizzaro at geoserve.net Mon May 15 18:50:01 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: <39206C9A.9C0F2AF5@geoserve.net> <3920F82A.F2106B@casema.net> Message-ID: <39207F19.17062FB8@geoserve.net> jarl van katwijk wrote: > > > I saw Miguel demonstrate a Bonobo SVG object when he gave a talk in Boston a > > few months ago, but I don't know exactly what he used. > > SVG? Scalable Vector Graphics (SVG) is an XML definition of vector (non-raster/bitmap) graphics. It was submitted to the W3C as a web standard but is being used elsewhere. My thoughts about the use of SVG in Piper are that vector graphics can be defined just like an ordinary GUI: both (will) use XML. Recall some earlier posts about an "XML representation of a GUI". > I aint really sure if what I'm about to say is obvious, but what if nautulus > supports to embed a bonobo component, what if we were to do some coding to add > support for this to the definition or brokering layer. I skip the user interface > because of functionality re-use. Keeps > coding new UI more easy. It'd be nice if we had a reusable Bonobo component for UI's (I think that is what you're saying). But, since Bonobo is entirely desktop-oriented (and Gnome-based), such support belongs in the UIL, IMHO. > I've been browsing bonobo some time ago, and I think hooking this quite simple, > but I do not know whether there's Python bindings for this, for bonobo and for > the gtk_plug widgets. gtk_socket support would be nice, but isn't needed. > Problem might be if bonobo requiers gtk to operate. >From what I gather, "Python-Bonobo" has been a difficult thing to produce, since the Bonobo definition is immature and keeps changing. But I definitely look forward to seeing such an animal :-) > Jeff: maybe you could explain the basic structure of the souces of the UI? > I didn't dare reading Python sources yet :) Directory structure or the core requirements to construct a UI? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue May 16 03:00:15 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: <39206C9A.9C0F2AF5@geoserve.net> <3920F82A.F2106B@casema.net> <39207F19.17062FB8@geoserve.net> Message-ID: <3920F1FE.1F7120DB@casema.net> > > It'd be nice if we had a reusable Bonobo component for UI's (I think that is > what you're saying). But, since Bonobo is entirely desktop-oriented (and > Gnome-based), such support belongs in the UIL, IMHO. OK, start learning corba Jeff :-) > > > Jeff: maybe you could explain the basic structure of the souces of the UI? > > I didn't dare reading Python sources yet :) > > Directory structure or the core requirements to construct a UI? both please. From bizzaro at geoserve.net Tue May 16 04:57:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] loci tarball and updated piper web page Message-ID: <39210D82.3C339D97@geoserve.net> Locians and Pipers, I placed a tarball of one of the later commits to CVS (May 10, by Brad) on the web server: http://bioinformatics.org/loci/download/snapshots/loci-latest.tar.gz This may be the last tarball to go by the name "Loci", as the code bases of Loci, GMS and Overflow will soon be merged (into "Piper"). I also made some minor changes to the Piper web page (bioinformatics.org/piper), including a link to Brad's documentation on the DL (Definitions Layer). Very nice job, Brad. You put me to shame, as usual :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 25 11:01:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] ISMB 2000 Message-ID: <392D405D.4EDDF11F@geoserve.net> I want to check again who will be going to ISMB 2000: http://ismb2000.sdsc.edu/ I haven't asked Deanne or David Lapointe yet, and Gary was going to get back to me about it. Brad, Jeff Chang, Harry, and Justin have said yes. Any others? It looks like I'll be going too. Brad and I are preparing a poster for ISMB and also BOSC: http://ismb2000.sdsc.edu/bosc2000/ Anyone going to BOSC as well? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat May 27 18:08:53 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Abstract on Piper/Loci for ISMB and BOSC Message-ID: Hello all! Jeff and I (at least) are planning on going to BOSC (http://ismb00.sdsc.edu/bosc2000/) and ISMB (http://ismb00.sdsc.edu/) and presenting a poster. Towards this end, we wrote up an abstract targetted at the use of Piper (was Loci) in bioinformatics research for these conferences. We were hoping we might be able to get some feedback from everyone about the abstract--any comments: good, bad or indifferent would be *extremely* appreciated. The deadline for the abstracts is in a few days (May 31st--of course we're doing this at the last minute)... Anyways, below is the abstract. Thanks in advance for your time. Brad Piper: A Distributed Platform for Linking Bioinformatics Programs J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad Chapman, Dominic Letourneau, Deanne Taylor A typical problem in bioinformatics research is linking together multiple programs to process information. A common example of this is in building phylogenetic trees from DNA sequences. The sequences are intially aligned using a sequence alignment program, are then analyzed in a phylogeny program to produce trees, and finally the trees are visualized in a viewer. This process can be further complicated by the fact that the programs may have incompatible inputs and outputs, as well as extensive memory and processing requirements. To address these problems the authors have developed Piper, a distributed platform to link bioinformatics programs. Piper is designed to provide a wrapper around exisiting bioinformatics programs so that they can be connected and executed in an intuitive manner. In addition, individual programs can be located on remote computers, so that expensive calculations can be executed on more robust equipment. Piper is designed as a modular system using CORBA connectivity as the backbone to link the modules. This design allows multiple user interfaces to control the core processing engine. In addition, Piper is being developed under an open-source model, allowing contribution and design feedback from individuals in multiple area of bioinformatics. Applications of Piper in comparative genomic mapping and phylogenetic analysis are discussed. From bizzaro at geoserve.net Sat May 27 19:30:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Abstract on Piper/Loci for ISMB and BOSC References: <200005260124.TAA12323@penguin.pharmacy.ualberta.ca> Message-ID: <39305A8A.CB913DC9@geoserve.net> Gary Van Domselaar wrote: > > My understanding was that Piper is data-independent. Loci is the > 'bioinformatics layer' that will run on top of Piper. So would > > "Piper & Loci" A Distributied Platform for Linking Bioinformatics > Programs" be more appropriate. We could then make the distinction between > loci and piper. BTW, I spoke to Gary about this when we met yesterday in Boston. I agree with Gary that Piper shouldn't be proposed as a bioinformatics-only system (some of the wording gives that impression). But I don't want to say "Piper/Loci" either (Loci will be the name of a model collaboratory based on Piper and not REALLY a software layer -- more on this later). So, I think we should word it to say Piper CAN distribute bioinformatics applications, rather than Piper IS SPECIFICALLY FOR distributing bioinformatics applications. How about this: "Distributing Bioinformatics Applications with Piper" ? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon May 29 09:47:08 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Take 2--Abstract on Piper/Loci for ISMB and BOSC Message-ID: Hello again; I got some very helpful comments on the abstract for Loci/Piper and made a few changes to it, so I thought I would resend it with the new info. Once again, if anyone has any comments, no matter how small, they would be much appreciated. Also, I need to get address info for everyone mentioned in the authors so I can get this together, so if you are listed please send me an e-mail off the list and drop me the info. Or, if Jeff has an idea how we can just all be referenced as coming from "The Open Lab" that would be even better. Now for your reading pleasure... Distributing Bioinformatics Application with Piper J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad Chapman, Dominic Letourneau, Deanne Taylor A typical problem in bioinformatics research is linking together multiple programs to analyze a set of information. A common example of this is in building phylogenetic trees from DNA sequences. The sequences are intially aligned using a sequence alignment program, are then analyzed in a phylogeny program to produce trees, and finally the trees are visualized in a viewer. This process can be further complicated by the fact that the programs may have incompatible inputs and outputs, as well as extensive memory and processing requirements. To address these problems the authors have developed Piper, a distributed platform that can be used to link bioinformatics programs. Piper is ideally suited to bionformatics analysis in that it can combine highly specific, modular, data repositories and data analysis functions together to provide sophisticated and efficient data processing networks. Piper is designed to provide a wrapper around exisiting bioinformatics programs so that they can be connected and executed in an intuitive manner. In addition, individual programs can be located on remote computers, so that expensive calculations can be executed on faster, dedicated systems. Piper is designed as a modular system using CORBA connectivity protocols as the backbone to link the modules. This design allows multiple user interfaces to control the core processing engine. In addition, Piper is being developed under the Open Source model, allowing contribution and design feedback from individuals in multiple area of bioinformatics. Piper is especially well suited to for automated high-throughput data analysis like protein fold identification, sequence condiditioning such as repeat/vector masking and data format conversion, and customization of batch scripting processes such as building phylogenetic trees from DNA sequences. From bizzaro at geoserve.net Mon May 29 10:23:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Re: Take 2--Abstract on Piper/Loci for ISMB and BOSC References: Message-ID: <39327D7F.D286C621@geoserve.net> Brad Chapman wrote: > > Hello again; > I got some very helpful comments on the abstract for Loci/Piper and > made a few changes to it, so I thought I would resend it with the new info. > Once again, if anyone has any comments, no matter how small, they would be > much appreciated. > Also, I need to get address info for everyone mentioned in the > authors so I can get this together, so if you are listed please send me an > e-mail off the list and drop me the info. Or, if Jeff has an idea how we > can just all be referenced as coming from "The Open Lab" that would be even > better. Especially being a poster, I think one address will do. You can put an asterisk next to my name and below write... * Corresponding author: Bioinformatics.org: The Open Lab c/o Department of Chemistry University of Massachusetts Lowell Lowell, MA 01854 jeff@bioinformatics.org > Now for your reading pleasure... I don't have any major changes, just some spelling corrections, etc. > Distributing Bioinformatics Application with Piper Applications > J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad > Chapman, Dominic Letourneau, Deanne Taylor Dominic Letourneau and Deanne Taylor > A typical problem in bioinformatics research is linking together > multiple programs to analyze a set of information. A common example of this > is in building phylogenetic trees from DNA sequences. The sequences are > intially aligned using a sequence alignment program, are then analyzed in a > phylogeny program to produce trees, and finally the trees are visualized in > a viewer. This process can be further complicated by the fact that the > programs may have incompatible inputs and outputs, as well as extensive > memory and processing requirements. To address these problems the authors > have developed Piper, a distributed platform that can be used to link > bioinformatics programs. Piper is ideally suited to bionformatics analysis analysis or analyses [?] > in that it can combine highly specific, modular, data repositories and data > analysis functions together to provide sophisticated and efficient data > processing networks. Piper is designed to provide a wrapper around > exisiting bioinformatics programs ...existing programs... [Piper is not designed FOR bioinformatics] or Piper provides a wrapper around existing bioinformatics programs... > so that they can be connected and > executed in an intuitive manner. In addition, individual programs can be > located on remote computers, so that expensive calculations can be executed ...on remote computers so that... [no comma] > on faster, dedicated systems. [Since we use "system" to describe Piper, should we use something else here?] ...on faster, even dedicated hardware. > Piper is designed as a modular system using > CORBA connectivity protocols as the backbone to link the modules. This > design allows multiple user interfaces ...allows multiple and different kinds of user interfaces... > to control the core processing > engine. In addition, Piper is being developed under the Open Source model, > allowing contribution and design feedback from individuals in multiple area areas > of bioinformatics. Piper is especially well suited to for automated > high-throughput ...well suited to automate high-throughput... or ...well suited for automating high-throughput... or ...well suited for automated, high-throughput... > data analysis like protein fold identification, sequence > condiditioning conditioning > such as repeat/vector masking and data format conversion, > and customization of batch scripting processes such as building > phylogenetic trees from DNA sequences. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Mon May 29 11:38:01 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] Re: Take 2--Abstract on Piper/Loci for ISMB and BOSC In-Reply-To: <39327D7F.D286C621@geoserve.net> Message-ID: > asterisk next to my name and below write... > > * Corresponding author: > Bioinformatics.org: The Open Lab > c/o Department of Chemistry > University of Massachusetts Lowell > Lowell, MA 01854 > jeff@bioinformatics.org You might also wish to include the relevant institution for various people in smaller letters with other symbols, since we're not at UMass. It's an academic point, but traditional even in posters. > > A typical problem in bioinformatics research is linking together > > multiple programs to analyze a set of information. A common example of this > > is in building phylogenetic trees from DNA sequences. The sequences are > > intially aligned using a sequence alignment program, are then analyzed in a > > phylogeny program to produce trees, and finally the trees are visualized in > > a viewer. This process can be further complicated by the fact that the > > programs may have incompatible inputs and outputs, as well as extensive > > memory and processing requirements. To address these problems the authors > > have developed Piper, a distributed platform that can be used to link > > bioinformatics programs. Piper is ideally suited to bionformatics analysis > > analysis or analyses [?] Actually, it isn't PIPER that is suited to "bioinformatics analysis" but that Piper is the analysis agent.... "Piper is ideally suited to broker bioinformatics analyses in that it can combine highly specific..." etc. From bizzaro at geoserve.net Mon May 29 18:00:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] Abstract on Piper/Loci for ISMB and BOSC Message-ID: <3932E893.1F0A6676@geoserve.net> Distributing Bioinformatics Applications with Piper J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad Chapman, Dominic Letourneau and Deanne Taylor ABSTRACT The service consists of a human interface component comprising starter utility object consisting of the utility server resulting in the database service consisting of a utility network connection whereas said utility server consisting of a remote host apparatus connected by desired database object consisting of a database computer consisting of the utility server consisting of a database functionality connected by desired remote host object resulting in said utility service resulting in starter database object comprising desired utility object connected by a utility client comprising starter database object providing access to starter human interface computer comprising desired database computer whereas a remote host component resulting in a remote host computer providing access to starter utility component providing access to the human interface server consisting of a remote host apparatus comprising said remote host server connected by the human interface server whereas the database server consisting of the remote host object providing access to a database functionality. ;-) (saw this on Slashdot) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From alan at neomorphic.com Wed May 31 12:47:09 2000 From: alan at neomorphic.com (Alan Williams) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] ISMB 2000 In-Reply-To: <392D405D.4EDDF11F@geoserve.net> Message-ID: I have been more of a lurker than contributor lately, but I will be at ISMB. Looking forward to meeting some of you. -Alan --------------------------------- Alan Williams Neomorphic, Inc. Alan@Neomorphic.com 510-981-8513 --------------------------------- On Thu, 25 May 2000, J.W. Bizzaro wrote: > Date: Thu, 25 May 2000 15:01:49 +0000 > From: J.W. Bizzaro > To: pipet-devel@bioinformatics.org, pipet-devel@bioinformatics.org > Subject: [Pipet Devel] ISMB 2000 > > I want to check again who will be going to ISMB 2000: > > http://ismb2000.sdsc.edu/ > > I haven't asked Deanne or David Lapointe yet, and Gary was going to get back > to me about it. Brad, Jeff Chang, Harry, and Justin have said yes. Any > others? It looks like I'll be going too. > > Brad and I are preparing a poster for ISMB and also BOSC: > > http://ismb2000.sdsc.edu/bosc2000/ > > Anyone going to BOSC as well? > > Cheers. > Jeff > -- > +----------------------------------+ > | J.W. Bizzaro | > | | > | http://bioinformatics.org/~jeff/ | > | | > | BIOINFORMATICS.ORG | > | The Open Lab | > | | > | http://bioinformatics.org/ | > +----------------------------------+ > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel > From deanne at density.biop.umich.edu Wed May 31 12:49:48 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] ISMB 2000 In-Reply-To: Message-ID: I won't be going, sadly. Wish I was. Money is always the issue. :P Deanne > > Date: Thu, 25 May 2000 15:01:49 +0000 > > From: J.W. Bizzaro > > To: pipet-devel@bioinformatics.org, pipet-devel@bioinformatics.org > > Subject: [Pipet Devel] ISMB 2000 > > > > I want to check again who will be going to ISMB 2000: > > > > http://ismb2000.sdsc.edu/ > > > > I haven't asked Deanne or David Lapointe yet, and Gary was going to get back > > to me about it. Brad, Jeff Chang, Harry, and Justin have said yes. Any > > others? It looks like I'll be going too. > > > > Brad and I are preparing a poster for ISMB and also BOSC: > > > > http://ismb2000.sdsc.edu/bosc2000/ > > > > Anyone going to BOSC as well? > > > > Cheers. > > Jeff > > -- > > +----------------------------------+ > > | J.W. Bizzaro | > > | | > > | http://bioinformatics.org/~jeff/ | > > | | > > | BIOINFORMATICS.ORG | > > | The Open Lab | > > | | > > | http://bioinformatics.org/ | > > +----------------------------------+ > > > > _______________________________________________ > > pipet-devel maillist - pipet-devel@bioinformatics.org > > http://bioinformatics.org/mailman/listinfo/pipet-devel > > > > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel > From bizzaro at geoserve.net Mon May 1 13:14:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] GPL and linking Message-ID: <390DBB6F.7F71894E@geoserve.net> Below is a conversation between Richard Stallman and Bruce Perens about the GPL and 'linking'. I think it addresses some of the questions we had, so I highly recommend reading it. Jeff --------------- Q: (from Bruce Perens) - I'm concerned that GPL restrictions on derived works haven't kept up with software technology. RMS: I am working on GPL version 3, but this is not something that should be rushed. I put it aside for most of a year to work on the GNU Free Documentation License, but now I plan to get back to it. Bruce: The most pernicious example is CORBA, which lets us create derived works from components that aren't in the same address space at all, yet work seamlessly as if they were. I'd rather not see my GPL work end up in somebody's proprietary program, simply because it's been server-ized to avoid my license restrictions. RMS: If people can write non-free software that makes use of free CORBA components, that is bad in one way: it means that their non-free software can build on our work. But using our free software through CORBA does not make our programs themselves non-free. So it is not as bad as extending our programs with their non-free code. I think it will be hard to claim that a program is covered by our licenses because it uses CORBA to communicate with our code. Perhaps in cases of particularly intimate coupling we could convince a court of that view, but in general I think we could not. Bruce: A more common problem is dynamic libraries that are distributed separately from the executable. You say that a court would hold those to be devices explicitly used to circumvent the license restrictions, but that's rather chancy, and no substitute for explicit language regarding what is, and what isn't, considered a derived work in the GPL. RMS: We have no say in what is considered a derivative work. That is a matter of copyright law, decided by courts. When copyright law holds that a certain thing is not a derivative of our work, then our license for that work does not apply to it. Whatever our licenses say, they are operative only for works that are derivative of our code. A license can say that we will treat a certain kind of work as if it were not derivative, even if the courts think it is. The Lesser GPL does this in certain cases, in effect declining to use some of the power that the courts would give us. But we cannot tell the courts to treat a certain kind of work as if it were derivative, if the courts think it is not. I think we have a pretty good argument that nontrivial dynamic linking creates a combined (i.e. derivative) work. I have an idea for how to change the GPL to make it clearer and more certain, but I need to see if we can work out the details in a way that our lawyer believes will really work. Bruce: There's also the problem of Application Service Providers, who make a work available for people to use without distributing it, and thus would be under no obligation to make the source code of their modifications available. Do I have to see my GPL work abused that way as well? RMS: I too feel these servers are not playing fair with our community, but this problem is very hard to solve. It is hard for a copyright-based license to make a requirement for these servers that will really stick. The difficulty is that they servers are not distributing the program, just running it. So it is hard to make any conditions under copyright that affect what they can do. I had an idea recently for an indirect method that might perhaps work. I'd rather not talk about it until our lawyer figures out better whether it can really do the job. ------------------ http://slashdot.org/article.pl?sid=00/05/01/1052216&mode=nocomment -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon May 1 13:22:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] GPL and linking References: <390DBB6F.7F71894E@geoserve.net> Message-ID: <390DBD5A.64AECED7@geoserve.net> *sigh* I just knew the formatting would be screwy. This should be easier to read: ------------- Q: (from Bruce Perens) - I'm concerned that GPL restrictions on derived works haven't kept up with software technology. RMS: I am working on GPL version 3, but this is not something that should be rushed. I put it aside for most of a year to work on the GNU Free Documentation License, but now I plan to get back to it. Bruce: The most pernicious example is CORBA, which lets us create derived works from components that aren't in the same address space at all, yet work seamlessly as if they were. I'd rather not see my GPL work end up in somebody's proprietary program, simply because it's been server-ized to avoid my license restrictions. RMS: If people can write non-free software that makes use of free CORBA components, that is bad in one way: it means that their non-free software can build on our work. But using our free software through CORBA does not make our programs themselves non-free. So it is not as bad as extending our programs with their non-free code. I think it will be hard to claim that a program is covered by our licenses because it uses CORBA to communicate with our code. Perhaps in cases of particularly intimate coupling we could convince a court of that view, but in general I think we could not. Bruce: A more common problem is dynamic libraries that are distributed separately from the executable. You say that a court would hold those to be devices explicitly used to circumvent the license restrictions, but that's rather chancy, and no substitute for explicit language regarding what is, and what isn't, considered a derived work in the GPL. RMS: We have no say in what is considered a derivative work. That is a matter of copyright law, decided by courts. When copyright law holds that a certain thing is not a derivative of our work, then our license for that work does not apply to it. Whatever our licenses say, they are operative only for works that are derivative of our code. A license can say that we will treat a certain kind of work as if it were not derivative, even if the courts think it is. The Lesser GPL does this in certain cases, in effect declining to use some of the power that the courts would give us. But we cannot tell the courts to treat a certain kind of work as if it were derivative, if the courts think it is not. I think we have a pretty good argument that nontrivial dynamic linking creates a combined (i.e. derivative) work. I have an idea for how to change the GPL to make it clearer and more certain, but I need to see if we can work out the details in a way that our lawyer believes will really work. Bruce: There's also the problem of Application Service Providers, who make a work available for people to use without distributing it, and thus would be under no obligation to make the source code of their modifications available. Do I have to see my GPL work abused that way as well? RMS: I too feel these servers are not playing fair with our community, but this problem is very hard to solve. It is hard for a copyright-based license to make a requirement for these servers that will really stick. The difficulty is that they servers are not distributing the program, just running it. So it is hard to make any conditions under copyright that affect what they can do. I had an idea recently for an indirect method that might perhaps work. I'd rather not talk about it until our lawyer figures out better whether it can really do the job. ------------------ http://slashdot.org/article.pl?sid=00/05/01/1052216&mode=nocomment -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 3 22:49:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] executing a network script References: <200005021909.PAA218962@archa12.cc.uga.edu> Message-ID: <3910E524.D5E04491@geoserve.net> Pipers, I'm moving this conversation Brad and I were having about the actual execution of a network script. Brad was wondering how the UI would manage this and what would be sent from the UI to the DL. Brad Chapman wrote: > > Network info is > sent to the dl gradually, as things like additions and connections > occur. So when the front says execute, and sends a list of loci to > execute to the middle, the info describing the user interface wfd is > already present in the dl (stored in xml), and so the dl just needs to > assemble this info into a form that it can present to the bl. Zactly. > > BTW, we can call them nodes :-) > > Yick, node is already taken by dom--especially since they have a Node > class and everything. We'll need to think up something creative to > refer to them as (but not pipers :-). I suppose the developers of Piper are "Pipers" (or Pijpers ;-)), just like the Loci developers were "Locians". Seriously, this was brought up a few weeks ago. If pig-dog languages like DOM must hog the namespace of common terms, we'll have to come up with something a little different. I think we can just prepend "piper" to the names and use... piper_node piper_pipe etc. It'd be good style to do this as much as possible, so that we have a unique namespace. What do you guys think? I also have a related question: Should we distinguish (in name) between a BL node and a PL node? They are very different. > You're right, the front really doesn't have any knowledge of the wfd > connections etc., and the API for passing stuff to be executed is very > simple-minded right now--I just have the front pass a list of all the > loci invovled in the WDF, and let the middle figure out the > connections and stuff. _Hopefully_ this will work... > Basically, I just wasn't sure the right way to select a bunch of > loci (wait, do we call them pipers now?) and then submit them. I > didn't know if we should: > > 1. just have 'submit wfd' type button that basically submits the whole > wfd at once, or > > 2 if we should allow people to select specific loci and then submit > them (and have a separate 'submit selected wfd' button: > But then, how should they be selected? > a. Via a big box that you drag to select everything in it. > b. Shift-button-1 type clicks. > c. Both of the above > d. A different method. > > I thought thet if we are going to have the "more specialized" second > case then I should start with this and work back to the general case > (since the specialized case will be harder :-) to make sure I cover > all the bases. > Do you have thoughts on this--how you think it should be done? I > know that multiple locus selection and stuff is on your TODO list, so > I figgered maybe you already had lots of great ideas for how to do it > all :-) For the selection of nodes for whatever purpose, I want my UI to do BOTH 2c (rectiliner select, shift-button1 select) AND 1 (whole network select) (3 selection options, really). But 2c brings up an interesting problem: Can the user EXECUTE PART of a network? Can the user select and execute a processing node that needs data from a node not selected? I don't think so. IMO, the user may be able to select partial (non-contiguous) networks for editing, etc., but s/he must select a whole (contiguous) network for execution. Thoughts, opinions? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Wed May 3 23:23:10 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] executing a network script References: <200005021909.PAA218962@archa12.cc.uga.edu> <3910E524.D5E04491@geoserve.net> Message-ID: <3910ED1E.23510549@hermes.usherb.ca> > For the selection of nodes for whatever purpose, I want my UI to do BOTH 2c > (rectiliner select, shift-button1 select) AND 1 (whole network select) (3 > selection options, really). But 2c brings up an interesting problem: > > Can the user EXECUTE PART of a network? Can the user select > and execute a processing node that needs data from a node not > selected? > > I don't think so. IMO, the user may be able to select partial > (non-contiguous) networks for editing, etc., but s/he must select a whole > (contiguous) network for execution. Thoughts, opinions? I think that if we want, at some point, to allow executing part of a network, this can be done by creating a network from the selected nodes, and executing this network. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Thu May 4 07:01:57 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script Message-ID: <200005041104.HAA127724@archa12.cc.uga.edu> Jeff wrote: > Seriously, this was brought up a few weeks ago. If pig-dog languages like > DOM must hog the namespace of common terms, we'll have to come up > with something a little different. I think we can just prepend "piper" > to the names and use... > > piper_node > piper_pipe > etc. > > It'd be good style to do this as much as possible, so that we have a unique > namespace. What do you guys think? It sounds good, except lets say I have xml like: stuff about the node If I stick this into dom, I have been referring to things basically as their tag with _node appended, so this would translate into a variable called 'piper_node_node' (where it had previously been 'locus_node'), which is really ugly :-) > I also have a related question: Should we distinguish (in name) between a BL > node and a PL node? They are very different. I think we should, but it is not clear to me how the BL and PL (gms and overflow) will work together exactly, so I don't know how to name them yet... > For the selection of nodes for whatever purpose, I want my UI to do BOTH 2c > (rectiliner select, shift-button1 select) AND 1 (whole network select) (3 > selection options, really). Okay, all of the options :-) Jeff wrote: >But 2c brings up an interesting problem: > > Can the user EXECUTE PART of a network? Can the user select > and execute a processing node that needs data from a node not > selected? > > I don't think so. IMO, the user may be able to select partial > (non-contiguous) networks for editing, etc., but s/he must select a whole > (contiguous) network for execution. Thoughts, opinions? Jean-Marc wrote: > I think that if we want, at some point, to allow executing part of a network, > this can be done by creating a network from the selected nodes, and executing > this network. I agree with both of you that executing a partial network will be really tricky, especially at the beginning. My thought was to try and have the dl "check" the work-flow-diagram/network and look for things like needing input that is not in the diagram, and then returning an error to the front before submitting to the bl. This will probably be some work and not be perfect at the beginning, but we can try to work through it and see what kind of errors we get from different weird work flow diagrams. The bigger issue here is that I think Jeff and Jean-Marc have two different ideas about what a "network" is. It seems like (from my little experience using Overflow before it seg-faults on me :-) in Overflow a network is always the entire workspace (in Loci terms). It kind of models it like this since a network is like the main function in a C program and the nodes are like functions it calls (am I right on this?). While in Loci it seems like Jeff was thinking that not every node inside of workspaces would necessarily be part of the network (only those that were selected). The Loci way seems more flexible, but is definately more of a pain. What Jean-Marc said above seems to be what I was thinking about doing in the dl, is to turn only the submitted (selected) nodes into the network that is submitted to the bl. I'm not sure if this helps take care of the issue of workspace=network versus workspace != network to everyone's satisfaction? Along these lines, I was also curious. What are the plans for trying to integrate the Overflow GUI with the Loci GUI? Will the Overflow GUI be a "composite locus" that can be loaded up? Can we make C Gtk/Gnome talk with python Gtk/Gnome (ie. transfer the control of the gui to the Overflow GUI when a user clicks inside the composite locus holding the Overflow GUI)? I was just curious how this was going to work. Brad From bizzaro at geoserve.net Thu May 4 12:49:12 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005041104.HAA127724@archa12.cc.uga.edu> Message-ID: <3911AA08.C9E66D8C@geoserve.net> Brad Chapman wrote: > > If I stick this into dom, I have been referring to things basically as > their tag with _node appended, so this would translate into a variable > called 'piper_node_node' (where it had previously been 'locus_node'), > which is really ugly :-) Hmmm. Is the appending of "_node" something that DOM requires or something that you came up with? > I agree with both of you that executing a partial network will be > really tricky, especially at the beginning. My thought was to try and > have the dl "check" the work-flow-diagram/network and look for things > like needing input that is not in the diagram, and then returning an > error to the front before submitting to the bl. This will probably be > some work and not be perfect at the beginning, but we can try to work > through it and see what kind of errors we get from different weird > work flow diagrams. The biggest problem is the selection and submission of non-contiguous sections of a network (e.g., selecting 2 nodes that are separated by one unselected node in the middle). While ctrl-button1 click in the UI will/can allow this, we wouldn't want this submitted to be executed. > The bigger issue here is that I think Jeff and Jean-Marc have two > different ideas about what a "network" is. It seems like (from my > little experience using Overflow before it seg-faults on me :-) in > Overflow a network is always the entire workspace (in Loci terms). It > kind of models it like this since a network is like the main function > in a C program and the nodes are like functions it calls (am I right > on this?). While in Loci it seems like Jeff was thinking that not > every node inside of workspaces would necessarily be part of the > network (only those that were selected). The Loci way seems more > flexible, but is definately more of a pain. I think what I've been calling a "network" or "workflow diagram" is more like an Overflow "subnet". We do need a consistent terminology. > What Jean-Marc said above seems to be what I was thinking about > doing in the dl, is to turn only the submitted (selected) nodes into > the network that is submitted to the bl. I'm not sure if this helps > take care of the issue of workspace=network versus workspace != > network to everyone's satisfaction? But they still need to be contiguous. It's a complex problem we can work on at a later point in the development. > Along these lines, I was also curious. What are the plans for > trying to integrate the Overflow GUI with the Loci GUI? Will the > Overflow GUI be a "composite locus" that can be loaded up? Can we make > C Gtk/Gnome talk with python Gtk/Gnome (ie. transfer the control of > the gui to the Overflow GUI when a user clicks inside the composite > locus holding the Overflow GUI)? I was just curious how this was going > to work. Bzzzzt. Of course Jean-Marc can do what he likes with his own GUI, but piper will have multiple UI's that function differently (some of them won't even be graphical). And each will have to construct a PL network in a manner consistent with the UI's own style (not to mention, in a manner that will WORK with the PL). So, we can't embed Overflow into every UI. For my Pied (Gnome) UI, I want to make a workspace widget for the PL that looks and works like the workspace for the BL (i.e., looks and work like Loci). It'll be in Python/Gtk. BTW, the UI interfaces with the PL only through the DL and BL, not directly. Correct? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 4 14:03:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005041104.HAA127724@archa12.cc.uga.edu> <3911AA08.C9E66D8C@geoserve.net> Message-ID: <3911BB59.16A8E504@geoserve.net> "J.W. Bizzaro" wrote: > > The biggest problem is the selection and submission of non-contiguous sections > of a network (e.g., selecting 2 nodes that are separated by one unselected > node in the middle). While ctrl-button1 click in the UI will/can allow this, > we wouldn't want this submitted to be executed. BTW, I would like the DL to keep track of the nodes that are selected. IOW, when the UI selects a node, it sends a request to the DL to consider that node selected. Then, when the UI requests that the selected set of nodes (a subnet) be executed, the UI won't have to send a big list of nodes: the DL will already know what is part of the selected set. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu May 4 16:46:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script Message-ID: <200005042048.QAA178582@archa12.cc.uga.edu> > Hmmm. Is the appending of "_node" something that DOM requires or something > that you came up with? Not required, just my brilliant idea :-) Seriously, I just try to use that so it is easier to distinguish between when you are working with dom specifically and when you are working with loci (or piper) objects. The code tends to mix because you are getting piper objects to put into dom, so I think adding the little _node is just my way to make things clear. My overall point is that I just think 'node' is taken up by the tools we are using and we should think up something else to describe our smallest elements. This will make the code easier to read and understand, IMO. I dug using locus, but I don't know how people feel about that now. Node was a Overflow term, right? > The biggest problem is the selection and submission of non-contiguous > sections > of a network (e.g., selecting 2 nodes that are separated by one unselected > node in the middle). While ctrl-button1 click in the UI will/can allow this, > we wouldn't want this submitted to be executed. Agreed, the error checking should all occur in the dl when it is getting it ready for sending to the bl. This way, the bl should be able to "count" on having a network definition that is complete and ready to run. This will also decrease the time between when a bad network is submitted and when it it run. [...me talking about combining the Loci and Overflow GUIs...] > Bzzzzt. Of course Jean-Marc can do what he likes with his own GUI, but piper > will have multiple UI's that function differently (some of them won't even be > graphical). And each will have to construct a PL network in a manner > consistent with the UI's own style (not to mention, in a manner that will > WORK > with the PL). So, we can't embed Overflow into every UI. Oh absolutely, I'm only talking about getting it into the Gnome UI. Whenever other people start on different interfaces, they will be starting things fresh and can plug into the framework we are developing with the Gnome interface. > For my Pied (Gnome) UI, I want to make a workspace widget for the PL that > looks and works like the workspace for the BL (i.e., looks and work like > Loci). It'll be in Python/Gtk. It just seems like that you both have such similar designs, that there isn't some kind of meeting place where we can have some code re-use? It just seems like the sooner we are able to get Overflow running under Piper the way it is now stand-alone, the sooner we can make better use of our resources and not have to be coding separate UIs and all of that. I'm just trying to think of ways that we can do that sooner, rather than later. I was kind of interested to hear Jean-Marc's thoughts on this as well, and how he thinks we can expedite the process of getting all of our programs together. So I was just trying to brainstorm ideas along those lines :-) > BTW, the UI interfaces with the PL only through the DL and BL, not directly. > Correct? The idea right now is that the UI only talks to the dl, and the only way it can talk through it is through the streaming XML dialog "API." Everything that the UI can currently talk to the dl about (and how to do it) is documented in doc/comProtocols.txt in the loci module in cvs. I need to talk some time to clean this documentation up and make it more readible (I'll redo it in latex or something), but what we have so far is there. Input on problems/suggestions for the interface would be super :-) Brad From chapmanb at arches.uga.edu Thu May 4 17:05:21 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] UI/DL and selection WAS executing a network script Message-ID: <200005042107.RAA197718@archa11.cc.uga.edu> Jeff wrote: > BTW, I would like the DL to keep track of the nodes that are selected. IOW, > when the UI selects a node, it sends a request to the DL to consider that > node > selected. Then, when the UI requests that the selected set of nodes (a > subnet) be executed, the UI won't have to send a big list of nodes: the DL > will already know what is part of the selected set. I don't think this will work with the streaming XML api. Right now to do that you would have to do the following everytime a locus is clicked on (selected): 1. Muster an xml message in the front with something like: 2. Send this message through the socket to the dl. 3. The dl would then have to somehow store this information. Right now the dl stores pretty much everything the front sends it in xml (to make it permanent). We would need to rethink some of the design issues if want the dl to store information like selected loci for the ui. Anyways, If you want this kind of selected info stored in xml we would need to: a. Open the xml file for the selected locus and set it as selected. b. Open the xml file for the previously selected locus/loci (I'm not sure how I would keep track of this) and set them as no longer selected. 4. Return a message to the front indicating success or failure. In my opinion, this is too much of a mess under the streaming XML dialog API, and if we want this really fine grained level of control we need to rethink things, and use CORBA to do the communication. Then it would be a function call like: middle.set_selected(list_of_selected_loci) instead of all that xml. The dl is also not designed with this kind of fine scale stuff in mind since I thought we were just dealing with large scale changes and not details like this, so we would also need to rethink things there. One of the reasons why I brought up the Berlin project on the list the other day is that I thought it might be a good model to help us figure out some of our design issues. They are working with having the whole GUI go through CORBA, and have it down to a set of idl interfaces, so there is probably a lot we can learn from there. But maybe I was off-base in seeing the similarity between the projects... Brad From bizzaro at geoserve.net Thu May 4 17:37:33 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> Message-ID: <3911ED9D.31247743@geoserve.net> Brad Chapman wrote: > > My overall point is that I just think 'node' is taken up by the > tools we are using and we should think up something else to describe > our smallest elements. This will make the code easier to read and > understand, IMO. I dug using locus, but I don't know how people feel > about that now. Node was a Overflow term, right? Node is an Overflow term, yes. And I don't know if Jean-Marc wants to change it. Do you have to turn Overflow/PL nodes into DOM nodes as well, or is that just for BL nodes? If it's just for BL nodes, we could continue to call each a "locus", meaning "location", which is what BL nodes are. We could also use "bl_node" and "pl_node", but that might again cause problems. > Agreed, the error checking should all occur in the dl when it is > getting it ready for sending to the bl. This way, the bl should be > able to "count" on having a network definition that is complete and > ready to run. This will also decrease the time between when a bad > network is submitted and when it it run. The way piper will work reminds me so much of writing a BASIC program: * You have 2 modes: program editing and program running * When editing, BASIC (some versions) will point out errors: "SYNTAX ERROR" * Typing "RUN" will send the program to the interpreter * The interpreter can return errors as well: "SYNTAX ERROR IN LINE 100" For piper, the UI is the editing environment, the DL checks for errors in the script, the BL runs the script, and the PL is the low-level implementation of the script. > It just seems like that you both have such similar designs, that there > isn't some kind of meeting place where we can have some code re-use? > It just seems like the sooner we are able to get Overflow running > under Piper the way it is now stand-alone, the sooner we can make > better use of our resources and not have to be coding separate UIs and > all of that. I'm just trying to think of ways that we can do that > sooner, rather than later. I was kind of interested to hear > Jean-Marc's thoughts on this as well, and how he thinks we can > expedite the process of getting all of our programs together. So I was > just trying to brainstorm ideas along those lines :-) We can get the Overflow GUI running under Pied (my Gnome GUI) by making Python bindings to the Overflow GUI or by using Bonobo. I think both approaches would be more work than what I had in mind: Make a widget that is a Loci workspace modified to build Overflow subnets. Then there's LOTS of code reuse :-) I have nothing against the Overflow GUI. It's very nice. It is just that it works differently enough from the Loci GUI that embedding it would be confusing to users and result in a higher learning curve. > The idea right now is that the UI only talks to the dl, and the only > way it can talk through it is through the streaming XML dialog "API." > Everything that the UI can currently talk to the dl about (and how to > do it) is documented in doc/comProtocols.txt in the loci module in > cvs. I need to talk some time to clean this documentation up and make > it more readible (I'll redo it in latex or something), but what we > have so far is there. Input on problems/suggestions for the interface > would be super :-) Great. I'll take a look. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 4 17:48:02 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] UI/DL and selection WAS executing a network script References: <200005042107.RAA197718@archa11.cc.uga.edu> Message-ID: <3911F012.25614DFD@geoserve.net> Brad, I understand the points you made. It's true that having the DL keep track of selected nodes will mean more communication through the UI2DL socket, resulting in slower performance. But I think we need to have ONE clear and simple rule about deciding which function is handled by the UI and which is handled by the DL: Whatever is common amongst all UI's should be handled by the DL. Whatever is unique to a UI should be handled by the UI. Selection of nodes is something ALL UI's will have to do. This means the code and system for doing this will have to be duplicated for EACH UI, and even in DIFFERENT LANGUAGES in some cases. Gee, it seems you and I are always arguing "code reuse" vs. "code duplication" ;-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri May 5 05:01:05 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] UI/DL and selection WAS executing a network script References: <200005042107.RAA197718@archa11.cc.uga.edu> Message-ID: <39128DD0.60674B66@casema.net> > > BTW, I would like the DL to keep track of the nodes that are > selected. IOW, > > I don't think this will work with the streaming XML api. Cant give every node a list of flags that represents wheter a node's selected = True or something else. False most of the time. > > In my opinion, this is too much of a mess under the streaming XML > dialog API ? explain please. > we need to rethink things, and use CORBA to do the communication. Then nice corba :) > > instead of all that xml. The dl is also not designed with this kind of > fine scale stuff in mind since I thought we were just dealing with > large scale changes and not details like this, so we would also need > to rethink things there. because non lineair node access makes troubble? Shouldn't this kinda access already be there? The UI user can do anything at anytime. > > One of the reasons why I brought up the Berlin project on the list > the other day is that I thought it might be a good model to help us > figure out some of our design issues. They are working with having the > whole GUI go through CORBA, and have it down to a set of idl > interfaces, so there is probably a lot we can learn from there. But > maybe I was off-base in seeing the similarity between the projects... > I read the site, and I didn't really saw the relanvance. Just the fact they use corba everywhere or is there more? From bizzaro at geoserve.net Thu May 4 21:13:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper Message-ID: <3912202E.8CF2C02@geoserve.net> I just moved the web page over to a new URL: http://bioinformatics.org/piper/ Do you dig the new logo? :-) Jeff From jean-marc.valin at hermes.usherb.ca Thu May 4 21:13:06 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> Message-ID: <39122022.8216C0B0@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > I just moved the web page over to a new URL: > > http://bioinformatics.org/piper/ I would suggest putting the project on sourceforge instead. It would be much easier to administrate. What do you all think? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jean-marc.valin at hermes.usherb.ca Thu May 4 21:11:42 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> Message-ID: <39121FCE.8B972615@hermes.usherb.ca> > > The biggest problem is the selection and submission of non-contiguous > > sections > > of a network (e.g., selecting 2 nodes that are separated by one > unselected > > node in the middle). While ctrl-button1 click in the UI will/can > allow this, > > we wouldn't want this submitted to be executed. If we're doing a pull, then only the output node matters. This means that we're not going to specify a section we want to run, but what output we want. The nodes that are actually going to run will depend on what needs to be calculated. > It just seems like that you both have such similar designs, that there > isn't some kind of meeting place where we can have some code re-use? > It just seems like the sooner we are able to get Overflow running > under Piper the way it is now stand-alone, the sooner we can make > better use of our resources and not have to be coding separate UIs and > all of that. I'm just trying to think of ways that we can do that > sooner, rather than later. I was kind of interested to hear > Jean-Marc's thoughts on this as well, and how he thinks we can > expedite the process of getting all of our programs together. So I was > just trying to brainstorm ideas along those lines :-) OK, first of all, I have to say I don't know anything about Python. I would rather code the GUI in C++, but if most people want Python, it's OK with me, as long as you don't expect me to contribute too much. As for how to integrate Overflow, here is an idea of the complexity of each part, in lines of code (this includes white lines and comments) 1- gnome GUI : 2500 lines 2- toolkit independent UI stuff : 2500 lines 3- Non-UI data-flow stuff : 3000 lines 4- Node implementations : ~28000 lines Only 1) depends on gnome/gtk and 2) depends on libXML. All the XML parsing and the conversion to a "real" runnable network is performed by 2). You cannot change 3) unless you want to change 4) (and I don't want to!). If I understand your terminology correctly, 3) (and 4?) is the data-flow layer. I basically see 4 ways to do the integration (number of lines to change/rewrite in parentheses): A) embed the Overflow GUI in piper (0 lines) B) use the GUI classes (GUINode, GUILink, ...) in piper (~0-200 lines) C) scrap the GUI (1), but keep 2) (2500-3000 lines) D) scrap both 1) and 2) (5000 lines) I would go for either C or D, that may depend on whether or not we're going to use the gnome canvas (I use it, and I suggest using it). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Thu May 4 21:29:03 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] UI/DL and selection WAS executing a network script References: <200005042107.RAA197718@archa11.cc.uga.edu> <39128DD0.60674B66@casema.net> Message-ID: <391223DF.A5695B75@geoserve.net> jarl van katwijk wrote: > > > > BTW, I would like the DL to keep track of the nodes that are > > > selected. IOW, > > > > I don't think this will work with the streaming XML api. > > Cant give every node a list of flags that represents wheter a node's > selected = True or something else. False most of the time. It may be simpler to have a separate data structure that stores the simply ID's of nodes that are selected. This is what I was planning for Pied which, again, would have to be implemented in EVERY UI if the DL doesn't do it. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 4 21:33:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> Message-ID: <391224E8.F00D246D@geoserve.net> Jean-Marc Valin wrote: > > I would suggest putting the project on sourceforge instead. It would be much > easier to administrate. What do you all think? Do you mean THE sourceforge.net or our own implementation of it? Here it is: http://alpha.bioinformatics.org/ Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 4 21:39:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> <39121FCE.8B972615@hermes.usherb.ca> Message-ID: <39122653.6E6F739C@geoserve.net> Jean-Marc Valin wrote: > > If we're doing a pull, then only the output node matters. This means that we're > not going to specify a section we want to run, but what output we want. The > nodes that are actually going to run will depend on what needs to be calculated. Hmmm. I never thought of that. So, a user can just select the "document" that recieves the output, and piper will do whatever it takes to get the data. I like it. > OK, first of all, I have to say I don't know anything about Python. I would > rather code the GUI in C++, but if most people want Python, it's OK with me, as > long as you don't expect me to contribute too much. Like I said, for my Gnome UI (was Loci, now Pied), I will write the workspace/network widget for Overflow/PL. It will be a modified version of what already exists for Loci. > A) embed the Overflow GUI in piper (0 lines) > B) use the GUI classes (GUINode, GUILink, ...) in piper (~0-200 lines) > C) scrap the GUI (1), but keep 2) (2500-3000 lines) > D) scrap both 1) and 2) (5000 lines) > > I would go for either C or D, that may depend on whether or not we're going to > use the gnome canvas (I use it, and I suggest using it). I'd go for C as well. BTW, the Loci GUI is already about 3000 lines, so we wouldn't be starting from scratch. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Thu May 4 21:32:30 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> Message-ID: <391224AE.895812FD@hermes.usherb.ca> > > I would suggest putting the project on sourceforge instead. It would be much > > easier to administrate. What do you all think? I mean THE sourceforge.net. I'm currently transferring Overflow (included in the Open Mind Speech project) to sourceforge. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Thu May 4 21:48:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> Message-ID: <39122863.E3F689A7@geoserve.net> Jean-Marc Valin wrote: > > I mean THE sourceforge.net. I'm currently transferring Overflow (included in the > Open Mind Speech project) to sourceforge. We have the same exact sourceforge system running on our own server (VA Linux GPL'd and released the software. Gary then installed it on our new Pentium III). Why not use our server? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Thu May 4 21:54:54 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> <39121FCE.8B972615@hermes.usherb.ca> <39122653.6E6F739C@geoserve.net> Message-ID: <391229EE.4AF5E53@hermes.usherb.ca> > > A) embed the Overflow GUI in piper (0 lines) > > B) use the GUI classes (GUINode, GUILink, ...) in piper (~0-200 lines) > > C) scrap the GUI (1), but keep 2) (2500-3000 lines) > > D) scrap both 1) and 2) (5000 lines) > > > > I would go for either C or D, that may depend on whether or not we're going to > > use the gnome canvas (I use it, and I suggest using it). > > I'd go for C as well. BTW, the Loci GUI is already about 3000 lines, so we > wouldn't be starting from scratch. Sorry, I meant B or C... does that change anything? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Thu May 4 22:09:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> <39121FCE.8B972615@hermes.usherb.ca> <39122653.6E6F739C@geoserve.net> <391229EE.4AF5E53@hermes.usherb.ca> Message-ID: <39122D45.1410F894@geoserve.net> Jean-Marc Valin wrote: > > > > A) embed the Overflow GUI in piper (0 lines) > > > B) use the GUI classes (GUINode, GUILink, ...) in piper (~0-200 lines) > > > C) scrap the GUI (1), but keep 2) (2500-3000 lines) > > > D) scrap both 1) and 2) (5000 lines) > > > > Sorry, I meant B or C... does that change anything? What do the classes in B do? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Thu May 4 22:01:27 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> Message-ID: <39122B77.7F4DD070@hermes.usherb.ca> > > I mean THE sourceforge.net. I'm currently transferring Overflow (included in the > > Open Mind Speech project) to sourceforge. > > We have the same exact sourceforge system running on our own server (VA Linux > GPL'd and released the software. Gary then installed it on our new Pentium > III). Why not use our server? > The reasons I suggested sourceforge.net is that 1) We don't have to take care of the server ourself (I'm guessing sourceforge has 7/24 support) 2) People can hear about the project more easily (eg. by browsing on sourceforge). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Thu May 4 22:18:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> Message-ID: <39122F87.8831EC4E@geoserve.net> Jean-Marc Valin wrote: > > The reasons I suggested sourceforge.net is that > 1) We don't have to take care of the server ourself (I'm guessing sourceforge > has 7/24 support) The Open Lab has been up and running for more than a year now, and we have several administrators. Plus, sourceforge won't offer the same level of access that I can :-) > 2) People can hear about the project more easily (eg. by browsing on > sourceforge). True, but more people probably go to freshmeat before sourceforge when looking for an app. Frequent announcements there and elsewhere should suffice. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 4 22:21:50 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> Message-ID: <3912303E.A4E1659@geoserve.net> Oh, plus The Open Lab will set up a server as a central locale for piper nodes. It'd look pretty silly if we could do that but not host the development :-/ Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 4 22:27:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> <3912303E.A4E1659@geoserve.net> Message-ID: <3912318A.F3A01FB0@geoserve.net> And Jarl just moved GMS's code to The Open Lab CVS :-) http://theopenlab.org/cgi-bin/cvsweb.cgi/gms/ Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Thu May 4 23:16:25 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> <3912303E.A4E1659@geoserve.net> <3912318A.F3A01FB0@geoserve.net> Message-ID: <39123D09.353B517E@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > And Jarl just moved GMS's code to The Open Lab CVS :-) > > http://theopenlab.org/cgi-bin/cvsweb.cgi/gms/ OK, I was just wondering why you insisted on haveing your own sourceforge server. I'm still leaving Overflow on sourceforge, since it is also tied with the "Open Mind Speech" project... Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Thu May 4 23:31:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:52 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> <3912303E.A4E1659@geoserve.net> <3912318A.F3A01FB0@geoserve.net> <39123D09.353B517E@hermes.usherb.ca> Message-ID: <391240A3.BE47FD88@geoserve.net> Jean-Marc Valin wrote: > > OK, I was just wondering why you insisted on haveing your own sourceforge > server. The reason WHY we have our own server is to create a collaborative environment for computational biologists. We're not competing with sourceforge in that sense. We have a much smaller audience/membership. But a large part of piper (i.e., Loci) is based at The Open Lab, so I'd like piper as a whole to be/stay here. I don't see a reason why it SHOULDN'T. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Fri May 5 11:03:00 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> <39121FCE.8B972615@hermes.usherb.ca> <39122653.6E6F739C@geoserve.net> <391229EE.4AF5E53@hermes.usherb.ca> <39122D45.1410F894@geoserve.net> Message-ID: <3912E2A4.4E117055@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > Jean-Marc Valin wrote: > > > > > > A) embed the Overflow GUI in piper (0 lines) > > > > B) use the GUI classes (GUINode, GUILink, ...) in piper (~0-200 lines) > > > > C) scrap the GUI (1), but keep 2) (2500-3000 lines) > > > > D) scrap both 1) and 2) (5000 lines) > > > > > > Sorry, I meant B or C... does that change anything? > > What do the classes in B do? in the vflow/src directory there are UI* classes and GUI* classes. The UI* classes (as in UINetwork, UINode, ...) are toolkit-independent (and are used in the command-line tool). They take care of XML saving/parsing, and building runnable networks from the object description. the GUI* classes (as in GUINode, GUINetwork, ...) are gnome-dependent and hadle the canvas items in the GUI. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jean-marc.valin at hermes.usherb.ca Fri May 5 11:15:10 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> <3912303E.A4E1659@geoserve.net> <3912318A.F3A01FB0@geoserve.net> <39123D09.353B517E@hermes.usherb.ca> <391240A3.BE47FD88@geoserve.net> Message-ID: <3912E57E.47C6F79D@hermes.usherb.ca> > > OK, I was just wondering why you insisted on haveing your own sourceforge > > server. > > The reason WHY we have our own server is to create a collaborative environment > for computational biologists. We're not competing with sourceforge in that > sense. We have a much smaller audience/membership. > > But a large part of piper (i.e., Loci) is based at The Open Lab, so I'd like > piper as a whole to be/stay here. I don't see a reason why it SHOULDN'T. As I told, you, it's OK with me, as long as the Overflow part stays on sourceforge (because of Open Mind Speech). Do you have any problem with that? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Fri May 5 11:55:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] Piper References: <3912202E.8CF2C02@geoserve.net> <39122022.8216C0B0@hermes.usherb.ca> <391224E8.F00D246D@geoserve.net> <391224AE.895812FD@hermes.usherb.ca> <39122863.E3F689A7@geoserve.net> <39122B77.7F4DD070@hermes.usherb.ca> <3912303E.A4E1659@geoserve.net> <3912318A.F3A01FB0@geoserve.net> <39123D09.353B517E@hermes.usherb.ca> <391240A3.BE47FD88@geoserve.net> <3912E57E.47C6F79D@hermes.usherb.ca> Message-ID: <3912EEF0.C087517C@geoserve.net> Jean-Marc Valin wrote: > > As I told, you, it's OK with me, as long as the Overflow part stays on > sourceforge (because of Open Mind Speech). Do you have any problem with that? No problem :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri May 5 13:54:26 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script Message-ID: <200005051756.NAA197662@archa12.cc.uga.edu> [...snip, discussion about what Overflow code does and how to use it in Piper...] Jean-Marc Valin wrote: > in the vflow/src directory there are UI* classes and GUI* classes. The UI* > classes (as in UINetwork, UINode, ...) are toolkit-independent (and are used > in > the command-line tool). They take care of XML saving/parsing, and building > runnable networks from the object description. the GUI* classes (as in > GUINode, > GUINetwork, ...) are gnome-dependent and hadle the canvas items in the GUI. I definately want to make use of the UI* classes in the dl! The structure of your classes is very similar to what I have mapped out for trying to do the same thing (from scratch) in the dl (you can take a look at the class design I sketched out in the loci module in middle/library/modules/bl/blrepresentation.py--and no, I swear I didn't rip my design off from you!). Thanks for clarifying what the different classes in vflow do so I could see this incredible similarity; I apologize that I didn't see this earlier (although it was probably good for me to think through the design on my own so I can understand your code better). The approach I'd like to try and take for incorporating them is to use SWIG (swig.sourceforge.net) to wrap the C++ into python and then just have my python skeleton classes to inheret from your C++ classes (just to provide a basic python-looking wrapper around the actual C++ functionality). I can start tackling this over the next week. I'm learning SWIG right now to mess with XDBM in python, so hopefully by the time I get into wrapping your code I'll be able to do it properly :-) It looks like most of the classes just take strings (and other UI* objects) for initialization, so what I'll be doing is feeding this information into the objects from stored xml describing the gui, instead of from the GUI itself (this is due to the separation of build time from run time what Jeff mentioned earlier). So essentially the code rewrites for Overflow should be very little. Under this scheme you can modify the underlying C++ as much as you want, and I'll just have to fix things if you modify the interface. How does this approach sound (especially to Jean-Marc and Dominic)? Brad From chapmanb at arches.uga.edu Fri May 5 14:13:20 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection Message-ID: <200005051815.OAA232370@archa11.cc.uga.edu> > But I think we need to have ONE clear and simple rule about deciding which > function is handled by the UI and which is handled by the DL: > > Whatever is common amongst all UI's should be handled by the DL. > Whatever is unique to a UI should be handled by the UI. > > Selection of nodes is something ALL UI's will have to do. This means the > code > and system for doing this will have to be duplicated for EACH UI, and even in > DIFFERENT LANGUAGES in some cases. You are absolutely right. I have a way to kind of hack in support for holding selected nodes, and I'll do that. The problem is that it is not really consistent with the overall style of how I'm handling things in the dl, which is to save all changes permanently in xml. I think the biggest problem that I was trying to point out is that I don't know if the streaming xml dialog is going to cut it, which makes me *extremely* sad :-< Another thing that we need to add is support for the xml holding the position of nodes on the canvas. Overflow supports this, and it will be necessary if we are going to implement crash-recovery stuff and saving of work-flow diagrams. However, if we keep pushing everything through the socket like we this, using Piper is going to be as slow as surfing the web with a 28.8 modem you got at a garage sale. Something we probably need to do is start trying to define a corba interface to replace this dialog. The problem with this is that I know implementing ui's on top of corba will be more technically demanding then implementing them on top of a socket with xml parsing stuff, so I don't know how this will limit the desire/ability of people to make different ui's. Specifically, I know Gary mentioned this previously, so I'm not sure how he feels about all of this... > Gee, it seems you and I are always arguing "code reuse" vs. "code > duplication" > ;-) Yeah, I guess so :-) That is why it is good to have lots of people on a project, so you can have lots of ways to looking at problems. Go open source development model! Brad From jean-marc.valin at hermes.usherb.ca Fri May 5 14:24:30 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005051756.NAA197662@archa12.cc.uga.edu> Message-ID: <391311DE.E8410D7C@hermes.usherb.ca> Brad Chapman a ?crit : > > [...snip, discussion about what Overflow code does and how to use it > in Piper...] > > Jean-Marc Valin wrote: > > in the vflow/src directory there are UI* classes and GUI* classes. > The UI* > > classes (as in UINetwork, UINode, ...) are toolkit-independent (and > are used > > in > > the command-line tool). They take care of XML saving/parsing, and > building > > runnable networks from the object description. the GUI* classes (as > in > > GUINode, > > GUINetwork, ...) are gnome-dependent and hadle the canvas items in > the GUI. > > I definately want to make use of the UI* classes in the dl! The > structure of your classes is very similar to what I have mapped out > for trying to do the same thing (from scratch) in the dl (you can take > a look at the class design I sketched out in the loci module in > middle/library/modules/bl/blrepresentation.py--and no, I swear I > didn't rip my design off from you!). Thanks for clarifying what the > different classes in vflow do so I could see this incredible > similarity; I apologize that I didn't see this earlier (although it > was probably good for me to think through the design on my own so I > can understand your code better). > The approach I'd like to try and take for incorporating them is to > use SWIG (swig.sourceforge.net) to wrap the C++ into python and then > just have my python skeleton classes to inheret from your C++ classes > (just to provide a basic python-looking wrapper around the actual > C++ functionality). I can start tackling this over the next week. I'm > learning SWIG right now to mess with XDBM in python, so hopefully by > the time I get into wrapping your code I'll be able to do it properly > :-) > It looks like most of the classes just take strings (and other UI* > objects) for initialization, so what I'll be doing is feeding this > information into the objects from stored xml describing the gui, > instead of from the GUI itself (this is due to the separation of build > time from run time what Jeff mentioned earlier). So essentially the > code rewrites for Overflow should be very little. Under this scheme > you can modify the underlying C++ as much as you want, and I'll just > have to fix things if you modify the interface. > How does this approach sound (especially to Jean-Marc and Dominic)? Sounds fine! I'm not sure I understand the modifications you want to make, though... could you explain more? Here's another precision I'd like to make about the way Overflow works... I'm going to compare 3 classes: Node, UINode, and GUINode Node is the (abstract) base class for all operations (including the Network class; a Network is a Node) if a certain node in the "program" is included twice (because of subnet inclusion) then, there are two instances of these Nodes. UINode is not an abstract class and can represent any node type in the "program". It is used to save/load XML and has a "build" method, which returns a Node (actually an object of a class that derives from Node). GUINode derives from UINode and adds some Gnome functionalities. If I were to write a KDE GUI, I'd simply create a KUINode that derives from UINode. Note that the Node/UINode/GUINode is about the same for Network/UINetwork/GUINetwork. Also, I think using swig is a good idea, as I'd like to be able to use the original Overflow without python. Jean-Marc From chapmanb at arches.uga.edu Fri May 5 14:50:53 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection WAS executing a network script Message-ID: <200005051853.OAA28528@archa10.cc.uga.edu> Brad wrote: >> In my opinion, this is too much of a mess under the streaming XML >> dialog API Jarl wrote: > ? explain please. This is what I was trying to do with my example :-) My point was supposed to be that a whole ton of stuff has to happen just to support a user click on the canvas. This will makes things reaaaaaaaly slow. Jarl wrote: > because non lineair node access makes troubble? > Shouldn't this kinda access already be there? The UI user can do anything > at anytime. No, non-linear access is actually the only kind of access to nodes I have :-) The problem is more that everything is stored in xml and not in memory. I was working with this model because I was thinking we were going to only be dealing with large scale changes to things. But now I need to re-think this. [...me talking about Berlin...] Jarl wrote: > I read the site, and I didn't really saw the relanvance. Just the fact they > use corba everywhere or is there more? I guess I thought the relevance was that we both have something like the following: external ui ---------> information that defines ui formal separation In their case they have the external ui (in any language) manipulating what they call a scene graph, which defines how the ui looks. In our case, we have an external ui manipulating an xml description, which defines how the ui looks. I just kind of throught there were some parallels here, at least in my warped mind :-) Brad From jean-marc.valin at hermes.usherb.ca Fri May 5 15:04:42 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] about XML References: <200005051853.OAA28528@archa10.cc.uga.edu> Message-ID: <39131B4A.B4924B51@hermes.usherb.ca> Hi, I think there's something we need to make clear about XML. The only reason I was using XML in Overflow is that I didn't want to spend too much time writing a parser. I'm storing all the info as objects (UINode, UINetwork, ...) and use the XML only for load/save (I use lib-xml as a black box and don't care how it's saved). This is why I don't understand everything that's going on on this list about XML... am I missing something? Jean-Marc From bizzaro at geoserve.net Fri May 5 15:17:32 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection References: <200005051815.OAA232370@archa11.cc.uga.edu> Message-ID: <39131E4C.111040F5@geoserve.net> Brad Chapman wrote: > > You are absolutely right. I have a way to kind of hack in support for > holding selected nodes, and I'll do that. The problem is that it is > not really consistent with the overall style of how I'm handling > things in the dl, which is to save all changes permanently in xml. I think node selection is not a permanent change to any network and should probably NOT be added to permanent XML storage. As I mentioned before, you may want to make a separate, temporary data structure to hold the ID's of selected nodes. > I think the biggest problem that I was trying to point out is that > I don't know if the streaming xml dialog is going to cut it, which > makes me *extremely* sad :-< I don't think we should consider scrapping it until a CORBA API is in place and proves to be better. > Another thing that we need to add is > support for the xml holding the position of nodes on the canvas. > Overflow supports this, and it will be necessary if we are going to > implement crash-recovery stuff and saving of work-flow diagrams. According to our simple rule, canvas positions are NOT common to all UI's, so they should not be managed by the DL. HOWEVER, speaking of "crash recovery", these positions are for permanent storage. A user can save a network and share one with others. It would be great if the network actually looked the same when reloaded. So, let me modify the rule a bit: I think the DL SHOULD save information such as icons, XY positions, widget descriptions/libraries in PARALLEL to the common network information. Brad, how can the DL manage this? I mentioned a while ago that if the DL kept XML info in the filesystem, such as... ls.xml then the DL could keep UI stuff along side it, such as... ls.xy ls.widget ls.icon But, I guess some things have changed recently. How would you do something like this now? As for Overflow, Jean-Marc said he recognized that node positions really shouldn't be included with the network XML. But my question is: Does Overflow REQUIRE the node positions in the XML? If Piper sends Overflow/PL a network description that does not include node positions, will Overflow crash? > However, if we keep pushing everything through the socket like we > this, using Piper is going to be as slow as surfing the web with a > 28.8 modem you got at a garage sale. Something we probably need to do > is start trying to define a corba interface to replace this dialog. Selecting nodes will be slow enough. I don't want to send XY info as well :-P > The problem with this is that I know implementing ui's on top of > corba will be more technically demanding then implementing them on top > of a socket with xml parsing stuff, so I don't know how this will > limit the desire/ability of people to make different ui's. > Specifically, I know Gary mentioned this previously, so I'm not sure > how he feels about all of this... I don't know if Gary is partial to sockets, but we both agree that simplicity matters. Again, I think we should continue to develop the sockets API until it is clear that a CORBA API is better. > Yeah, I guess so :-) That is why it is good to have lots of people on > a project, so you can have lots of ways to looking at problems. Go > open source development model! Woohoo! Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri May 5 15:09:35 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script Message-ID: <200005051911.PAA141066@archa11.cc.uga.edu> [...snip...my description of SWIGing the UI* classes of Overflow in the dl...] > Sounds fine! I'm not sure I understand the modifications you want to make, > though... could you explain more? Well, I don't really know if I'll have to make any modifications. Let me start working on it and see how things fit and we can discuss more... I just wanted to make the goal "a little bit of code rewriting" so then we could be excited if we had "no code rewriting." :-) > Here's another precision I'd like to make > about the way Overflow works... I'm going to compare 3 classes: Node, UINode, > and GUINode > > Node is the (abstract) base class for all operations (including the Network > class; a Network is a Node) if a certain node in the "program" is included > twice > (because of subnet inclusion) then, there are two instances of these Nodes. > > UINode is not an abstract class and can represent any node type in the > "program". It is used to save/load XML and has a "build" method, which > returns a > Node (actually an object of a class that derives from Node). Cool, this makes a lot of sense, since the dl is set up in a very similar way, except for the fact that I don't have an abstract node class. In the case of the dl, we have a non-abstract locus class, from which all other classes derive, including workspaces (the equivalent of your network). I also have the basic locus class derive from what is kind of a "persistence" class. Right now this class defines stuff for directly interacting with the file describing a locus (ie. loading it into DOM, and even actually getting the location of it), and then derived classes implement functions like create (like your "build") and remove that interact with this specific persistant representation. I forget exactly where I read about this and ripped it off from, but the idea is that we could change the underlying storing mechanism without totally having to completely gut and revamp the code. > GUINode derives from UINode and adds some Gnome functionalities. If I were to > write a KDE GUI, I'd simply create a KUINode that derives from UINode. Loci doesn't have this formal inheritence of both the ui class and the dl class from an abstract base class. The reason for this is the goal of making ui's implementatble in any language. When the ui and dl were together, This kind of mechanism was starting to creep in (until I forcibly drug them apart). Personally, I like the goal of multiple UIs in different langauges, and not just different toolkits. This way maybe one day I'll be able to run Piper on my Mac with a java ui or something :-) > Also, I think using swig is a good idea, as I'd > like to be able to use the original Overflow without python. Great! I'll start taking a look at it and give updates as it goes along. As I said my goal is to not mess with your code, so you definately shouldn't have to give up the stand alone operation of Overflow. Of course, I'm positive that eventually you will be drawn into the wonderful world of python and won't want Overflow to run without python wrapping it :-) Brad From bizzaro at geoserve.net Fri May 5 15:24:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] about XML References: <200005051853.OAA28528@archa10.cc.uga.edu> <39131B4A.B4924B51@hermes.usherb.ca> Message-ID: <39131FE7.3F6F9554@geoserve.net> Jean-Marc Valin wrote: > > I think there's something we need to make clear about XML. The only reason I was > using XML in Overflow is that I didn't want to spend too much time writing a > parser. I'm storing all the info as objects (UINode, UINetwork, ...) and use the > XML only for load/save (I use lib-xml as a black box and don't care how it's > saved). This is why I don't understand everything that's going on on this list > about XML... am I missing something? We were planning on using XML for permanent storage of information about where nodes are, what nodes are connected to what, etc. This is the "pseudo-distributed-filesystem" I mentioned before. Brad, while we're on this topic, perhaps XML writing should be done only when the user chooses to "save" a network. You could use DOM in-between saves to speed things up. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri May 5 15:30:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] about XML References: <200005051853.OAA28528@archa10.cc.uga.edu> <39131B4A.B4924B51@hermes.usherb.ca> <39131FE7.3F6F9554@geoserve.net> Message-ID: <3913214F.404FF43A@geoserve.net> "J.W. Bizzaro" wrote: > > Brad, while we're on this topic, perhaps XML writing should be done only when > the user chooses to "save" a network. You could use DOM in-between saves to > speed things up. You may recall from my earlier message about the "pseudo-distributed-filesystem" that we want to treat networks (of the BL and PL kind) something like a word-processing document: The user can choose "new", "open", "save", "save as", and "close" for any network. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri May 5 15:20:57 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection Message-ID: <200005051923.PAA61402@archa11.cc.uga.edu> > I think node selection is not a permanent change to any network and should > probably NOT be added to permanent XML storage. As I mentioned before, you > may want to make a separate, temporary data structure to hold the ID's of > selected nodes. Agreed. It won't be that hard because I already have this in place (to store passwords in memory). I was just mentioning how it contrasts with the beautiful model I'd tried to set up :-) > I don't think we should consider scrapping it until a CORBA API is in place > and proves to be better. 100% agreed. > So, let me modify the rule a bit: I think the DL SHOULD save information such > as icons, XY positions, widget descriptions/libraries in PARALLEL to the > common network information. > > Brad, how can the DL manage this? I mentioned a while ago that if the DL > kept > XML info in the filesystem, such as... > > ls.xml > > then the DL could keep UI stuff along side it, such as... > > ls.xy > ls.widget > ls.icon > > But, I guess some things have changed recently. How would you do something > like this now? I would like to store everything in one format only, and I want to stick with xml since we already have that. I don't see any reason why we can't have an xml tag like: and if the ui doesn't have widgets (ie. a text based ui) it just ignores these tags (assuming it is using a script saved on a gui based ui). I think one thing we don't need is more files being introduced into the filesystem and would like to keep everything describing a node in a single file of xml. If we introduce the idea of xml that can be parsed into a widget by the ui, then this should be in a separate file, but I want to keep simple info like widgets and x/y position together. *Most* uis that are implemented will want this type of info. > As for Overflow, Jean-Marc said he recognized that node positions really > shouldn't be included with the network XML. But my question is: Does > Overflow > REQUIRE the node positions in the XML? If Piper sends Overflow/PL a network > description that does not include node positions, will Overflow crash? It requires it in the current api, but I'll just pass x=0 and y=0 to make Overflow functions happy, since the bl won't be needing this information anyways. I want to keep Jean-Marc's interface intact so Overflow still works standalone, but we can incorporate his code, which is why we'll have these extra attributes that aren't used, in the xml passed to the bl. Brad From chapmanb at arches.uga.edu Fri May 5 15:30:07 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] permanent vs. temporary storage WAS about XML Message-ID: <200005051932.PAA27112@archa12.cc.uga.edu> > "J.W. Bizzaro" wrote: >> >> Brad, while we're on this topic, perhaps XML writing should be done only > when >> the user chooses to "save" a network. You could use DOM in-between saves > to >> speed things up. > > You may recall from my earlier message about the > "pseudo-distributed-filesystem" that we want to treat networks (of the BL and > PL kind) something like a word-processing document: The user can choose > "new", > "open", "save", "save as", and "close" for any network. I understand your point, and it definately would be possible to keep everything in dom and save it when the user chooses save, but there are 3 problems: 1. XML in dom format can't be parsed using a standard parser, and so we always have to use the dom_iterator to iterate through xml. This method is *much* slower than parsing with a parser. So I don't think we would see a big speed up in everything was in dom. 2. There would be no "crash" recovery since everything would be lost if Piper crashes (since nothing is stored in the filesystem). 3. We would have *a lot* of information in memory all of the time, which I don't think would scale well to complex applications/scripts with lots of nodes. This could also lead to crazy confusing data structures in the code. In addition, this would make debugging the thing a serious problem. Right now you can often pick up problems by browsing the temporarily stored xml, in this case you would have to dumb all kinds of xml to a file and sort through it. Brad From jean-marc.valin at hermes.usherb.ca Fri May 5 16:25:24 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection References: <200005051815.OAA232370@archa11.cc.uga.edu> <39131E4C.111040F5@geoserve.net> Message-ID: <39132E34.B1D96E48@hermes.usherb.ca> > As for Overflow, Jean-Marc said he recognized that node positions really > shouldn't be included with the network XML. But my question is: Does Overflow > REQUIRE the node positions in the XML? If Piper sends Overflow/PL a network > description that does not include node positions, will Overflow crash? Currenty, yes. This is only because of the xmlGetProp call, all the rest doesn't care. I can say it's going to be trivial to have the UINode class ignore the xy pos of the node. Jean-Marc From jean-marc.valin at hermes.usherb.ca Fri May 5 16:55:19 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] permanent vs. temporary storage WAS about XML References: <200005051932.PAA27112@archa12.cc.uga.edu> Message-ID: <39133537.776B5120@hermes.usherb.ca> > I understand your point, and it definately would be possible to keep > everything in dom and save it when the user chooses save, but there > are 3 problems: > > 1. XML in dom format can't be parsed using a standard parser, and so > we always have to use the dom_iterator to iterate through xml. This > method is *much* slower than parsing with a parser. So I don't think > we would see a big speed up in everything was in dom. > > 2. There would be no "crash" recovery since everything would be lost > if Piper crashes (since nothing is stored in the filesystem). > > 3. We would have *a lot* of information in memory all of the time, > which I don't think would scale well to complex applications/scripts > with lots of nodes. This could also lead to crazy confusing data > structures in the code. In addition, this would make debugging the > thing a serious problem. Right now you can often pick up problems by > browsing the temporarily stored xml, in this case you would have to > dumb all kinds of xml to a file and sort through it. I still prefer seeing XML as a dumb object serializer, as it is in overflow. We can use it to exchange data or to save it (we can have autosave for crash recovery), but I wouldn't like the internals of the system to depend on XML. Jean-Marc From bizzaro at geoserve.net Fri May 5 17:13:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection References: <200005051815.OAA232370@archa11.cc.uga.edu> <39131E4C.111040F5@geoserve.net> <39132E34.B1D96E48@hermes.usherb.ca> Message-ID: <3913398C.16247B10@geoserve.net> Jean-Marc Valin wrote: > > > As for Overflow, Jean-Marc said he recognized that node positions really > > shouldn't be included with the network XML. But my question is: Does Overflow > > REQUIRE the node positions in the XML? If Piper sends Overflow/PL a network > > description that does not include node positions, will Overflow crash? > > Currenty, yes. This is only because of the xmlGetProp call, all the rest doesn't > care. I can say it's going to be trivial to have the UINode class ignore the xy > pos of the node. If you could make that one change it would be great. So, Overflow will not care if x and y fail to show up in the network description. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri May 5 17:17:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] permanent vs. temporary storage WAS about XML References: <200005051932.PAA27112@archa12.cc.uga.edu> Message-ID: <39133A7B.9E58B84A@geoserve.net> Brad Chapman wrote: > > 1. XML in dom format can't be parsed using a standard parser, and so > we always have to use the dom_iterator to iterate through xml. This > method is *much* slower than parsing with a parser. So I don't think > we would see a big speed up in everything was in dom. Well, you know more about DOM. I'll leave it up to you. I was just suggesting the use of some sort of temporary storage until "save" is selected by the user. > 2. There would be no "crash" recovery since everything would be lost > if Piper crashes (since nothing is stored in the filesystem). Between saves, even a word processor would loose info. > 3. We would have *a lot* of information in memory all of the time, > which I don't think would scale well to complex applications/scripts > with lots of nodes. This could also lead to crazy confusing data > structures in the code. In addition, this would make debugging the > thing a serious problem. Right now you can often pick up problems by > browsing the temporarily stored xml, in this case you would have to > dumb all kinds of xml to a file and sort through it. That's why I like XML :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri May 5 17:18:55 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] permanent vs. temporary storage WAS about XML References: <200005051932.PAA27112@archa12.cc.uga.edu> <39133537.776B5120@hermes.usherb.ca> Message-ID: <39133ABF.FAFA456D@geoserve.net> Jean-Marc Valin wrote: > > I still prefer seeing XML as a dumb object serializer, as it is in overflow. We > can use it to exchange data or to save it (we can have autosave for crash > recovery), but I wouldn't like the internals of the system to depend on XML. Autosave is a good idea. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri May 5 20:40:02 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] UI/DL and selection References: <200005051923.PAA61402@archa11.cc.uga.edu> Message-ID: <391369E2.19DF9C9D@geoserve.net> Brad Chapman wrote: > > I would like to store everything in one format only, and I want to > stick with xml since we already have that. I don't see any reason why > we can't have an xml tag like: > > > > and if the ui doesn't have widgets (ie. a text based ui) it just > ignores these tags (assuming it is using a script saved on a gui based > ui). > I think one thing we don't need is more files being introduced > into the filesystem and would like to keep everything describing a > node in a single file of xml. If we introduce the idea of xml that can > be parsed into a widget by the ui, then this should be in a separate > file, but I want to keep simple info like widgets and x/y position > together. *Most* uis that are implemented will want this type of info. Okay, I agree. It does seem simplest to put this "meta-data XML" in with the network XML. And here I am arguing against mixing content and presentation :-P But to help the DL identify which tag belongs to which UI (or even layer), shouldn't the UI's name be in there? Example: Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri May 5 20:47:26 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005051756.NAA197662@archa12.cc.uga.edu> Message-ID: <39136B9E.E0D0E1B3@geoserve.net> Brad Chapman wrote: > > The > structure of your classes is very similar to what I have mapped out > for trying to do the same thing (from scratch) in the dl (you can take > a look at the class design I sketched out in the loci module in > middle/library/modules/bl/blrepresentation.py--and no, I swear I > didn't rip my design off from you!). Great minds think alike. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat May 6 18:39:57 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> Message-ID: <39149F3D.E1D0FF4A@geoserve.net> Brad Chapman wrote: > > I need to talk some time to clean this documentation up and make > it more readible (I'll redo it in latex or something) Have you tried LyX? Super program. It'd be great if we could all agree to use that. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Sat May 6 19:31:16 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> <39149F3D.E1D0FF4A@geoserve.net> Message-ID: <3914AB44.6C4A061@hermes.usherb.ca> > > I need to talk some time to clean this documentation up and make > > it more readible (I'll redo it in latex or something) > > Have you tried LyX? Super program. It'd be great if we could all agree to > use that. I use KLyX (KDE version of LyX), which has a better UI. I think the use the same format, though. I agree with LyX/KLyX. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Sat May 6 20:27:40 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script Message-ID: <200005070029.UAA217292@archa12.cc.uga.edu> > Brad Chapman wrote: >> I need to talk some time to clean this documentation up and make >> it more readible (I'll redo it in latex or something) Jeff wrote: > Have you tried LyX? Super program. It'd be great if we could all agree to > use that. I tried it out, although I don't dig it that much because I'm a dork and prefer working directly with LaTeX in a plain ol' text editor. This shouldn't be a big deal, tho, since LyX imports and exports LaTeX, right? I've been using HeVeA (http://para.inria.fr/~maranget/he vea/index.html) to convert LaTeX to HTML and plain text and TeX itself to convert to any other imaginable format. So I'll definately jump on the LaTeX bandwagon (although without the fancy graphical front end :-). Brad From bizzaro at geoserve.net Sat May 6 21:05:17 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005070029.UAA217292@archa12.cc.uga.edu> Message-ID: <3914C14D.674CCBB8@geoserve.net> Brad Chapman wrote: > > I tried it out, although I don't dig it that much because I'm a dork > and prefer working directly with LaTeX in a plain ol' text editor. > This shouldn't be a big deal, tho, since LyX imports and exports > LaTeX, right? Right. LyX exports PS and HTML too. > I've been using HeVeA (http://para.inria.fr/~maranget/he > vea/index.html) to convert LaTeX to HTML and plain text and TeX itself > to convert to any other imaginable format. What is the difference between LaTeX and TeX? > So I'll definately jump on > the LaTeX bandwagon (although without the fancy graphical front end > :-). Gary and David were starting (very preliminary) to document Loci with DocBook. Can someone explain why DocBook might or might not be better than LyX/LaTeX? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat May 6 21:08:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] executing a network script References: <200005042048.QAA178582@archa12.cc.uga.edu> <39149F3D.E1D0FF4A@geoserve.net> <3914AB44.6C4A061@hermes.usherb.ca> Message-ID: <3914C20F.23585957@geoserve.net> Jean-Marc Valin wrote: > > I use KLyX (KDE version of LyX), which has a better UI. I think the use the same > format, though. I agree with LyX/KLyX. Yeah, from what I read, KLyX is just LyX with Qt widgets. The roadmap for LyX (in case you're interested) says that they will make LyX GUI-independent, so Gtk, Qt and XForms can be used in the future (kind of like Piper, eh?). Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Tue May 9 07:45:27 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script Message-ID: <200005091147.HAA77790@archa11.cc.uga.edu> Sorry to be so slow in responding... dumb finals... > What is the difference between LaTeX and TeX? TeX is actually what does all of the beautiful typesetting. This was developed by Donald E. Knuth, and only contained some pretty basic macros to work with it. These macros are pretty hard core and difficult to learn, so eventually Leslie Lamport developed LaTeX, which in a more accessable set of macros to work with the underlying typesetting engine. You lose some power and flexibility using LaTeX, but it is definately made up for by being a lot easier to learn and use. I am not nearly experienced enough with it to even touch TeX yet. All I know if that the day I discovered LaTeX was the day I said goodbye to horrible horrible Microsoft Word > Gary and David were starting (very preliminary) to document Loci with > DocBook. Can someone explain why DocBook might or might not be better than > LyX/LaTeX? In my mind, LaTeX is a better choice. I think the most difficult thing about LaTeX is learning it, and getting all of the tools working on your system to generate the right kind of documentation. However, it seems like LyX helps a lot in this regard. The advantage of DocBook is that the tools are more easily installed and "standard" so it is probably easier to set up, and is also easier for other users to generate all kinds of different documentation from the raw SGML. With LaTeX you have to have all of the right packages and other stuff installed to generate ps/pdf documentation right from the original .tex source, so this is more likely to be difficult (I know that it is a problem mentioned on some of the python lists--since python uses LaTeX for documentation). However, I think we could get around this by having a non-bulky readible format (like html) included along with the .tex files, so then users who don't care about producing documentation from the source and just want something to read have the html to look at. Just my thoughts on this... Brad From chapmanb at arches.uga.edu Tue May 9 07:58:16 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] Fun with ORBs Message-ID: <200005091200.IAA187962@archa10.cc.uga.edu> [...snip...my rambling about how orbit-python won't work and other ORB choices...] Well, the official 'request for discussion' period on the new python ORB implementation for Piper has officially passed so I'm happy to announce my choice is...(drum roll please)... omniORBpy! Yay! Anyways, changes to make the Loci part o' Piper use omniORBpy will go into cvs tonight (it has been using Fnorb temporarily), so anyone with objections should speak up quickly :-) Brad From jarl at casema.net Tue May 9 07:28:52 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] Fun with ORBs & M$ Word References: <200005091200.IAA187962@archa10.cc.uga.edu> Message-ID: <3917F674.C3E5A128@casema.net> > [...snip...my rambling about how orbit-python won't work and other > ORB choices...] > > Well, the official 'request for discussion' period on the new python > ORB implementation for Piper has officially passed so I'm happy to > announce my choice is...(drum roll please)... > > omniORBpy! > > Yay! Anyways, changes to make the Loci part o' Piper use omniORBpy > will go into cvs tonight (it has been using Fnorb temporarily), so > anyone with objections should speak up quickly :-) > I dont like Latex, I'm using Mircosoft Word. Nah, go ahead Brad, have your judgement pick the best. Like I'll do with the documentation format :) I'm trying to get hold of automake e.c. and will get a mental breakdown when you people want me to learn some wierd text-formatting system.. bye, jarl From chapmanb at arches.uga.edu Tue May 9 08:58:51 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:53 2006 Subject: [Pipet Devel] Clarification on documentation stuff Message-ID: <200005091301.JAA24920@archa11.cc.uga.edu> Jarl wrote: > I dont like Latex, I'm using Mircosoft Word. > > Nah, go ahead Brad, have your judgement pick the best. Like I'll do > with the > documentation format :) > > I'm trying to get hold of automake e.c. and will get a mental breakdown > when > you people want me to learn some wierd text-formatting system.. I just wanted to clarify my LaTeX comments, since I definately think I wasn't clear on some stuff. I do not care about having "one format" or "one standard way" to do documentation for Piper. All I was (inadequately) trying to say is that LaTeX (my preferred way to do documentation) was "compatible" with LyX, which Jeff and Jean-Marc seem to like. I do not think anyone should need to learn a new system to do documentation, and everyone can use whatever they want, as long as they produce documentation :-) Just like I would *hate* to have to use Word, I would never want to make anyone who likes Word (or LyX, or whatever) use LaTeX. Besides, time spent learning LaTeX could be better spent coding on Piper :-) Brad From bizzaro at geoserve.net Tue May 9 18:10:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> Message-ID: <39188CE7.3A3933A4@geoserve.net> Brad Chapman wrote: > > Well, the official 'request for discussion' period on the new python > ORB implementation for Piper has officially passed so I'm happy to > announce my choice is...(drum roll please)... > > omniORBpy! > > Yay! Anyways, changes to make the Loci part o' Piper use omniORBpy > will go into cvs tonight (it has been using Fnorb temporarily), so > anyone with objections should speak up quickly :-) I'm happy with that decision. Perhaps I forgot to comment on this when you first posted the question, but Fnorb is incompatible with our distribution plans, if not with the LGPL itself. Fnorb restricts its free use to non-commercial systems and/or non-profit purposes. And if Fnorb is required for Piper to work, Piper would simply have the same exact restrictions. So, I'm glad you didn't choose Fnorb :-) About ORBit, a few weeks ago I may have argued to use Gnome tools merely for the sake of using Gnome tools. But, after some more thought, I believe it would be best to NOT make Piper (at its core) rely on Gnome (libraries or tools): Gnome is a DESKTOP system and Piper is NOT. Piper's UI's may or may not be used in a graphical desktop, but even if they are, they will not all be limited to Gnome (KDE or whatever may be used). At the moment, the only thing that should work closely with Gnome is the Pied (my Loci front) UI. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue May 9 18:17:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs & M$ Word References: <200005091200.IAA187962@archa10.cc.uga.edu> <3917F674.C3E5A128@casema.net> Message-ID: <39188E69.DB82AE2A@geoserve.net> Jarl van Katwijk wrote: > > I'm trying to get hold of automake e.c. and will get a mental breakdown > when you people want me to learn some wierd text-formatting system.. Have you tried LyX? There's nothing much to learn: It is a *GUI* that is actually simpler than M$ Word to use, because you don't have to worry about positioning text with spaces and carriage returns. LaTeX/TeX, on the other hand, are formatting languages/systems run from a textual shell. LyX is a front-end to LaTeX. http://www.lyx.org/ Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue May 9 18:24:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005091147.HAA77790@archa11.cc.uga.edu> Message-ID: <39189038.EA20E153@geoserve.net> Brad Chapman wrote: > > You lose some power and flexibility using LaTeX, > but it is definately made up for by being a lot easier to learn and > use. I am not nearly experienced enough with it to even touch TeX yet. Why do you think LyX wraps LaTeX rather than TeX, if TeX is the more powerful tool? LaTeX is already an abstracted UI, correct? So, why doesn't LyX work directly with TeX? > However, I think we could get around this by having a non-bulky > readible format (like html) included along with the .tex files, so > then users who don't care about producing documentation from the > source and just want something to read have the html to look at. Also, is there a different between .latex and .tex file formats? Thanks for the thoughtful reply. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue May 9 18:26:40 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Clarification on documentation stuff References: <200005091301.JAA24920@archa11.cc.uga.edu> Message-ID: <391890A0.2A93F04@geoserve.net> Brad Chapman wrote: > > Just like I would *hate* to have to use Word, I would never want > to make anyone who likes Word (or LyX, or whatever) use LaTeX. Are there any Word <-> TeX/LaTeX format converters? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Wed May 10 03:57:46 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> Message-ID: <3919167A.13B5CB61@casema.net> > > Fnorb is incompatible with our distribution plans, if not with the LGPL thinking the same thing. Must note that I already used some GPL code in the plugins of GMS, but those are seperate binairies, gms runs 100% without any of them. > > About ORBit, a few weeks ago I may have argued to use Gnome tools merely for > the sake of using Gnome tools. But, after some more thought, I believe it > would be best to NOT make Piper (at its core) rely on Gnome (libraries or > tools): Aaarg. What did you say? Thought you liked gnome as much as I did > Gnome is a DESKTOP system and Piper is NOT.\ Disagree. Gnome has desktop libraries, which can or can not be used. But gnome is much more as just a desktop layer. Checkout their http://developer.gnome.org/doc/API/api-toc.html Not making use of gnome's features will be like not using posix features of the libc, just in case we might want to port Piper to Win32. I think using 'default' unix libraries that happen to give the best should be used. I think gnome (+all other emerging library dependancies) give too much functionality to drop it. But ok, maybe when everybody will hate my gnome advocacy, but what if we would drop gnome, what will than be the basis of Piper? Drop glib? Or even gcc maybe? bye, jarl From jarl at casema.net Wed May 10 04:03:35 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Clarification on documentation stuff References: <200005091301.JAA24920@archa11.cc.uga.edu> <391890A0.2A93F04@geoserve.net> Message-ID: <391917D7.903A1284@casema.net> > > Just like I would *hate* to have to use Word, I would never want > > to make anyone who likes Word (or LyX, or whatever) use LaTeX. > > Are there any Word <-> TeX/LaTeX format converters? > Uhh, just in case to save somebody the trouble: I'm happy with any kinda document, but dont expect me to produce anything else as txt or html. From bizzaro at geoserve.net Tue May 9 19:49:27 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> Message-ID: <3918A407.D8F3FAC7@geoserve.net> jarl van katwijk wrote: > > Aaarg. What did you say? Thought you liked gnome as much as I did > > > Gnome is a DESKTOP system and Piper is NOT.\ > > Disagree. Gnome has desktop libraries, which can or can not be used. But gnome > is much more as just a desktop layer. > Checkout their http://developer.gnome.org/doc/API/api-toc.html > > Not making use of gnome's features will be like not using posix features of the > libc, just in case we might want to port Piper to Win32. I think using > 'default' unix libraries that happen to give the best should be used. I think > gnome (+all other emerging library dependancies) give too much functionality to > drop it. But ok, maybe when everybody will hate my gnome advocacy, but what if > we would drop gnome, what will than be the basis of Piper? Drop glib? Or even > gcc maybe? Wait a minute, Jarl! :-) (1) I'm sure I like Gnome as much as you do. Anyone on the Loci list can attest to my devotion to Gnome and the GNU ideology. I will always choose a GNU solution whenever one exists. (2) The primary GOAL of Gnome is build a desktop system based on GNU libraries and tools. If Gnome seems to be more than a desktop, it's because many new libraries and tools had to be developed to meet that goal. Would ORBit exist without Gnome? (3) I am trying to make a distinction between Piper and the DESKTOP. Piper is not trying to make a desktop (one of the UI's might, but it is not the goal of the project). Therefore, it would be unwise to create a dependency on a DESKTOP system without regard for what libraries and tools are BEST. (Maybe omniORB is best.) (4) Even Gnome and Gtk will not create a dependency on one system. Gnome developers are constantly correcting people who call Gnome a "Linux Desktop", because Gnome can run on almost every other Unix. And Gtk runs on Windows! This is why they have developed their own libraries and tools: independence. (5) I never said "Drop Gnome". I said we shouldn't try to create a dependency on any one DESKTOP system, because Piper is not about the DESKTOP. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue May 9 20:33:47 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005091147.HAA77790@archa11.cc.uga.edu> Message-ID: <3918AE6B.98021C1B@hermes.usherb.ca> > In my mind, LaTeX is a better choice. I think the most difficult > thing about LaTeX is learning it, and getting all of the tools working > on your system to generate the right kind of documentation. However, > it seems like LyX helps a lot in this regard. I think LyX is the easiest word processor (although technically, they say it's not a word processor), though LaTeX is more standard. The best would be to be able to use both, as Brad suggested, but I see one problem. You can export from LyX to LaTeX, but if you modify the LaTeX file, you can't put it back in the LyX document. There's a LaTeX to LyX converter (called ReLyX), but I don't think we should rely on it too much (it must be fault-free). Any thought on this? Jean-Marc From gvd at redpoll.pharmacy.ualberta.ca Tue May 9 21:24:01 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005091147.HAA77790@archa11.cc.uga.edu> Message-ID: <3918BA31.BF18CE04@redpoll.pharmacy.ualberta.ca> Brad Chapman wrote: > > Gary and David were starting (very preliminary) to document Loci with > > DocBook. Can someone explain why DocBook might or might not be > better than > > LyX/LaTeX? > I don't have the experience with LaTeX to say which way is better. We chose to document loci with DocBook, because it is oriented for technical document writing, plus you can generate many different types of output from the SGML (or XML, on the way BTW) source code. There is a strong push from the GNOME crowd to build a structered document editor that supports DocBook (GNOME itself supports DocBook), and we just felt at the time that DocBook is a better solution. I still feel that way. Like LaTeX, the biggest problem is installing the tools (from Cygnus) and learning all the tags. Can someone tell me why LaTeX is better than DocBook? Once I have the server running (very close now), I will refocus my efforts on writing documentation, so I would like some consensus on which environment we choose to write our documentation, as I feel it is important to preserve the style, and reuse the content of the documentation that we create. Regards, g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From bizzaro at geoserve.net Tue May 9 23:06:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005091147.HAA77790@archa11.cc.uga.edu> <3918AE6B.98021C1B@hermes.usherb.ca> Message-ID: <3918D237.55295DAE@geoserve.net> Jean-Marc Valin wrote: > > I think LyX is the easiest word processor (although technically, they say it's > not a word processor), though LaTeX is more standard. The best would be to be > able to use both, as Brad suggested, but I see one problem. You can export from > LyX to LaTeX, but if you modify the LaTeX file, you can't put it back in the LyX > document. There's a LaTeX to LyX converter (called ReLyX), but I don't think we > should rely on it too much (it must be fault-free). Any thought on this? ReLyX comes standard with the latest version of LyX and is how LaTeX "imports" are handled. I don't know how well it works. (BTW, LyX was considering using LaTeX as its file format - no import/export and no .lyx files.) I am in the same boat with Jarl regarding command-based text formatting systems like LaTeX/TeX and DocBook: They would take too long for me to learn, and I have many other things to do :-) So, I would prefer something with a GUI front like LyX. Wasn't someone working on a GUI front for DocBook? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue May 9 23:19:25 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005091147.HAA77790@archa11.cc.uga.edu> <3918BA31.BF18CE04@redpoll.pharmacy.ualberta.ca> Message-ID: <3918D53D.BC020AC9@geoserve.net> Gary Van Domselaar wrote: > > Once I have the server running (very close now), I will refocus my > efforts on writing documentation, so I would like some consensus on > which environment we choose to write our documentation, as I feel it is > important to preserve the style, and reuse the content of the > documentation that we create. It's nice knowing that someone will manage the final production of documentation :-) To make it easier for Gary and his team of documentors, we do need to come to some concensus about the format that our writings will come in. We can work with different interfaces, providing there is one GOOD format that we can all export things to. I think LaTeX is a good middle-ground. Jarl, I just checked AbiWord, and it does output LaTeX files. AbiWord works a LOT like M$ Word: http://www.abisource.com/ There's also Rich-Text (RTF). But LyX doesn't output RTF, and I don't know of a LyX/LaTeX <-> RTF converter. It'd probably be best to find something where an extra conversion step is not needed. (I haven't found one word proc that outputs DocBook, BTW.) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue May 9 23:29:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] [Fwd: [Pipet Devel] Docbook online] Message-ID: <3918D7A2.AD94B831@geoserve.net> I was looking through the Loci archive for messages about DocBook, and I stumbled across this message from Konrad Hinsen. I'm not trying to start a flame war against DocBook, just trying to be objective. Jeff -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: Re: [Pipet Devel] Docbook online Date: Fri, 19 Nov 1999 10:37:51 +0100 Size: 2431 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000510/b1f27ecb/attachment.mht From bizzaro at geoserve.net Tue May 9 23:37:04 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] conglomerate Message-ID: <3918D960.3C8D1486@geoserve.net> This is what I was looking for: http://www.conglomerate.org/ Conglomerate seems nice. I don't think it outputs DocBook SGML but something like it. It does output LaTeX. Has anyone here actually used it? Jeff From bizzaro at geoserve.net Tue May 9 23:46:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> Message-ID: <3918DBB0.78482820@geoserve.net> "J.W. Bizzaro" wrote: > > (5) I never said "Drop Gnome". I said we shouldn't try to create a dependency > on any one DESKTOP system, because Piper is not about the DESKTOP. Let's simply use the best GNU libraries and tools that are available, whatever they belong to. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Wed May 10 00:20:29 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> <3918DBB0.78482820@geoserve.net> Message-ID: <3918E38D.E2D8D1A2@hermes.usherb.ca> > > (5) I never said "Drop Gnome". I said we shouldn't try to create a dependency > > on any one DESKTOP system, because Piper is not about the DESKTOP. > > Let's simply use the best GNU libraries and tools that are available, whatever > they belong to. I guess this comes down to having the minimum library dependencies for each part of the project. We should separate parts that require gnome from parts that doesn't (as for the UI* vs GUI* classes in Overflow). I like gnome, but I don't want to use it for parts that don't require it (eg. libraries that could be used in a command-line tool). I don't want to reinvent the wheel (i.e. write code instead of using an available library), but I don't want to add a dependency for just a trivial function. I guess there's nothing really new in what I'm saying... Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Wed May 10 02:51:09 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> <3918DBB0.78482820@geoserve.net> <3918E38D.E2D8D1A2@hermes.usherb.ca> Message-ID: <391906DD.42B9F505@casema.net> > > I guess this comes down to having the minimum library dependencies for each part > of the project. We should separate parts that require gnome from parts that > doesn't (as for the UI* vs GUI* classes in Overflow). I like gnome, but I don't > want to use it for parts that don't require it (eg. libraries that could be used > in a command-line tool). Has anyone of you people ever used the NON-gui features of Gnome? I'm not just promoting gnome because it's the Right thing, but because of it's richness. Or maybe is this only usefull when coding in C? Anyone on this? Which parts of Gnome can be used by C++ or Python? bye, jarl From jarl at casema.net Wed May 10 02:59:51 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005091147.HAA77790@archa11.cc.uga.edu> <3918BA31.BF18CE04@redpoll.pharmacy.ualberta.ca> <3918D53D.BC020AC9@geoserve.net> Message-ID: <391908E7.377228C1@casema.net> > I think LaTeX is a good middle-ground. Jarl, I just checked AbiWord, and it > does output LaTeX files. AbiWord works a LOT like M$ Word: > > http://www.abisource.com/ > > There's also Rich-Text (RTF). But LyX doesn't output RTF, and I don't know of > a LyX/LaTeX <-> RTF converter. > Hehe, when I said I liked Word I meant I like GUI-ish simple SWTG editors. In fact I'm using AbiWord a long time... I don't even have M$ Word. This editor is sweet: simple and all I need. From chapmanb at arches.uga.edu Wed May 10 08:33:49 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX v. Docbook Message-ID: <200005101235.IAA78540@archa11.cc.uga.edu> Jeff wrote: >> > Gary and David were starting (very preliminary) to document Loci with >> > DocBook. Can someone explain why DocBook might or might not be >> better than >> > LyX/LaTeX? Gary wrote: > Can someone tell me why LaTeX is better than > DocBook? I don't think we can really make a good comparison between LaTeX and DocBook. They can be processed to produce nice output in lots of different formats, and they both can be used to get quality technical documentation. I think the most important question is, as I said before, that people use what they feel most confortable with. 90% of the time a particular piece of documentation will be written primarily by one person, and I just don't think it makes sense for it to take 3 times as long to do the documentation because you have to struggle through learning DocBook markup or LaTeX macros. On the other extreme I don't think it would be fair for someone to write documentation in some random format and then hand it to Gary and expect him to have 100,000 converters to process stuff around and spend hours hand editing everything. So what I'm trying to say is that I think it will be very difficult to meet the lofty goal of having everyone do documentation in one format. Instead could we settle on the less lofty goal of everyone using whatever they please, but then being responsible for converting it to a format that Gary will like and can use without too much trouble (hopefully this format won't be DocBook, tho :-). If two or more people are working on a specific piece of documentation that has to work on all their systems, then they can hash out a format for it. This puts the responsibility of conversion in the hands of individual people and lets us avoid having an officially mandated system. How does this plan sound? Down with a totalitarian documentation scheme! Long live individual responsibility! Brad From chapmanb at arches.uga.edu Wed May 10 08:47:02 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script Message-ID: <200005101249.IAA33156@archa11.cc.uga.edu> Jeff wrote: > Why do you think LyX wraps LaTeX rather than TeX, if TeX is the more powerful > tool? LaTeX is already an abstracted UI, correct? So, why doesn't LyX work > directly with TeX? Well, LaTeX isn't a UI, it is just a set of macros to make things easier. For instance, in TeX you might have to do some crazy thing like: \ncn{\!}\index{"!@{\ntt\bslchar\qcbang}}} to get a particular set of text typeset a certain way, while LaTeX just takes the most useful of these commands and makes them into macros like: \section{} What you lose is that there are lots of small changes you could do in TeX to specifically alter the typeset output, while you are stuck with the way the macro does it in LaTeX. However, most of these changes are probably so subtle that only an expert typesetter would notice the differences, so for someone like me, LaTeX has plenty of control. I would imagine that LyX doesn't work directly with TeX because they would just end up redifining the macros all over again in a similar way to LaTeX. Why bother to do this when you can use an exisiting popular system? Sure, if they started from TeX they would probably make things a little different, but then you would spend a ton of time, and also lose all of the nice packages that have already been written to use with LaTeX. Plus LaTeX is sooooo damn nice :-) > Also, is there a different between .latex and .tex file formats? I think that both LaTeX and TeX always just use a .tex extension. Since the underlying typsetting program in TeX in both cases, the program just has to know whether it needs to expand LaTeX macros or not. It is actually incredibly easy to tell the difference between documents and plain TeX and LaTeX so I don't think having different extensions is really needed. > Are there any Word <-> TeX/LaTeX format converters? But of course -> http://www.kfa-juelich.de/isr/1/texconv/texcnv.html. Brad From chapmanb at arches.uga.edu Wed May 10 09:02:46 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Why Gnome is sooooo damn good WAS Fun with ORBs Message-ID: <200005101304.JAA115612@archa12.cc.uga.edu> > Has anyone of you people ever used the NON-gui features of Gnome? I'm not > just > promoting gnome because it's the Right thing, but because of it's richness. > Or maybe > is this only usefull when coding in C? I would imagine that a lot of the usefulness of gnome is lost if you aren't programming in C. I think the only point Jean-Marc was trying to make in his original comment was that we should just try to avoid generating dependencies "if possible." I think if you find the gnome libs nicer to work with then other options, then it is all you. I think the problem is that in the past we have tried to use Gnome tools "just because" they are Gnome, like ORBit with python for instance :-) Instead, we should just pick the best option for the programmer based on more objective criteria :-) > Anyone on this? Which parts of Gnome can be used by C++ or Python? In python all of the stuff that gnome libraries offer, like threading, internet stuff, option parsing, regex, etc. comes in the standard library. This puts the burden of porting this code to different systems in the hands of the python community as a whole, instead of just on an individual developer with a program. So if python is ported to a platform, all of these library options will be available there. So my point is that I don't see why anyone would want to use these gnome tools with python, since the functionality already exists in the standard library. Brad From chapmanb at arches.uga.edu Wed May 10 09:58:08 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Installation + Directory clean-up Message-ID: <200005101400.KAA151202@archa12.cc.uga.edu> Hello o' great ones: After I finish and commit the changes to make the python stuff use omniORB, I was going to start work on wrapping Overflow's non-GUI UI code into the dl. What this means is that we are now going to need some formal means to install the Loci part of Piper, since we'll have to compile the extensions and C++ code and all of that. What I'd like to propose is that we use Distutils to do this installation (http://www.python.org/sigs/distutils-sig/). Although Distutils will currently require an extra download and install, it is the up-and-coming official python installation tool, and will be included standard in python 1.6. I have used it for biopython and also for XDBM python stuff, and it is quite smooth. *Much* less horrible then autoconf, and it generates tarballs and, eventually, ready to run "built" distributions. It's pretty darn cool. The other options besides this are: 1. Writing our own "installer" program to compile stuff and put it in the right place. 2. There is a version of autoconf/automake that can be used for python. Although it has been submitted to athe autoconf/make people (a year ago, I guess) it is not included with these tools, so this would require that we distribute this along with the program. Any thoughts on this from anyone? Also, I think we should take this chance to narrow the Loci directory structure to not be so deep and expansive. It is going to be a pain to install all of this, and plus I think it is a little too deep. What I'd like to do is: 1. Remove the 'library' step in the directory structure, since this seems redundant with modules (we can pick whichever people like better). I'd like to have something for the front (for example) like: front console web gnome config pixmaps modules So this will make things less deep and a little more understandable, IMO. 2. Cut the stuff which is supposed to hold code out of the 'back.' The functionality that was supposed to be here is now in GMS, so we don't need the library/modules directories here. How does this sound to people? Any thoughts? Brad From jean-marc.valin at hermes.usherb.ca Wed May 10 11:30:39 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> <3918DBB0.78482820@geoserve.net> <3918E38D.E2D8D1A2@hermes.usherb.ca> <391906DD.42B9F505@casema.net> Message-ID: <3919809F.BCB7D37C@hermes.usherb.ca> > Has anyone of you people ever used the NON-gui features of Gnome? I'm not just > promoting gnome because it's the Right thing, but because of it's richness. Or maybe > is this only usefull when coding in C? > > Anyone on this? Which parts of Gnome can be used by C++ or Python? We could probably use gnome-print and gnome-conf, but that would be for a GUI part, so it wouldn't add dependencies. However, I strongly suggest not to use glib, as must of what it contains (linked lists, ...) is already available in the STL, which is cleaner. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Wed May 10 21:39:09 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX v. Docbook References: <200005101235.IAA78540@archa11.cc.uga.edu> Message-ID: <391A0F3D.C37C941B@casema.net> > How does this plan sound? Down with a totalitarian documentation > scheme! Long live individual responsibility! I found this editor on http://localhost and it's the best by far, I think we all should use it... From gvd at penguin.pharmacy.ualberta.ca Wed May 10 11:48:02 2000 From: gvd at penguin.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX v. Docbook In-Reply-To: <391A0F3D.C37C941B@casema.net> Message-ID: On Wed, 10 May 2000, jarl van katwijk wrote: > > How does this plan sound? Down with a totalitarian documentation > > scheme! Long live individual responsibility! > > I found this editor on http://localhost and it's the best by far, I think we all > > should use it... jarl, did you mess up your url? Or am I just missing the joke? :-) g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From jarl at casema.net Thu May 11 03:01:01 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> <3918DBB0.78482820@geoserve.net> <3918E38D.E2D8D1A2@hermes.usherb.ca> <391906DD.42B9F505@casema.net> <3919809F.BCB7D37C@hermes.usherb.ca> Message-ID: <391A5AAD.F6432544@casema.net> > > We could probably use gnome-print and gnome-conf, but that would be for a GUI > part, so it wouldn't add dependencies. However, I strongly suggest not to use > glib, as must of what it contains (linked lists, ...) is already available in > the STL, which is cleaner. > STL = glibc? I'm a bit confused when you say something is cleaner as glib, because I've seen nothing as clean, portable and fast as glib. bye, jarl From jarl at casema.net Thu May 11 03:03:29 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] LaTeX v. Docbook References: Message-ID: <391A5B40.B8EBF368@casema.net> > > > > How does this plan sound? Down with a totalitarian documentation > > > scheme! Long live individual responsibility! > > > > I found this editor on http://localhost and it's the best by far, I think we all > > > > should use it... > > jarl, > > did you mess up your url? > > Or am I just missing the joke? :-) > You are :) I'm saying we all should use the tool we've been using so far. Only need to take into account we should produce some readable format so other people can read the docu's. bye, jarl From jean-marc.valin at hermes.usherb.ca Thu May 11 08:14:02 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:54 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> <3918DBB0.78482820@geoserve.net> <3918E38D.E2D8D1A2@hermes.usherb.ca> <391906DD.42B9F505@casema.net> <3919809F.BCB7D37C@hermes.usherb.ca> <391A5AAD.F6432544@casema.net> Message-ID: <391AA40A.BE571CC0@hermes.usherb.ca> Jarl van Katwijk a ?crit : > > > > > We could probably use gnome-print and gnome-conf, but that would be for a GUI > > part, so it wouldn't add dependencies. However, I strongly suggest not to use > > glib, as must of what it contains (linked lists, ...) is already available in > > the STL, which is cleaner. > > > > STL = glibc? > > I'm a bit confused when you say something is cleaner as glib, because I've seen nothing glib != glibc glib = the gnu lib under gtk glibc = the gnu C library And the STL is the C++ standard library and isn't part of either, but it ships with gcc though. Actually, you cannot have an ANSI C++ compiler without the STL. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Thu May 11 07:46:39 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Fun with ORBs References: <200005091200.IAA187962@archa10.cc.uga.edu> <39188CE7.3A3933A4@geoserve.net> <3919167A.13B5CB61@casema.net> <3918A407.D8F3FAC7@geoserve.net> <3918DBB0.78482820@geoserve.net> <3918E38D.E2D8D1A2@hermes.usherb.ca> <391906DD.42B9F505@casema.net> <3919809F.BCB7D37C@hermes.usherb.ca> <391A5AAD.F6432544@casema.net> <391AA40A.BE571CC0@hermes.usherb.ca> Message-ID: <391A9D9F.B9F66288@casema.net> > glib != glibc > glib = the gnu lib under gtk > glibc = the gnu C library Yes, know this. > > And the STL is the C++ standard library and isn't part of either, but it ships > with gcc though. Actually, you cannot have an ANSI C++ compiler without the STL. > Ic. I'm not into C++ at all.. every time I use it it start complaining about things not being compliant by some ANSI standard. So it ssems every langauge needs their own bindings, C a lot more as the more modern languages. Not much need to have a Piper-wide library standard.. bye, jarl From bizzaro at geoserve.net Thu May 11 15:45:02 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] LaTeX etc. WAS executing a network script References: <200005101249.IAA33156@archa11.cc.uga.edu> Message-ID: <391B0DBE.4A6E2D69@geoserve.net> Brad Chapman wrote: > > For instance, in TeX you might have to do some crazy thing > like: > > \ncn{\!}\index{"!@{\ntt\bslchar\qcbang}}} Ah, so it's like Perl! Now I get it ;-) Thanks for the reply. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 11 17:45:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] LaTeX v. Docbook References: Message-ID: <391B29F1.4A569BFC@geoserve.net> Gary Van Domselaar wrote: > > > I found this editor on http://localhost and it's the best by far, I think we all > > should use it... > > did you mess up your url? > > Or am I just missing the joke? :-) This is like "Please send your comments to /dev/null" :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 11 22:22:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: <200005101400.KAA151202@archa12.cc.uga.edu> Message-ID: <391B6ACF.5E7BD1F4@geoserve.net> Brad Chapman wrote: > > After I finish and commit the changes to make the python stuff use > omniORB, I was going to start work on wrapping Overflow's non-GUI UI > code into the dl. What this means is that we are now going to need > some formal means to install the Loci part of Piper, since we'll have > to compile the extensions and C++ code and all of that. > What I'd like to propose is that we use Distutils to do this > installation (http://www.python.org/sigs/distutils-sig/). Although > Distutils will currently require an extra download and install, it is > the up-and-coming official python installation tool, and will be > included standard in python 1.6. I have used it for biopython and also > for XDBM python stuff, and it is quite smooth. *Much* less horrible > then autoconf, and it generates tarballs and, eventually, ready to run > "built" distributions. It's pretty darn cool. 2 questions: (1) Are you talking about a tool that the user will need to INSTALL Piper, or a tool that the developers will use to PACKAGE Piper? (2) What parts of Piper will be "managed" by this tool? Just the Loci stuff (UIL and DL) or all parts (including the BL and PL)? > 1. Writing our own "installer" program to compile stuff and put it in > the right place. It would be nice if the user could just type "install". > 2. There is a version of autoconf/automake that can be used for > python. Although it has been submitted to athe autoconf/make people (a > year ago, I guess) it is not included with these tools, so this would > require that we distribute this along with the program. Are you referring to James Henstridge's tools? > Also, I think we should take this chance to narrow the Loci directory > structure to not be so deep and expansive. It is going to be a pain to > install all of this, and plus I think it is a little too deep. What > I'd like to do is: > > 1. Remove the 'library' step in the directory structure, since this > seems redundant with modules (we can pick whichever people like > better). I'd like to have something for the front (for example) like: > > front > console > web > gnome > config > pixmaps > modules > > So this will make things less deep and a little more understandable, > IMO. Okay, are we merging Loci with GMS and Overflow at this point? Because I'm confused why you're referring to the "old" Loci structure, which has a "front" directory. And "front" == "UIL" (User Interface Layer) now, and it should be separated from your own DL. Correct? If you want to eliminate "library", that's fine with me. I think "widgets" should probably go into the "gnome" (I'll probably rename it "Pied" soon) directory too. > 2. Cut the stuff which is supposed to hold code out of the 'back.' > The functionality that was supposed to be here is now in GMS, so we > don't need the library/modules directories here. Yeah, that makes sense. I thought much of it would move to the DL as well. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri May 12 09:29:26 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up Message-ID: <200005121331.JAA50904@archa11.cc.uga.edu> Jeff wrote: > (1) Are you talking about a tool that the user will need to INSTALL Piper, or > a tool that the developers will use to PACKAGE Piper? You can think of Distutils as being analagous to autoconf/automake, except that it is designed for dealing with python installations and not C/C++ installations. So it is primarily a tool to make it *really* easy to install Piper, but also contains stuff to help with packaging (like a target that will generate a .tar.gz automagically). > (2) What parts of Piper will be "managed" by this tool? Just the Loci stuff > (UIL and DL) or all parts (including the BL and PL)? This is definately not a replacement for autoconf/automake, so this would just be used to manage installation of the python parts of the program. So I guess the idea is that Piper, as it stands right now, will be distributed in two "sections": 1. the pyGTK UI and the dl -> Distutils installation 2. the BL and PL (GMS and Overflow) -> autoconf/automake installation > It would be nice if the user could just type "install". Well, Distutils is close. To install everything you need to type: python setup.py install How's that? :-) [...snip...my description of autoconf/automake for python...] > Are you referring to James Henstridge's tools? Either his tools or stuff separately done by Andrew Dalke could be used for installation if we want to go the autoconf route. Either way, there will be some serious patching to autoconf and automake for Piper developers. My personal opinion is that we should go the Disutils route. This is going to be the standard way to distribute and install python programs (since it is going to be included as standard in the python 1.6). Autoconf was never really designed for python, and so I think putting it together is a big mess we don't need. It should be easy enough to tie the python Distutils build with the configure builds for the bl and pl, if we want the user to be able to type one command and get everything installed. To do this, we just need to call './configure && make && make install' after the Distutils finishes installing the python parts of the program, and this is really easy to do. [...snip...my description of my plan for a new package structure...] > Okay, are we merging Loci with GMS and Overflow at this point? Because I'm > confused why you're referring to the "old" Loci structure, which has a > "front" > directory. And "front" == "UIL" (User Interface Layer) now, and it should be > separated from your own DL. Correct? Sorry, I should have been referring to things as the ui and dl, I was just trying to use the old directory structure so it would make more sense what I was trying to say about rearranging (of course, it ended up making less sense :-). Yes, I am definately talking about making this new directory structure complient with merging with GMS and Overflow. > If you want to eliminate "library", that's fine with me. I think "widgets" > should probably go into the "gnome" (I'll probably rename it "Pied" soon) > directory too. Okay, I'm going to cut library in everything then. What I'll do is make a new directory structure on my local machine and then make a tar.gz and let people take a look at it to see what they think and we can kind of hash it out that way. I'll take the fun responsibility of merging work done in cvs in the meantime into this new directory structure. I'll get the new directory structure installing with Distutils, so everyone can look at how that works first hand. It is really smoov, so I'm sure everyone will dig it. Then once we get stuff hashed out, we can work on fixing cvs (maybe we should just import the new structure as a new module--> piper. >> 2. Cut the stuff which is supposed to hold code out of the 'back.' >> The functionality that was supposed to be here is now in GMS, so we >> don't need the library/modules directories here. > > Yeah, that makes sense. I thought much of it would move to the DL as well. Thinking about it more, I'd like to completely get rid of both 'main' and 'back'. So what would be left is the following type of structure. piper ui -> What is currently in 'front' dl -> what is currently in 'middle' piper_config.py -> What is currently in const.py. The piper configuration file. piper -> The main executable. So then during the install, we will install the piper directory with all of the libraries that make things work inside of the 'site-packages' directory, and install the piper executable in /bin (where is specified as a flag during the install (just with with autoconf)). Now that we are installing things, we will also not be able to save temporary and permanent xml files "inside of" the directory structure (since otherwise the user will have to run stuff as root to write things inside the directory structure, which is not a good thing). I'd like to suggest that we store all xml for piper inside $HOME/piper, where $HOME is the environmental variable specifying the home of the user running piper. How does this sound to people? Brad From bizzaro at geoserve.net Sat May 13 01:56:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: <200005121331.JAA50904@archa11.cc.uga.edu> Message-ID: <391CEE83.5C6DA9D3@geoserve.net> Brad Chapman wrote: > > This is definately not a replacement for autoconf/automake, so this > would just be used to manage installation of the python parts of the > program. So I guess the idea is that Piper, as it stands right now, > will be distributed in two "sections": > > 1. the pyGTK UI and the dl -> Distutils installation Build-Time System (BTS) BTW, what about non-Python UI's? > 2. the BL and PL (GMS and Overflow) -> autoconf/automake installation and Run-Time System (RTS) > > It would be nice if the user could just type "install". > > Well, Distutils is close. To install everything you need to type: > > python setup.py install > > How's that? :-) Pretty simple :-) > It should be easy enough to > tie the python Distutils build with the configure builds for the bl > and pl, if we want the user to be able to type one command and get > everything installed. > To do this, we just need to call './configure && make && make > install' after the Distutils finishes installing the python parts of > the program, and this is really easy to do. Yeah, I would like to see a single-command install process. > I'll get the new directory structure installing with > Distutils, so everyone can look at how that works first hand. Okay, then you're talking about just the Python stuff (UIL and DL), because Distutils doesn't handle C/C++. Right? > It is > really smoov, so I'm sure everyone will dig it. Then once we get stuff > hashed out, we can work on fixing cvs (maybe we should just import the > new structure as a new module--> piper. Yes, it'd be MUCH easier to re-import everything. (Getting rid of "library" will also break a lot of things :-( ) > Thinking about it more, I'd like to completely get rid of both 'main' > and 'back'. So what would be left is the following type of structure. > > piper > ui -> What is currently in 'front' Could we use "uil" instead of "ui"? Just semantics here, but we're really talking about a "layer". The UIL is a layer comprised of multiple UI's, and more than one UI will go in the "uil" directory. > dl -> what is currently in 'middle' > piper_config.py -> What is currently in const.py. The piper > configuration > file. > piper -> The main executable. > > So then during the install, we will install the piper directory with > all of the libraries that make things work inside of the > 'site-packages' directory, and install the piper executable in > /bin (where is specified as a flag during the install > (just with with autoconf)). Hold on a sec. My understanding is that the "site-packages" directory is used for Python development modules/libraries and not for applications. Have you heard or seen otherwise? Are we considering most of Pied and the DL to be development libraries like PyGTK? Don't we need a home directory for Piper anyway? I was thinking of putting the Python code in something like /home/piper, and then a symlink can go in /usr/bin. > Now that we are installing things, we will also not be able to > save temporary and permanent xml files "inside of" the directory > structure (since otherwise the user will have to run stuff as root to > write things inside the directory structure, which is not a good > thing). I'd like to suggest that we store all xml for piper inside > $HOME/piper, where $HOME is the environmental variable specifying the > home of the user running piper. How does this sound to people? Definitely, each user needs to keep his/her own stuff in his/her own space. Most Unix apps work that way. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat May 13 02:13:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: <200005121331.JAA50904@archa11.cc.uga.edu> <391CEE83.5C6DA9D3@geoserve.net> Message-ID: <391CF291.6EA3650@geoserve.net> "J.W. Bizzaro" wrote: > > Don't we need a home directory for Piper anyway? I was thinking of putting > the Python code in something like /home/piper, and then a symlink can go in > /usr/bin. Mailman, written in Python, uses /home/mailman. Also, something like... /usr[/local]/lib/piper would be acceptable for Unix systems. I actually had this discussion with the author of Anaconda (the RedHat installer) when he put an Anaconda file called "gui.py" in the site-packages directory. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat May 13 03:46:46 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up Message-ID: <200005130748.DAA156952@archa11.cc.uga.edu> Jeff wrote: > BTW, what about non-Python UI's? They will have to have their own installation system. I just don't know about any solutions which can effectively manage installations for tons of different programming languages, so right now all I'm worrying about is the python stuff that we have :-). If a better installation mechanism exists that can handle tons of languages and will do this generally, that would be better, but I just don't know what that would be... In general, I don't know exactly how we are going to handle non-python ui's. I guess it will depend on what language they are written it. > Okay, then you're talking about just the Python stuff (UIL and DL), because > Distutils doesn't handle C/C++. Right? Distutils only handles C/C++ that is being build explicitly for the purpose of being imported into a python program (ie. wrapped C/C++ code). There is no way it is as well suited for handling compiling big C/C++ programs like Overflow and GMS as autoconf is. > Yes, it'd be MUCH easier to re-import everything. (Getting rid of "library" > will also break a lot of things :-( ) Nah, just the import statements and xpm directories, right? I've been trying to put the directories for xpms into constants so that it would be easier to fix problems like this. > Could we use "uil" instead of "ui"? Just semantics here, but we're really > talking about a "layer". The UIL is a layer comprised of multiple UI's, and > more than one UI will go in the "uil" directory. I don't care :-). Seriously, naming doesn't mean much to me, as long as decide on something and stick with it. > Hold on a sec. My understanding is that the "site-packages" directory is > used > for Python development modules/libraries and not for applications. Have you > heard or seen otherwise? Are we considering most of Pied and the DL to be > development libraries like PyGTK? Is it really this well defined? It seems like the site-packages directory is for libraries, and the loci code is still a library, it is just that we use it and not anyone else :-). I didn't really know that their was a standard on this. By putting a piper module there we really aren't competing with anyone's namespace, so I don't really see what the big problem with it is. Fnorb, for instance, actually has it's fnidl script inside of site-packages (so that you set your $PATH to include this script inside of site-packages) so all of the code for running this script is inside site-packages. > Also, something like... > /usr[/local]/lib/piper > would be acceptable for Unix systems. Well, if we put it in site-packages, we would be putting it in /usr/local/lib/python1.5/site-packages/piper... Why is this not appropriate? > I actually had this discussion with the author of Anaconda (the RedHat > installer) when he put an Anaconda file called "gui.py" in the site-packages > directory. Well, this is kind of an ugly namespace violation (much the way orbit-python sucks up the namespace CORBA by putting its module right in site-packages), but we won't be doing this because everything will be inside of a piper module. > Don't we need a home directory for Piper anyway? I was thinking of putting > the Python code in something like /home/piper, and then a symlink can go in > /usr/bin. Why do we need a home directory explicitly for Piper? If we start doing stuff like this they we'll have to start writing our own installation scripts. I'm just trying to make use of what is already available to do our installation for us. What kind of stuff would we be putting in this home directory that makes it necessary? Brad From bizzaro at geoserve.net Sat May 13 11:35:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: <200005130748.DAA156952@archa11.cc.uga.edu> Message-ID: <391D762C.4FD693D5@geoserve.net> Brad Chapman wrote: > > > Yes, it'd be MUCH easier to re-import everything. (Getting rid of > > "library" will also break a lot of things :-( ) > > Nah, just the import statements and xpm directories, right? I've been > trying to put the directories for xpms into constants so that it would > be easier to fix problems like this. That sounds cool. I'll check that out. > > Hold on a sec. My understanding is that the "site-packages" > > directory is used for Python development modules/libraries > > and not for applications. > > Is it really this well defined? It seems like the site-packages > directory is for libraries, and the loci code is still a library, it > is just that we use it and not anyone else :-). site-packages is for *Python* libraries, modules that are used to develop programs in Python. Installing a Python application in... /usr/lib/python1.5/site-packages is like installing a Gnome application in... /usr/lib/gnome-libs/include :-) > I didn't really know > that their was a standard on this. By putting a piper module there we > really aren't competing with anyone's namespace, so I don't really see > what the big problem with it is. You've won every debate so far, Brad. But I think I'm right on this one ;-) > Fnorb, for instance, actually has it's fnidl script inside of > site-packages (so that you set your $PATH to include this script > inside of site-packages) so all of the code for running this script is > inside site-packages. Yeah, but Fnorb is a development tool/library. > > Also, something like... > > /usr[/local]/lib/piper > > would be acceptable for Unix systems. > > Why do we need a home directory explicitly for Piper? If we start > doing stuff like this they we'll have to start writing our own > installation scripts. I'm just trying to make use of what is > already available to do our installation for us. What kind of stuff > would we be putting in this home directory that makes it necessary? Usually programs that run under their own username have a directory in /home. Mailman, httpd, and cvs all have directories in /home. They also have shared repositories: mailing lists, web pages, and cvs modules, respectively. If Piper is to have a directory in /home, we need to consider whether or not Piper will (1) run under its own username and (2) have a shared repository. If Piper runs under a *user's* name and keeps "everything" in $HOME/piper, it may not need a /home directory. The big question is: WILL THERE BE ONE PIPER INSTANCE PER COMPUTER OR PER USER? As for Piper libraries, such as Pied's modules, I REALLY think they should go under... /usr/lib/piper Look at just a few of the applications that have directories in /usr/lib (from my own system): Mesa-3.1/ apache/ cvs/ dia/ emacs/ gimp/ mc/ rpm/ xmms/ sketch-0.6.0/ ***This is a Python application*** Here is a listing of /usr/lib/sketch-0.6.0: 1 Lib/ 1 Resources/ 1 Sketch/ 2 sketch.py* 1 Plugins/ 1 Script/ 5 sk2ps.py* Notice the executables. BUT, will Distutils handle the installation of libraries into /usr/lib/piper? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat May 13 11:51:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: <200005130748.DAA156952@archa11.cc.uga.edu> <391D762C.4FD693D5@geoserve.net> Message-ID: <391D79E9.78258722@geoserve.net> "J.W. Bizzaro" wrote: > > Mesa-3.1/ I forgot, Mesa is not an application. Anyway, what is wrong or difficult about writing a shell script for installation that does something like this: mkdir /usr/lib/piper cp -dfpRx uil /usr/lib/piper cp -dfpRx dl /usr/lib/piper ... ? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat May 13 11:59:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: <200005130748.DAA156952@archa11.cc.uga.edu> <391D762C.4FD693D5@geoserve.net> Message-ID: <391D7BFE.BF64FA7F@geoserve.net> "J.W. Bizzaro" wrote: > > As for Piper libraries, such as Pied's modules, I REALLY think they should go > under... > > /usr/lib/piper Also, Piper's pixmaps should go under... /usr/share/pixmaps/piper Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat May 13 12:56:10 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up Message-ID: <200005131658.MAA118022@archa11.cc.uga.edu> > site-packages is for *Python* libraries, modules that are used to develop > programs in Python. Okay, if you say so. > You've won every debate so far, Brad. But I think I'm right on this one ;-) I think you misunderstand me, Jeff. I have no desire to win debates, I just have a desire to make things easier :-). I don't want to put stuff in site-packages because I think it is the "right" thing to do, nor do I even have any clue about what the "right" thing to do is. I just want to put stuff in site-packages because it is the "easiest" thing to do given the tools we have. > Usually programs that run under their own username have a directory in > /home. > Mailman, httpd, and cvs all have directories in /home. They also have shared > repositories: mailing lists, web pages, and cvs modules, respectively. I'm afraid this is definately not true across all UNIX systems. Even on FreeBSD, which is not that "out there," the /home directory is only for users with logins to the computer. So I definately would never think that Piper should be installed there. > If Piper is to have a directory in /home, we need to consider whether or not > Piper will (1) run under its own username The only thing that runs under it's own username on my system is stuff like the PostgreSQL and MySQL daemons, but we aren't running a daemon, right? Plus the home problem I mentioned above (pgsql and mysql users don't even get directories in /home). > and (2) have a shared repository. Sure, I would think this makes sense to have a shared respository that all of the different users on a machine would have access to. This way a sys admin could set up Piper and it would be easy for other users to get started with it. But I'm no sys admin -> I'm the only one on my machine so it doesn't make much difference if it in my directory or in a main directory :-) If you want something like this then it should go in $PREFIX/piper, I guess, where prefix defaults to /usr/local and can be specified by the user during the build (this is the way things work with configure). > WILL THERE BE ONE PIPER INSTANCE PER COMPUTER OR PER USER? Well, one Piper instance per computer. Who wants to install Piper multiple times on a single computer? I guess I think that all xml generated during runtime should be stored in $HOME/piper (where $HOME is the home directory of the user running piper) and that the only way to add stuff to $PREFIX/piper is by copying xml files there while things aren't running. (so the root user copies them there directly, or "installs" them from a repository of useful xml files describing programs). > Look at just a few of the applications that have directories in /usr/lib > (from > my own system): > rpm/ Why the heck do you have this cruft on your computer? :-) > BUT, will Distutils handle the installation of libraries into /usr/lib/piper? > Also, Piper's pixmaps should go under... > /usr/share/pixmaps/piper I don't think it will do this. I'll look into it more. Damn, I really don't want to have to use autoconf. > Anyway, what is wrong or difficult about writing a shell script for > installation that does something like this: > mkdir /usr/lib/piper > cp -dfpRx uil /usr/lib/piper > cp -dfpRx dl /usr/lib/piper difficult? <- Nothing (although this should be written in python :-) wrong? <- Lots of things. 1. Not everyone will want things in these directories. I don't care about the debate of /usr/local vs. /usr or whatever, I'm just saying that things work differently on different systems and having a hardcoded build is not a good way to make anyone happy. 2. The original point of talking about this was that we'll need to compile extensions. Using hand written Makefiles is *very* bad and non-portable (that's why I'm making Jarl fight with autoconf :-). 3. The reason that installation tools are cool is that they provide flexibility for the installer _and_ give the developer a lot of tools to work with. For instance, both autoconf and distutils make nice tarballs for you, distutils will eventually have "binary" creation tools, autoconf provides lots of targets like uninstall, etc. Writing your installation script is no fun and you get no nice tools. Anyways, I'll look at Distutils more if we really need to put Piper in $PREFIX/piper... Brad From deanne at density.biop.umich.edu Sat May 13 17:05:37 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up In-Reply-To: <200005131658.MAA118022@archa11.cc.uga.edu> Message-ID: > > 1. Not everyone will want things in these directories. I don't care > about the debate of /usr/local vs. /usr or whatever, I'm just saying > that things work differently on different systems and having a > hardcoded build is not a good way to make anyone happy. I use /usr/local/ for all non-system programs, because of how I set up my diskspace. So, I agree, I'd enjoy seeing a bit of flexibility in where the program ends up > > 2. The original point of talking about this was that we'll need to > compile extensions. Using hand written Makefiles is *very* bad and > non-portable (that's why I'm making Jarl fight with autoconf :-). I recently tried installing a package that had a hand-written Makefile ported from a whole 'nother architecture. What a nightmare. I think it's a wonderous thing that I can go into any gnome system cvs and type 'autoconf blah blah' and it's a no-brainer. For the most part. There are some little adjustments here and there, but otherwise, i sing the praises of autoconf. d From jarl at casema.net Sun May 14 13:50:34 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up References: Message-ID: <391EE76A.F971F4A9@casema.net> > > 1. Not everyone will want things in these directories. I don't care > > I use /usr/local/ for all non-system programs, because of how I set up my > diskspace. So, I agree, I'd enjoy seeing a bit of flexibility in where the > program ends up My interest is main focused on the updating of Piper. I know this is something not to be realized soon, but maybe after compiling we can install just the 'basic' and have that install the complete system, and have it up to date. > > non-portable (that's why I'm making Jarl fight with autoconf :-). > > I recently tried installing a package that had a hand-written > Makefile ported from a whole 'nother architecture. What a nightmare. Automake is a nightmare too.. but only for one person. I've used handcrafted makefiles till recently, but I must agree autoconf should be used, or similar tools. bye, jarl From deanne at density.biop.umich.edu Sun May 14 10:39:24 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] Installation + Directory clean-up In-Reply-To: <391EE76A.F971F4A9@casema.net> Message-ID: > > > 1. Not everyone will want things in these directories. I don't care > > > > I use /usr/local/ for all non-system programs, because of how I set up my > > diskspace. So, I agree, I'd enjoy seeing a bit of flexibility in where the > > program ends up > > My interest is main focused on the updating of Piper. I know this is something > not to be realized soon, but maybe after compiling we can install just the > 'basic' > and have that install the complete system, and have it up to date. I figured CVS was good for the updating of piper. The best solution would be to include detailed CVS instructions for an end-user so they could go thru CVS and have it install new piper on top of old (choosing right directories, etc). Just tell the user in the beginning that they should remember what the directory prefix is for installing piper (/usr or /usr/local). Since most of that stuff is configuable at the configure level, why not just include it as part of the INSTALL file? (ie, "2. Choose the prefix for piper installation by typing (blah blah) --prefix=/usr/local for example. This will be your $PIPERPATH; if you want to update piper later thru CVS, make sure you use the same prefix as this one to avoid version clashes. > > > > non-portable (that's why I'm making Jarl fight with autoconf :-). > > > > I recently tried installing a package that had a hand-written > > Makefile ported from a whole 'nother architecture. What a nightmare. > > Automake is a nightmare too.. but only for one person. I've used handcrafted > makefiles till recently, but I must agree autoconf should be used, or similar > tools. > > bye, > jarl > > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel > From bizzaro at geoserve.net Sun May 14 23:24:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] NETPIPES Message-ID: <391F6DE7.FF74CCF8@geoserve.net> I sent this link to the list a couple weeks ago. I would very much like to get a comment from Jarl on Netpipes. Would any of this code be usable in the BL? Does it give you any ideas? It seems to me that we will need to re-invent much of this in the BL. Am I wrong (again)? "The netpipes package makes TCP/IP streams usable in shell scripts. It can also simplify client/server code by allowing the programmer to skip all the tedious programming bits related to sockets and concentrate on writing a filter/service." http://web.purplefrog.com/~thoth/netpipes/netpipes.html Jeff From bizzaro at geoserve.net Sun May 14 23:28:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] NETPIPES References: <391F6DE7.FF74CCF8@geoserve.net> Message-ID: <391F6EF1.78798A90@geoserve.net> "J.W. Bizzaro" wrote: > > It seems to me that we will need to > re-invent much of this in the BL. At least in CORBA -- Netpipes uses sockets. Perhaps the author of Netpipes would like to collaborate with us. There are many similarities. Just my US$0.02. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon May 15 00:57:39 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] NETPIPES Message-ID: <200005150459.AAA78622@archa10.cc.uga.edu> > Jeff wrote: [...snip...stuff about Netpipes...] Okay, after starting at the documentation for a long time (man, this thing has a lot of switches!), it seems like Netpipes makes a client/server process that runs through TCP/IP, right? Mostly, it just seems to make it so that you can deal with sockets at a higher level and make simple client/servers. Like in this example: server$ faucet 3000 --out tar cf - . client$ hose server 3000 --in tar xvf - You just set up a simple server that untars everything that comes in (it listens on port 3000) and then a client tars up a directory and sends it to the server on port 3000. The server untars it and voila, you have a transferred directory. At least from the python end this type of stuff is already covered in the standard library--the uil to dl layer works through these type of convenience classes. You also can deal with things using a nice scripting language and not shell scripts (bleah!). >> It seems to me that we will need to >> re-invent much of this in the BL. Can you explain exactly how you see netpipes being used? I think I understand what it does, I just don't see your vision for how to use it. Also have you checked out the dl_info.html doc in the loci module? I have a diagram in that of how Jarl and I were last talking about handling remote communication. At least, this is what we ended up settling on last I heard :-). If stuff works like this then the dl shouldn't need to worry about setting up TCP/IP connections, right? Or do you disagree with this model? > At least in CORBA -- Netpipes uses sockets. Didn't we decide that sockets = bad and corba = good? :-) > Perhaps the author of Netpipes would like to collaborate with us. There are > many similarities. Just my US$0.02. I don't know Jeff, the page you sent us was dated 1997, and I downloaded the "latest" code and it doesn't look like it's been touched since 98. Netpipes is looking pretty fast asleep... Brad From jarl at casema.net Mon May 15 11:49:52 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] NETPIPES References: <391F6DE7.FF74CCF8@geoserve.net> Message-ID: <39201CA0.CD57A35A@casema.net> > I sent this link to the list a couple weeks ago. I would very much like to > get a comment from Jarl on Netpipes. Would any of this code be usable in the > BL? Does it give you any ideas? It seems to me that we will need to > re-invent much of this in the BL. Am I wrong (again)? > Dont want to disencourage, but ... ;) Netpipes is like netcat (nc), it's for piping (like the '|' shell sign) streams across a network. But only in 2D space. This tool is just too simplistic for our needs. It aint got the ability to define connection types at all. As I said before, I'm intending to use Gnet for high speed connections, and corba for all the others. Gnet is a direct concurrent to netpipes, but it's a library that doesn't need any coding to integrate with the BL. Netpipes could be used in a 'wrapping' mode, but that's not very tempting to me. (Gnet : http://www.eecs.umich.edu/~dhelder/misc/gnet/) bye, jarl From bizzaro at geoserve.net Mon May 15 18:09:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:55 2006 Subject: [Pipet Devel] NETPIPES References: <200005150459.AAA78622@archa10.cc.uga.edu> Message-ID: <392075B7.AA65A08C@geoserve.net> Okay, I just wanted to hear from you guys if you thought Netpipes was applicable or usable. I guess not. The reason I wanted some feedback on it was because of some of the similarities with Piper. Both Piper and Netpipes extend the Unix paradigm (at least the standard shell in Netpipes' case) to allow piping across networks, among other things. And I thought some ideas or code may be reused from Netpipes. I've been trying to keep "The Unix Way" in mind when thinking about the design of Loci (and now Piper). For example, "networks" can be thought of as directories or filesystem volumes (I've mentioned this a number of times). And nodes are often networks (and often not), just like Unix files (or what seems to be a file when you take a listing) are often directories (and often not). It's important for user interface design (people will have to use Piper somehow ;-)) to be able to represent this extended Unix paradigm in a familiar way. Those who have been on the Loci list will remember I mentioned a console-based (textual) "front" (UI) for Loci. The user would be able to control Loci/Piper with the UI in a Unix shell-like manner. How? That's what we have to keep in mind. I'm thinking that the user would always be "inside" of a network, just like a Unix shell user is inside of a directory. So, a user can choose to "change networks" (perhaps with a "cn" command), jumping between parent and child networks. Of course, this means the user needs to see what other nodes and networks are in the "working network". So, perhaps he/she can take a "listing" ("ls" command?) of what is in that network. Do you see what I'm getting at? We're right in line with "The Unix Way" here (very smoov), and we should should continue to think like this. You may also see now why Netpipes caught my attention (in case you don't, Netpipes ALSO lets you make CONNECTIONS via command-line :-)). (I'm not saying to use Netpipes. Let's not, since it seems obsolete. But, I want to borrow some ideas for the console-based UI.) Cheers. Jeff Brad Chapman wrote: > > Okay, after starting at the documentation for a long time (man, this > thing has a lot of switches!), it seems like Netpipes makes a > client/server process that runs through TCP/IP, right? Mostly, it just > seems to make it so that you can deal with sockets at a higher level > and make simple client/servers. Like in this example: > > server$ faucet 3000 --out tar cf - . > client$ hose server 3000 --in tar xvf - > > You just set up a simple server that untars everything that comes in > (it listens on port 3000) and then a client tars up a directory and > sends it to the server on port 3000. The server untars it and voila, > you have a transferred directory. > > At least from the python end this type of stuff is already covered in > the standard library--the uil to dl layer works through these type > of convenience classes. You also can deal with things using a nice > scripting language and not shell scripts (bleah!). > > >> It seems to me that we will need to > >> re-invent much of this in the BL. > > Can you explain exactly how you see netpipes being used? I think I > understand what it does, I just don't see your vision for how to use > it. > Also have you checked out the dl_info.html doc in the loci module? > I have a diagram in that of how Jarl and I were last talking about > handling remote communication. At least, this is what we ended up > settling on last I heard :-). If stuff works like this then the dl > shouldn't need to worry about setting up TCP/IP connections, right? Or > do you disagree with this model? > > > At least in CORBA -- Netpipes uses sockets. > > Didn't we decide that sockets = bad and corba = good? :-) > > > Perhaps the author of Netpipes would like to collaborate with us. > There are > > many similarities. Just my US$0.02. > > I don't know Jeff, the page you sent us was dated 1997, and I > downloaded the "latest" code and it doesn't look like it's been > touched since 98. Netpipes is looking pretty fast asleep... jarl van katwijk wrote: > > Dont want to disencourage, but ... ;) > Netpipes is like netcat (nc), it's for piping (like the '|' shell sign) streams > across a > network. But only in 2D space. This tool is just too simplistic for our needs. > It aint > got the ability to define connection types at all. > As I said before, I'm intending to use Gnet for high speed connections, and > corba > for all the others. Gnet is a direct concurrent to netpipes, but it's a library > that > doesn't need any coding to integrate with the BL. Netpipes could be used in a > 'wrapping' mode, but that's not very tempting to me. > > (Gnet : http://www.eecs.umich.edu/~dhelder/misc/gnet/) -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon May 15 19:24:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] [Fwd: [Pipet Devel] Re: Sodipodi and Loci] Message-ID: <3920874B.48198370@geoserve.net> I thought I'd forward these to the Piper list, since the Loci list will change its focus soon, and not everyone here is on the Loci list. Jeff -------------- next part -------------- An embedded message was scrubbed... From: Lauris Kaplinski Subject: [Pipet Devel] Re: Sodipodi and Loci Date: Mon, 15 May 2000 13:19:50 +0200 (CEST) Size: 2248 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000515/0807fd25/attachment.mht -------------- next part -------------- An embedded message was scrubbed... From: Jarl van Katwijk Subject: Re: [Pipet Devel] Re: Sodipodi and Loci Date: Mon, 15 May 2000 12:48:35 +0200 Size: 1928 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000515/0807fd25/attachment-0001.mht -------------- next part -------------- An embedded message was scrubbed... From: "J.W. Bizzaro" Subject: [Pipet Devel] Re: Sodipodi and Loci Date: Mon, 15 May 2000 21:31:06 +0000 Size: 3632 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000515/0807fd25/attachment-0002.mht -------------- next part -------------- An embedded message was scrubbed... From: Lauris Kaplinski Subject: [Pipet Devel] Re: Sodipodi and Loci Date: Mon, 15 May 2000 23:59:54 +0200 (CEST) Size: 2467 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000515/0807fd25/attachment-0003.mht -------------- next part -------------- An embedded message was scrubbed... From: "J.W. Bizzaro" Subject: Re: [Pipet Devel] Re: Sodipodi and Loci Date: Mon, 15 May 2000 22:50:01 +0000 Size: 4187 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000515/0807fd25/attachment-0004.mht -------------- next part -------------- An embedded message was scrubbed... From: jarl van katwijk Subject: Re: [Pipet Devel] Re: Sodipodi and Loci Date: Mon, 15 May 2000 23:26:34 -0800 Size: 3211 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000515/0807fd25/attachment-0005.mht From bizzaro at geoserve.net Mon May 15 19:58:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] [Fwd: [Pipet Devel] Re: Sodipodi and Loci] References: <3920874B.48198370@geoserve.net> Message-ID: <39208F1F.DB490459@geoserve.net> "J.W. Bizzaro" wrote: > > It'd be nice if we had a reusable Bonobo component for UI's (I think that is > what you're saying). But, since Bonobo is entirely desktop-oriented (and > Gnome-based), such support belongs in the UIL, IMHO. It appears the UIL (not just a single UI directory) will need a "library" of reusable (by more than one UI) resources, such as this SVG component. Previously, I said that things common to all UI's will go in the DL, and things NOT common to all UI's will go in the UIL (my "simple rule"). Then we realized that only the DL could handle node selection and even node XY positions. But in this case, the "things" are XML information, not actual code or widgets. I think the "simple rule" pertains to XML information and network construction. It's easy to pass this stuff back and forth without closely integrating the DL and UIL. But, in nearly every case, tangible code and widgets used by the UI's should remain in the UIL. The DL can then just "tell" the UI to use them when needed. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon May 15 23:46:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Software Carpentry Project Message-ID: <3920C48D.714E00C9@geoserve.net> Brad, did you know these Python (not GPL'd though) tools were just made? Software Carpentry (SC) Configuration, a platform investigation and project reconfiguration tool to supersede autoconf SC Build, a dependency-management and program reconstruction tool to to supersede make SC Test, a unit and regression testing framework SC Track, an issue tracking system http://www.LinuxMall.com/news/?1,139 Jeff From bizzaro at geoserve.net Tue May 16 04:57:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] loci tarball and updated piper web page Message-ID: <39210D82.3C339D97@geoserve.net> Locians and Pipers, I placed a tarball of one of the later commits to CVS (May 10, by Brad) on the web server: http://bioinformatics.org/loci/download/snapshots/loci-latest.tar.gz This may be the last tarball to go by the name "Loci", as the code bases of Loci, GMS and Overflow will soon be merged (into "Piper"). I also made some minor changes to the Piper web page (bioinformatics.org/piper), including a link to Brad's documentation on the DL (Definitions Layer). Very nice job, Brad. You put me to shame, as usual :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue May 16 06:11:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] biological network design Message-ID: <39211EE3.E094A686@geoserve.net> Jarl, As soon as the web page is done being slashdotted, you can browse over and read an article about using biological rules/laws to design networks. I thought you might find it interesting and perhaps applicable to the BL. http://bolero.ics.uci.edu/projectx/publications/publications.html Jeff From jarl at casema.net Tue May 16 06:41:16 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] biological network design References: <39211EE3.E094A686@geoserve.net> Message-ID: <392125CC.FA22A223@casema.net> > HI Jeff, > I thought you might find it interesting and perhaps applicable to the BL. > > http://bolero.ics.uci.edu/projectx/publications/publications.html > Yes, this is very interesting indeed! I read their project description and they've huge similairities with the BL. I definitly will adapt some of their idears into the BL, like their 'power' system, with works like money to but cpu power and network bandwidth. When I read the document a 2nd time I'll make notes and post usable aspects on our mailinglist. bye, jarl From chapmanb at arches.uga.edu Wed May 17 06:56:58 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Software Carpentry Project Message-ID: <200005171059.GAA55620@archa10.cc.uga.edu> Jeff wrote: > Brad, did you know these Python (not GPL'd though) tools were just made? [...snip...description of software-carpentry tools...] Yeah, these tools will be very cool, but are still vaporware for at least another year or so. I've been watching them because it is kind of an interesting thing they have going. Software Carpentry is having a design competition with big prize money, and are posting all of the designs from different people. Some of the designs are really interesting to read, at least for me, since it kind of gives some insight into how to lay out a project design (which I have zero training in :-). You can check out the pages and stuff at http://software-carpentry.codesourcery.com/. I wish these were available now, but right now we've only got the fun of autoconf! Brad From bizzaro at geoserve.net Wed May 17 07:13:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Software Carpentry Project References: <200005171059.GAA55620@archa10.cc.uga.edu> Message-ID: <39227ED4.7B2EB005@geoserve.net> I didn't realize they were vaporware. I had heard of the contest, and the recent announcement made it sound as though these tools were the finished result. And they are NOT GPL'd (it's odd they wouldn't allow the GPL to be used in the contest -- read the rules), which means our installer (if based on SC) would have to be distributed separately. Hmmm. Jeff Brad Chapman wrote: > > Jeff wrote: > > Brad, did you know these Python (not GPL'd though) tools were just > made? > > [...snip...description of software-carpentry tools...] > > Yeah, these tools will be very cool, but are still vaporware for at > least another year or so. I've been watching them because it is kind > of an interesting thing they have going. Software Carpentry is having > a design competition with big prize money, and are posting all of the > designs from different people. Some of the designs are really > interesting to read, at least for me, since it kind of gives some > insight into how to lay out a project design (which I have zero > training in :-). > You can check out the pages and stuff at > http://software-carpentry.codesourcery.com/. I wish these were > available now, but right now we've only got the fun of autoconf! > > Brad > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 17 08:11:14 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep Message-ID: <39228C62.88E59166@geoserve.net> Pipers, After an e-mail conversation with Deanne, she agreed to head-up the development of the "Peep" UI for Piper. "What the Hell is Peep???" you may ask. This is the textual UI or CLI that I spoke about recently and have been planning for Loci since early this year. Of course, Peep will interface with the DL and not the Gnome (Pied) interface. It will basically translate the XML command stream into the more common human language of "English". Being completely non-graphical, Peep will of course have many limitations. It won't, for example, be able to display Jean-Marc's lovely charts. But that's...okay. We can think of Peep as being like the Lynx web browser. It can do most things, but not everything. You may also ask, "What the f**k do we need that for???" Well, if you'd please watch your cursing I'll tell you. Peep will allow Piper to be operated without a windowing system. This means Piper can be started via console, through telnet, and even be more portable to other operating systems. For these reasons, I would also like Peep to be the default UI for Piper, not Pied. "Why the name Peep???" you say. That's better. "Peep" is a species of sandpiper bird, our mascot. It also means, in English, "a quick glance" and "a short, sharp utterance". I think it is a very fitting name. "What language will Peep be written in???" Python will allow Peep and Pied to share a code base, so I think it would be best. Any MORE questions? ;-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Wed May 17 07:24:54 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep References: <39228C62.88E59166@geoserve.net> Message-ID: <39228186.FEEB049B@casema.net> > > > After an e-mail conversation with Deanne, she agreed to head-up the > development of the "Peep" UI for Piper. "What the Hell is Peep???" you may > ask. This is the textual UI or CLI that I spoke about recently and have been > planning for Loci since early this year. Of course, Peep will interface with > the DL and not the Gnome (Pied) interface. It will basically translate the > XML command stream into the more common human language of "English". > nice to have a textmode interface. > Any MORE questions? ;-) Will it be aalib based, like Textmode Quake? From deanne at density.biop.umich.edu Wed May 17 08:29:08 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Software Carpentry Project In-Reply-To: <39227ED4.7B2EB005@geoserve.net> Message-ID: > And they are NOT GPL'd (it's odd they wouldn't allow the GPL to be used in the > contest -- read the rules), which means our installer (if based on SC) would > have to be distributed separately. Hmmm. License info is available at http://software-carpentry.codesourcery.com/license.html Essentially they want the artist to keep rights to the code, looks like. Open Source without changes, or something. From bizzaro at geoserve.net Wed May 17 08:35:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep References: Message-ID: <392291FC.2A4CD0A0@geoserve.net> deanne@density.biop.umich.edu wrote: > > Why, yes, I have a question. Where should I start? :) (ahem, you weren't on the list ;-)) Not to pressure Brad or anything (we all know he's done tons more than I), but he said he's preparing a new directory structure for Piper. We need that ready first. Then, we can make a copy of Pied and strip out the Gnome stuff. Peep will need a text input loop (that will likely replace the Gtk event loop) that lets it work like the Unix command line or any other CLI such as telnet, ftp, etc. I haven't done this myself, so perhaps in the meantime you can figure out how to do this in Python. It should be real eeeeeasy. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 17 08:36:20 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep References: <39228C62.88E59166@geoserve.net> <39228186.FEEB049B@casema.net> Message-ID: <39229244.4F284B84@geoserve.net> Jarl van Katwijk wrote: > > Will it be aalib based, like Textmode Quake? I'm not familiar with that. Are you talking about something like ncurses? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 17 08:50:20 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Software Carpentry Project References: Message-ID: <3922958C.D968AD4@geoserve.net> deanne@density.biop.umich.edu wrote: > > License info is available at > > http://software-carpentry.codesourcery.com/license.html > > Essentially they want the artist to keep rights to the code, looks > like. Open Source without changes, or something. Not to start a big licensing debate here, but the GPL does not cause the artist to lose any rights to his/her code. Every GPL license starts with a copyright notice in the name of the artist(s). The FSF lets people assign their copyright to the FSF, but this is only an option. The page you're referring to, Deanne, isn't the same one I saw at the beginning of the contest many moons ago. The wording of the licensing rules I saw said the competitors MUST use the MIT license. It's not as though the authors came to a concensus about it. It's strange. I might think this requirement means the contest holders have a closed-source distribution in mind, but it's a little hard to do that with Python, isn't it? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Wed May 17 07:48:15 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep References: <39228C62.88E59166@geoserve.net> <39228186.FEEB049B@casema.net> <39229244.4F284B84@geoserve.net> Message-ID: <392286FF.8B26B2A@casema.net> > > Will it be aalib based, like Textmode Quake? > > I'm not familiar with that. Are you talking about something like ncurses? Something more flexible, it supports displaying pictures on a textmode screen..The result is pretty prehistoric :) Maybe I should have asked something else: will Peep work with a commandline or menu's? bye, jarl From bizzaro at geoserve.net Wed May 17 08:55:25 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep References: <39228C62.88E59166@geoserve.net> <39228186.FEEB049B@casema.net> <39229244.4F284B84@geoserve.net> <392286FF.8B26B2A@casema.net> Message-ID: <392296BD.9C9A3D1A@geoserve.net> Jarl van Katwijk wrote: > > Something more flexible, it supports displaying pictures on a textmode > screen..The result is pretty prehistoric :) > > Maybe I should have asked something else: will Peep work with a commandline > or menu's? Command line. Regarding both questions, an interface that uses aalib/ncurses and menus is a possibility for yet another UI. But I think Peep should be simple and use a CLI with a scrolling screen. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 17 09:13:33 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: <39206C9A.9C0F2AF5@geoserve.net> <3920F82A.F2106B@casema.net> <39207F19.17062FB8@geoserve.net> <3920F1FE.1F7120DB@casema.net> Message-ID: <39229AFD.F5CDF86E@geoserve.net> Jarl van Katwijk wrote: > > > > Jeff: maybe you could explain the basic structure of the souces of the UI? > > > I didn't dare reading Python sources yet :) > > > > Directory structure or the core requirements to construct a UI? > > both please. Okay, now I can answer this question. This answer is...(drum roll)...Give me a little more time until Peep is up and running ;-) Then I will have a better picture of the core requirements and dir structure. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Wed May 17 09:12:39 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:56 2006 Subject: [Pipet Devel] Peep In-Reply-To: <392296BD.9C9A3D1A@geoserve.net> Message-ID: > > Maybe I should have asked something else: will Peep work with a commandline > > or menu's? > > Command line. Regarding both questions, an interface that uses aalib/ncurses > and menus is a possibility for yet another UI. But I think Peep should be > simple and use a CLI with a scrolling screen. I like command-line better than menus, but that's because I'm a textmode purist. Plus, I've been on terms where the ncurses stuff is ugly. Simplicity is always better. Okay, tonight i'll look for ways to make the scrolling screen in piper, it should be easy to do. From bizzaro at geoserve.net Wed May 17 09:19:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Peep References: Message-ID: <39229C5A.E8BF3B6@geoserve.net> deanne@density.biop.umich.edu wrote: > > Okay, tonight i'll look for ways to make the scrolling screen in piper, it > should be easy to do. I'm not sure if text input in Python lets you use the cursor arrows and backspace without getting something like ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H It probably does. Using the up arrow for command history would be nice too, but that's a little fancy for now ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 17 09:42:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Peep References: <39228C62.88E59166@geoserve.net> Message-ID: <3922A1D3.B0D187B0@geoserve.net> "J.W. Bizzaro" wrote: > > Peep will allow Piper to be operated > without a windowing system. This means Piper can be started via console, > through telnet, and even be more portable to other operating systems. I forgot to mention the best part: PEEP WILL LET PIPER WORK WITH VOICE RECOGNITION AND SYNTHESIS 8-D Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Wed May 17 09:37:42 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: <39206C9A.9C0F2AF5@geoserve.net> <3920F82A.F2106B@casema.net> <39207F19.17062FB8@geoserve.net> <3920F1FE.1F7120DB@casema.net> <39229AFD.F5CDF86E@geoserve.net> Message-ID: <3922A0A6.6CA0D7E8@casema.net> > > > Directory structure or the core requirements to construct a UI? > > both please. > Okay, now I can answer this question. This answer is...(drum roll)...Give me > a little more time until Peep is up and running ;-) hehe... arf! > Then I will have a better > picture of the core requirements and dir structure. aaiks, shouldn't you know this already by now? :-) From bizzaro at geoserve.net Wed May 17 10:46:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: <39206C9A.9C0F2AF5@geoserve.net> <3920F82A.F2106B@casema.net> <39207F19.17062FB8@geoserve.net> <3920F1FE.1F7120DB@casema.net> <39229AFD.F5CDF86E@geoserve.net> <3922A0A6.6CA0D7E8@casema.net> Message-ID: <3922B0AE.449514E8@geoserve.net> Jarl van Katwijk wrote: > > aaiks, shouldn't you know this already by now? :-) Yeah, but things are changing a lot. I want to be able to write a precise specification like the one Brad wrote for the DL. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Wed May 17 20:46:34 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Peep Message-ID: <200005180048.UAA62832@archa12.cc.uga.edu> > deanne@density.biop.umich.edu wrote: >> Why, yes, I have a question. Where should I start? :) Deanne, Have you read through the description of the user interface to definition layer "API" in comProtocols.txt? It is not very good documentation (apologies) so I just wanted to make sure that the way to communicate with the definition layer made sense. I've just basically been making it up as I go along, so suggestions/questions/comments on it are very welcome. Also, does the code in the current gnome front (Pied) make sense? I messed up a lot of crap in there and some of it needs some serious cleaning. Since it seems like you'll be building off of that for Peep, I just wanted to make sure that what was going on in there makes any sense. I'm so happy you're going to be starting up on this :-) Jeff wrote. > Brad said he's preparing a new directory structure for Piper. We need that > ready first. Then, we can make a copy of Pied and strip out the Gnome stuff. Yuppers. Very soon :-). I've been fighting with my old c++ compiler and my lack of c++ knowledge on trying to wrap Overflow (as Jean-Marc can attest to by my many frantic, confused messages to him :-). I'll drop that for now and focus on just getting what we have working under the new directory structure with the new install process. I'll be using autoconf for this, so working out of cvs will soon require understanding how this works and all of that. I'm sorry to be so slow. I'm just getting back from a conference and one of my good friends is visiting right now, but hopefully I'll crank it out by Fridayish. Sorry again to slow up the freight train o' progress... Brad From bizzaro at geoserve.net Wed May 17 22:36:25 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Peep References: <200005180048.UAA62832@archa12.cc.uga.edu> Message-ID: <39235729.BD322429@geoserve.net> Brad Chapman wrote: > > I'm sorry to be so slow. I'm just getting back from a conference > and one of my good friends is visiting right now, but hopefully I'll > crank it out by Fridayish. Sorry again to slow up the freight train > o' progress... 'zalright, no rush. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri May 19 16:17:13 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] New directory structure Message-ID: <200005192020.QAA46606@archa11.cc.uga.edu> Hello everybody; I just finished getting piper building/installing in the way that we discussed on the list, so I was hoping people might be able to take a look at it and see what they think. You can grab the tarball from my spiffy bioinformatics.org site (courtesy o' Gary): http://alpha.bioinformatics.org/bradstuff/index.html. I would be really appreciative if you could try installing it and let me know what you think of the installation locations and directory structure. I'm using autoconf/automake for the build/install process. Right now things are really simple and you shouldn't need any patches to autoconf at all. I'm going to work on understanding better the m4s that are available for python and work on getting the .py files byte-compiled before I install them (the way it is supposed to be done :-). I'll update the install instructions in the distribution tonight/tommorrow, but here is the simple overview: 1. To just install it, you should just need to type ./configure && make && make install, just like with any autoconfed build. Right now configure takes the following options: 1.--prefix=/the/location/you/want/to/put/piper (deafaults as /usr/local) 2.--with-peep-ui or --without-peep-ui (the default is with if you don't put anything) 3. --with-pied-ui or --without-pied-ui (like peep) 2. To build it using autoconf, you should be able to just run: ./autogen.sh This script will do all the aclocal, automake, autoconf stuff for you (thanks to the Overflow guys for this fine script). Piper installs into the following directories under the specified $prefix: bin -> The executables for piper ('piper' and 'piperpass') piper -> All of the stuff that makes up piper share/pixmaps/piper -> The pixmaps for the gnome ui (pied) I've made an attempt to help separate the different sections of Piper so that we can break away from being all python. The dl, peep and pied are all "stand-alone" so that they have their own directories and configure scripts. The main script that runs 'piper' (name changed to runpiper.py) no longer imports python modules, but instead just runs scripts provided by the different modules. Right now pied and the dl have scripts that can be run, Deanne'll need to get one going for peep once there is something there. I think that's it :-) Thanks for reading all the way down. I'll work on fixing the install documentation and getting a snazzier byte-compiled installation, but I'd really like to get people's opinions on this structure and install before we stick it in cvs. Thanks much! Brad From deanne at density.biop.umich.edu Fri May 19 16:53:10 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Peep, etc. In-Reply-To: <200005192020.QAA46606@archa11.cc.uga.edu> Message-ID: I've been looking around for text-based UI stuff for python, and I found ttyio.py, which is a little module that supposedly acts as a little tty input for the front end of a computer. I may adapt it for peep. It's licensed under the LGPL, though I will only be using it as example of how to use the corresponding modules that it loads: import os import tty import sys import types import string D From deanne at density.biop.umich.edu Fri May 19 16:54:20 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Peep, etc. In-Reply-To: Message-ID: > input for the front end of a computer Front end of a program. Duh. D From chapmanb at arches.uga.edu Sat May 20 17:54:57 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Update of new directory structure Message-ID: <200005202157.RAA43014@archa11.cc.uga.edu> Hello all; I've been working again on the new directory structure and autoconf/automake build and posted an update at the same place as before: http://alpha.bioinformatics.org/bradstuff/index.html. The changes since yesterday are: 1. The INSTALL file has been updated with all the info about the current installation process. Please check it out and let me know if it makes any sense :-) 2. We are now byte-compiling (with optimization!) the .py scripts using James Henstridge's patches to automake. So now we are properly installing the python files--yippee! 3. I added the stuff I'm working on for wrapping some overflow code to be used in the definition layer. This is compiling for me, using gcc 2.95.2, but I'm really interested to hear if it compiles for anyone else, since this code will need to be able to compile for everyone to use piper in the future. Please let me know any errors you get, so I can try to figure this all out. If you get stuck badly on the compile and can't go any further, you can skip this part of the make (it isn't necessary to make anything work right now) by modifying dl/Makefile.am as follows: was -> SUBDIRS = modules scripts vflow now -> SUBDIRS = modules scripts and then running ./autogen.sh to revamp everything. As always, I'm looking forward to hearing from everyone about this. Toodle-loo! Brad From jean-marc.valin at hermes.usherb.ca Sun May 21 13:35:54 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Update of new directory structure References: <200005202157.RAA43014@archa11.cc.uga.edu> Message-ID: <39281E7A.F58907A2@hermes.usherb.ca> Brad Chapman a ?crit : > > Hello all; > I've been working again on the new directory structure and > autoconf/automake build and posted an update at the same place as > before: http://alpha.bioinformatics.org/bradstuff/index.html. > The changes since yesterday are: I've seen that you've included the UI* classes in the directory tree. Are you planning on doing this for the future releases, as it may become very hard to maintain the Overflow code in two different places. Instead, I suggest checking out Overflow separatly from CVS (though everything could be in one package for a tar.gz release). In this way, there would only be one Overflow tree to maintain. What do you think? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Sun May 21 14:20:36 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] piper on project admin system Message-ID: <392828F4.FA0F1FF1@geoserve.net> Pipers, I created a project on The Open Lab's new project admin system (based on SourceForge): http://alpha.bioinformatics.org/ (temporary location) We are about to move everything over to this new system. It will replace the current server. And I'd like to put Brad's new module there. If you have not already done so (Brad, Deanne and Gary have), please go there and "Join The Open Lab" (link on left side of page). Then I will be able to add you to the Piper project. (When you get an e-mail back saying to go to www.bioinformatics.org, change that to alpha.bioinformatics.org.) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun May 21 14:32:21 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Update of new directory structure Message-ID: <200005211835.OAA140292@archa10.cc.uga.edu> Jean-Marc wrote: > I've seen that you've included the UI* classes in the directory tree. Are you > planning on doing this for the future releases, as it may become very hard to > maintain the Overflow code in two different places. Definately not. Sorry, I forgot to write about this. I just included these classes as a convenience since Piper isn't using Overflow full scale yet. Once it starts getting integrated into the bl as well, then I'll start assuming that everyone using Piper has Overflow installed. The included classes are basically the UI classes from Overflow, but I hacked them into a horrible shape by commenting out lots of stuff I'm not using in the dl (so they can compile stand-alone without the data-flow module). The wrapping is *very much* a work in progress since it doesn't do anything at all yet :-). I just included them because I was interested to see if people could compile the SWIG extension without problems. Instead, I suggest > checking > out Overflow separatly from CVS (though everything could be in one package > for a > tar.gz release). In this way, there would only be one Overflow tree to > maintain. > What do you think? Agreed. I'll maintain these few classes while I'm messing with things, but toss them out for any kind of release., It should be quite easy to include different parts of Overflow into Piper for a full tar.gz distribution since they both use autoconf build systems and are set up in the same way (since I stole a lot from the Overflow distribution :-). Brad From bizzaro at geoserve.net Sun May 21 16:11:57 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing Message-ID: <3928430D.49E9AFFA@geoserve.net> Jarl, I don't know if these are of any use to us now, but we were considering the use of a batch processing system for Loci. Here are a couple I had bookmarked: Generic NQS: http://www.gnqs.org/ GNU Queue: http://bioinfo.mbb.yale.edu/~wkrebs/queue.html Jeff From jarl at casema.net Mon May 22 06:24:07 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> Message-ID: <39290AC7.72590D1E@casema.net> > > I don't know if these are of any use to us now, but we were considering the > use of a batch processing system for Loci. Here are a couple I had > bookmarked: > Before I'll start being too technically about batch processing, I want to know if people have a wish list for this. I haven't looked into detail at these projects, but I've some professional experience with batch processing (SA7). Personally I do not have any speciafic wishes, but I see why the bioinformatic people need to have this, thnx to Jeff's explainations about the linking of simulation software inside the Piper environment. > Generic NQS: > http://www.gnqs.org/ > > GNU Queue: > http://bioinfo.mbb.yale.edu/~wkrebs/queue.html > From chapmanb at arches.uga.edu Tue May 23 11:55:17 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] (fwd) KQML Message-ID: <200005231558.LAA107100@archa12.cc.uga.edu> Hey all; Jarl's e-mail is apparently having some issues, so he asked me to forward these urls on to everyone. http://www.cs.umbc.edu/kqml KQML... Knowledge Query Modeling Language. I've read a part of their API, looks very good! Also found an idl for it: http://www.irit.fr/~Dominique.Benech/cobalt/cobalt.idl From bizzaro at geoserve.net Tue May 23 15:52:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> Message-ID: <392AE16D.A7685FDB@geoserve.net> Jarl van Katwijk wrote: > > Before I'll start being too technically about batch processing, I want to know > if people have a wish list for this. I haven't looked into detail at these > projects, but I've some professional experience with batch processing (SA7). > Personally I do not have any speciafic wishes, but I see why the bioinformatic > people need to have this, thnx to Jeff's explainations about the linking of > simulation software inside the Piper environment. For those not familiar with bioinformatics and our plans for Loci, we're talking about the difference between sequential (non-streaming) and non-sequential (streaming) data transfer. A bioinformatics (or scientific) computation is typically performed "all at once", returning results when finished. Many are often long-running (depending on the computer), taking minutes, hours, or days. While designing Loci, my first thought was that these "jobs" could be handled as they are on a supercomputer: with batch processing. This allows some information to be returned about the progression of the job, cpu time used, etc. It also allows jobs to be scheduled to run at a certain time, with a set priority, etc. You may think that batch processing has disappeared along with expensive computer time. But I think it may be particularly important for Piper, because (1) the system needs to report back to the user when the job has been "gone" for a long period of time (or else the user may think the data has been lost) and (2) because we Piper will use "other people's computers" (we want those people to decide when jobs will be run and to decide the resources to be used). Thoughts? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue May 23 17:57:55 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> Message-ID: <392AFEE2.9842375A@hermes.usherb.ca> > For those not familiar with bioinformatics and our plans for Loci, we're > talking about the difference between sequential (non-streaming) and > non-sequential (streaming) data transfer. A bioinformatics (or scientific) > computation is typically performed "all at once", returning results when > finished. Many are often long-running (depending on the computer), taking > minutes, hours, or days. > > While designing Loci, my first thought was that these "jobs" could be handled > as they are on a supercomputer: with batch processing. This allows some > information to be returned about the progression of the job, cpu time used, > etc. It also allows jobs to be scheduled to run at a certain time, with a set > priority, etc. > > You may think that batch processing has disappeared along with expensive > computer time. But I think it may be particularly important for Piper, > because (1) the system needs to report back to the user when the job has been > "gone" for a long period of time (or else the user may think the data has been > lost) and (2) because we Piper will use "other people's computers" (we want > those people to decide when jobs will be run and to decide the resources to be > used). > > Thoughts? I think at least part of the work can be done by "regular" Overflow (pl) nodes. Just as Overflow defines Probes (which can be viewed as "breakpoints"), we could have log nodes that log whatever data "passes through them" and send the log to a central logging system that would correspond to the GMS part. Does that make sense? Jean-Marc From jarl at casema.net Wed May 24 03:01:38 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> Message-ID: <392B7E52.3A0ED0B7@casema.net> > > While designing Loci, my first thought was that these "jobs" could be handled > as they are on a supercomputer: with batch processing. This allows some > information to be returned about the progression of the job, cpu time used, > etc. It also allows jobs to be scheduled to run at a certain time, with a set > priority, etc. I think the sequence or hiarchy of the nets are something of high importance to a batch schedular: job that should not start untill other(s) are finished. Or job termintion once certain situations occure. I've worked a lot with JCL, job control language, with is the scripting language of IBM mainfraimes. A very typical aspect of jcl is that it's laking iterations and jumps. So no for\next until\while stuff and no goto's. Does Loci depends upon those or can we leave them out to? This way we'll eliminate deadlocks and halfway jumps. I suggest we'll ALWAYS use timeouts on jobs and use triggering or stalling as the only scheduling primals. I'm only talking about SUBNET batching, inside those at PL level nothing will change. The BL will already filter out the subnet structure, so it will be supplied with the execution scheme. We do not need any changes to the current XML definitions do we? I hope I'm being clear.. I had to code too much with JCL. Horrible devices those mainframes, for your pleasure I attached a jcl script 8) P.S. I'll be looking at how to implement the KQML as the communication protocol between BL instances. I dont think it's a question about 'whether or not' to use it anymore. It's just to perfect. [beep] democracy on this one :) bye, jarl From jarl at casema.net Wed May 24 03:03:36 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392AFEE2.9842375A@hermes.usherb.ca> Message-ID: <392B7EC8.9AB4F193@casema.net> > > I think at least part of the work can be done by "regular" Overflow (pl) nodes. > Just as Overflow defines Probes (which can be viewed as "breakpoints"), we could > have log nodes that log whatever data "passes through them" and send the log to > a central logging system that would correspond to the GMS part. Does that make > sense? Very much. But will Overflow pass job controll to the BL, or will it only notify? From jarl at casema.net Wed May 24 03:05:18 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392AFEE2.9842375A@hermes.usherb.ca> Message-ID: <392B7F2E.DE2D9BA2@casema.net> > I think at least part of the work can be done by "regular" Overflow (pl) nodes. > Just as Overflow defines Probes (which can be viewed as "breakpoints"), we could > have log nodes that log whatever data "passes through them" and send the log to > a central logging system that would correspond to the GMS part. Does that make > sense? [forgot this:] We there be need for scheduling overflow\PL nodes? I rather see whole subnets batched as a whole. Or does Overflow need\wants this? From jean-marc.valin at hermes.usherb.ca Tue May 23 23:29:49 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392B7E52.3A0ED0B7@casema.net> Message-ID: <392B4CAD.1C8ED2C9@hermes.usherb.ca> > > While designing Loci, my first thought was that these "jobs" could be handled > > as they are on a supercomputer: with batch processing. This allows some > > information to be returned about the progression of the job, cpu time used, > > etc. It also allows jobs to be scheduled to run at a certain time, with a set > > priority, etc. > > I think the sequence or hiarchy of the nets are something of high importance to a > batch schedular: job that should not start untill other(s) are finished. Or job Wouldn't all those dependencies be solved by "pulling" on the data-flow? or am I missing something? > termintion once certain situations occure. I've worked a lot with JCL, job control > language, with is the scripting language of IBM mainfraimes. A very typical aspect > of jcl is that it's laking iterations and jumps. > So no for\next until\while stuff and no goto's. Does Loci depends upon those or Loops are supported by Overflow through the "Iterator" (which derives from the subnet). I'm also using some kind of "checkpointing" in Overflow for very long jobs (a couple days of processing), such as neural network training. Now, about goto's, I'm strongly against them in a data-flow type of processing. > suggest we'll ALWAYS use timeouts on jobs and use triggering or stalling as the > only scheduling primals. > I'm only talking about SUBNET batching, inside those at PL level nothing will > change. I think most (though not all) of this is likely to be simpler if implemented in the PL. J-M P.S. Brad and I have ran into some problems with the antialiased gnome canvas as used in Overflow (But everything now *compiles* on FreeBSD). Has anyone compiled Overflow on something else than Mandrake 7.0 and FreeBSD? -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Wed May 24 08:57:35 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Development model proposal Message-ID: <200005241300.JAA72314@archa11.cc.uga.edu> Hello everyone; I was thinking a bit about cvs and development and stuff like that, and I thought it would be cool if we could kind of sketch out a plan for "how to work on piper cvs" so that we can make development go in as smooth a way as possible. I think this is important because we are going to have more people working on the same program, so I just wanted to try and make things go as smooth as possible. Towards this goal, I came up with the following points as an idea for how we should try and deal with cvs: 1. Only check in code which doesn't break the compilation/working of piper. That is, don't check in code which is going to require other people to fix it before they can work on their stuff. This doesn't seem to be a universally accepted way of doing things, but I think it is very nice. This doesn't mean that code has to be "perfect" to check in, but rather that there aren't any glaring issues that will be immediately a problem as soon as someone else tries to compile/run the cvs code. 2, Check in small chunks of code and changes frequently, rather than doing a lot of coding on your local machine and then trying to check it all in at once. This is also not a universally accepted way of doing things. For instance, on the bioperl project the way things work is that people work on big sections on their local machine for a long time and then try to merge it with the code in cvs. I think this way is a pain, and checking in frequently helps us to find bugs in each others code before they get too far. 3. Always write your changes in the ChangeLog, even if you only changed something very small. This way, if something isn't working, you can figure it out from the changes, instead of having to try and mail around to figure out what is going on. Something I haven't been doing, but which I think might be a good idea, is to also put the ChangeLog info into the cvs log message, so it is visible in cvsweb, and also if people like to browse log messages. This model requires people to update from cvs frequently, and make more cvs checkins, but I think this is nicer than duplicating/overlapping work that has to be merged. What does everyone think about this? More suggestions? Opposition to my suggestions? Profound pearls of wisdom? Brad From jarl at casema.net Wed May 24 08:15:03 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392B7E52.3A0ED0B7@casema.net> <392B4CAD.1C8ED2C9@hermes.usherb.ca> Message-ID: <392BC7C7.51665BF6@casema.net> > > I think the sequence or hiarchy of the nets are something of high importance to a > > batch schedular: job that should not start untill other(s) are finished. Or job > > Wouldn't all those dependencies be solved by "pulling" on the data-flow? or am I > missing something? > consider this structure: >--O1 \ >---O2--O5---O6--> / / >--O3 / / O4/ Where the O's are the nodes. Once could execute on dataflow basis, so O1,2 & 3 will run, and before O5 O4 has to run, so O5 will stall untill O4 is ready. As good batching will run O4 before O5 is stalled. But I must admit the dataflow is 90% of the batch logic. > > > termintion once certain situations occure. I've worked a lot with JCL, job control > > language, with is the scripting language of IBM mainfraimes. A very typical aspect > > of jcl is that it's laking iterations and jumps. > > So no for\next until\while stuff and no goto's. Does Loci depends upon those or > > Loops are supported by Overflow through the "Iterator" (which derives from the > subnet). I'm also using some kind of "checkpointing" in Overflow for very long > jobs (a couple days of processing), such as neural network training. Now, about > goto's, I'm strongly against them in a data-flow type of processing. > > > suggest we'll ALWAYS use timeouts on jobs and use triggering or stalling as the > > only scheduling primals. > > I'm only talking about SUBNET batching, inside those at PL level nothing will > > change. > > I think most (though not all) of this is likely to be simpler if implemented in > the PL. You did take cpu load, ram\HD space usage etc into account already? > > P.S. Brad and I have ran into some problems with the antialiased gnome canvas as > used in Overflow (But everything now *compiles* on FreeBSD). Has anyone compiled > Overflow on something else than Mandrake 7.0 and FreeBSD? I had it compiling on my slackware 7.0 with gcc 2.95.x manually installed. But I reinstalled slack :( From jarl at casema.net Wed May 24 08:39:18 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Development model proposal References: <200005241300.JAA72314@archa11.cc.uga.edu> Message-ID: <392BCD76.DD419146@casema.net> > 2, Check in small chunks of code and changes frequently, rather than > doing a lot of coding on your local machine and then trying to check > it all in at once. This is also not a universally accepted way of > doing things. For instance, on the bioperl project the way things work > is that people work on big sections on their local machine for a long > time and then try to merge it with the code in cvs. I think this way > is a pain, and checking in frequently helps us to find bugs in each > others code before they get too far. > We all run Unixxes, so maybe we could setup a cron\at scheme so that we all commit our code dayly, and check it out after all commit are finished? From chapmanb at arches.uga.edu Wed May 24 09:59:41 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Development model proposal Message-ID: <200005241402.KAA135188@archa10.cc.uga.edu> > We all run Unixxes, so maybe we could setup a cron\at scheme so that we > all commit our code dayly, and check it out after all commit are > finished? The only problem is that having cron jobs do the commiting might result in breaking suggestion #1, checking in code which doesn't work/compile. Also, a simple cvs commit won't work if you added new files or directories, and will also fail if your code isn't updated to the most recent version. So it might end up being less reliable that is sounds. Another idea that might help is that I know some places have cvs setup so that it sends out e-mails to developers when people make commits. I don't know much about setting this up, but I think if we had this going it would become clear pretty quickly how often and when people normally check in their stuff, so you could update after these times. Brad From jarl at casema.net Wed May 24 09:29:48 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Development model proposal References: <200005241402.KAA135188@archa10.cc.uga.edu> Message-ID: <392BD94C.EE485C6D@casema.net> > > Another idea that might help is that I know some places have cvs setup > so that it sends out e-mails to developers when people make commits. I > don't know much about setting this up, but I think if we had this > going it would become clear pretty quickly how often and when people > normally check in their stuff, so you could update after these times. > Ok, no cron job :) This email sounds good, Jeff, can you realize this? From chapmanb at arches.uga.edu Wed May 24 10:47:14 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:57 2006 Subject: [Pipet Devel] Development model proposal Message-ID: <200005241450.KAA68468@archa10.cc.uga.edu> > Ok, no cron job :) This email sounds good, Jeff, can you realize this? To avoid being a jerk who suggests things and has no idea how to implement them, I checked the cvs book Jeff suggested a while ago on the list (http://cvsbook.red-bean.com/cvsbook.html, a *very* useful book!), and this has a section on doing this ('Commit Emails'). Gary might know how well this would work under the new bioinformatics.org structure. Brad From jean-marc.valin at hermes.usherb.ca Wed May 24 11:28:32 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Development model proposal References: <200005241300.JAA72314@archa11.cc.uga.edu> <392BCD76.DD419146@casema.net> Message-ID: <392BF520.8FE8FC38@hermes.usherb.ca> > We all run Unixxes, so maybe we could setup a cron\at scheme so that we > all commit our code dayly, and check it out after all commit are > finished? Automatic commits won't work because you always need to do an update before you can commit a file that needs a merge. And the resulting code is very likely not to compile. Now I'm not sure e-mails would be the right solution. The likely outcome is that it will generate enough trafic that noone will look at it. If you read the section "What is CVS not?" in the book, you'll see "CVS is not a replacement for communication" ie, we should not try to automate everything. I suggest commiting small changes regularly and sending e-mails only when breaking source compatibility. I think with a little coordination and care, we can avoid most problems with little pain. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Wed May 24 11:44:14 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Development model proposal Message-ID: <200005241547.LAA29680@archa11.cc.uga.edu> Jean-Marc wrote: > Now I'm not sure e-mails would be the right solution. The likely outcome is > that > it will generate enough trafic that noone will look at it. I agree with you on this (even though I am the one who suggested e-mails :-). It probably will be too much noise. > I suggest > commiting > small changes regularly and sending e-mails only when breaking source > compatibility. I think with a little coordination and care, we can avoid most > problems with little pain. This is a very reasonible proposal and I'm all for it. I think what Jarl was worried about is making sure to always have the "most recent" cvs when working. For example, he could update and have me commit some changes 5 minutes later, and thus be working on the "old" stuff. I don't know if this will be a very big problem because: 1. We aren't hacking too much on the "exact same" code at the same time, and if two of us working on the same thing, they will need to coordinate personally. 2. Cvs is very good at handling updates to changed code. If someone made changes to files you didn't change locally, cvs will just update your local files without a problem. If they did make changes to a file you change, cvs produces a pretty reasonibly diff in the code which is easy to edit manually. 3. We definately should be reporting major source changes on the list, as Jean-Marc suggested :-) So, I'll put my vote in for no auto e-mails and more communication. Brad From jean-marc.valin at hermes.usherb.ca Wed May 24 14:27:47 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392B7E52.3A0ED0B7@casema.net> <392B4CAD.1C8ED2C9@hermes.usherb.ca> <392BC7C7.51665BF6@casema.net> Message-ID: <392C1F23.F60DBE41@hermes.usherb.ca> I think your structure didn't show up as you expected... >--O1 \ >---O2--O5---O6--> / / >--O3 / / O4/ Were you talking about the case where we haev one CPU, so one node running at the same time of multiple CPU's and multiple nodes at the same time? There is a basic threading support in Overflow that allows to compute multiple nodes at the same time, while taking care of dependencies... is that what you were thinking about? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Wed May 24 16:31:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Development model proposal References: <200005241547.LAA29680@archa11.cc.uga.edu> Message-ID: <392C3C31.74E5A7DB@geoserve.net> Brad Chapman wrote: > > 1. We aren't hacking too much on the "exact same" code at the same > time, and if two of us working on the same thing, they will need to > coordinate personally. This is key. We are each working on very distinct parts of Piper, with little overlap. Brad may end up working in the UIL from time to time, and perhaps the BL. But I doubt Jarl would work in the DL or UIL, nor will Jean-Marc work in the BL, DL or UIL. And Deanne and I will likely never work directly on the DL, BL or PL :-) > So, I'll put my vote in for no auto e-mails and more communication. Same here. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu May 25 01:46:41 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392B7E52.3A0ED0B7@casema.net> <392B4CAD.1C8ED2C9@hermes.usherb.ca> Message-ID: <392CBE41.392419F7@casema.net> > P.S. Brad and I have ran into some problems with the antialiased gnome canvas as > used in Overflow (But everything now *compiles* on FreeBSD). Has anyone compiled > Overflow on something else than Mandrake 7.0 and FreeBSD? > I've a problem: c++ -DLINUX=1 -DPROTOTYPES=1 -DHAVE_LIBM=1 -I. -I. -I../../data-flow/include -I../include -I/usr/local/include -g -O2 -c -fPIC -DPIC FFT.cc -o .libs/FFT.lo FFT.cc: In method `void FFT::calculate(int, int, Buffer &)': FFT.cc:66: passing `float *' as argument 2 of `rfftw_one(fftw_plan_struct *, fftw_real *, fftw_real *)' make[2]: *** [FFT.lo] Error 1 I did installed the fftw library and gcc 2.95.2, any thoughs? From jean-marc.valin at hermes.usherb.ca Wed May 24 17:06:02 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392B7E52.3A0ED0B7@casema.net> <392B4CAD.1C8ED2C9@hermes.usherb.ca> <392CBE41.392419F7@casema.net> Message-ID: <392C443A.4FABE238@hermes.usherb.ca> > I've a problem: > c++ -DLINUX=1 -DPROTOTYPES=1 -DHAVE_LIBM=1 -I. -I. -I../../data-flow/include > -I../include -I/usr/local/include -g -O2 -c -fPIC -DPIC FFT.cc -o .libs/FFT.lo > FFT.cc: In method `void FFT::calculate(int, int, Buffer &)': > FFT.cc:66: passing `float *' as argument 2 of `rfftw_one(fftw_plan_struct *, fftw_real > *, fftw_real *)' > make[2]: *** [FFT.lo] Error 1 > > I did installed the fftw library and gcc 2.95.2, any thoughs? Yes, you need to compile fftw with the --enable-float option. By default, it expects vectors of double. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Wed May 24 18:33:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] batch processing References: <3928430D.49E9AFFA@geoserve.net> <39290AC7.72590D1E@casema.net> <392AE16D.A7685FDB@geoserve.net> <392B7E52.3A0ED0B7@casema.net> <392B4CAD.1C8ED2C9@hermes.usherb.ca> Message-ID: <392C58C9.89D55F30@geoserve.net> Jean-Marc Valin wrote: > > P.S. Brad and I have ran into some problems with the antialiased gnome canvas as > used in Overflow (But everything now *compiles* on FreeBSD). Has anyone compiled > Overflow on something else than Mandrake 7.0 and FreeBSD? I compiled a previous version (not the latest) on RedHat 6.1. I think I had to leave out FFTW though. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu May 25 03:17:43 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Development model proposal References: <200005241547.LAA29680@archa11.cc.uga.edu> <392C3C31.74E5A7DB@geoserve.net> Message-ID: <392CD397.45D131D0@casema.net> > > This is key. We are each working on very distinct parts of Piper, with little > overlap. Brad may end up working in the UIL from time to time, and perhaps > the BL. But I doubt Jarl would work in the DL or UIL, nor will Jean-Marc work > in the BL, DL or UIL. And Deanne and I will likely never work directly on the > DL, BL or PL :-) > > > So, I'll put my vote in for no auto e-mails and more communication. > > Same here. Ok, adhoc emails it shall be From bizzaro at geoserve.net Thu May 25 08:21:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] DOA'00 Message-ID: <392D1AE6.842E112F@geoserve.net> Jarl, perhaps you could present a poster on Piper... 2nd International Symposium Distributed Objects & Applications University of Antwerp Antwerp, Belgium Sept. 21-23, 2000 http://www.cs.rmit.edu.au/doa/2000/ Jeff From jarl at casema.net Thu May 25 07:41:24 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] DOA'00 References: <392D1AE6.842E112F@geoserve.net> Message-ID: <392D1164.38E359B@casema.net> > Jarl, perhaps you could present a poster on Piper... I'll have a Piper Tshirt made :) > 2nd International Symposium Distributed Objects & Applications > http://www.cs.rmit.edu.au/doa/2000/ > cool! I probably visit it, it aint far away. The site is a bit incomplete, no program or prizes :( thnx 4 the link, jarl From bizzaro at geoserve.net Thu May 25 09:04:15 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] DOA'00 References: <392D1AE6.842E112F@geoserve.net> <392D1164.38E359B@casema.net> Message-ID: <392D24CF.A3B646A9@geoserve.net> Jarl van Katwijk wrote: > > > Jarl, perhaps you could present a poster on Piper... > > I'll have a Piper Tshirt made :) > > > 2nd International Symposium Distributed Objects & Applications > > > http://www.cs.rmit.edu.au/doa/2000/ > > cool! I probably visit it, it aint far away. > The site is a bit incomplete, no program or prizes :( Brad and I (and maybe others) will be preparing a poster for ISMB (Intelligent Systems for Molecular Biology) in San Diego, California in August. If you're serious about going to DOA'00, we can mail the poster to you right after. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu May 25 08:06:24 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] DOA'00 References: <392D1AE6.842E112F@geoserve.net> <392D1164.38E359B@casema.net> <392D24CF.A3B646A9@geoserve.net> Message-ID: <392D1740.71DC0EC0@casema.net> > > > > cool! I probably visit it, it aint far away. > > The site is a bit incomplete, no program or prizes :( > > Brad and I (and maybe others) will be preparing a poster for ISMB (Intelligent > Systems for Molecular Biology) in San Diego, California in August. If you're > serious about going to DOA'00, we can mail the poster to you right after. Mail me a Tshirt :) Joking, I'd like too once you people have one, here's my address: J.S. van Katwijk Beeklaan 404c 2562BH Den Haag The Netherlands This ISMB sounds pretty cool 2! I'll be going to this DOA'00 to see at which knowledge level other people nowerdays. I wont be actively promoting Piper or any of my idears. Maybe next time. bye, jarl From bizzaro at geoserve.net Thu May 25 10:16:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] DOA'00 References: <392D1AE6.842E112F@geoserve.net> <392D1164.38E359B@casema.net> <392D24CF.A3B646A9@geoserve.net> <392D1740.71DC0EC0@casema.net> Message-ID: <392D35C2.2711C933@geoserve.net> Jarl van Katwijk wrote: > > Mail me a Tshirt :) Yeah, we'll need promotional items some day. But what I mean by "poster" is not all that exciting. It's just a summary of one's research. See the attached photo of a poster I made for Loci last year. > This ISMB sounds pretty cool 2! Do you think you could make it to California? > I'll be going to this DOA'00 to see at which knowledge level other people > nowerdays. I wont be actively promoting Piper or any of my idears. Maybe next > time. So, you wouldn't want to hang a poster? It doesn't involve much. Other people just stop by and look it over. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: poster2.jpg Type: image/jpeg Size: 5944 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000525/9df9557e/poster2.jpg From bizzaro at geoserve.net Thu May 25 11:01:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] ISMB 2000 Message-ID: <392D405D.4EDDF11F@geoserve.net> I want to check again who will be going to ISMB 2000: http://ismb2000.sdsc.edu/ I haven't asked Deanne or David Lapointe yet, and Gary was going to get back to me about it. Brad, Jeff Chang, Harry, and Justin have said yes. Any others? It looks like I'll be going too. Brad and I are preparing a poster for ISMB and also BOSC: http://ismb2000.sdsc.edu/bosc2000/ Anyone going to BOSC as well? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu May 25 11:37:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Developing GNOME Applications with Gnome-Python Message-ID: <392D48A1.DE9513D3@geoserve.net> "In this article we'll show you how you can use the Gnome-Python module for creating GNOME applications with Python. Can Python, the interpreted, object oriented (OO), high-level programming language that has become so widely popular among programmers, really be used for creating GUIs? Of course it can! In fact, you can create whole GNOME applications with it. Using this Python module, creating GNOME applications will be easier and faster." http://www.linuxdev.net/features/articles/05.24.2000/index.shtml Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Fri May 26 01:08:07 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Gnome 1.2 and Overflow Message-ID: <392E06B7.D376BC73@hermes.usherb.ca> Hi everyone, This may be of interrest to some people. I've just tried gnome 1.2 (Helix). The good news is that it doesn't break source or binary compatibility with Overflow. The bad news is that there is one bug and one "very undesirable feature". The bug is in the text canvas item and make the boxes around nodes too large. The "very undesirable feature" concerns those who run gnome with a locale that use the "," as a decimal mark. For me (I use the french locale), the floating point numbers are printed and parsed with a "," insteat of a ".", which breaks everything. This affects C++ streams. I don't know whether the printf and scanf are affected. The only way around is to unset the language environment variables. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Fri May 26 11:12:45 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Gnome 1.2 and Overflow Message-ID: <200005261515.LAA73610@archa10.cc.uga.edu> > The "very undesirable feature" concerns those who run gnome with a locale > that > use the "," as a decimal mark. Well, why would anyone ever want to run in a non-english locale? :-) > For me (I use the french locale), the floating > point numbers are printed and parsed with a "," insteat of a ".", which > breaks > everything. This affects C++ streams. I don't know whether the printf and > scanf > are affected. The only way around is to unset the language environment > variables. I don't know how stable 1.2 is supposed to be (it's still in the preview stage, right?) but I would report this. It seems like they are very for supporting internationalization, so they would probably be quite iterested to hear about this problem. Brad From jarl at casema.net Fri May 26 21:45:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Gnome 1.2 and Overflow References: <200005261515.LAA73610@archa10.cc.uga.edu> Message-ID: <392F289D.931C1E7F@casema.net> > > Well, why would anyone ever want to run in a non-english locale? :-) > `killall -9 --gid=usa` > > > For me (I use the french locale), the floating > > point numbers are printed and parsed with a "," insteat of a ".", > which > > breaks > > everything. This affects C++ streams. I don't know whether the > printf and > > scanf > > are affected. The only way around is to unset the language > environment > > variables. > > I don't know how stable 1.2 is supposed to be (it's still in the > preview stage, right?) but I would report this. It seems like they are > very for supporting internationalization, so they would probably be > quite iterested to hear about this problem. gtk 1.4 will get fill i18n support; gnome being build on top of gtk 1.2 will keep having non-100% locale support :( My personal opinion is alien languages like dutch should be low priority. sorry bout being not really constructive, jarl From jean-marc.valin at hermes.usherb.ca Fri May 26 13:14:19 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Gnome 1.2 and Overflow References: <392E06B7.D376BC73@hermes.usherb.ca> Message-ID: <392EB0EB.9F4F5C9A@hermes.usherb.ca> > This may be of interrest to some people. I've just tried gnome 1.2 (Helix). The > good news is that it doesn't break source or binary compatibility with Overflow. > The bad news is that there is one bug and one "very undesirable feature". The > bug is in the text canvas item and make the boxes around nodes too large. This bug is now fixed in the gnome CVS. > > The "very undesirable feature" concerns those who run gnome with a locale that > use the "," as a decimal mark. For me (I use the french locale), the floating > point numbers are printed and parsed with a "," insteat of a ".", which breaks > everything. This affects C++ streams. I don't know whether the printf and scanf > are affected. The only way around is to unset the language environment > variables. I solved the problem by calling: setlocale (LC_NUMERIC, "C"); after the gnome_init(...) Case solved! Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Fri May 26 19:06:27 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Understanding Overflow + Getting programs to work under piper Message-ID: Hey everyone; I've been on a mission to try and understand how Overflow works so that we can start to get it integrated into Piper. Towards this goal, Jean-Marc was kind enough to help me work through some of the areas where I was stuck. We thought the IRC conversation might also be useful for other people who are interested, so here goes. Enjoy! Brad brad-: Started <- Sure. Did what I was talking about in my e-mail make any sense? jm: Well, I'm having some problems with your terminology... brad-: What terminology? jm: But I understand you don't want to link the DL with Overflow brad-: Linking Dl and Overflow <- Well, I think most of the linking will be occuring at the level of the bl, right? brad-: If there are parts of Overflow you think would be useful in the dl, I'm definately more than happy to use them! jm: I don't understand what you're refering to by "A piper user should be able to wrap any program" brad-: Okay, what I'm trying to talk about is having a user be able to convert a program (or library) to be able to run under piper. jm: Well, all Overfow nodes need to be classes... using a program has to be done by wrapping it in a node. brad-: I've been trying to go through Overflow to see how the libraries you are using get loaded to work with the program, but I get kind of lost. I can't see the link... brad-: When you say wrapping in a node, how does this work. For instance, let's just take the HMM library. Where in the code does it get integrated into Overflow? jm: Well when you do a dlopen() on the librairy, the code for the node gets loaded and there's an initializer that sets some data about how to create each node in the lib, as well as what inputs/outputs/parameters are required brad-: Okay, this was the general picture I had. What specifically is the initializer that sets the data and figures out the inputs/outputs/parameters? jm: BTW, all those libraries contain classes that all derive from the base "Node" class jm: If you look at .cc files that define nodes, all have the NODE_INFO(...) macro at the start. jm: The macro arguments are the node name, category, inputs, outputs, parameters brad-: Oh, macros, okay. Where is the macro defined? jm: It's in data-flow/include/Node.h brad-: Okay. Gotcha on that. So If I wanted to get a new library working under Overflow, what steps would I need to take? jm: Basically, it uses a C++ initializer to call addFactory(...) with all the data. brad-: Yeah, I'm just looking at it. Man, I was having the hardest time trying to figure out how NodeFactories got added :-) jm: You create a class that derives from Node and understands the getOutput(...) method. Then you include the NODE_INFO macro and link with it brad-: Okay, makes sense, I gotcha. What are your thoughts on ways to move this system into piper? jm: The idea is that in C++, you can define a global variable as int dummy = some_funct(); and some_funct() will get called before the main starts (or when the library is linked) jm: Two ways: 1) get the data by linking with the library (which you don't like), or 2) get the data somewhere else. jm: One way would be to create an executable that loads all those libs and outputs the content of the NodeDictionary in an XML file. brad-: Get the data by linking with the library <- It is not that I don't like this :-). I just was trying to think of a way to generalize it so people wouldn't have to know c++ to get a program working under piper. jm: What do you mean by "get programs working under piper"? brad-: loading libs to XML <- This sounds very nice :-). That sounds like a good way to go. The Overflow could link in the libraries and get their info, and I could link in the libraries in the dl and output the info as an XML file. This way the info would then be available to send to the ui. jm: There is already a node (C++ class) that takes a program name as input and outputs the stdout of the program brad-: "get programs working under piper" <- Oh sorry, my bad terminology again :-). What I'm just trying to say: integrate a program into piper so that it can be used as a piper node. brad-: program name node <- Where is this defined? Also, how can we get at the available flags, etc to send to the program? jm: There will be a set of nodes that can "talk" to other programs... But no need to code a new node for each program you want to use in piper. jm: It's called ExecStream brad-: ExecStrem <- Gotcha. I'll talk a look at this later and understand what is going on :-) brad-: Okay, maybe I should stop chatting now and take some time to look things over again with all of the new info :-) jm: I'm going to have dinner anyway... ttyl brad-: I'll have better questions to ask you once I manage to understand things more. jm: BTW, we should save the log... it might help other people... brad-: Have a good dinner. Thanks for talking me through this, I really appreciate it! ttyl From chapmanb at arches.uga.edu Sat May 27 15:51:44 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Propoal for integrating Overflow Message-ID: <200005271954.PAA75270@archa11.cc.uga.edu> Hello all; I've been thinking a lot about how to start getting Overflow integrated into Piper so that we can start getting all three programs working together to actually start doing something. Towards this goal, I went back to the simple example of using the unix command "ls" as our starting point. What I'd like to try and do is use the Overflow ExecStream class (in data-flow/src/ExecStream.cc), which runs a command line argument, returning the output as a string. So the simple goal is to re-do what I had going a long time ago (but now in a real format that will actually do something more interesting later) and pipe the output of an ls statement into a text viewer. So here is the way I'd like to propose to do that: 1. Create a simple XML document to describe 'ls'. I've done this already (yay! step 1 done!) and it is at the bottom of this mail, along with a dtd which is just a start towards generating a format for writing these xml files). The idea is that this XML file can be used to read all of the information about how to deal with a program. Right now, we can just write these by hand (for simplicity) and later can explore Jeff's plans to have the user be able to develop these in the user interface, and Jean-Marc's ideas to be able to generate these files automatically by dlopening a library. 2. Use this xml file to be able to build a command line in the user interface. Right now I propose that we use a really simple widget, with a text box to type in the command line, and a button which pops up the description. This will free Jeff and Deanne from having to feel pressured to produce something quickly, but will still allow everyone else to be able to use the UIs for testing (since it is hard to test things when you have nothing to drive them :-). Of course, this UI can expand to be a lot more user friendly as Jeff and Deanne see fit. I need to work on the dl as well to be able to give this description to the uil in a nice format. 3. Once the work-flow diagram (of a 'ls' command piped into a viewer) is completed, the ui will need to submit this diagram to the dl. From there, the dl will need to convert this diagram into a Overflow style XML file. This is coming along as I've wrapped the Overflow classes that do this... 4. Have the dl submit the created xml description to gms (the bl). Jarl and I worked out this interface and are working on connecting us, so hopefully this will be ready soon. 5. For right now, just have the bl submit the xml document directly to Overflow, and use Overflow's 'pull technology' to run the document and return the output to the bl. Looking at Overflow, I'm not exactly positive about the way to do this in Overflow, but it seems like using the UIDocument class (in vflow/src and include) with a UIDocument::load and a UIDocument::run might be the way. I think there might need to be some modifications here becaue of the next step... 6. Overflow (the pl) returns the results to the bl. Then the bl passes them back to the dl, and voila, they are sent back to the user interface where they are displayed. I know this isn't perfect and that 'ls' isn't the most exciting program to get working through this system but I think this might provide us with some initial connectivity, and a place to build on for more exciting things, and will help us get the problems connecting things ironed out right away. What do people think of this idea? Opposition? Suggestions? Mistakes I made? Things I didn't think of? Random comments about unbelievably bad the Detroit Tigers are doing yet again this year? Anything? Anyways, thanks for reading all the way though this. Below, for your further reading enjoyment, are the ls.xml class and the _very preliminary_ dtd for representing a program "plugged in" to Piper. These will be in cvs whenever piper gets to go to its new home. Brad ls [-ACFLRTWacdfiloqrstu1] [file ...] For each operand that names a file of a type other than directory, ls displays its name as well as any requested, associated information. For each operand that names a file of type directory, ls displays the names of files contained within that directory, as well as any requested, asso- ciated information. If no operands are given, the contents of the current directory are dis- played. If more than one operand is given, non-directory operands are displayed first; directory and non-directory operands are sorted sepa- rately and in lexicographical order. From chapmanb at arches.uga.edu Sat May 27 18:08:53 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:58 2006 Subject: [Pipet Devel] Abstract on Piper/Loci for ISMB and BOSC Message-ID: Hello all! Jeff and I (at least) are planning on going to BOSC (http://ismb00.sdsc.edu/bosc2000/) and ISMB (http://ismb00.sdsc.edu/) and presenting a poster. Towards this end, we wrote up an abstract targetted at the use of Piper (was Loci) in bioinformatics research for these conferences. We were hoping we might be able to get some feedback from everyone about the abstract--any comments: good, bad or indifferent would be *extremely* appreciated. The deadline for the abstracts is in a few days (May 31st--of course we're doing this at the last minute)... Anyways, below is the abstract. Thanks in advance for your time. Brad Piper: A Distributed Platform for Linking Bioinformatics Programs J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad Chapman, Dominic Letourneau, Deanne Taylor A typical problem in bioinformatics research is linking together multiple programs to process information. A common example of this is in building phylogenetic trees from DNA sequences. The sequences are intially aligned using a sequence alignment program, are then analyzed in a phylogeny program to produce trees, and finally the trees are visualized in a viewer. This process can be further complicated by the fact that the programs may have incompatible inputs and outputs, as well as extensive memory and processing requirements. To address these problems the authors have developed Piper, a distributed platform to link bioinformatics programs. Piper is designed to provide a wrapper around exisiting bioinformatics programs so that they can be connected and executed in an intuitive manner. In addition, individual programs can be located on remote computers, so that expensive calculations can be executed on more robust equipment. Piper is designed as a modular system using CORBA connectivity as the backbone to link the modules. This design allows multiple user interfaces to control the core processing engine. In addition, Piper is being developed under an open-source model, allowing contribution and design feedback from individuals in multiple area of bioinformatics. Applications of Piper in comparative genomic mapping and phylogenetic analysis are discussed. From bizzaro at geoserve.net Sat May 27 19:30:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Re: Abstract on Piper/Loci for ISMB and BOSC References: <200005260124.TAA12323@penguin.pharmacy.ualberta.ca> Message-ID: <39305A8A.CB913DC9@geoserve.net> Gary Van Domselaar wrote: > > My understanding was that Piper is data-independent. Loci is the > 'bioinformatics layer' that will run on top of Piper. So would > > "Piper & Loci" A Distributied Platform for Linking Bioinformatics > Programs" be more appropriate. We could then make the distinction between > loci and piper. BTW, I spoke to Gary about this when we met yesterday in Boston. I agree with Gary that Piper shouldn't be proposed as a bioinformatics-only system (some of the wording gives that impression). But I don't want to say "Piper/Loci" either (Loci will be the name of a model collaboratory based on Piper and not REALLY a software layer -- more on this later). So, I think we should word it to say Piper CAN distribute bioinformatics applications, rather than Piper IS SPECIFICALLY FOR distributing bioinformatics applications. How about this: "Distributing Bioinformatics Applications with Piper" ? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun May 28 12:27:22 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] front(uil) to middle(dl) communication Message-ID: <200005281630.MAA106754@archa11.cc.uga.edu> Hey Deanne and Jeff; Since you guys are planning on doing both fronts in python, what I was thinking about doing was taking the front to middle XML protocol and extracting it into python function calls, so that a lot of the XML generating code could be reusable in both of your front ends. For instance, instead of having to generate XML like this to connect two nodes: Instead, I could just add a function call like: connect_loci(self, workspace_id, input_id, in_connector_id, output_id, out_connector_id), and you could just call this instead, and all of the xml building could happen inside of this. I think this would make more efficient re-use of code, and could help pave the way towards a corbafied front to middle communication protocol. What do you guys think about this? If you like it, I can put it together on my local copy and make a new tarball of it, so you can work off of this (since we don't have cvs ready for the new directory structure yet). Brad From deanne at density.biop.umich.edu Sun May 28 12:41:51 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Front to middle, peep, and piper. In-Reply-To: <200005281630.MAA106754@archa11.cc.uga.edu> Message-ID: > Hey Deanne and Jeff; > Since you guys are planning on doing both fronts in python, what I > was thinking about doing was taking the front to middle XML protocol > and extracting it into python function calls, so that a lot of the > XML generating code could be reusable in both of your front ends. For > instance, instead of having to generate XML like this to connect two > nodes: > > > > > connector_id = '1'/> > connector_id = '1'/> > > > > Instead, I could just add a function call like: > > connect_loci(self, workspace_id, input_id, in_connector_id, > output_id, out_connector_id), > > and you could just call this instead, and all of the xml building > could happen inside of this. I don't know enough XML to parse this correctly, but I assume you're speaking about a function call that will link nodes together w/out XML building the links? > I think this would make more efficient re-use of code, and could > help pave the way towards a corbafied front to middle communication > protocol. I'm all for corbafied front to middle. > What do you guys think about this? If you like it, I can put it > together on my local copy and make a new tarball of it, so you can > work off of this (since we don't have cvs ready for the new directory > structure yet). I'm still in dissertation hell. I'm working today (and was yesterday) on still poking away at my python skills. I feel a bit overwhelmed still, mostly for all the reasons beyond "where does peep actually fit in" to "what the heck is bl, dl, and etc?" I love python, though. The tty thing, is just about reading input from the keyboard and returning the input from the python function. I found ttyio.py that only returns what you want the keyboard to return (it traps exceptions and also can be modified to transform inputted text into your own definitions). Anyway, I need to figure out exactly what peep is going to be expecting in this input thing. Are we going to be doing all the text filtering at the layer of input, or is it going to be a free-for-all and the downunder going to sort it/handle exceptions? If so, then all the peep input is going to do is to read the text input and then return the character and wait for the next one, until a condition is reached. I can have a tree of input functions that read off one another? I need to know what i'm going to aim for next. I don't have a good idea of what peep needs to be doing. Should I start stripping gnu from stuff? And when should I start worrying about that? From bizzaro at geoserve.net Sun May 28 13:51:50 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Front to middle, peep, and piper. References: Message-ID: <39315CB6.40E3D130@geoserve.net> deanne@density.biop.umich.edu wrote: > > The tty thing, is just about reading input from the keyboard and returning > the input from the python function. I found ttyio.py that only returns > what you want the keyboard to return (it traps exceptions and also can be > modified to transform inputted text into your own definitions). > > Anyway, I need to figure out exactly what peep is going to be expecting in > this input thing. Are we going to be doing all the text filtering at the > layer of input, or is it going to be a free-for-all and the downunder > going to sort it/handle exceptions? If so, then all the peep input is > going to do is to read the text input and then return the character and > wait for the next one, until a condition is reached. I can have a tree of > input functions that read off one another? I'm not sure we need exception checking at the character-by-character level, except perhaps for arrow and delete keys. The input layer shouldn't be verifying commands, just passing a string of text on to the netherlands when ENTER is pressed. About commands, we need to come up with a list of them. Unlike the Unix command line, these commands are not programs. They're more like FTP commands, so we can start with the HELP command to list all of the others. I can't give you a complete list of commands yet, because there's likely to be more functionality to come. I want Peep to do whatever Pied does, except with text. Here are some I can think of off-hand: connect [node] [pipe] [to] [node] [pipe] disconnect [node] [pipe] [[from] [node] [pipe] ] list [nodes] change [network (or node)] select [node] deselect [node] view [interface] (also view with ability to set parameters) (also some execution commands) Of course, [] means optional, and <> means variable. can also be "." and ".." So, we actually need a layer lower than the tty layer to evaluate the command line. > I need to know what i'm going to aim for next. I don't have a good idea of > what peep needs to be doing. Should I start stripping gnu from stuff? And > when should I start worrying about that? Okay, so the command-line evaluator is next. It'll be a while longer before we see Peep come together, since I'd like Brad to implement abstraction from the XML API he just wrote about. Be patient :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun May 28 13:55:36 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] front(uil) to middle(dl) communication References: <200005281630.MAA106754@archa11.cc.uga.edu> Message-ID: <39315D98.D827F031@geoserve.net> Brad Chapman wrote: > > Instead, I could just add a function call like: > > connect_loci(self, workspace_id, input_id, in_connector_id, > output_id, out_connector_id), Great! It'll make both Peep and Pied easier to develop, and as you said, it'll make CORBA easier to implement. Go fer it, Dude! Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Sun May 28 13:45:08 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Front to middle, peep, and piper. In-Reply-To: <39315CB6.40E3D130@geoserve.net> Message-ID: > About commands, we need to come up with a list of them. Unlike the Unix > command line, these commands are not programs. They're more like FTP > commands, so we can start with the HELP command to list all of the others. Right, gotcha. > Here are some I can think of off-hand: > So, we actually need a layer lower than the tty layer to evaluate the command > line. Okay, that helps...I'll keep that in mind. > Okay, so the command-line evaluator is next. It'll be a while longer before > we see Peep come together, since I'd like Brad to implement abstraction from > the XML API he just wrote about. Be patient :-) (puts on her Zen face) This tells me I have to learn XML, oh mah oui. From bizzaro at geoserve.net Sun May 28 14:03:27 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Front to middle, peep, and piper. References: Message-ID: <39315F6F.DD4077F7@geoserve.net> deanne@density.biop.umich.edu wrote: > > > Okay, so the command-line evaluator is next. It'll be a while longer before > > we see Peep come together, since I'd like Brad to implement abstraction from > > the XML API he just wrote about. Be patient :-) > > (puts on her Zen face) > > This tells me I have to learn XML, oh mah oui. No, just the opposite. When Brad puts the XML stuff into its own module, we won't have to touch it. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Mon May 29 14:31:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Communication DL->BL References: <200005271954.PAA75270@archa11.cc.uga.edu> Message-ID: <3932B765.7407B85D@casema.net> > > I've been thinking a lot about how to start getting Overflow > integrated into Piper so that we can start getting all three programs > working together to actually start doing something. Towards this goal, > I went back to the simple example of using the unix command "ls" as > our starting point. What I'd like to try and do is use the Overflow > ExecStream class (in data-flow/src/ExecStream.cc), which runs a > command line argument, returning the output as a string. So the simple > goal is to re-do what I had going a long time ago (but now in a real > format that will actually do something more interesting later) and > pipe the output of an ls statement into a text viewer. > Sorry Brad bout this late response. I've just a very small reply: this proposal sounds fine to me, lets use it to get the 1st Piper stream running! For everybody's pleasure: I've been working on the DL->BL corba communication layer , and after some horrible problems, it's working now. It's now finished, but the DL Python code IS calling a BL C function. After this it's just a matter of getting the other corba functions running the way this 1st one does. I'll inform you people when you can checkout the fully communicating sources. bye, jarl From chapmanb at arches.uga.edu Mon May 29 09:47:08 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Take 2--Abstract on Piper/Loci for ISMB and BOSC Message-ID: Hello again; I got some very helpful comments on the abstract for Loci/Piper and made a few changes to it, so I thought I would resend it with the new info. Once again, if anyone has any comments, no matter how small, they would be much appreciated. Also, I need to get address info for everyone mentioned in the authors so I can get this together, so if you are listed please send me an e-mail off the list and drop me the info. Or, if Jeff has an idea how we can just all be referenced as coming from "The Open Lab" that would be even better. Now for your reading pleasure... Distributing Bioinformatics Application with Piper J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad Chapman, Dominic Letourneau, Deanne Taylor A typical problem in bioinformatics research is linking together multiple programs to analyze a set of information. A common example of this is in building phylogenetic trees from DNA sequences. The sequences are intially aligned using a sequence alignment program, are then analyzed in a phylogeny program to produce trees, and finally the trees are visualized in a viewer. This process can be further complicated by the fact that the programs may have incompatible inputs and outputs, as well as extensive memory and processing requirements. To address these problems the authors have developed Piper, a distributed platform that can be used to link bioinformatics programs. Piper is ideally suited to bionformatics analysis in that it can combine highly specific, modular, data repositories and data analysis functions together to provide sophisticated and efficient data processing networks. Piper is designed to provide a wrapper around exisiting bioinformatics programs so that they can be connected and executed in an intuitive manner. In addition, individual programs can be located on remote computers, so that expensive calculations can be executed on faster, dedicated systems. Piper is designed as a modular system using CORBA connectivity protocols as the backbone to link the modules. This design allows multiple user interfaces to control the core processing engine. In addition, Piper is being developed under the Open Source model, allowing contribution and design feedback from individuals in multiple area of bioinformatics. Piper is especially well suited to for automated high-throughput data analysis like protein fold identification, sequence condiditioning such as repeat/vector masking and data format conversion, and customization of batch scripting processes such as building phylogenetic trees from DNA sequences. From bizzaro at geoserve.net Mon May 29 10:23:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Re: Take 2--Abstract on Piper/Loci for ISMB and BOSC References: Message-ID: <39327D7F.D286C621@geoserve.net> Brad Chapman wrote: > > Hello again; > I got some very helpful comments on the abstract for Loci/Piper and > made a few changes to it, so I thought I would resend it with the new info. > Once again, if anyone has any comments, no matter how small, they would be > much appreciated. > Also, I need to get address info for everyone mentioned in the > authors so I can get this together, so if you are listed please send me an > e-mail off the list and drop me the info. Or, if Jeff has an idea how we > can just all be referenced as coming from "The Open Lab" that would be even > better. Especially being a poster, I think one address will do. You can put an asterisk next to my name and below write... * Corresponding author: Bioinformatics.org: The Open Lab c/o Department of Chemistry University of Massachusetts Lowell Lowell, MA 01854 jeff@bioinformatics.org > Now for your reading pleasure... I don't have any major changes, just some spelling corrections, etc. > Distributing Bioinformatics Application with Piper Applications > J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad > Chapman, Dominic Letourneau, Deanne Taylor Dominic Letourneau and Deanne Taylor > A typical problem in bioinformatics research is linking together > multiple programs to analyze a set of information. A common example of this > is in building phylogenetic trees from DNA sequences. The sequences are > intially aligned using a sequence alignment program, are then analyzed in a > phylogeny program to produce trees, and finally the trees are visualized in > a viewer. This process can be further complicated by the fact that the > programs may have incompatible inputs and outputs, as well as extensive > memory and processing requirements. To address these problems the authors > have developed Piper, a distributed platform that can be used to link > bioinformatics programs. Piper is ideally suited to bionformatics analysis analysis or analyses [?] > in that it can combine highly specific, modular, data repositories and data > analysis functions together to provide sophisticated and efficient data > processing networks. Piper is designed to provide a wrapper around > exisiting bioinformatics programs ...existing programs... [Piper is not designed FOR bioinformatics] or Piper provides a wrapper around existing bioinformatics programs... > so that they can be connected and > executed in an intuitive manner. In addition, individual programs can be > located on remote computers, so that expensive calculations can be executed ...on remote computers so that... [no comma] > on faster, dedicated systems. [Since we use "system" to describe Piper, should we use something else here?] ...on faster, even dedicated hardware. > Piper is designed as a modular system using > CORBA connectivity protocols as the backbone to link the modules. This > design allows multiple user interfaces ...allows multiple and different kinds of user interfaces... > to control the core processing > engine. In addition, Piper is being developed under the Open Source model, > allowing contribution and design feedback from individuals in multiple area areas > of bioinformatics. Piper is especially well suited to for automated > high-throughput ...well suited to automate high-throughput... or ...well suited for automating high-throughput... or ...well suited for automated, high-throughput... > data analysis like protein fold identification, sequence > condiditioning conditioning > such as repeat/vector masking and data format conversion, > and customization of batch scripting processes such as building > phylogenetic trees from DNA sequences. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Mon May 29 11:38:01 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: Take 2--Abstract on Piper/Loci for ISMB and BOSC In-Reply-To: <39327D7F.D286C621@geoserve.net> Message-ID: > asterisk next to my name and below write... > > * Corresponding author: > Bioinformatics.org: The Open Lab > c/o Department of Chemistry > University of Massachusetts Lowell > Lowell, MA 01854 > jeff@bioinformatics.org You might also wish to include the relevant institution for various people in smaller letters with other symbols, since we're not at UMass. It's an academic point, but traditional even in posters. > > A typical problem in bioinformatics research is linking together > > multiple programs to analyze a set of information. A common example of this > > is in building phylogenetic trees from DNA sequences. The sequences are > > intially aligned using a sequence alignment program, are then analyzed in a > > phylogeny program to produce trees, and finally the trees are visualized in > > a viewer. This process can be further complicated by the fact that the > > programs may have incompatible inputs and outputs, as well as extensive > > memory and processing requirements. To address these problems the authors > > have developed Piper, a distributed platform that can be used to link > > bioinformatics programs. Piper is ideally suited to bionformatics analysis > > analysis or analyses [?] Actually, it isn't PIPER that is suited to "bioinformatics analysis" but that Piper is the analysis agent.... "Piper is ideally suited to broker bioinformatics analyses in that it can combine highly specific..." etc. From bizzaro at geoserve.net Mon May 29 18:00:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] Abstract on Piper/Loci for ISMB and BOSC Message-ID: <3932E893.1F0A6676@geoserve.net> Distributing Bioinformatics Applications with Piper J.W. Bizzaro, Gary Van Domselaar, Jarl van Katwijk, Jean-Marc Valin, Brad Chapman, Dominic Letourneau and Deanne Taylor ABSTRACT The service consists of a human interface component comprising starter utility object consisting of the utility server resulting in the database service consisting of a utility network connection whereas said utility server consisting of a remote host apparatus connected by desired database object consisting of a database computer consisting of the utility server consisting of a database functionality connected by desired remote host object resulting in said utility service resulting in starter database object comprising desired utility object connected by a utility client comprising starter database object providing access to starter human interface computer comprising desired database computer whereas a remote host component resulting in a remote host computer providing access to starter utility component providing access to the human interface server consisting of a remote host apparatus comprising said remote host server connected by the human interface server whereas the database server consisting of the remote host object providing access to a database functionality. ;-) (saw this on Slashdot) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Tue May 30 02:49:05 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] IRC - Overflow/Piper merging and XML files Message-ID: Hello all; Jean-Marc and I were talking on IRC last night trying to get things set up for merging Piper and Overflow, and also just generally discussing other stuff about the definition layer and XML representing nodes/loci. I thought some people might be interested, so here's the log. Questions/comments are more than welcome, as always. Happy reading! Brad jm: I was wondering, do you think the UI* class (after some added features) could fit for the whole GUI (both Overflow and GMS)? brad: Yeah, that is exactly what I've been trying to figure out :-). What I'm thinking about doing is adjusting the XML stuff I have now in the dl to make it look more like the UI stuff, and then go from there. As I'm redoing this communication I'm stealing a lot from Overflow, like using parameters to represent everything "internal" to a node. jm: What do you mean by adjusting the XML. BTW, just to make sure I'm not dead wrong, for me the UI* classes would be the equivalent of the DL and the GUI* would be the GUI. brad: Well, the dl currently has it's own xml format that it stores everything about the ui in. It is a lot different then Overflow's because each node stores its info in a separate xml file, and the files are updated constantly as the ui changes. brad: UI* and DL, GUI ad UI <- Right, they are approximately equivalent :-). I think they each do some different things which I'd like to merge together. For instance, one big thing that the dl does right now is deal with the filesystem and with connecting to databases, which I need for the stuff I want to do. Of course, Overflow brad: ... does a lot of things that the dl doesn't... jm: We need to be careful about the meaning of node. Is it node as a class or node as an instance of the class. For instance, the "ls.n" wrapper would be a node class, while the place you use it in a program would be a node instance. jm: I don't see a reason to put each node instance in a separate XML file, while putting each node class definition in a separate file makes sense (except for the builtin node classes with are in .so) brad: Right, good point. What I mean is that each "node instance" in a program has an individual XML file describing it. brad: The reason for this is that I see the node instance and class definition as one in the same. The instance can just be modified by changing parameters when the user is building a work-flow diagram. brad: So I guess I sort of see node instances and class definitions as more similar than you do. But I'm not sure if this is the right way to think about it... jm: I'm not sure we're talking about the same thing. Using the "C function" analogy, the node class is the code (and prototype) for the function, while the node instance is simply a function call. jm: Maybe one thing that (I think is different from Loci) is the recursivity introduced by the "a Network is a Node" brad: Okay, but I see the XML file as being part of the code. So, where you put the info about parameters, inputs and outputs into the code describing a node, I would rather have this info in the XML file describing a node. Then the code could get this information from the XML file. Does that make any sense? brad: "a Network is a Node" <- We do have the same sort of thing in Loci actually. The 'composites' (in Loci, the equivalent of Networks) are also nodes. So they also have XML definitions. Is this what you mean by recursivity? jm: Let's take the 'ls.n' example, this file is a "node class definition" (I just made up the expression). The parameters it accepts are defined from the "subnet_param"s you use, and the inputs and outputs are defined from the net terminals. jm: Now, when you want to use the ls node, you bring up an instance of it (with the new node menu). The system then identifies what parameters, inputs and outputs are required. You can then connect it to other node instances. jm: Are we talking about the same thing? brad: Okay, I'm with you. brad: I think we are talking about the same thing :-) jm: (the networks are node is what I meant by recursivity... I didn't know Loci was doing it too) brad: Loci doing it <- Well, sort of but not really yet. We are not really at that stage yet because we don't have plugged in programs to do that with, so we never really got past the "base" types. jm: Basically, what goes between the and the is just the equivalent of a function call: you specify the parameters you pass to the function, but this function is defined elsewhere. brad: So the idea was discussed, but not yet implemented. Hopefully for Piper we can swipe this from Overflow :-). jm: Is the "each node is defined in a XML file" the equivalent of defining 'ls.n' in it's own file? brad: I see what you are saying. One issue to consider in piper is that the dl doesn't have direct access to the "function" to get the information about it like Overflow does (because of the added layers of abstraction). This is why I want to put the info about what needs to be passed to the function call into an xml file. Does that make sense? brad: each node like ls.n <- Yes, exactly. Except I am just extending the concept to also include "base" (non-derived) nodes. jm: Just to make sure, that would be (for Overflow) to have one (or many) XML file that keeps the data about builtin nodes so you don't need to load the libs to get it? brad: Right, so you get the data without loading the libs, exactly :-). jm: I was thinking about doing that... that's one of the things I wanted to discuss with you. brad: Cool :-). brad: IMO, we should just stick with doing it in Piper and kind of focus on that, if you don't mind too much. Or do you want to add it to Overflow "stand-alone" as well. jm: However, I'm not sure about the details: One big file, one file per lib, one file per node? What do we do to make sure everything is consistent? ... jm: I don't want to keep two separate ways of doing the same job, let's try to find something that will fit for both Piper and stand-alone Overflow brad: I guess it should start with one xml file per "function call" where a "function call" is the smallest possible node that could be useful to do something. Then other xml files can build from these. How does that sound? brad: separate ways <- Good! I just didn't want to have to try and remember two different ways :-). jm: You mean one "fnuction definition"? brad: Yeah function definition :-) Sorry. jm: Then a builtin node XML file would contain fields about "which lib to load" and "what C++ class name to use"... brad: I guess it would probably need to. brad: Maybe I can write up a revised XML format based on what I sent before and send it to you so we can think about this more. I can also write up a couple of "example" XML files for different overflow nodes so we have something concrete to think about. How does this sound? jm: I'm having a crazy idea... what if we tried to setup a quick "overflow-only" version of piper, just a a base and proof of concept. It would differ from the current overflow by a modified DL (what you've been doing with UI*) and a new Python GUI. Is it feasable? jm: Show me the XML! brad: crazy idea <- That sounds great! That is sort of like what I was proposing on the list, but a little more ambitious :-). I'm very much for doing this. The only thing I would add is that we need to include the bl layer, which for now is just an "extra" layer, but will eventually be doing the scheduling of nodes, etc. brad: XML <- Okay :-). I'll work something up and send it on to you. Then we can work that through more and get the exact syntax and everything down. jm: My idea of the BL is very vague... but if you see how to do it, sure. But the idea would be to have some working code ASAP, so we can add features. I've found that as soon as there is something barely working, the work goes a lot faster. That's been the case for Overflow. brad: I agree totally and that is definately what I want. Things are very frustrating to do now because there is nothing actually "working." Plus this way we can get rid of stand-alone Overflow and just have Piper-based Overflow :-). jm: That's exactly what I was thinking about! The main reason I want to keep "stand-alone" overflow alive is that I need it to do real work (i.e. it is my only development environment for my master). The sooner Piper is on a feature match, the sooner I can put more time on it. jm: ...just thinking of that. It we set up a node definition XML file for builtin node, it should support nodes that have a variable number of inputs. This is supported by the overflow libraries, but it can't be used in Overflow now, because the UI* classes don't support it. brad: That sounds super, and I completely understand your reasons for wanting stand-alone right now. Having more people working directly with Piper would be great! brad: variable inputs <- Agreed. This way should have that since I'll just have a tag or something for inputs, so new ones can be added or old ones removed. jm: Just an idea... Do you think it would be feasable to take Overflow as it is now, and replace one part after the other (and add a BL layer) until it becomes Piper? brad: bl <- You should probably talk some with Jarl and see if you guys can work on calling Overflow functions from the bl. I only know vaguely how the bl works and he might have a better idea how to do this than I. brad: idea <- I think that is very possible. Let's start with the basic nodes to make 'ls' work and print out, and then build from there. How's that sound? jm: When I say variable inputs, I don't mean old and new inputs... For example, the Mux node (class) can be instanciated with any number of inputs it can have 10000 inputs if you like. If you try to connect a link to input "Foo", this input become valid. jm: Well, instead of starting with ls, I'd start with the hundred of already defined (and working) builtin nodes. brad: inputs <- Okay, that makes sense. I think the GUI should have some kind of option to "add input" or "add output" and a new link choice will appear in the UI and a new tag will be added to the XML file. Right now the DL uses XML in temporary storage to represent the GUI, so it would be no big deal to add a new tag to the XML file. jm: What do you mean by "the DL uses XML in temporary storage to represent the GUI"? brad: ls and built-in nodes <- Okay. I just thought 'ls' would be a bit more of a challenge since it requires both built in nodes, and the ability to construct these nodes to make a bigger node :-). jm: Sure, we can do ls *too*. brad: temp storage <- What I mean is that when a new node of a particular "type" is created in the GUI, the dl copies the XML file describing that type to a temproary storage location. Then as the GUI modifies the node (by adding parameters, etc.) this XML copy gets modified, and not the original. So the XML copy being modified has the same format as the "permanent" XML file describing a type, only with GUI added info. Does that make more sense? jm: This "something I always wanted to know but was afraid to ask": when you want to distribute your job, to you want to run the same job (and split the data) on multiple machines, or do you want to send different jobs to different machines? brad: ls <- I just don't want to lose my lovely 'ls' example :-). Seriously, you are right, this is definately in addition to the basic types, which we should do first. jm: I'm lost with your temporary storage... when you say a new node is created, do you refer to a new definition (class) or a new instance? brad: afraid to ask <- Different jobs. I don't know *anything* about real parallel computing, so this is kind of a cheap and easy way to do it, I hope. brad: temp storage <- I mean a new instance (thanks for giving me the right words :-). So then the new instance is modified in temporary storage while the definition/class remains unmodified. jm: My idea would be more to specify in the definition that a node can handle variable inputs/outputs, but I don't see the need for the temporary XML. The fact that we added an input to that node can be included in the "program" XML file. brad: Well, another idea behind the temporary XML is that it gives you immediate back-up in case of a crash, since it is a permanent representation of the GUI at any point. jm: The thing I dislike is that you end up with lots and lots of temporary files... plus that fact that I like the programs to be "self-contained". jm: ...or am I completely off the track? brad: I agree about the temporary files, but I'm not exactly sure what you mean by self contained. The dl classes are very similary to the Overflow UI* classes, with the main difference being that they grab their info from XML files instead of from in-memory class variables, or whatever. brad: temp files <- What I would like to do to deal with this is to store the XML in some kind of database, but there aren't any very good XML databases that do this kind of thing. So for now I've just stuck with writing stuff to the filesystem... brad: temp files <- Also, these files are cleaned up when a program shuts down normally, so you don't have to worry about a million temp files building up to sap all your hard drive memory. jm: What I mean be self-contained, it that an "Overflow program" can be completely defined by a single .n that you can export. jm: Then it means that all the info in the temp files has to be somewhere else... where is it? brad: self-contained <- This can be done with the multiple files as well. I use xml:link link files with other ones, and they could all be inlined into a single file using this. I haven't gotten into this yet, but this was the idea. brad: info in temp files <- What do you mean? I just add the info directly into the XML file (using DOM to manipulate the XML). jm: Sorry, can you simlpify you last remark? jm: About the differences between the DL, That's minor, since I already load node info from XML for "External" (ie. non-builtin) nodes. brad: simplify <- Do you mean the xml:link stuff or the dom stuff? jm: Both! (I don't know anything about either) brad: xml:link <- This isn't really anything more than just a "standard" way for linking files in xml, like href in html or something. So inside an xml file I have something like: brad: . Then I can go through (with a dom iterator that moves through the xml file tag by tag) and everytime I see a xml:link, I subsitute this with the "another_file.xml" that I reference. So then everything gets substituted into the original main file. jm: But how does that allow to remove the temp files with changing the program? brad: dom <- This is the w3c's standard way to manipuate XML. Basically, what you do is use a parser to parse XML into a tree-like structure, where each tag or attribute or whatever is a node in the tree. Then, since the XML is now in memory in the form of this dom tree, you can add new nodes (tags) or move nodes around, and thus change the format of the tree. Then you can save it back out as XML again. This is what I use to manipulate the XML files in temporary storage. brad: remove temp files <- They aren't really removed (unless a node is deleted), but are just modified, using DOM (document object model, BTW...). The temporary files are only deleted when the nodes are deleted normally. Am I making any sense? :-). jm: I think my IQ is going back to the carrot state... I guess it'll be easier to see when you send me some sample XML... but still I don't like the idea of temporary files when we could store the added inputs in the main file (that's the only data that differs from the node definition). jm: Didn't you say when you exit Piper, the temp files get removed, but that no data is lost? brad: The big reason for using lots of files is that reading an xml file into memory using dom is pretty slow, so it is better to use smaller files to make each manipulation quicker. If you had one big file, it would really be a mess. jm: Well, that's the whole point of using "sub networks' brad: no data is lost <- Well, the idea is that if you crash or something, the temporary files won't get deleted. Then when the program starts up, it will find these files which aren't supposed to be there, and then can possibly resurrect the crashed system in the GUI. I haven't work on this enough to actually realize it, but it is basically there... brad: sub-networks <- Agreed. I guess this is just a way to divide the node storage to an even finer degree. brad: But maybe we should call it for now and I'll send you the XML i'm thinking of and we can talk more later. Whadda you think? brad: It'll give me a chance to digest this all :-). jm: That's what I was about to suggest... If assimilated a lot of info and now the processing pipe is full. brad: Agreed. I'll send this log to the list too so other people can read it over if they want. Thanks for talking stuff through with me. I'm really looking forward to having Overflow and Piper come together :-). From deanne at density.biop.umich.edu Tue May 30 07:41:53 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] IRC - Overflow/Piper merging and XML files In-Reply-To: Message-ID: Why don't we just code our own XML/Python DB storage 'dbm' file? We could store things in dictionaries and by keys (wink to Brad) instead of creating lots of little files. Then we could either load the thing into memory or just leave it as a file on the filesystem (through auto-pickling on occasion). I guess it goes by how fast Python can search thru the keys, but the dictionary type seems so well suited to this. D Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From chapmanb at arches.uga.edu Tue May 30 12:21:38 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] IRC - Overflow/Piper merging and XML files Message-ID: <200005301624.MAA42576@archa11.cc.uga.edu> Deanne wrote: > Why don't we just code our own XML/Python DB storage 'dbm' file? We could > store things in dictionaries and by keys (wink to Brad) instead of > creating lots of little files. Then we could either load the thing into > memory or just leave it as a file on the filesystem (through auto-pickling > on occasion). I guess it goes by how fast Python can search thru the > keys, but the dictionary type seems so well suited to this. I think this is a very good idea, as I thought up the same thing myself a little while ago :-) (see the thread 'XML database stuff' from the march archives of the Loci list). I was proposing using the shelve module, which is basically a dictionary-like interface to pickle. I never actually implemented it, but from my reading into it, it didn't seem like it would scale well to a lot of files :-<. I currently use the shelve module for storing encrypted password information, but haven't dared to try and extend it to the xml files we store. I wrote some preliminary python bindings for XDBM (http://www.bowerbird.com.au/XDBM/), which is an xml database manager. It might be possible to build a system like you propose based on that, but I haven't really gotten into it any more from lack of time/lack of necessity, etc. Brad From chapmanb at arches.uga.edu Tue May 30 18:47:41 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] XML descriptions for loci Message-ID: Hello all; As you might have noticed if you read the IRC log between Jean-Marc and I yesterday, I promised that I would try and draw up XML descriptions for nodes in piper, so here is my first attempt at that. I've included a few xml files and the dtd describing the general format below, along with comments along the way. I hope I am making some sense with this... Please ask questions and I can try to expand on anything that is confusing. Thanks much! Brad The biggest thing to note is that I changed the name "node" to now be "locus". The reason I did this is that node just conflicts too much with DOM, and it makes things confusing, in my opinion. I know that "locus" might not be that descriptive to start with, but at least it is unambiguous when you see it, unlike node (or pnode or piper_node or whatever). Other suggestions for names are always welcome :-). Below is the description of a locus constant (Constant.cc from the Overflow code). This is a description of a bit more complicated locus that executes a command line and returns the results. Execute an argument on the command line and return the results and status. Below is how you could use these two basic locus types to create a locus describing 'ls -l.' The biggest change over how Overflow does things is that I use the concepts of xlink's exensively. Xlink (http://www.w3.org/TR/2000/WD-xlink-20000221/) is the XML specification for relating two documents. The big advantage of doing things this way is that a locus like still contains all the information about how it was constructed, so we could "reverse construct" a created node to its individual parts, so it could be modified. The basic idea behind how the xlink stuff will work is that the 'xlink:href' would suck in another xml document, and the xlink:to stuff would make substitutions in the xml file. I _think_ this will work and this seems like the "good official" way to do it. ls -l List the long contents of the current directory. One thing that Jean-Marc mentioned is handling nodes that can have a variable number of inputs. The way I thought to handle this was to add an attribute called "expand" to the , and tags. This attribute is set at "no" by default, but if it set at "yes," then this will tell Piper that it can add new tags of this type on demand by the user. So this would mean that if someone was dealing with the Mux locus in the user interface, they could select an option like "add input" on the the choices input, and could do this, while they would get an error if they tried to do the same thing on the "switch" input. And finally, here is the DTD that describes the piper-plugin xml format: From jean-marc.valin at hermes.usherb.ca Tue May 30 19:19:32 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] XML descriptions for loci References: Message-ID: <39344C84.6ABF4D0@hermes.usherb.ca> > The biggest thing to note is that I changed the name "node" to now be > "locus". The reason I did this is that node just conflicts too much with > DOM, and it makes things confusing, in my opinion. I know that "locus" > might not be that descriptive to start with, but at least it is unambiguous > when you see it, unlike node (or pnode or piper_node or whatever). Other > suggestions for names are always welcome :-). > > Below is the description of a locus constant (Constant.cc from the Overflow > code). > > I would remove this comment and put it in the definition so it can be used from Piper > > > > > > > > > > > > > I suggest something like: Locus type describing a constant value. If each node definition is in its own XML file, the module name can just be a property. Also, this is just a detail, but I suggest not to use a .xml extension since most of the piper files will be XML files. > > > > > > > > > > > > > > > "General/Constant.xml"> > > > > "General/Constant.xml"> > > > > > ls -l > List the long contents of the current directory. > > > > > > I may be missing something, but that seems to be too compilicated and I don't see the gain. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Tue May 30 20:31:43 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] XML descriptions for loci Message-ID: <200005310034.UAA60570@archa11.cc.uga.edu> I wrote: >> Jean-Marc wrote: > I would remove this comment and put it in the definition so it can be used from > Piper Ooops, yeah, I meant to do that. Sorry! Jean-Marc wrote: > I suggest something like: > > > > > > Locus type describing a constant value. > > > > If each node definition is in its own XML file, the module name can just be a > property. This all looks great, although I'm not sure about the module thing just because you could have multiple levels of module organization within a top level category. For instance, sticking with UNIX examples, you could have: unix/utilities -> for stuff like ls, grep unix/processes -> for process associated stuff like kill, nice just as an example. We could also do this with module = "unix/utilities" or module = "unix.utilities" What do you think? > Also, this is just a detail, but I suggest not to use a .xml > extension > since most of the piper files will be XML files. I agree, I just didn't have enough brainpower to think up a good extension. Any ideas? random.pip? random.ppr? random.brad? [...snip...xml for ls...] > I may be missing something, but that seems to be too compilicated and I don't > see the gain. I guess the major gain is just that we can deconstruct the "built" node back into its individual components, so it could be modified and then "re-built." There may be better ways to accomplish this goal (or maybe this isn't even a good goal?). What were your thoughts on how 'ls -l' would look considering how the individual loci look? Brad From deanne at density.biop.umich.edu Tue May 30 21:22:43 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:59 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. In-Reply-To: <39344C84.6ABF4D0@hermes.usherb.ca> Message-ID: Don't know if this is useful or if you know about it, but here's a link to a description of GConf, a library that is meant to "leapfrog" over the concept of a "Registry". It seems to have some useful features and it might be nice to think about possibly going into compliance with it w/piper if we are pretty well gnomified. http://developer.gnome.org/feature/current/index.html Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From bizzaro at geoserve.net Tue May 30 21:57:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: Message-ID: <3934719F.4EFBCF7D@geoserve.net> deanne@density.biop.umich.edu wrote: > > Don't know if this is useful or if you know about it, but here's a link to > a description of GConf, a library that is meant to "leapfrog" over the > concept of a "Registry". It seems to have some useful features and it > might be nice to think about possibly going into compliance with it > w/piper if we are pretty well gnomified. > > http://developer.gnome.org/feature/current/index.html This was bounced around on the Loci list in yonder days gone past, but I haven't heard from Jarl or Jean-Marc. Basically, there were many shrills on the other list about using anything that resembled the M$ regi$try. Also, I will continue to stress that we don't want a dependency on a desktop system for the CORE of Piper. I hope that Piper can be installed, configured and ran without the REQUIREMENT of a GUI. Using GConf for the Gnome UI (Pied/Piper) is fine with me, just not for everything else. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Wed May 31 00:14:16 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> Message-ID: <39349198.D260A6EB@hermes.usherb.ca> > This was bounced around on the Loci list in yonder days gone past, but I > haven't heard from Jarl or Jean-Marc. Basically, there were many shrills on > the other list about using anything that resembled the M$ regi$try. I don't know enough about GConf to comment about the technology, but I don't like to depend too much on gnome (or any other desktop). Plus, I don't think a registry-like system would be very good when it comes to exporting piper "programs". > > Also, I will continue to stress that we don't want a dependency on a desktop > system for the CORE of Piper. I hope that Piper can be installed, configured > and ran without the REQUIREMENT of a GUI. Using GConf for the Gnome UI > (Pied/Piper) is fine with me, just not for everything else. Same for me! Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Wed May 31 00:42:29 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] XML descriptions for loci References: Message-ID: <39349835.D39AC172@geoserve.net> Brad Chapman wrote: > > > > Brad, can you explain why there is a distinction between (more than one tag for) plugin, module, and locus? I always thought there would be only one basic object that would be tagged: locus. Perhaps this shows some hierarchical grouping, like... plugin.module.locus ? Me confooosed. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Wed May 31 01:01:46 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] XML descriptions for loci Message-ID: <200005310504.BAA115850@archa12.cc.uga.edu> > Brad Chapman wrote: >> >> >> Jeff wrote: > Brad, can you explain why there is a distinction between (more than one tag > for) plugin, module, and locus? I always thought there would be only one > basic object that would be tagged: locus. Perhaps this shows some > hierarchical grouping, like... > > plugin.module.locus > > ? > > Me confooosed. That's becuase I'm doing it stupidly :-). I think the way you are proposing above is better than my stupid way with a whole bunch of tags. So maybe we should just have: (to use some earlier examples) and just drop the whole module thing entirely (then we can drop as well, since I just added that to have a root element). I like this a lot, as it will help get rid of a ton of my extraneous tags and attributes. Anyone else like this way better? Brad From jean-marc.valin at hermes.usherb.ca Wed May 31 01:11:48 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] XML descriptions for loci References: <200005310034.UAA60570@archa11.cc.uga.edu> Message-ID: <39349F14.2A100686@hermes.usherb.ca> > > I suggest something like: > > > > > > > > > > > > Locus type describing a constant value. > > > > > > > > > If each node definition is in its own XML file, the module name can > just be a > > property. > > This all looks great, although I'm not sure about the module thing > just because you could have multiple levels of module organization > within a top level category. For instance, sticking with UNIX > examples, you could have: > > unix/utilities -> for stuff like ls, grep > unix/processes -> for process associated stuff like kill, nice Well, the module hierarchy in this way makes sense if you are going to have many nodes described in the same XML file, but if you have only one node, the module is only a property. On a related topic, modules (I call them categories) in Overflow are just a cleaner way to set up the menu. To get an instance of a certain node, say constant, you don't need to know which category it belongs to. It's not like a UNIX path. I see that in the same way as Matlab. You know that the "dct" is in the signal processing toolbox, but to call it you just write "dct", not "signal:dct". > > Also, this is just a detail, but I suggest not to use a .xml > > extension > > since most of the piper files will be XML files. > > I agree, I just didn't have enough brainpower to think up a good > extension. Any ideas? random.pip? random.ppr? random.brad? random.nod or random.cls, or random.def > > I may be missing something, but that seems to be too compilicated > and I don't > > see the gain. > > I guess the major gain is just that we can deconstruct the "built" > node back into its individual components, so it could be modified and > then "re-built." There may be better ways to accomplish this goal (or > maybe this isn't even a good goal?). What were your thoughts on how > 'ls -l' would look considering how the individual loci look? It could work the same way as the current .n in Overflow: specify which nodes you need and how to connect them. if you use a certain type, say "Constant" the system will look in its list of available nodes, and will find the right inputs/outputs/params. I don't like to have xml links, since it would restrict how we can move node definitions around. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Wed May 31 01:16:12 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] XML descriptions for loci References: <200005310504.BAA115850@archa12.cc.uga.edu> Message-ID: <3934A01C.B5FDEC0F@geoserve.net> Brad Chapman wrote: > > That's becuase I'm doing it stupidly :-). I think the way you are > proposing above is better than my stupid way with a whole bunch of > tags. So maybe we should just have: > > > > > > > (to use some earlier examples) and just drop the whole module thing > entirely (then we can drop as well, since I just added > that to have a root element). I like this a lot, as it will help get > rid of a ton of my extraneous tags and attributes. Anyone else like > this way better? Yes, much better :-) BTW, will the hierarchy (this.that.theotherthing) be reflected in locus storage? IOW, will Piper know any more about the hierarchy than what can be gleaned from the name? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed May 31 01:23:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] XML descriptions for loci References: <200005310034.UAA60570@archa11.cc.uga.edu> <39349F14.2A100686@hermes.usherb.ca> Message-ID: <3934A1C4.ADD852D1@geoserve.net> Jean-Marc Valin wrote: > > On a related topic, modules (I call them categories) in > Overflow are just a cleaner way to set up the menu. Yeah, this is what I was getting at in my last message. I'm thinking that the (Pied) user can create a blank workspace/network and use a popup menu to choose available loci/nodes to be placed on the workspace/network (as with Overflow). The hierarchy will help to make submenus. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Wed May 31 01:30:33 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] XML descriptions for loci References: <200005310504.BAA115850@archa12.cc.uga.edu> <3934A01C.B5FDEC0F@geoserve.net> Message-ID: <3934A379.EF86E36D@hermes.usherb.ca> > Yes, much better :-) > > BTW, will the hierarchy (this.that.theotherthing) be reflected in locus > storage? IOW, will Piper know any more about the hierarchy than what can be > gleaned from the name? I'd prefer this hierarchy be only for confenience, so that it's easier to find a node, but I wouldn't like to remember all those hierarchy. For instance, you know that "sin" belongs to math.h and "printf" belongs to stdio.h, but When you call them, you don't need to specify where they come from. The node names should be descriptive enough that they can live in the same namespace. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Wed May 31 13:50:22 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> Message-ID: <393550DE.6C7DC044@casema.net> > > I don't know enough about GConf to comment about the technology, but I don't > like to depend too much on gnome (or any other desktop). Plus, I don't think a > registry-like system would be very good when it comes to exporting piper > "programs". Like I said before, I think GConf is very usedfull for gathering information about applications that are about to be wrapped. > > > > > Also, I will continue to stress that we don't want a dependency on a desktop > > system for the CORE of Piper. I hope that Piper can be installed, configured > > and ran without the REQUIREMENT of a GUI. Using GConf for the Gnome UI > > (Pied/Piper) is fine with me, just not for everything else. > > Same for me! > Not for me :) But I wont stand in your way if you people ever port Piper to some other environment. GMS needs some serious modifications to remove gnome dependancies is we were to do so. From bizzaro at geoserve.net Wed May 31 15:41:03 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> Message-ID: <39356ACF.90ED2288@geoserve.net> jarl van katwijk wrote: > > Like I said before, I think GConf is very usedfull for gathering information about > applications that are about to be wrapped. Yes, I remember :-) > Not for me :) But I wont stand in your way if you people ever port Piper to some > other environment. GMS needs some serious modifications to remove gnome > dependancies is we were to do so. What are the dependencies you have? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+