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 | | |