From jeff at bioinformatics.org Sat Aug 12 07:52:02 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] slides for piper talk at bosc2000 Message-ID: <39953A62.EBC1F7B2@bioinformatics.org> I will be giving a talk about Piper at BOSC2000 next week. I put the slides on the website: http://www.bioinformatics.org/piper/slides/bosc2000/slide_01.html They include some mockup screenshots that you might enjoy seeing. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jeff at bioinformatics.org Tue Aug 1 15:44:32 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] Could not contact the dl, it appears not to be started. Message-ID: <398728A0.8B8731E9@bioinformatics.org> I get the following error occasionally, for no apparent reason. And it seems a little odd that the error says, "it appears not to be started", when Piper should take care of starting the DL automagically. ----------------------------------------------------------------- jeff@dexter:jeff> piper jeff@dexter:jeff> Starting definition layer... Starting pied... Getting document... Could not contact the dl, it appears not to be started. The dl must be running before the Gnome user interface. jeff@dexter:jeff> ps -aux | grep python jeff 11279 18.6 10.3 10236 6528 pts/1 S 15:37 0:03 python startdl.py jeff 11282 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11283 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11284 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11285 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11291 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11292 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11293 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff 11294 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python startdl.py jeff@dexter:jeff> jeff@dexter:jeff> shutting down dl... Unhandled exception in thread: Traceback (innermost last): File "/var/tmp/python/python-root/usr/lib/python1.5/threading.py", line 392, in __bootstrap File "/var/tmp/python/python-root/usr/lib/python1.5/threading.py", line 401, in __delete AttributeError: 'None' object has no attribute 'acquire' ----------------------------------------------------------------- Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Let the machine do the dirty work." -- Kernighan and Ritchie -- From chapmanb at arches.uga.edu Tue Aug 1 16:52:50 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] Could not contact the dl, it appears not to be started. Message-ID: <200008012052.QAA30270@archa10.cc.uga.edu> > I get the following error occasionally, for no apparent reason. And it seems > a little odd that the error says, "it appears not to be started", when Piper > should take care of starting the DL automagically. Okay, here's the gist of why you would get this error: The dl automatically "pings" all of the ui clients (well there is only one right now, but anyways...) to determine if they are still alive. When all of the clients either call close and shut down or die, the dl notices that it doesn't have any clients left, and shuts itself down. Right now I have the timeout for the dl set relatively quickly (10 seconds or so) since that helps with development. So what you are seeing is this: 1. You shut down your ui. The dl is still waiting around and hasn't noticed all of the clients are shut down. 2. You go to start piper up again right after that. The dl is still running at this point, so the script doesn't start a new dl. 3. The old dl shuts itself down because it hasn't recieved a request from the new user interface to initiate contact yet. 4. Then the ui calls the dl, but the dl shut down, so the ui gets a CORBA communication error and reports the message that you see. Eventually the dl will run for long periods of time and won't time out so rapidly, and so we shouldn't see this error any more. For now it is just an artifact of development. > jeff@dexter:jeff> ps -aux | grep python > jeff 11279 18.6 10.3 10236 6528 pts/1 S 15:37 0:03 python > startdl.py > jeff 11282 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11283 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11284 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11285 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11291 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11292 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11293 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py > jeff 11294 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > startdl.py Man, why the heck do you have 9 copies of the dl running? Kill some of those, for pete's sake! :-). Seriously, if the dl gets hung up because of a crash or error and doesn't close, you'll need to kill the old ones. They won't recieve any requests from new user interfaces because the string IOR that is written from newer dl's doesn't refer to them. So having them running doesn't mean they can recieve requests. From my experience coding the dl never gets hung up under "normal" circumstances, but you'll start seeing this during crashes/development. Brad From jeff at bioinformatics.org Tue Aug 1 17:59:55 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] Could not contact the dl, it appears not to be started. References: <200008012052.QAA30270@archa10.cc.uga.edu> Message-ID: <3987485B.42BC7931@bioinformatics.org> Brad Chapman wrote: > > 2. You go to start piper up again right after that. The dl is still > running at this point, so the script doesn't start a new dl. Hmmm. But I do get a "shutting down dl..." message before I try to restart Piper. > Eventually the dl will run for long periods of time and won't time out > so rapidly, and so we shouldn't see this error any more. For now it is > just an artifact of development. I understand. Well, I'm not getting the message as much now that I am able to get Pied running longer (I'm working on renaming a lot of things). > > jeff@dexter:jeff> ps -aux | grep python > > jeff 11279 18.6 10.3 10236 6528 pts/1 S 15:37 0:03 python > > startdl.py > > jeff 11282 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11283 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11284 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11285 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11291 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11292 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11293 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > jeff 11294 0.0 10.3 10236 6528 pts/1 S 15:37 0:00 python > > startdl.py > > Man, why the heck do you have 9 copies of the dl running? Kill some of > those, for pete's sake! :-). Take a closer look at those processes. You'll notice (1) they all started at about the same time and (2) the only one that's really doing anything is 11279. Think back to a long time ago, in a galaxy far, far away, and you'll remember that I had this same "problem" with Loci's middle. I get 9 processes running on Linux, while you get one running on FreeBSD. Thanks for the info. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Let the machine do the dirty work." -- Kernighan and Ritchie -- From jeff at bioinformatics.org Wed Aug 2 22:09:12 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] progress on pied Message-ID: <3988D448.42E5131A@bioinformatics.org> I have successfully changed a lot of names in Pied. Recall that Pied was the GUI for Loci and that we have decided to pretty much adopt Overflow's nomenclature. Pied is working well with these new names, although the source is not yet in CVS. The one remaining issue about names is what to call that little thingy that dangles unconnected from the icon. I was going to call it "link", but Brad pointed out link refers to a /connected/ thingy. The Loci term was "connector". But I think I connector forms a "connection", not a link. A link is formed by a "linker"? Anyway, maybe we should vote on it. Jeff's little dangling thingy should be called (1) Link (2) Connector (3) Linker (4) Branch (5) Line (6) Thingy Any other non-profane suggestions? What would you call the lines forming a flow chart or tree? Remember that this also applies to non-graphical UI's such as Peep. I'll continue working on shifting stuff around in Pied and tackling tasks in Pied's TODO list. I've got thingy names working, just like the node names. I should have thingy windowlets working soon too. Thingy selection is another big task. Thingies will actually be somewhat more distinct from the nodes they're connected to, having more features than before. Lots to do. I could go on and on. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Let the machine do the dirty work." -- Kernighan and Ritchie -- From chapmanb at arches.uga.edu Wed Aug 2 22:35:21 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] progress on pied In-Reply-To: <3988D448.42E5131A@bioinformatics.org> Message-ID: <200008030235.WAA48838@archa13.cc.uga.edu> Jeff wrote: > Jeff's little dangling thingy > should be called Jeff, I really think you leave personal issues like this off the mailing list :-) Seriously, > (1) Link > (2) Connector > (3) Linker > (4) Branch > (5) Line > (6) Thingy I vote strongly for "connector" and "connection" because this is already what we are using right now. All of these really say the same thing, so why not just stick with what we have and minimize our re-naming headaches as much a possible. I'd rather worry about adding new functionality to Piper rather than shuffling names around, so if we can make it less painless, I vote for that! Brad From jeff at bioinformatics.org Wed Aug 2 22:43:52 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] progress on pied References: <200008030235.WAA48838@archa13.cc.uga.edu> Message-ID: <3988DC68.23B70602@bioinformatics.org> Brad Chapman wrote: > > I vote strongly for "connector" and "connection" because this is already > what we are using right now. All of these really say the same thing, so > why not just stick with what we have and minimize our re-naming headaches > as much a possible. I'd rather worry about adding new functionality to > Piper rather than shuffling names around, so if we can make it less > painless, I vote for that! Are you suggesting then that the .n files use tags rather than tags? Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Let the machine do the dirty work." -- Kernighan and Ritchie -- From chapmanb at arches.uga.edu Wed Aug 2 22:59:04 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] progress on pied In-Reply-To: <3988DC68.23B70602@bioinformatics.org> Message-ID: <200008030259.WAA93634@archa10.cc.uga.edu> > Are you suggesting then that the .n files use tags rather> than > tags? Eh, right, forgot about them :-). I am suggesting that we leave both alone for right now. In my mind it seems unambiguous and I'm not getting confused. I do not want to touch the .n format for fear of making Jean-Marc's Overflow stuff be incompatible with Piper. I also do not really want to change very much code just for naming issues. Changing names is a painful and unenjoyable exercise for me and the dl is already enough of a mess right now since I just had to rewrite it yet again to incorporate Jean-Marc's plan. So unless people are really confused by the naming, I again vote to be lazy and leave things the way they are. Brad From jeff at bioinformatics.org Wed Aug 2 23:09:06 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] progress on pied References: <200008030259.WAA93634@archa10.cc.uga.edu> Message-ID: <3988E252.496158C8@bioinformatics.org> Brad Chapman wrote: > > I am suggesting that we leave both alone for right now. In my mind it > seems unambiguous and I'm not getting confused. I do not want to touch > the .n format for fear of making Jean-Marc's Overflow stuff be > incompatible with Piper. I also do not really want to change very much > code just for naming issues. Changing names is a painful and unenjoyable > exercise for me and the dl is already enough of a mess right now since I > just had to rewrite it yet again to incorporate Jean-Marc's plan. So > unless people are really confused by the naming, I again vote to be lazy > and leave things the way they are. Alright then, since I already have the little thingies called "link" in Pied, and it doesn't affect the DL, I'll keep it that way for now. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Let the machine do the dirty work." -- Kernighan and Ritchie -- From jeff at bioinformatics.org Fri Aug 4 15:14:14 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] When Should Source Be Released? Message-ID: <398B1606.97116BF3@bioinformatics.org> There is a relevant discussion at Slashdot about when a new project should be `released': LATE: ``While releasing the source early is a good thing, it can be released too early. I would never release the code to a project that wasn't in a runnable state, and would honestly consider holding off source releases until the project was at least in the "beta" stage.'' EARLY: ``Releasing early also gives you the advantage of having more eyes looking at your code early to spot any bad design decisions -- it's a lot easier to fix bad choices early in the project than it is when the code is more developed... You don't want to have to rewrite the entire foundation just because you made a seemingly good decision early on, which later turns out to cause issues.'' http://slashdot.org/article.pl?sid=00/07/29/1816254&mode=flat Jeff From chapmanb at arches.uga.edu Fri Aug 4 18:06:28 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:23 2006 Subject: [Pipet Devel] Snazzy CVS commits Message-ID: <200008042206.SAA45700@archa12.cc.uga.edu> Hey everybody; I just commited a whole ton of changes to Piper in CVS which I've been working on over the past few days that do the following: 1. Remove the requirement for any python XML or DOM libraries. All of my code which used to do things with XML has been replaced by Overflow code which does the similar things, so our only XML library dependence now is libxml (1 not 2, BTW). I don't want to ever hear anyone say I didn't do my part for removing dependencies :-). 2. Integrate Piper *very* closely with Overflow. I am now using the overflow UI* libs extensively in the dl and am working on both Overflow CVS and Piper CVS concurrently. So to follow Piper CVS, you also need to build from and follow Overflow CVS. You can do a checkout of just the "Core" libraries that we need for Piper by doing 'cvs checkout OverflowCore' (instead of Overflow) to get what you need. Overflow is on sourceforge, so you can grab the instructions from the page there (http://sourceforge.net/project/?group_id=590). 3. Provide a drastic speed improvement over what we had before. If you were using Piper from CVS any time this summer, then you'll see how much faster things are now. 4. Implement saving and loading of Overflow '.n' files. This *should* work for any file produced by Overflow, although I haven't done enough testing to bet anything on it. Crash recovery is also working, so you can kill the user interface (or just click on the little X in the upper right corner -- I set that to "simulate" a crash instead of being a normal logout). So that's what we've got. I'm going to be doing some serious camping and canoing over the next week so I won't have e-mail (hell, we won't even have anything as fancy as a pit toilet :-). So if you have a chance, please check things out before tommorrow and see if you see any glaring problems or anything. That's all to report from the battlefront. Thanks for listening! Brad From jeff at bioinformatics.org Fri Aug 4 20:39:58 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits References: <200008042206.SAA45700@archa12.cc.uga.edu> Message-ID: <398B625E.DC5E8E94@bioinformatics.org> Brad Chapman wrote: > > 1. Remove the requirement for any python XML or DOM libraries. All of my > code which used to do things with XML has been replaced by Overflow code > which does the similar things, so our only XML library dependence now is > libxml (1 not 2, BTW). What's the status of libxml 2 ? > I don't want to ever hear anyone say I didn't do > my part for removing dependencies :-). Okay, I won't say it :-) > 2. Integrate Piper *very* closely with Overflow. I am now using the > overflow UI* libs extensively in the dl and am working on both Overflow > CVS and Piper CVS concurrently. So, you've actually been changing Overflow code? > 3. Provide a drastic speed improvement over what we had before. If you > were using Piper from CVS any time this summer, then you'll see how much > faster things are now. That's great. Are you running Piper on your 486? I know it's been a little slow on my P1/200. So, have you made any changes to the UI2DL IDL that might break Pied? Cool going there thuper dude! Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From chapmanb at arches.uga.edu Fri Aug 4 21:08:59 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits In-Reply-To: <398B625E.DC5E8E94@bioinformatics.org> Message-ID: <200008050109.VAA56652@archa13.cc.uga.edu> J.W. Bizzaro wrote: > What's the status of libxml 2 ? Well, it is out there and working and all of that stuff. I don't think there are questions about whether or not it is usable. The issue that Jean-Marc brought up earlier was -> what version of libxml are people likely to have already installed on their machine? I don't really know the answer to this, but I just installed linux and it came with 1.8.6, so I guess sticking with 1 for now makes as much sense as moving to 2. > So, you've actually been changing Overflow code? Shhhh, not so loud, Jean-Marc might hear :-). Sure, yeah, Jean-Marc and I have had to make some adjustments, mostly so that Piper could get more information from the UI libs. These changes are all compatible with Overflow, so we're just working on melding Overflow and Piper together as much as possible. This will make it nice and easy for Jean-Marc to switch over to Piper :-). > That's great. Are you running Piper on your 486? I know it's been a > little slow on my P1/200. Yeah, it's a 486 and it runs pretty okay. I think the important thing for now is that it is not *so incredibly slow* like it was previously. Trying to make small changes to get speed up is not something we need to worry about right now, I don't think. Besides, by the time we finish with Piper, computers will be a lot faster :-). > So, have you made any changes to the UI2DL IDL that might break Pied? Nope, the idl is intact. Three cheers for modularity! Brad From jeff at bioinformatics.org Fri Aug 4 21:29:58 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits References: <200008050109.VAA56652@archa13.cc.uga.edu> Message-ID: <398B6E16.8824C6A2@bioinformatics.org> Brad Chapman wrote: > > Besides, by the time we finish with > Piper, computers will be a lot faster :-). That's not only funny but very true. Moore's Law says that computer capabilities double every 18 months. So, if Piper is "ready" by January, 2002, store-bought PC's will have a processor clock speed of more than 2 GHz, come with 128 MB RAM minimum, and have at least 30 GB hard drives. Will they run Piper fast enough for you, Brad? Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Sat Aug 5 15:32:53 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits References: <200008050109.VAA56652@archa13.cc.uga.edu> Message-ID: <398C6BE5.20FB0969@casema.net> > > So, have you made any changes to the UI2DL IDL that might break Pied? > Does this mean the UI and DL are communicating thruogh Corba already? bye, jarl From chapmanb at arches.uga.edu Sat Aug 5 07:57:51 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits In-Reply-To: <398C6BE5.20FB0969@casema.net> Message-ID: <200008051157.HAA48786@archa12.cc.uga.edu> jarl wrote: > Does this mean the UI and DL are communicating thruogh Corba already? Yuppers. This feature has actually been in there for a while and so the IDL is "semi-stable" (although now we might make a few name changes to make things more compiant with our current naming scheme for things). All of the communication is through a CORBA interface (no cheating at all :-) so we are ready at any time for someone to write a user interface in a different language. Additionally, the user interface should not have to access the filesystem at all, so we should be able to run a user interface on one machine and the definition layer on another. Of course, right now things are just set up to run everything on the same machine, but in the future we should be able to add hooks to do stuff like this without too many problems. Now I remember why I like CORBA so much :-) Brad From jarl at casema.net Sat Aug 5 17:38:35 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits References: <200008051157.HAA48786@archa12.cc.uga.edu> Message-ID: <398C895B.621CDBC4@casema.net> > > Yuppers. This feature has actually been in there for a while and so the > IDL is "semi-stable" (although now we might make a few name changes to > make things more compiant with our current naming scheme for things). All > of the communication is through a CORBA interface (no cheating at all :-) > so we are ready at any time for someone to write a user interface in a > different language. Additionally, the user interface should not have to > access the filesystem at all, so we should be able to run a user > interface on one machine and the definition layer on another. Of course, > right now things are just set up to run everything on the same machine, > but in the future we should be able to add hooks to do stuff like this > without too many problems. Now I remember why I like CORBA so much :-) Sounds good! I'm currently working on rewriting the BL sources so that they use OOP C++ Corba code, and will use this specialised software http://www.cs.utah.edu/flux/flick/ for IDL compilation. Maybe we can make the autoconfigure so that it tries to use Flick, and if it's not availeble it falls back on the default OMNIorb idl compiler? bye, jarl From chapmanb at arches.uga.edu Sat Aug 5 09:07:37 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Snazzy CVS commits In-Reply-To: <398C895B.621CDBC4@casema.net> Message-ID: <200008051307.JAA61346@archa10.cc.uga.edu> jarl wrote: > I'm currently working on rewriting the BL sources so that they use OOP > C++ Corba code, and will use this specialised software > http://www.cs.utah.edu/flux/flick/ for IDL compilation. Flick looks like it does some cool stuff, but does it work with omniORB? >From a quick glance at the page and manuals, the only ORB implementation I see mentioned (that I recognize) is TAO. Won't you have to write a back end that works with omniORB. Or am I missing something about how Flick works? > Maybe we can make the autoconfigure so that it > tries to use Flick, and if it's not availeble it falls back on the default OMNIorb > idl compiler? Sure, I don't think should be too incredibly difficult. But, will Flick and omniidl generate stubs and skeletons that are interchangable enough to support this? Brad From jeff at bioinformatics.org Mon Aug 7 14:05:31 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] PyGuiXml Message-ID: <398EFA6B.592C6800@bioinformatics.org> ``PyGuiXml is a Python package designed to help creating Graphical User Interfaces. It takes an XML description of the GUI and outputs a graphical component that looks like and behaves as specified in the XML description.'' http://fang.free.fr/ Jeff From jonyi at MIT.EDU Fri Aug 11 12:44:29 2000 From: jonyi at MIT.EDU (Jon Yi) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] PVM or MPI? Message-ID: <200008111644.MAA02080@elysium.mit.edu> hi, i just joined this mailing list, because i couldn't find any FAQ or mailing list archive to answer my question. piper has the potential to distribute computation jobs across a WAN, but has there been any thought to layer additional communications protocols beyond CORBA for LAN clusters? jon From jarl at casema.net Fri Aug 11 22:27:09 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] PVM or MPI? References: <200008111644.MAA02080@elysium.mit.edu> Message-ID: <3994B5FD.3D265F6C@casema.net> > Hi John, > > i just joined this mailing list, because i couldn't find any FAQ or > mailing list archive to answer my question. piper has the potential > to distribute computation jobs across a WAN, but has there been any > thought to layer additional communications protocols beyond CORBA > for LAN clusters? There are at least 2 answers to your question: 1. The communication between Piper instances will eventually go trough an KQML compliant interface which will be available as a Corba ORB and a URI socket. KQML stands for Knowledge base Query Modeling Language, and URI for Universal Resource Identification. 2. Piper offers plugin support at 'Whole Network' level (cq applications and such). Plugins can be dynamic load able binaries or corba based. Besides this Piper has it's own (XML) 'language' for describing the wrapping of just about anything but Xwin apps at network node level. Does one of these answer your question? bye, jarl From jeff at bioinformatics.org Sat Aug 12 07:52:02 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] slides for piper talk at bosc2000 Message-ID: <39953A62.EBC1F7B2@bioinformatics.org> I will be giving a talk about Piper at BOSC2000 next week. I put the slides on the website: http://www.bioinformatics.org/piper/slides/bosc2000/slide_01.html They include some mockup screenshots that you might enjoy seeing. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Tue Aug 15 04:20:24 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] slides for piper talk at bosc2000 References: <39953A62.EBC1F7B2@bioinformatics.org> Message-ID: <3998FD47.E2A4DA9A@casema.net> > I will be giving a talk about Piper at BOSC2000 next week. I put the slides > on the website: > > http://www.bioinformatics.org/piper/slides/bosc2000/slide_01.html > > They include some mockup screenshots that you might enjoy seeing. Look nice! I'll be going to the DOA'00, they've put a speakers list online, look promishing. bye, jarl From jeff at bioinformatics.org Mon Aug 14 06:43:07 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] slides for piper talk at bosc2000 References: <39953A62.EBC1F7B2@bioinformatics.org> <3998FD47.E2A4DA9A@casema.net> Message-ID: <3997CD3B.47AB1F3@bioinformatics.org> Jarl van Katwijk wrote: > > Look nice! Thanks. > I'll be going to the DOA'00, they've put a speakers list online, look promishing. Right, that's the one coming up in Belgium next month? Do you want to present the Piper poster we have? The abstract deadline has probably passed. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Tue Aug 15 05:31:30 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] slides for piper talk at bosc2000 References: <39953A62.EBC1F7B2@bioinformatics.org> <3998FD47.E2A4DA9A@casema.net> <3997CD3B.47AB1F3@bioinformatics.org> Message-ID: <39990DF2.EC3E429B@casema.net> "J.W. Bizzaro" wrote: > Jarl van Katwijk wrote: > > > > Look nice! > > Thanks. > > > I'll be going to the DOA'00, they've put a speakers list online, look promishing. > > Right, that's the one coming up in Belgium next month? Do you want to present > the Piper poster we have? The abstract deadline has probably passed. > Think so, but I'll be a listener over there, not a participant. Maybe next time :) bye, jarl From chapmanb at arches.uga.edu Mon Aug 14 11:39:04 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Poster for ISMB Message-ID: <200008141538.LAA40518@archa12.cc.uga.edu> Hello all! We'll also be presenting Piper as the ISMB conference next week in a poster format, and I just posted a very preliminary draft of the poster information at my exciting web site: .http://bioinformatics.org/bradstuff/ You can grab it in pdf, html and text formats (and the original tex, if you like that :-). i would really like to get feedback on this. I'm not worried about formatting (it will be completely different for the final thing we're taking along) but more about content and styling. What do you think of what is said? Are there any mistakes? Is anything unclear? Was something important left out? Should something that is in there be deleted? Jeff and I will be working more on it over the next couple o' days getting it finalized, so any comments would be really really appreciated. Thanks much! Brad From jeff at bioinformatics.org Mon Aug 14 12:10:33 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Poster for ISMB References: <200008141538.LAA40518@archa12.cc.uga.edu> Message-ID: <399819F9.374C4449@bioinformatics.org> Brad Chapman wrote: > > i would really like to get feedback on this. I'm not worried about > formatting (it will be completely different for the final thing we're > taking along) but more about content and styling. What do you think of > what is said? Are there any mistakes? Is anything unclear? Was something > important left out? Should something that is in there be deleted? That was fast. You must have been a whiz at term papers :-) Upon first inspection, it looks quite good. I see that much of the "Introduction" comes from the orginal abstract. Are we going to start the poster off with an abstract? Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From chapmanb at arches.uga.edu Mon Aug 14 12:31:54 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Poster for ISMB In-Reply-To: <399819F9.374C4449@bioinformatics.org> Message-ID: <200008141631.MAA102732@archa10.cc.uga.edu> > That was fast. You must have been a whiz at term papers :-) Well, you get a lot of practice at sitting down and writing like a maniac when you spend your life procrastinating everything until the very last second :-) > Upon first inspection, it looks quite good. I see that much of the > "Introduction" comes from the orginal abstract. Are we going to start > the > poster off with an abstract? I was just thinking of the Intro in-lieu of the abstract. Do you think more of the abstract needs to be included in the intro? Or do you want a abstract on there? I just dig an Intro over an abstract since you aren't so constrained by the "abstract format." I just see the intro as a quick glimpse at what is in the poster and why you would want to read it, which is why it overlaps with the abstract in my (warped) mind. Brad From jeff at bioinformatics.org Mon Aug 14 12:41:15 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Poster for ISMB References: <200008141631.MAA102732@archa10.cc.uga.edu> Message-ID: <3998212B.A685000F@bioinformatics.org> Brad Chapman wrote: > > I was just thinking of the Intro in-lieu of the abstract. Do you think > more of the abstract needs to be included in the intro? Or do you want a > abstract on there? I just dig an Intro over an abstract since you aren't > so constrained by the "abstract format." I just see the intro as a quick > glimpse at what is in the poster and why you would want to read it, which > is why it overlaps with the abstract in my (warped) mind. Actually, in my warped mind, abstract == quick overview, and intro == background and motivation. You could just rename the intro to abstract. I'll let you decide. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From chapmanb at arches.uga.edu Mon Aug 14 13:00:16 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:24 2006 Subject: [Pipet Devel] Poster for ISMB In-Reply-To: <3998212B.A685000F@bioinformatics.org> Message-ID: <200008141700.NAA55076@archa13.cc.uga.edu> I wrote: > > I just see the intro as a > > quick > > glimpse at what is in the poster and why you would want to read it, > > which > > is why it overlaps with the abstract in my (warped) mind. Jeff wrote: > Actually, in my warped mind, abstract == quick overview, and intro == > background and motivation. You could just rename the intro to > abstract. I'll > let you decide. I see it like this for a paper, but not as much for a poster. Since a poster is about a lot less finished research than a paper (otherwise you'd be publishing it :-), a lot more time is spent on why you are doing something and where you are coming from. This is good because it is a lot more interesting and easier to get into then lots of lab details and also gives you a chance to get feedback about your motivation. However, it is bad since it makes a lot of your paper end up being the introduction (hell, half of the Piper poster is about motivation :-). So I think of the intro as taking on a different role for the poster. Plus, it makes my head hurt to read too many abstracts at poster sessions :-). Brad From jeff at bioinformatics.org Tue Aug 15 10:07:02 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] [Fwd: [Bioperl-l] BOF] Message-ID: <39994E86.EED67338@bioinformatics.org> David Lapointe sent me a BioPerl message, and the reply is attached. -------------- next part -------------- An embedded message was scrubbed... From: "J.W. Bizzaro" Subject: Re: [Bioperl-l] BOF Date: Tue, 15 Aug 2000 14:05:09 +0000 Size: 2499 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000815/d8a21e1f/attachment.mht From gvd at penguin.pharmacy.ualberta.ca Tue Aug 15 10:36:03 2000 From: gvd at penguin.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Poster for ISMB In-Reply-To: <200008141700.NAA55076@archa13.cc.uga.edu> Message-ID: Brad, Jeff, The poster looks great. The writing is excellent, Brad, well done! g. -- -- Gary Van Domselaar Ph.D. Candidate, Associate Director, Faculty of Pharmacy, Bioinformatics.org: The Open Lab University of Alberta gary@bioinformatics.org gary@penguin.pharmacy.ualberta.ca http://bioinformatics.org/gary -- -- From jeff at bioinformatics.org Tue Aug 15 10:55:50 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Poster for ISMB References: Message-ID: <399959F6.B6601555@bioinformatics.org> Gary Van Domselaar wrote: > > The poster looks great. The writing is excellent, Brad, well done! The final version should be ready by tonight. We'll post a PostScript file to the list then. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From chapmanb at arches.uga.edu Tue Aug 15 16:35:38 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Poster for ISMB part 2 Message-ID: <200008152035.QAA86498@archa13.cc.uga.edu> Hello all; We've got ready what is the "almost final" version of the poster for ISMB and BOSC. It is a huge postscript file (which I will double in size and then get printed on the ol' big paper at my friendly neighborhood Kinko's). The postscript and the LaTeX file are available from my normal place: http://www.bioinformatics.org/bradstuff/ Comments on the formatting or content would be greatly appreciated. I'll probably have the real final copy printed out late tonight sometime... Enjoy! Brad From jeff at bioinformatics.org Sat Aug 26 14:06:55 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Intel execs: Napster-like sharing will transform businesses Message-ID: <39A8073F.35BA91BF@bioinformatics.org> ``The peer-to-peer technology popularized by Napster could usher in the next wave of the Internet and, in the process, save companies billions of dollars by using computing power already in place, Intel executives said today.'' http://news.cnet.com/news/0-1003-200-2603611.html Jeff From chapmanb at arches.uga.edu Sat Aug 26 16:47:38 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] IRC about TextViewers Message-ID: <200008262047.QAA27752@archa11.cc.uga.edu> Hey all; I was doing some thinking about plugging things together more and how we would be returning output back to the user interface components. I wrote to Jean-Marc with the idea of having a TextViewer node that would return the text back to the user interface as follows: 1. UIDocument::run() would be called initially, to get the process started. 2. During the processing, the TextViewer node would do something like store the info that is to be displayed so that the BL can get it (this idea migrated into having callbacks during the IRC discussion). 3. The BL could then return the info back to the dl, which would place a callback to the user interface to let it know it had some values to display. This way we could keep the UI completely separate, and still return values back. Anyways, Jean-Marc and I had an IRC discussion about this, so here it is below, for your reading pleasure. As always, comments are very welcome. Enjoy! I'm off to start coding some of this... Brad Actually, I wanted to tell you that your last ideas (for text output) do make sense, and were something I was planning in the (near) future. So my last e-mail made some sense? Really? I'm happy that some of my ideas did get accepted into Piper. I think so far we managed to take the best from each project... I think so too. Now we just have to work on moving forward and adding more! Tell me what you think about this: instead of having a new system for the text output, why not use the Save node and create a special C++ stream that sends the data to a viewer instead of a file (or stdout) That sounds good, although I would like to pipe the steam through the bl (eventually) and then trhough the dl, instead of directly to the user interface. This way we can kind of keep the separation between user interface and everything else intact. Although I'm not so sure how well this will work in practice... Sure, you keep the same "Save" node and you can write any kind of stream. We can write one that sends that to the BL. That would be really great -- what do you think it would take to implement that? Well, you need to define a class that derives from iostream (or stream, I don't know) and that implements the standard stream operators (read, write, ..), but differenly that the file streams. For the rest, Jarl (and you?) know more about how to talk to the BL. I've been thinking, though. what do we do with the probes? Those are not like a viewer, they're interactive. Well, I don't know much about the BL... but how about if we wrote directly to the DL right now...Would I just need to wrap and store the info generated by the write operation? probes <- I'm not sure... (especially since I've never seen them in action :-). What do you use them for? a Probe is the Overflow equivalent of a debugger. You can see the data that passes through them for every iteration and you can control the flow with a set of next/stop/continue buttons. Take a look at http://freespeech.on.openprojects.net/08-03-00_023434_screenshot.jpg to see probes in action. Hmm, well I think we could use the same kind of thing for viewing them. Everytime you wrote to the "Save" stream, this would call an update in the user interface. But I'm not sure about controlling the flow...what are the functions that control the run() process right now? The problem is the flow control. As in a debugger, you tell the probes to stop the stream until you press next. The way a probe stops the flow is by not returning from getOutput() until the user presses next. This was the part where I changed semaphores for mutexes Okay, well how about if we had something like this: 1. The Probe has an internal variable, say 'info,' that gets set after every iteration. 2. The Probe also has a function has_info() which only returns TRUE when the info is set. 3. The BL or DL retrieves the info with a get_info() function every time has_info() is TRUE, and then displays this info by a callback to the User interface. 4. The User interface then has a "next" button like in your probes, that the DL or BL will call to advance the debugger to the next step. 5. The Probe then clears its info and runs again, and so on... Does this make sense or no? Let me think...... makes sense... but I think it would be better for the probe to send the info to the BL instead of waiting for the BL to read it. The result of this idea is to simply replace the GUI calls in the probes by BL calls, right? (Of course, the simple solution is to limit the probes to local processing...) info to the BL <- This make better sense, you are right. simple solution <- Right, but I guess we will have a similar problem with the "Viewer" function I was talking about. The probe is just a harder superclass of this same type of thing, right? This way, your text viewer will end up as being a modified TextProbe Yeah, that is what I was thinking! Does that seem like the right thing to do? For now it does look to me... we'll have to wait until Jarl comes up with a version of the BL that works with the DL. I've learned from developing Overflow that the line between a very clever idea and a stupid idea is often very thin! Definately true :-) --> katie (lizzy@cn-380.ccisp.net) has joined #piper For now, I suggest you try to work with the actual probes and we'll modify them when the BL starts getting stable. Also, what about a TextViewer that is at the end of a work path, like in my example. How is that handled? What do you mean by "at the end of a work path"? <-- katie (lizzy@cn-380.ccisp.net) has left #piper actual probes <- How about if I write a TextViewer.cc node that is similar to TextProbe, that does this sort of thing? (I think katie wasn't much interested in Piper!) I'm now sure I understand... end of work path <- I mean that then end of a set of connected nodes. Like in my diagram, the TextViewer kind of ends the connection path... understand <- Do you mean you do understand or don't? oops that should have read I'm NOT sure I understand... sort of changes the meaning! well, you just put the netOutput at the output of the probe? netOutput <- How would this be done exactly? In Overflow you explicitly set the output to point somewhere (like the less_print box), but in Piper this isn't necessarily true (like in the screenshot I sent you..) Also, if you don't want the result to be sent out of the network, you send it do a Discard node (returns NIL regardless of the input) Oh, okay, a discard node! But doesn't that still have an output connector? understand <- So you don't understand the TextViewer thing? I was just thinking maybe I could implement this type of viewer to do what I was trying to do, and then we can kind of see if it works. Maybe I'll just have it do callbacks to the DL for now or something. Well, regardless of the text viewer issue, all Overflow networks need to have an output. That ouput is printed with on stdout in batchflow or in a window in vflow. You do not have to print it in Piper, or you can use the Discard node, but you still need to have an output, since Overflow uses a "pull". But I thought Overflow would pull from the end of the path. I guess I'm confused -- where does the pull start from? The pull starts from the netOutput of the toplevel network. If you have more than one netOutput, Overflow will pull from all of them. Oooooh, netOutput! Right. Okay, I'll have to think of a way to make this jive with how things look in Piper... From what I understand, Piper (Loci) used to consider any unconnected terminal as a netOutput (or netInput). That's maybe where the confusion comes from. Okay, I think this makes some sense. I'm not sure if I understand the entire process of making a node, so I might go ahead and try to make a TextViewer node and see how it goes. I still don't understand how the TextViewer you want is different from the TextProbe unconnected terminals <- Yeah, this is definately the point of my confusion. TextViewer <- Well, I think it would be different in the following ways: 1. No "stopping" of process flow, like with your Probe nodes. 2. Try and implement some of this "callback" thing we were just talking about, so that the node wouldn't have to talk directly to the user interface. Does that make sense? Sure, go ahead... and tell me if you need help. I'm sure I will :-) It will be good for me to dig further into the whole node process anyways. I understand the UI layer okay now, but not the data-flow/node stuff, so I need to work on this anyways! Oh yeah, I've got another smaller question for you -- what case does Overflow expect the types of node parameters (and inputs and outputs) to be in? In this case, I suggest you start from the NOP node. NOP is the "no op" node and simply retuns its input, without any processing. For instance does it want INT or int or Int? NOP <- Sounds nice and easy -- a good place for me to start :-) Its lowercase (int, float), although the actual classes in the code are called Int, Float, so it doesn't cause problem with the real int, float types. Thanks. That is what I was thinking, but I wanted to be sure. I have everything as ALLCAPS now, and run doesn't like it :-) I'll work on changing it over to lowercase... For the rest (input/output name, parameter name, ...), you can use what you want for the node you build, but the convention (so far) is to use all caps for the input/output/parameter names and mixed for node names (like the ConstantVector node) Okay, I think I had been "sort of" sticking by this, but I'll keep an eye out to make sure everything is the same. Well, my girlfriend just arrived, and it seems like we're leaving for ice cream... (D'OH!) Sounds fun :-) So ttyl... Thanks for talking this stuff over with me, ttyl! <-- jm has quit ([x]chat) From chapmanb at arches.uga.edu Sun Aug 27 20:31:34 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? Message-ID: <200008280031.UAA35814@archa13.cc.uga.edu> Hey All; During the BOSC/ISMB conference that Jeff and I were at last week, I became a serious Wiki convert, and was thinking that Wiki might be the solution to lots of documentation needs for Piper. Basically Wiki is an environment for collaboratively building web pages. In this case, I think it would be great environment to work on documentation and idea building for Piper. Wiki allows you edit html pages with a simple markup system for bolding, verbatim and other fun stuff. What would people think about trying to adopt a Wiki type system for doing basic Piper documentation? I think the advantages are: 1. Easy to learn and work with -- makes it quick and easy for us to put together documentation and ideas. 2. We don't have to fight over docbook versus LaTeX versus AbiWord versus LyX or whatever for just putting together docs. 3. This might encourage other people besides developers to contribute to ideas, etc. As far as I can see the disadvantages are: 1. It is a web only format, so it couldn't be distributed as pdf, postscript, etc. I guess to get around this we would just need to have someone put together documentation in a format like LaTeX once a Wiki page got interesting enough to deserve it. Or, Wiki could just be something that goes along with documentation. 2. It could get messy if no one goes in and cleans it up every once in a while. So what do you all think? I set up a very nice python wiki, the MoinMoin wiki (http://moin.sourceforge.net) on my local machine. It was pretty easy to set up and configure and only requires python and a web server (I am using apache). You can check it out and play around on it here: http://24.9.210.117/piperwiki/moin.cgi If people think this is a good idea I have no problems setting it up on the bioinformatics.org site (probably with a bit of help from Gary to learn my way around :-). Thanks for reading -- I look forward to hearing your feedback! Brad From jeff at bioinformatics.org Sun Aug 27 21:30:46 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? References: <200008280031.UAA35814@archa13.cc.uga.edu> Message-ID: <39A9C0C6.7727859A@bioinformatics.org> Brad Chapman wrote: > > During the BOSC/ISMB conference that Jeff and I were at last > week, I became a serious Wiki convert, and was thinking that Wiki might > be the solution to lots of documentation needs for Piper. Yeah, I like Wiki. I met with Gary yesterday, who is here in Boston, and told him about Wiki and said that we should install it on the server. > 1. It is a web only format, so it couldn't be distributed as pdf, > postscript, etc. I guess to get around this we would just need to have > someone put together documentation in a format like LaTeX once a Wiki > page got interesting enough to deserve it. Or, Wiki could just be > something that goes along with documentation. HTML can be converted to PostScript (I don't know about direct conversion, but you can save a web page as a PostScript file in Netscape for Unix), and PostScript can be converted to PDF. > 2. It could get messy if no one goes in and cleans it up every once in a > while. I suppose that is true of many things in life :-) Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jean-marc.valin at hermes.usherb.ca Sun Aug 27 21:26:49 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? References: <200008280031.UAA35814@archa13.cc.uga.edu> Message-ID: <39A9BFD9.AB4A10B4@hermes.usherb.ca> > 2. We don't have to fight over docbook versus LaTeX versus AbiWord versus > LyX or whatever for just putting together docs. Now, he have to fight over *Wiki* versus LaTeX versus AbiWord versus LyX ;-) > 1. It is a web only format, so it couldn't be distributed as pdf, > postscript, etc. I guess to get around this we would just need to have > someone put together documentation in a format like LaTeX once a Wiki > page got interesting enough to deserve it. Or, Wiki could just be > something that goes along with documentation. This is a major disadvantage, I don't like the idea that the document can be in only one form. For that reason, I much prefer LyX (or LaTeX). Actually, my opinion on documentation format is: "He who writes the doc gets to decide on the format". Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jeff at bioinformatics.org Sun Aug 27 23:20:52 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] solutions spanning the drug discovery pipeline Message-ID: <39A9DA94.6F969A03@bioinformatics.org> ``ISMB 2000, LA JOLLA, Calif., Aug. 22 /PRNewswire/ -- Sun Microsystems, Inc. (Nasdaq: SUNW, news, msgs) and Molecular Simulations, Inc. (MSI), a wholly owned subsidiary of Pharmacopeia, Inc. (Nasdaq: PCOP, news, msgs), today announced their collaboration to deliver advanced dot-com grade solutions spanning the drug discovery pipeline. Leveraging the robust, scalable and highly-reliable Solaris(TM) Operating Environment, Sun and MSI will enable cheminformatics and bioinformatics researchers to deploy MSI's solutions across networked environments and through application service providers (ASPs). The collaboration aims to open new markets for MSI's bioinformatics and structural biology products, and demonstrates Sun's strengthened commitment to dot-com the discovery process.'' http://quicken.excite.com/investments/news/story/?story=/News/stories/pr/20000822/SFTU107.htm The cat is out of the bag. We should no longer be surprised when we see and hear people talk about ideas similar to ours for Piper. As the Intel article I sent yesterday says, the concept is likely to be the next big wave on the Internet. Now we can play along or take a back seat. I'd rather play :-) Jeff From jeff at bioinformatics.org Sun Aug 27 23:37:36 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] SashXB for Linux Message-ID: <39A9DE80.AD7A6FBF@bioinformatics.org> Gary mentioned Sash to me the other day. It too has a lot in common with Piper, but probably more on the BlueBox side of the collaborative. However, I don't particularly care for its dependency on such massive "libraries" as "Mozilla". ``Sash can be thought of as technology that maps the native Application Programming Interfaces (API's) provided by an operating system and it's particular Graphical User Interfaces to ones that are abstracted and straightforward enough to be useful to web page developers who use HTML, JavaScript and XML.'' http://oss.software.ibm.com/developerworks/opensource/sashxb/ Jeff From jeff at bioinformatics.org Mon Aug 28 00:16:00 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] ISYS and OpenBSA Message-ID: <39A9E780.7C1770DC@bioinformatics.org> When Brad and I were at ISMB 2000 last week, we came upon 2 posters about applications very similar to Piper. I spoke with both authors. ISYS uses Java for its GUI and most of its framework, but the clients need not be in Java. ISYS is more developed than Piper in that it can already connect clients together. However, they do not have a way to pre-design a network, and especially have not considered a "connect-the-dots" GUI like Pied. The license is "free for non-commercial use" and the source is not available. They do have a nicely developed API (not in XML though) for wrapping applications that we should take a look at. http://www.ncgr.org/research/isys (Adam Siepel, coordinator) OpenBSA also uses Java and has more in common with ISYS than with Piper. OpenBSA is however Open Source. It is partly based on Applab, which we (Loci developers) have considered before as a way to wrap applications. The author did tell me that they are working on a GUI for pre-designing a network. OpenBSA can work with generic clients, but they are pushing it as a bioinformatics tool. Both applications, as you can tell from the URL's, are in fact hosted by bioinformatics organizations. http://industry.ebi.ac.uk/openBSA (Juha Muilu, coordinator) I asked the authors of both applications if we can all work on a common API for wrapping applications. This would allow a client wrapped for one system to work in another system. They said yes, but considering that ISYS does not use XML and OpenBSA already uses Applab, I don't know if we could reach a consensus. Can I get the opinions of people on this list before I consider contacting them again? Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From chapmanb at arches.uga.edu Mon Aug 28 03:18:25 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? In-Reply-To: <39A9BFD9.AB4A10B4@hermes.usherb.ca> Message-ID: <200008280718.DAA34372@archa12.cc.uga.edu> Jean-Marc wrote: > Now, he have to fight over *Wiki* versus LaTeX versus AbiWord versus > LyX ;-) Well, you've got me there :-). [Wiki is really only for making Web based documentation] > This is a major disadvantage, I don't like the idea that the document > can be in > only one form. For that reason, I much prefer LyX (or LaTeX). I guess we could make a distinction between two types of documentation: 1. Real hard-core documentation that describes a particular part of Piper design or use. I agree with you that this should be done in LaTeX (or rather, the format of whoever works on it first). 2. Documentation on ideas, design discussion, and "softer" documentation, like how to install Piper, how to get started coding on Piper, ToDo lists, etc. The distinction between this and "hard-core" documentation is that this stuff is more likely to change regularly, and have multiple people contribute to it (ie. to make install instructions more clear, add to a discussion, etc). Anyways, I am for this type of documentation being done in Wiki. The reason I like Wiki is because I've just been trying to think up ideas to make people more likely to contribute. Right now, if someone wanted to contribute, basically we would just say something like: "Well, read through the mailing list and get up to speed." which is not neccessarily so easy or fun to do. I thought maybe if we could structure some discussions in Wiki (or at least paste them over there after they happen on the mailing list) it might help organize things and lessen the barriers to entry. What do you think? Do you think Wiki can serve a useful purpose, in addition to LaTeX/LyX et al. documentation, in this type of framework? Brad From jean-marc.valin at hermes.usherb.ca Mon Aug 28 03:50:00 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? References: <200008280718.DAA34372@archa12.cc.uga.edu> Message-ID: <39AA19A8.2F04F591@hermes.usherb.ca> > 1. Real hard-core documentation that describes a particular part of Piper > design or use. I agree with you that this should be done in LaTeX (or > rather, the format of whoever works on it first). > > 2. Documentation on ideas, design discussion, and "softer" documentation, > like how to install Piper, how to get started coding on Piper, ToDo > lists, etc. The distinction between this and "hard-core" documentation is > that this stuff is more likely to change regularly, and have multiple > people contribute to it (ie. to make install instructions more clear, add > to a discussion, etc). Anyways, I am for this type of documentation being > done in Wiki. Sounds reasonable. In the worst case, we'd just switch from Wiki to standard HTML, which is easy to do. I agree that what you call soft doc is mostly useful in HTML form anyway. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Tue Aug 29 02:00:51 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? References: <200008280031.UAA35814@archa13.cc.uga.edu> Message-ID: <39AB5193.EA3BD991@casema.net> > > > If people think this is a good idea I have no problems setting it up on > the bioinformatics.org site (probably with a bit of help from Gary to > learn my way around :-). Thanks for reading -- I look forward to hearing > your feedback! Look good. HTML is fine to me. bye, jarl From pvh at egenetics.com Mon Aug 28 07:49:34 2000 From: pvh at egenetics.com (Peter van Heusden) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] ISYS and OpenBSA In-Reply-To: <39A9E780.7C1770DC@bioinformatics.org> Message-ID: On Mon, 28 Aug 2000, J.W. Bizzaro wrote: > > I asked the authors of both applications if we can all work on a common API > for wrapping applications. This would allow a client wrapped for one system > to work in another system. They said yes, but considering that ISYS does not > use XML and OpenBSA already uses Applab, I don't know if we could reach a > consensus. No, OpenBSA is an AppLab replacement, and it also uses XML (based on the old GCG wrapper formal) to specify wrappings. I've just bugged Juha again on actually making the code available, so we should hopefully see what's out there soon enough. For the record, I'm for a standard, if only one shared between OpenBSA and Piper (and dare I hope, NetGenics' BSA-compliant product...). Peter -- Peter van Heusden NOTE: I do not speak for my employer, Electric Genetics "Criticism has torn up the imaginary flowers from the chain not so that man shall wear the unadorned, bleak chain but so that he will shake off the chain and pluck the living flower." - Karl Marx, 1844 From gvd at penguin.pharmacy.ualberta.ca Mon Aug 28 13:22:42 2000 From: gvd at penguin.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:20:25 2006 Subject: [Pipet Devel] Wiki for Piper? In-Reply-To: <200008280031.UAA35814@archa13.cc.uga.edu> Message-ID: I took a quick look at Wiki and I think it looks great. Like Brad suggests, I think Wiki is useful for assembling the 'soft documentation', which can then be reworked into formal documentation in a structured docuement format. Can we install it on Thurs? I have an interview on Wednesday to prepare for. Regards, g. -- -- Gary Van Domselaar Ph.D. Candidate, Associate Director, Faculty of Pharmacy, Bioinformatics.org: The Open Lab University of Alberta gary@bioinformatics.org gary@penguin.pharmacy.ualberta.ca http://bioinformatics.org/gary -- -- From chapmanb at arches.uga.edu Tue Aug 29 22:15:45 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] ISYS and OpenBSA In-Reply-To: Message-ID: <200008300215.WAA44270@archa13.cc.uga.edu> Jeff wrote: [described ISYS and OpenBSA/ALBeanBox -- two application with similar goals to Piper] > I asked the authors of both applications if we can all work on a common API > for wrapping applications. This would allow a client wrapped for one system > to work in another system. They said yes, but considering that ISYS does not > use XML and OpenBSA already uses Applab, I don't know if we could reach > a consensus. Can I get the opinions of people on this list before I consider > contacting them again? Peter wrote: > For the record, I'm for a standard, if only one shared between OpenBSA > and Piper (and dare I hope, NetGenics' BSA-compliant product...). I'd like to add my enthusiastic support to the idea of trying to collaborate with OpenBSA/ALBeanBox and the ISYS projects. I think we all have the same goal in mind (ie. an easy to use tool that can connect stuff together) and we will get there a lot faster and with better success if we can work together. So far our collaborations with Overflow and GMS have been really excellent, and I'd really be for seeing this type of thing continue. So when you contact them Jeff, can you keep us informed of what happens? I don't know if either the projects has active public mailing lists, but I think here would be a good place to discuss colloborating, if they are into it. Thanks for thinking about putting this together! Brad From jeff at bioinformatics.org Tue Aug 29 23:11:32 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] pictures from BOSC Message-ID: <39AC7B64.28B6824F@bioinformatics.org> Greetings. Attached are some pictures of Brad and me during the BOSC conference a couple weeks ago. Brad is the one with the baseball cap. I suppose now you can put faces to some of the names you see on this list :-) There are some more pictures from the conference on the BioPerl site: http://bio.perl.org/bosc-2000/pictures.html Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: brad+jeff.jpg Type: image/jpeg Size: 14657 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000830/728c255b/bradjeff.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: brad.jpg Type: image/jpeg Size: 14873 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000830/728c255b/brad.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: jeff-cropped.jpg Type: image/jpeg Size: 5807 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000830/728c255b/jeff-cropped.jpg From jeff at bioinformatics.org Wed Aug 30 00:01:43 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] standard API for ISYS, OpenBSA & Piper Message-ID: <39AC8727.53140912@bioinformatics.org> Adam and Juha, I spoke with both of you at your respective posters during ISMB2000. I'm the coordinator of the Piper project, which is very similar to both ISYS and OpenBSA. I asked if you would consider developing a standard API that defines how our systems could interface with an independent program (client or node). The advantage is that programs wrapped to work with one system will work with all 3. You both said that you thought it would be a good idea :-) I don't believe that either of you are familiar with each other's system (ISYS and OpenBSA). At least, Juha told me that he did not see the ISYS poster. So, I will quickly summarize where I believe we all stand. Correct me if I am wrong. o ISYS has developed an API based on what looked to me like C or Java code. Adam said that he would consider an XML-based API. o OpenBSA is a replacement for Applab and so uses a similar API. I don't know what stage of development that API is in. o Piper is in the process of clearly defining an API based on XML. Piper uses XML extensively. Perhaps we can all work toward defining an XML-based API? The main requirement that Piper has is that we want to automate program wrapping and/or have it done graphically by the user. In other words, have the API be straight-forward enough so that a human need not program it by hand. What do you think? If we all agree to work on this, I can create a mailing list (and subsequently a CVS module) for this collaborative sub-project. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From muilu at ebi.ac.uk Wed Aug 30 05:07:31 2000 From: muilu at ebi.ac.uk (Juha Muilu) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] Re: standard API for ISYS, OpenBSA & Piper References: <39AC8727.53140912@bioinformatics.org> Message-ID: <39ACCED3.ED8E5D59@ebi.ac.uk> Hi Jeff, Thanks for the mail! The idea of integrating our systems is great and we are happy to collaborate. The openBSA project consist basically two separate systems. One is the application server which uses new BSA compliant API and other one is ALBeanBox components. The ALBeanBox contains Java beans that can be connected together based on XML metadata to make analysis pipelines. ALBeanBox framework as such is independent of BSA system, but we have made couple of BSA specific beans for running remote applications and for visualizing the BSA bio-objects. Configuration of the BSA server based also on XML metadata, which is used to describe properties of analysis applications (e.g. input/output data, command line parameters..) and how the output is adapted (e.g.. conversion to CORBA or XML bio-objects). Currently the XML metadata is auto generated from GCG like configuration files, but Martin is planning to make GUI tool for that (perhaps same tool can be used also with the ALBeanBox components as well) The system is more or less working and can be found from: http://industry.ebi.ac.uk/openBSA The BSA API is already standardized, but it is open for extensions and also for small changes, I believe. I wonder is this something you can use or are you thinking some higher level abstraction!? I do not fully understand what you meant by XML-based API... Perhaps we can made bridge components to connect our systems and then have common GUI tools (and XML format) for building pipelines. Cheers, Juha "J.W. Bizzaro" wrote: > > Adam and Juha, > > I spoke with both of you at your respective posters during ISMB2000. I'm the > coordinator of the Piper project, which is very similar to both ISYS and > OpenBSA. > > I asked if you would consider developing a standard API that defines how our > systems could interface with an independent program (client or node). The > advantage is that programs wrapped to work with one system will work with all > 3. You both said that you thought it would be a good idea :-) > > I don't believe that either of you are familiar with each other's system (ISYS > and OpenBSA). At least, Juha told me that he did not see the ISYS poster. > So, I will quickly summarize where I believe we all stand. Correct me if I am > wrong. > > o ISYS has developed an API based on what looked to me like > C or Java code. Adam said that he would consider an > XML-based API. > > o OpenBSA is a replacement for Applab and so uses a similar > API. I don't know what stage of development that API is in. > > o Piper is in the process of clearly defining an API based > on XML. Piper uses XML extensively. > > Perhaps we can all work toward defining an XML-based API? The main > requirement that Piper has is that we want to automate program wrapping and/or > have it done graphically by the user. In other words, have the API be > straight-forward enough so that a human need not program it by hand. > > What do you think? If we all agree to work on this, I can create a mailing > list (and subsequently a CVS module) for this collaborative sub-project. > > Cheers. > Jeff > -- > J.W. Bizzaro jeff@bioinformatics.org > Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff > "Injustice anywhere is a threat to justice everywhere." > -- Martin Luther King, Jr. > -- -- +--------------------------------------------------------------------+ |Juha Muilu, Ph.D., EMBL Outstation| Email: muilu@ebi.ac.uk | |European Bioinformatics Institute | Phone: +44 (0)1223 494 624 | |Wellcome Trust Genome Campus | Fax: +44 (0)1223 494 468 | |Hinxton, Cambridge CB10 1SD, UK | http://industry.ebi.ac.uk/~muilu| +--------------------------------------------------------------------+ From senger at ebi.ac.uk Wed Aug 30 05:28:45 2000 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] Re: standard API for ISYS, OpenBSA & Piper In-Reply-To: <39ACCED3.ED8E5D59@ebi.ac.uk> Message-ID: Hi all, I am very happy that a discussion about collaborating and exchanging of the software component has started. I think that Jeff's idea about having a mailing list for comparing various approaches is useful. We may use such mailing list to clarify things and hopefully to find how the components (whatever they are) can be re-used. I am interested especially in finding more about various approaches how to "pipe" together more applications. The BSA standard (implemented by EBI under the project called "OpenBSA") is a CORBA-based standard defining how to run and control _an_ analysis, not the pipe of analysis. The BSA specification can be used within some framework spec (or API, or whatever) combining more analysis together. Our ALBeanBox project aims to do it - but it does the "piping" using Java events, not CORBA, and it is a EBI's spec not 'blessed' by any standard. Regarding XML, we like it (who does not? :-)) - however, in our projects the role of XML is mostly for metadata, and less for the real data (which may radically changed for microarry data, but still other projects, especially OpenBSA and its component projects, will use it mainly for metadata). This may correspond with your definitions "XML-based API" - am I right? Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From jeff at bioinformatics.org Wed Aug 30 05:48:38 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] Re: standard API for ISYS, OpenBSA & Piper References: <39AC8727.53140912@bioinformatics.org> <39ACCED3.ED8E5D59@ebi.ac.uk> Message-ID: <39ACD876.81FC00C6@bioinformatics.org> Okay, I have created a mailing list on our server for discussing standards between us. The name of the list is "DNP-API", which stands for "Distributed Network of Programs API". It is a Mailman mailing list, and you can subscribe via the Web: http://bioinformatics.org/mailman/listinfo/dnp-api See you there :-) Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From acs at ncgr.org Wed Aug 30 11:13:03 2000 From: acs at ncgr.org (Adam C. Siepel) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] Re: standard API for ISYS, OpenBSA & Piper In-Reply-To: <39ACD876.81FC00C6@bioinformatics.org> References: <39AC8727.53140912@bioinformatics.org> <39ACCED3.ED8E5D59@ebi.ac.uk> <39ACD876.81FC00C6@bioinformatics.org> Message-ID: <14765.9343.790317.215639@gargle.gargle.HOWL> Hi Jeff -- thanks for your interest ... I've been meaning to get in touch with both you and the EBI folks with OpenBSA (whose poster I did study) but have been busy since ISMB with some other stuff. I agree that there's potentially much room for collaboration. I want to take a second look at the material on both of your systems to develop a better idea of how we might work together; as soon as I've done so, I'll try to respond in a less superficial way. In the meantime, I invite all of you to check out our website at http://www.ncgr.org/research/isys. The material there is presented for a general audience, but there is some substance to be found amid the hype. In short, ISYS is a client-side platform that focuses on intuitive, visual integration among user interface components. It uses a decentralized, bottom-up approach by which components can interoperate without being "hardwired" together. We're interested in doing pipelines but so far have not done the necessary design work (a good reason to collaborate with you folks). Our model for distributed computing is restricted -- essentially, server proxies pull resources from other servers into the client-side environment, making it appear local. Our platform and most of our components are written in Java. We're not using Beans because we're not too interested in the use of IDEs for component assembly, but there's no reason why our components couldn't be converted to Beans. We've avoid use of XML for data exchange among client-side components for performance reasons but there's no reason why components shouldn't provide external interfaces based on XML. Adam Siepel J.W. Bizzaro writes: > Okay, I have created a mailing list on our server for discussing standards > between us. The name of the list is "DNP-API", which stands for "Distributed > Network of Programs API". > > It is a Mailman mailing list, and you can subscribe via the Web: > > http://bioinformatics.org/mailman/listinfo/dnp-api > > See you there :-) > > Jeff > -- > J.W. Bizzaro jeff@bioinformatics.org > Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff > "Injustice anywhere is a threat to justice everywhere." > -- Martin Luther King, Jr. > -- > -- Adam Siepel phone: (505)982-7840 IT Program Leader, Integration fax: (505)995-4432 National Center for Genome Resources WWW: http://www.ncgr.org 2935 Rodeo Park Drive East e-mail: acs@ncgr.org Santa Fe, NM 87505 From jean-marc.valin at hermes.usherb.ca Thu Aug 31 12:28:12 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:26 2006 Subject: [Pipet Devel] Profiling Overflow Message-ID: <39AE879C.8A6BA08@hermes.usherb.ca> Hi, This information might be interesting to some of you. I have done some profiling in Overflow in order to measure the overhead of spliting the process into nodes (the overhead of Overflow vs. C/C++). The tests were performed on my Athlon 500. Here are the timings I got (+- 10%): Node overhead: 2.7 us (1350 clock cycles) Loop overhead: 1.1 us (550 clock cycles) The node overhead is the time it takes to execute the simplest node. It means that you should try, on average, to have nodes that do more that 2.7 us of calculation. Loop overhead is the minimum time for one loop iteration. Basically, it means that the loop overhead is negligeable. I think these timings are quite reasonable. What that means is that if you use Overflow (or Piper, of course!) to compute FFT's, then your everhead is negligeable, but it you use it for elementary operations (+,-,*,/) at the node level, then expect to pay a high price. When I tried the same with matlab I got: Function (node) overhead: 8-18 us (8 for a builtin, 18 for an m-file) Loop overhead: < 1 us (I cannot measure more precisly) Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca