From bizzaro at geoserve.net Mon Jun 19 13:38:11 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] old messages Message-ID: <394E5A82.7AF58B22@geoserve.net> This morning you may have gotten some messages from this list dated back a couple months. Just ignore them. It's some sendmail bug on the older system. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 19 16:44:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:33 2006 Subject: [Pipet Devel] THE SECOND COMING - A MANIFESTO Message-ID: <394E864B.7AF07231@geoserve.net> I found this interesting and relevant: ``"Second Coming," a 10,000-word essay, contends that rather than remaining a world that Microsoft or any company might dominate, computing is actually shifting to a world in which data and computer processing will be increasingly spread across thousands, if not millions, of interconnected computers. "Information travels through a sea of anonymous, interchangeable computers like a breeze through tall grass," Mr. Gelernter wrote.'' Sound familiar? NY Times article: http://www.nytimes.com/library/tech/00/06/biztech/articles/19gale.html David Gelernter's (a very well-known Yale comp-sci prof) essay: http://www.edge.org/3rd_culture/gelernter/gelernter_p1.html Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 1 01:20:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:00 2006 Subject: [Pipet Devel] piper 0.0.0 suggestions Message-ID: <3935F2A7.27BE5F29@geoserve.net> I tried installing piper-0.0.0 as root, but running it as jeff, I get the following errors: ----------------------------------------------------------- jeff@dexter:loci> piper Traceback (innermost last): File "/usr/bin/piper", line 24, in ? os.chmod("runpiper.py", 0755) OSError: [Errno 1] Operation not permitted: 'runpiper.py' ----------------------------------------------------------- The error is obviously because the root owns the file and jeff can't change the mode. Looking up the command, it seems chmod is run if permission denied returned. Here's why: -rw-r--r-- 1 root root 2815 Jun 1 00:35 runpiper.py Could/should chmod 0755 be run in the install script? I have the same problem with... uil/pied/locignome.py dl/startdl.py 'temp' (wherever that goes) You may also want to change this: /usr/piper/uil/pied/modules/middlecommunicate.py lines 47-50: ----------------------------------------------- except socket.error: if (middle_started == 0): middle_started = 1 os.system("./loci -g=off &") ----------------------------------------------- ^^^^^^^^^^^^ command not found A couple more things: When I run... ./config --prefix=/usr the usual... /usr/lib /usr/bin get populated, and that's fine, but I also end up with... /usr/piper which I'd rather not have. Running RedHat Linux, I would put Piper's home dir in... /usr/opt/piper or /usr/home/piper My question is: Can we allow 2 locales to be defined on config? Also, for the sake of updating Piper (when that time comes), would it be better to specify the version number in the path, like... /usr/opt/piper-0.0.0 ? So that we don't mix the new with the old. BTW Brad, I am utterly amazed by how much you've done to put this package together. And such a great job! The install instructions are better than I've seen for most applications, especially omniORB (ick). I need to get off my arse and make a better UI to go along with it. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu Jun 1 12:44:49 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> Message-ID: <39369301.A1ABB72A@casema.net> > > Like I said before, I think GConf is very usedfull for gathering information about > > applications that are about to be wrapped. > > Yes, I remember :-) > > > Not for me :) But I wont stand in your way if you people ever port Piper to some > > other environment. GMS needs some serious modifications to remove gnome > > dependancies is we were to do so. > > What are the dependencies you have? > Most of the gnome dependancies are inside the GUI, but I use some non-graphical gnome features in de dataflow processor. These wont be hard to remove. Something that can not be removed is glib. I'll be gone for a week, expect me to catch up after I'm back. Hollyday to Rome. laters, jarl From chapmanb at arches.uga.edu Thu Jun 1 10:55:55 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] piper 0.0.0 suggestions Message-ID: <200006011458.KAA110550@archa10.cc.uga.edu> Hey Jeff; Thanks for looking at the package, and for the bug reports! > I tried installing piper-0.0.0 as root, but running it as jeff, I get the > following errors: [...snip...trace...] > The error is obviously because the root owns the file and jeff can't change > the mode. Looking up the command, it seems chmod is run if permission denied > returned. Here's why: > > -rw-r--r-- 1 root root 2815 Jun 1 00:35 runpiper.py > > Could/should chmod 0755 be run in the install script? Ooops, yeah, I am installing these scripts as python modules and not as scripts, so they don't get chmoded. I'll fix this. I think I'll also double fix it by calling the scripts using "python runpiper.py," so this should take care of everything :-) > /usr/piper/uil/pied/modules/middlecommunicate.py lines 47-50: > ----------------------------------------------- > except socket.error: > if (middle_started == 0): > middle_started = 1 > os.system("./loci -g=off &") > ----------------------------------------------- > ^^^^^^^^^^^^ > command not found Ok, lingering traces of Loci... I'll try to flush these out. Thanks! [...snip... Jeff wants the scripts in $prefix/bin and the piper directory somewhere else...] > My question is: Can we allow 2 locales to be defined on config? I'll look into this. I guess what I'd probably try to do is have an optional configure argument --piperprefix in addition to prefix, so you could do: ./configure --prefix=/usr --piperprefix=/usr/home and do what you want. Does this sound good? Damn, why can't everyone just put everything in /usr/local and be happy with it :-). > Also, for the sake of updating Piper (when that time comes), would it be > better to specify the version number in the path, like... > > /usr/opt/piper-0.0.0 > > ? So that we don't mix the new with the old. Okay, I'll look at this too. I think what would be best if you want this is to have piper-0.0.0 or whatever, and then a symlink from piper -> piper-0.0.0, then when you install you just install the new package (piper-0.1) and update the link to point to this. I have no clue how to do this, but I can look into it. > The install instructions are better than > I've seen for most applications, especially omniORB (ick). I'm glad they were helpful. If anything is unclear I'll be happy to update it, I think it is much nicer to write nice install instructions then to always be answering a million questions about installation. Plus then we can give people a hard time if they ask a question and don't read the documentation :-). > I need to get off > my arse and make a better UI to go along with it. Hopefully, I'll be able to get a new tarball up within a few days with the new corba communication between the dl and uil and this will give something a little more stable to work off of. It would of course be quite excellent to have improvements on the UIs. This is definately one of the most important parts o' Piper, especially since that is what a lot of people base their initial impressions on, irregardless of how good (or bad) the underlying program is. Plus, no one else much likes doing GUI stuff, so we are quite excited that you like to work on this! Brad From bizzaro at geoserve.net Thu Jun 1 12:38:00 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] piper 0.0.0 suggestions References: <200006011458.KAA110550@archa10.cc.uga.edu> Message-ID: <39369168.A6B7DD72@geoserve.net> Brad Chapman wrote: > > Ooops, yeah, I am installing these scripts as python modules and not > as scripts, so they don't get chmoded. I'll fix this. I think I'll > also double fix it by calling the scripts using "python runpiper.py," > so this should take care of everything :-) Yeah, that should do it. > I'll look into this. I guess what I'd probably try to do is have an > optional configure argument --piperprefix in addition to prefix, so > you could do: > > ./configure --prefix=/usr --piperprefix=/usr/home > > and do what you want. Does this sound good? Damn, why can't everyone > just put everything in /usr/local and be happy with it :-). [snip stuff about piper-0.0.0 being dir name] > Okay, I'll look at this too. I think what would be best if you want > this is to have piper-0.0.0 or whatever, and then a symlink from piper > -> piper-0.0.0, then when you install you just install the new package > (piper-0.1) and update the link to point to this. I have no clue how > to do this, but I can look into it. I was thinking (amazing, aint it?) about a single solution to both problems. Instead of the second option being... --piperprefix=/usr/home it could be... --piperhome=/usr/home/piper-0.0.0 Then, people can put the thing wherever they want AND name it whatever they want :-) What do you think? > Hopefully, I'll be able to get a new tarball up within a few days with > the new corba communication between the dl and uil and this will give > something a little more stable to work off of. It would of course be > quite excellent to have improvements on the UIs. This is definately > one of the most important parts o' Piper, especially since that is > what a lot of people base their initial impressions on, irregardless > of how good (or bad) the underlying program is. Plus, no one else much > likes doing GUI stuff, so we are quite excited that you like to work > on this! I'm glad to have a smaller piece of code to work on and that it's the piece I enjoy working on the most. I can't imagine writing this whole thing myself anymore :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 1 12:59:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> Message-ID: <39369684.43399ABD@geoserve.net> jarl van katwijk wrote: > > Most of the gnome dependancies are inside the GUI, but I use some non-graphical gnome > features in de dataflow processor. These wont be hard to remove. Something that can not > be removed is glib. Yeah, glib is pretty popular now with C programmers. I thought I heard of a library being made just like it, maybe for C++. Anyone know what I'm talking about? > I'll be gone for a week, expect me to catch up after I'm back. Hollyday to Rome. Have fun. It sure sounds like it will be :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Jun 1 13:08:37 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] piper 0.0.0 suggestions Message-ID: <200006011711.NAA116638@archa10.cc.uga.edu> [...snip...my babbling about symlinks...] > I was thinking (amazing, aint it?) about a single solution to both problems. > Instead of the second option being... > > --piperprefix=/usr/home > > it could be... > > --piperhome=/usr/home/piper-0.0.0 > > Then, people can put the thing wherever they want AND name it whatever they > want :-) What do you think? I think you are a genius :-). I'll definately do it this way. > I'm glad to have a smaller piece of code to work on and that it's the piece I > enjoy working on the most. I can't imagine writing this whole thing myself > anymore :-) Me neither! Brad From bizzaro at geoserve.net Thu Jun 1 13:19:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] piper 0.0.0 suggestions References: <200006011458.KAA110550@archa10.cc.uga.edu> <39369168.A6B7DD72@geoserve.net> Message-ID: <39369B3C.C88BE5ED@geoserve.net> "J.W. Bizzaro" wrote: > > --piperhome=/usr/home/piper-0.0.0 Make the default... --piperhome=/usr/local/piper-0.0 We can have... piper-0.0 piper-0.1 piper-0.2 piper-0.3 ... and move up in number each time an upgrade would cause problems (e.g., the directory structure changes). This is pretty much what Python does, as they've been using the directory... python1.5 even though they've been using version numbers 1.5.0, 1.5.1, 1.5.2. (BTW, the dash "-" is used in about 1/2 of all directories with version numbers.) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 1 13:24:12 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] piper 0.0.0 suggestions References: <200006011458.KAA110550@archa10.cc.uga.edu> <39369168.A6B7DD72@geoserve.net> <39369B3C.C88BE5ED@geoserve.net> Message-ID: <39369C3C.4CED1F75@geoserve.net> "J.W. Bizzaro" wrote: > > Make the default... > > --piperhome=/usr/local/piper-0.0 > > We can have... > > piper-0.0 > piper-0.1 > piper-0.2 > piper-0.3 > ... Oh, and go ahead and start number the releases. I think the next one you post can be 0.0.1. 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 Jun 1 14:51:11 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> Message-ID: <3936B09F.ED0E5888@hermes.usherb.ca> > > Most of the gnome dependancies are inside the GUI, but I use some non-graphical gnome > > features in de dataflow processor. These wont be hard to remove. Something that can not > > be removed is glib. > > Yeah, glib is pretty popular now with C programmers. I thought I heard of a > library being made just like it, maybe for C++. Anyone know what I'm talking > about? Well, for C++, there's the STL (Standart Template Library) which is now part of the new ANSI standard. Since it uses templates and is all inline code, it is very fast, and Overflow makes heavy use of it. Combined with the automatic reference counting ("smart pointer" style garbage collection), it's possible to program without ever caring about leaks, array overflows, ... glib is like the C equivalent of the C++ STL (but more compilcated, because of C). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Thu Jun 1 15:51:12 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> Message-ID: <3936BEB0.980D7682@geoserve.net> Jean-Marc Valin wrote: > > Well, for C++, there's the STL (Standart Template Library) which is now part of > the new ANSI standard. Since it uses templates and is all inline code, it is > very fast, and Overflow makes heavy use of it. Combined with the automatic > reference counting ("smart pointer" style garbage collection), it's possible to > program without ever caring about leaks, array overflows, ... glib is like the C > equivalent of the C++ STL (but more compilcated, because of C). That's it :-) Maybe this sounds naive (I'm not very experienced with C/C++ nonetheless STL), but could Jarl use STL for the BL? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 1 16:22:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] librsvg Message-ID: <3936C5ED.F07A683B@geoserve.net> "Librsvg is a library currently living inside the Nautilus codebase for batch rendering of SVG files. It derives its SVG support from the Gill codebase, but with these latest commits passes Gill in functionality. There may be other interesting applications for Librsvg, for example to dynamically generate web graphics." I think this is what the author of Sodopodi sent us a message about. I believe librsvg will lead to a very important viewer for Pied/Piper. All we need are some Python bindings. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 1 16:27:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] Embedding Mozilla into Gtk Applications Message-ID: <3936C741.C0CDB5C4@geoserve.net> This looks interesting too: http://www.mozilla.org/unix/gtk-embedding.html Jeff From jean-marc.valin at hermes.usherb.ca Thu Jun 1 16:26:14 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3936BEB0.980D7682@geoserve.net> Message-ID: <3936C6E6.93FDDEF@hermes.usherb.ca> > > Well, for C++, there's the STL (Standart Template Library) which is now part of > > the new ANSI standard. Since it uses templates and is all inline code, it is > > very fast, and Overflow makes heavy use of it. Combined with the automatic > > reference counting ("smart pointer" style garbage collection), it's possible to > > program without ever caring about leaks, array overflows, ... glib is like the C > > equivalent of the C++ STL (but more compilcated, because of C). > > That's it :-) > > Maybe this sounds naive (I'm not very experienced with C/C++ nonetheless STL), > but could Jarl use STL for the BL? Not unless the BL switches to C++. The STL (as the name implies) is heavily based on templates, a C++ only feature. I think all the glib types have an equivalent in the STL (lists, trees, ...). Jean-Marc From bizzaro at geoserve.net Thu Jun 1 19:58:40 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] apache xml parser Message-ID: <3936F8B0.BE366F@geoserve.net> "As part of the Apache XML effort, IBM and other software firms previously donated their XML parsers, so Apache could take the best features of each and combine them into one product....In March, Sun Microsystems was criticized for not donating its parser as promised. The company has since submitted its parser, and the Apache group is now considering how to incorporate Sun's technology into the Apache parser." http://news.cnet.com/news/0-1003-200-1993071.html It looks like Apache is going to have one heck of an XML parser. Have you looked into it, Brad? Too bad it's not GPL. We may still be able to use it though. Jeff From chapmanb at arches.uga.edu Thu Jun 1 21:10:36 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] apache xml parser Message-ID: <200006020113.VAA46596@archa10.cc.uga.edu> > It looks like Apache is going to have one heck of an XML parser. Yeah, all the nitty gritty info is at xml.apache.org. Xerces, the XML parser, is really nice since it is fully validating and everything. Right now I just started using xmlproc, which is also fully validating. It's written in pure python tho, so it is probably a bit slower. However, the number of bugs I've already caught is so incredible that I'm going to stick with validation (now that I finally learned how to write DTDs :-). > Too bad it's not GPL. The license is copyright only, I think (http://xml.apache.org/dist/LICENSE.txt), so it is even better. > We may still be able to use it though. Well, no python bindings :-<. Writing python bindings for an XML parser and making it fit into the existing python XML framework is not an easy task, unfortunately. The easiest way to use it would be if I started working in jpython, then I could use the java version of the parser. Brad From deanne at density.biop.umich.edu Thu Jun 1 21:03:03 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] Peep In-Reply-To: <3935F2A7.27BE5F29@geoserve.net> Message-ID: Last weekend, I got the basic form of peep running, which is using the Cmd.cmd class. I've pasted a sample "dummy" session below to show you what it'll look like. I put the code at the end. Brad helped me in choosing to use python dictionaries instead of lists... I was debating whether to send this to the list, since it's so damn simple, but heck. You may not like the use of the cmd class. If you put in something that's not in the interpretation list (do_) you just get a "Unknown syntax" error. If you hit return for a blank line, it repeats the last command, though I'm sure I can override that. This will allow you to limit input in peep to a handful (or more) of commands as well as include a built-in help handler. Simple and effective... D Sample of peep front end --------------------------------------- density:~/python> python peep_input.py Welcome to Peep! Type 'help' for help. help Documented commands (type help ): ======================================== EOF nodelist nodeset Undocumented commands: ====================== help jobscan help nodeset Allows you to set the node name, number, and IP address for a node instance. Nod e number should be an integer of where the node falls in your process. You can r eview this with 'nodelist' (see 'help nodelist') nodeset Enter the number of the new node: 1 Enter new node type: type1 Enter the remote IP or name for this node: 121.00.00.00 Node number: 1 Node Type: type1 Remote IP: 121.00.00.00 nodeset Enter the number of the new node: 2 Enter new node type: type2 Enter the remote IP or name for this node: 121.00.00.01 Node number: 2 Node Type: type2 Remote IP: 121.00.00.01 nodeset Enter the number of the new node: 3 Enter new node type: type3 Enter the remote IP or name for this node: 12.1.11.0 Node number: 3 Node Type: type3 Remote IP: 12.1.11.0 nodelist Current Configured Nodes ------------------------ Node # Node Type IP address ========================================= 1 type1 121.00.00.00 2 type2 121.00.00.01 3 type3 12.1.11.0 EOF Exiting peep... density:~/python> -------------------------- import cmd import sys import string print "Welcome to Peep! Type 'help' for help." class Peep_Input(cmd.Cmd): def __init__(self): self.prompt = " " self.node_domain_num={} node_num=0 def help_nodeset(self): print "Allows you to set the node name, number, and IP address for a node instance. Node number should be an integer of where the node falls in your process. You can review this with 'nodelist' (see 'help nodelist')" def do_nodeset(self,node_num): node_num1= raw_input("Enter the number of the new node: ") node_name = raw_input("Enter new node type: ") domain_name = raw_input("Enter the remote IP or name for this node: ") node_num=string.atoi(node_num1) self.node_domain_num[node_num]=(node_num,node_name,domain_name) print "Node number: ", node_num, " Node Type: ", node_name," Remote IP: ", domain_name def help_EOF(self): print "Quits the program." def do_EOF(self, line): print "Exiting peep..." sys.exit() def help_nodelist(self): print "Gives you the list of current nodes and IP addresses." def do_nodelist(self,line): print "Current Configured Nodes" print "------------------------" print "Node # Node Type IP address" node_nums = self.node_domain_num.keys() if node_nums == []: return node_nums.sort() print '='*41 for i in node_nums: print " ",self.node_domain_num[i][0]," ",self.node_domain_num[i][1]," ",self.node_domain_num[i][2] def do_jobscan(self,line): print "Status of Current Jobs" print "----------------------" if __name__ == '__main__': peep= Peep_Input() peep.cmdloop() ------------- Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From bizzaro at geoserve.net Thu Jun 1 22:35:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] Peep References: Message-ID: <39371D85.A3AC3973@geoserve.net> deanne@density.biop.umich.edu wrote: > > If you put in something that's not in the interpretation list > (do_) you just get a "Unknown syntax" error. If you hit return for a > blank line, it repeats the last command, though I'm sure I can override > that. I'd like it to work as much like the Unix shell/CLI as possible. So, hitting return on a blank line should give you another prompt. > nodeset > > Enter the number of the new node: 1 > Enter new node type: type1 > Enter the remote IP or name for this node: 121.00.00.00 > Node number: 1 Node Type: type1 Remote IP: 121.00.00.00 Interesting. I was thinking about a non-interactive, all-in-one command like... nodeset number=1 type=1 ip=121.0.0.0 But command-lines like this are hard to remember. How about we combine the two: If the user enters an incomplete command, Peep asks for the extra values? > nodeset > > Enter the number of the new node: 2 Okay, maybe this is just a test/example, but node numbering should be automatic...probably handled by the UI (not the DL). > Enter new node type: type2 > Enter the remote IP or name for this node: 121.00.00.01 These two are really for specifying a BRAND NEW node, and I'm not sure how much or if that will be needed. Piper should know what is on the local filesystem and any remote systems you're connected to. The user should be able to type a "list" command to see all basic nodes available and all pre-prepared networks. I think the only time the user will need to enter an IP is to link with a Piper on another, known system. > nodelist > > Current Configured Nodes > ------------------------ > Node # Node Type IP address > ========================================= > 1 type1 121.00.00.00 > 2 type2 121.00.00.01 > 3 type3 12.1.11.0 Yeah, this is what I was thinking about. It's something like the ls command, aint it? Again, about node numbering: Actual node ID's will be pretty long. Brad had a good idea to make the path the ID, something like... ID=unix/commands/ls I think we could make it more unique by using a full URI like... ID=piper://bioinformatics.org:1000/unix/commands/ls That's definitely unique (no duplicate nodes on the net). But then it would be kind of silly to have to type that out on the command-line. Imagine... connect locus=piper://bioinformatics.org:1000/unix/commands/ls:out1pipe locus=piper://bioinformatics.org:1000/viewers/text:in1pipe If the UI would simply assign a number (dynamically -- if a locus is removed, everything is renumbered) to each locus:pipe in the network, it'd be a lot easier on the user. So, if... piper://bioinformatics.org:1000/unix/commands/ls = 1 piper://bioinformatics.org:1000/unix/commands/ls = 2 and out1pipe = C in1pipe = A (attached to different loci, actually) the user can type... connect 1:C 2:A Simple. Peep may be small now, but I expect it to gain A LOT of functionality. Still, it's meant to be small and light-weight compared to Pied. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Fri Jun 2 05:06:21 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] Peep In-Reply-To: <39371D85.A3AC3973@geoserve.net> Message-ID: > I'd like it to work as much like the Unix shell/CLI as possible. So, hitting > return on a blank line should give you another prompt. I think I can do that just by redefining what "" does on input. > Interesting. I was thinking about a non-interactive, all-in-one command > like... > > nodeset number=1 type=1 ip=121.0.0.0 > > But command-lines like this are hard to remember. How about we combine the > two: If the user enters an incomplete command, Peep asks for the extra values? Pretty easy to do. I was thinking of that too...I'm an inpatient user, and I hate prompts...I love command line stuff. But I figured it would also order the process a bit more if that ability was there. I'll write that in. > > Okay, maybe this is just a test/example, but node numbering should be > automatic...probably handled by the UI (not the DL). *nods*...the UI probably should hand it off. The numbering part is easy enough. I'll just assign a list of loci. Editing a large stack of loci after they're built won't be too hard in python, looks like, since dictionary data types are mutable and searchable. Did I mention I really love python? :) > > > Enter new node type: type2 > > Enter the remote IP or name for this node: 121.00.00.01 > > These two are really for specifying a BRAND NEW node, and I'm not sure how > much or if that will be needed. Piper should know what is on the local > filesystem and any remote systems you're connected to. The user should be > able to type a "list" command to see all basic nodes available and all > pre-prepared networks. Yup. This was just a test case, to figure out how stuff works. I can have a command in peep to add to the network list, too, as part of the UI. As a user, I'd like to see that functionality in peep so I don't have to leave peep to define new loci. Is there a central datafile (I guess this is for Brad) with loci lists and local network lists? > I think the only time the user will need to enter an IP is to link with a > Piper on another, known system. *nods* THat could be a submenu entry, then. > > Yeah, this is what I was thinking about. It's something like the ls command, > aint it? Yup. Peep will probably be pulling this stuff from the ls subroutine. I was just playing with learning how to select out dictionary entries. :) > > If the UI would simply assign a number (dynamically -- if a locus is removed, > everything is renumbered) to each locus:pipe in the network, it'd be a lot > easier on the user. So, if... > > piper://bioinformatics.org:1000/unix/commands/ls = 1 > piper://bioinformatics.org:1000/unix/commands/ls = 2 > > and > > out1pipe = C > in1pipe = A (attached to different loci, actually) > > the user can type... > > connect 1:C 2:A > > Simple. Yup, but that sounds even longer than I personally would like as a user. How about a configuration file somewhere that has those definitions in it, maybe indexed by locus nickname, and the user can select from a list they get with "config list" or something, like... job1 target testing.file config list Nickname Process Type ---------------------------------------------------- bioinf_ls piper:// bioinformatics.org:1000/unix/commands/ls density_ls piper://density.biop.umich.edu:1000/unix/commands/ls bioinfo_ps piper://bioinformatics.org:1000/unix/commands/ps density_gcg piper://density.biop.umich.edu:1000/usr/local/gcg bioinf_psc piper://bioinformatics.org:1000/usr/local/psc density_rpl piper://density.biop.umich.edu:1000/usr/local/perl/r.pl job initiate testing testing.file Intializing job named "testing" with input data "testing.file" testing loci1 density_gcg -> bioinf_psc -align_center testing loci2 -> density_rpl testing loci3 -> density_ls (etc) loci map testing Job: Testing Locus:A Input Pipe: density.biop.umich.edu:1000/usr/local/gcg Output Pipe: bioinformatics.org:1000/unix/commands/psc -align center Locus:B (etc) From deanne at density.biop.umich.edu Fri Jun 2 09:46:00 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] Peep In-Reply-To: Message-ID: I re-read what I wrote last letter, that I'm an "inpatient user". I hope this doesn't reflect badly on peep. :) Deanne impatient, but not inpatient. Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From chapmanb at arches.uga.edu Fri Jun 2 11:16:47 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:01 2006 Subject: [Pipet Devel] bonobo Message-ID: <200006021519.LAA120634@archa10.cc.uga.edu> Hey all; People keep talking and talking about bonobo and python, and I know that Jeff mentioned it earlier as being important for having the Gnome GUI talk to different gnome programs. Is this still the case? If so, are there any programs specifically that you'd like to talk to through bonobo? The reason I ask is that I thought I would like to try and take a serious stab at seeing how exactly to do this, so I can figure out exactly how much would need to be done before bonobo stuff woudl actually work in python. ie. does it require gnorba? If so, does gnorba require ORBit? and so on... Plus, I'm also kind of interested in learning more about how bonobo works, since it seems like a really nice implementation to steal things from :-). Anyways, is there enought interest in this on the Gnome front to look into it more, or is it a waste of time? Just curious. Brad From bizzaro at geoserve.net Fri Jun 2 14:52:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] bonobo References: <200006021519.LAA120634@archa10.cc.uga.edu> Message-ID: <39380266.C675E6E9@geoserve.net> Brad Chapman wrote: > > People keep talking and talking about bonobo and python, and I > know that Jeff mentioned it earlier as being important for having the > Gnome GUI talk to different gnome programs. Is this still the case? If > so, are there any programs specifically that you'd like to talk to > through bonobo? Yeah, if many Gnome apps become bonobo-ized, then Pied can show them in a windowlet. I think that would be important. Also, I'm not sure if I would use bonobo, pygtk, or pyglade to make widgets appear in windowlets. Additionally, bonobo may allow Pied to make use of an SVG viewer, as I've been writing so much about. Yeah, there are lots of apps :-) > The reason I ask is that I thought I would like to try and take a > serious stab at seeing how exactly to do this, so I can figure out > exactly how much would need to be done before bonobo stuff woudl > actually work in python. ie. does it require gnorba? If so, does > gnorba require ORBit? and so on... Plus, I'm also kind of interested > in learning more about how bonobo works, since it seems like a really > nice implementation to steal things from :-). Post this to the pygtk list. You may also want to check the gnome-devel, orbit, and pyorbit lists to see if anyone is working on it already. > Anyways, is there enought interest in this on the Gnome front to > look into it more, or is it a waste of time? Just curious. It may be worth-while, if you're bored. And I'd appreciate it, but it's not critical, yet. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri Jun 2 15:03:26 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] bonobo -- off-list Message-ID: <200006021906.PAA159062@archa10.cc.uga.edu> Just moved this off the list because this is probably noise, and I don't want to get tied into anything to do with bonobo :-). > Yeah, if many Gnome apps become bonobo-ized, then Pied can show them in a > windowlet. I think that would be important. Also, I'm not sure if I would > use bonobo, pygtk, or pyglade to make widgets appear in windowlets. > Additionally, bonobo may allow Pied to make use of an SVG viewer, as I've > been > writing so much about. Yeah, there are lots of apps :-) Can you name one in particular you'd specifically like me to play with? I just need a direction to get going on that will be useful to you. > Post this to the pygtk list. > > You may also want to check the gnome-devel, orbit, and pyorbit lists to see > if > anyone is working on it already. I just want to look into it, not actually do it if it turns out to be a serious pain. So getting myself mixed up in it is a serious no-no! > It may be worth-while, if you're bored. And I'd appreciate it, but it's not > critical, yet. Well, I'm certainly not bored :-). Just curious about what it would entail. Maybe I'll take a look into it. I'll let you know where I get stuck, or if I have any luck. Thanks Jeff, I was just curious about this and didn't want to bother if you "never would think of using bonobo" or something. Brad From chapmanb at arches.uga.edu Fri Jun 2 15:14:09 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] bonobo -- off-list, just kidding! Message-ID: <200006021917.PAA11612@archa12.cc.uga.edu> I wrote: > Just moved this off the list because this is probably noise, and I > don't want to get tied into anything to do with bonobo :-). Ooops, just kidding. I can't use e-mail correctly and now am just adding on with an extra stupid message. Sorry :-<. Brad From bizzaro at geoserve.net Fri Jun 2 15:33:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] bonobo -- off-list, just kidding! References: <200006021917.PAA11612@archa12.cc.uga.edu> Message-ID: <39380C11.437E35AC@geoserve.net> Brad Chapman wrote: > > I wrote: > > Just moved this off the list because this is probably noise, and I > > don't want to get tied into anything to do with bonobo :-). > > Ooops, just kidding. I can't use e-mail correctly and now am just > adding on with an extra stupid message. Sorry :-<. Okay, but I will reply off the list ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 2 15:55:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] Peep References: Message-ID: <3938111C.B38BD44D@geoserve.net> deanne@density.biop.umich.edu wrote: > > I re-read what I wrote last letter, that I'm an "inpatient user". I hope > this doesn't reflect badly on peep. :) At least you're not apathetic, which would make you.......pathetic? ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Jun 5 20:40:53 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] New piper version + docs Message-ID: <200006060044.UAA113372@archa10.cc.uga.edu> Hello all; I'm happy to report that I just uploaded a brad new version of Piper (with an actual version number--0.0.1, pretty exciting!) to my university of Georgia site (http://www.arches.uga.edu/~chapmanb/). Sorry for the change of location, but either I can't remeber how to ftp to alpha.bioinformatics.org, or it isn't working right now (Gary? Is this my fault? Probably :-). This version is quite changed from the past ones since we are now using CORBA for communication between the user interface and the definition layer. Excitement abounds! This change-over has resulted in some loss of functionality from the socket version as a result. What works right now is addition, deletion, connection and disconnection of loci, basically. The container widget stuff hasn't been changed over yet (mainly because I'm not sure how to do it with the new system.) There are also a ton of other changes, including a switch to use the most recent 4DOM. This switch involves a lot of changes in namespaces, since 4DOM is going to become the default DOM for python, so it has now taken the xml.dom namespace over. So you'll need to have this version, and also need to be careful when installing it to blast away the PyXML version of xml.dom. Thanks to Jeff's keen eye, I also fixed some install bugs (and hopefully didn't add any more), and I added an extra target --with-piperhome=/a/different/path/to/put/piper, so that people can put the libraries in one place and the scripts to run it in another (and add version numbers). I also updated the dl documentation and added two new docs, "How to Plug a Program into Piper" and "How to write a UI for Piper." My idea is that we can use these as a starting point to get more docs and firm up our ideas about how to do things. In the user interface one, I tried to address some of the points Deanne and Jeff raised on the list in their disccusion on peep about how to talk to the dl. I would really like to hear feedback on these docs so we can make them better. These are just my attempts to do this from a marathon session of doc writing. The html versions of these docs are in the distribution, and pdf versions are at the university of georgia site. I'm very excited, as this is taken us much closer to getting piper integrated with Overflow--we've even got Overflow node types being loaded up (now we just need a little GUI to go with 'em). I'd be more than happy to answer any questions about what things I did and really look forward to hearing people's feedback. Okay, time to get some sleep... Brad From bizzaro at geoserve.net Mon Jun 5 21:01:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] New piper version + docs References: <200006060044.UAA113372@archa10.cc.uga.edu> Message-ID: <393C4D79.BE5F823@geoserve.net> Brad Chapman wrote: > > Sorry for the change of location, but either I can't remeber how to > ftp to alpha.bioinformatics.org, or it isn't working right now (Gary? > Is this my fault? Probably :-). (I'll get to the rest of your message in a bit.) As I mentioned in my last security alert, non-anonymous FTP is no longer available. I want all connections to go through SSH. You can upload it using SCP (secure copy) by typing... scp /path/to/piper-0.0.1 chapmanb@alpha.bioinformatics.org:/path/to/bradstuff Or you can use SFTP. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 6 03:57:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] Recognition versus Recollection Message-ID: <393CAEF1.5DDB8BF7@geoserve.net> I thought some might find this interesting, particularly the UIL developers: http://www.advogato.org/article/100.html I don't think they quite see how something like Loci or Overflow (now Piper) can combine the CLI with the GUI via our connect-the-dots paradigm. Jeff From chapmanb at arches.uga.edu Tue Jun 6 09:13:19 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] New piper version + docs Message-ID: <200006061317.JAA41048@archa11.cc.uga.edu> Hello all; Thanks to Jeff's pointer that I was stupid to be beating my head against the wall trying to use non-secure ftp to upload things to the server, I updated my bioinformatics.org site, so now you can get stuff from a nice server, instead of the frequently out of service University o' Georgia server. (man, that was a nice run-on sentence!). Anyways, now you can check everything out at: http://alpha.bioinformatics.org/bradstuff/ Enjoy! Brad From bizzaro at geoserve.net Fri Jun 9 02:56:20 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] plumbing Message-ID: <39409514.7E02D183@geoserve.net> "Plumbing is a new mechanism for inter-process communication in Plan 9, specifically the passing of messages between interactive programs as part of the user interface. Although plumbing shares some properties with familiar notions such as cut and paste, it offers a more general data exchange mechanism without imposing a particular user interface." http://plan9.bell-labs.com/sys/doc/plumb.html Jeff From jarl at casema.net Sat Jun 10 02:14:23 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> Message-ID: <3941DCBF.925DF824@casema.net> > Hi all, I'm back after a horrible week without coding, all I had to do with was sunshine, italian girls and -food :) > > Well, for C++, there's the STL (Standart Template Library) which is now part of > the new ANSI standard. Good to hear, is this STL also garateed to be portable like glib is? (one of the main reseason for glibs exsistance is portability). From jarl at casema.net Sat Jun 10 02:18:46 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3936BEB0.980D7682@geoserve.net> <3936C6E6.93FDDEF@hermes.usherb.ca> Message-ID: <3941DDC6.79B47F48@casema.net> > > > Maybe this sounds naive (I'm not very experienced with C/C++ nonetheless STL), > > but could Jarl use STL for the BL? > > Not unless the BL switches to C++. Correct. With wont be possible unless there will be hundereds of manhours spend in porting the code. Something I wont be doing.. > The STL (as the name implies) is heavily > based on templates, a C++ only feature. I think all the glib types have an > equivalent in the STL (lists, trees, ...). Yes, besides portability glib provides lists\trees\memory management and many other enhancements of the kinda old C library. From jean-marc.valin at hermes.usherb.ca Fri Jun 9 17:33:49 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> Message-ID: <394162BD.F410E65D@hermes.usherb.ca> > > Well, for C++, there's the STL (Standart Template Library) which is now part of > > the new ANSI standard. > > Good to hear, is this STL also garateed to be portable like glib is? (one of the main reseason > for glibs exsistance is portability). I'd say that the STL is *more* portable than glib. The STL is to C++ what libc is to C. The STL is part of the C++ standard. > Yes, besides portability glib provides lists\trees\memory management and many > other enhancements of the kinda old C library. The STL also provides lists, trees and memory management. Additionnaly, it's easy to have a "smart pointer" (using reference counting) class. Also, with templates, it's easy to declare things like a "list of maps from string to int" (list >). That being said, I'm not the one who decides whether or not to switch to C++ and the STL. However, I *think* the switch from glib to the STL would be that hard to do (assuming everybody knows C++). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Fri Jun 9 20:51:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3936BEB0.980D7682@geoserve.net> <3936C6E6.93FDDEF@hermes.usherb.ca> <3941DDC6.79B47F48@casema.net> Message-ID: <39419104.1DD02E96@geoserve.net> jarl van katwijk wrote: > > > Not unless the BL switches to C++. > > Correct. With wont be possible unless there will be hundereds of manhours spend in > porting the code. Something I wont be doing.. Brad can do it. (Just kidding!) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Sat Jun 10 05:59:37 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> Message-ID: <39421189.119B29BD@casema.net> > > The STL also provides lists, trees and memory management. Additionnaly, it's > easy to have a "smart pointer" (using reference counting) class. Also, with > templates, it's easy to declare things like a "list of maps from string to int" > (list >). Sounds nice this lib. Even nicer that it is part of the ansi std. In C world there's still a obscure piece of software needed :-) > > > That being said, I'm not the one who decides whether or not to switch to C++ and > the STL. However, I *think* the switch from glib to the STL would be that hard > to do (assuming everybody knows C++). "Would NOT be that hard if ..." ? One thing I'm not quite clear about: why is the issue 'switch to C++' a discussion? For the BL there's no problem, we'll just link both the BL and PL at binary level. (In human terms, I will compile the BL sources slightly different and the results can simply be combined to one executable). Actually calling C++ functions is somewhat limited, but besides this I see no reason enough to spend so much work in conversion. I tried to compile Overflow on OpenBSD, but got this during configuring. Jean Mark, maybe you could gimme a hint? ----- configure:1976: checking for c++ configure:2008: checking whether the C++ compiler (c++ ) works configure:2024: c++ -o conftest conftest.C 1>&5 In file included from configure:2019: confdefs.h:2: invalid macro name `1' configure: failed program was: #line 2019 "configure" #include "confdefs.h" int main(){return(0);} ----- From bizzaro at geoserve.net Fri Jun 9 21:51:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> Message-ID: <39419F0B.8C274465@geoserve.net> jarl van katwijk wrote: > > One thing I'm not quite clear about: why is the > issue 'switch to C++' a discussion? Because I got bored trying to convince Brad to rewrite the DL, and now I want to pick on you ;-) Seriously, one consideration is the reduction of dependencies (C/glib vs. C++/STL) and the sharing of libraries. And I guess that since you need to make many changes anyway, now might be the best time for a switch. But, it's your baby. I promise you, I won't pressure you anymore........today ;-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 9 23:17:14 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] New piper version + docs References: <200006060044.UAA113372@archa10.cc.uga.edu> Message-ID: <3941B33A.D1CA9B9A@geoserve.net> Brad Chapman wrote: > This version is quite changed from the > past ones since we are now using CORBA for communication between the > user interface and the definition layer. Excitement abounds! Woo-hoo! BTW, do you want the sockets API to be phased out? > This > change-over has resulted in some loss of functionality from the socket > version as a result. What works right now is addition, deletion, > connection and disconnection of loci, basically. The container widget > stuff hasn't been changed over yet (mainly because I'm not sure how to > do it with the new system.) There was quite a bit of confusion between you and me about how to implement this container. I eventually wanted to make container == workspace of unconnected loci, and we argued about that for a while. I still want container == workspace (network) of unconnected loci (nodes) for MOST types of containers. But, a database "container" is a special case, particularly since there are so many database "items" to consider (we can't make one node per database item when some databases are huge). So, perhaps databases should not be workspaces but instead treated like any other external program. > There are also a ton of other changes, including a switch to use > the most recent 4DOM. This switch involves a lot of changes in > namespaces, since 4DOM is going to become the default DOM for python, > so it has now taken the xml.dom namespace over. So you'll need to have > this version, and also need to be careful when installing it to blast > away the PyXML version of xml.dom. Do they still use "node" in the namespace? > Thanks to Jeff's keen eye, I also fixed some install bugs (and > hopefully didn't add any more), and I added an extra target > --with-piperhome=/a/different/path/to/put/piper, so that people can > put the libraries in one place and the scripts to run it in another > (and add version numbers). Grrrrrrrreat! > I also updated the dl documentation and added two new docs, "How > to Plug a Program into Piper" Super. But maybe this should be part of the BL or PL docs. > and "How to write a UI for Piper." And this should be part of the UIL docs. Jeez Brad, now you're doing our work for us ;-) > My > idea is that we can use these as a starting point to get more docs and > firm up our ideas about how to do things. In the user interface one, I > tried to address some of the points Deanne and Jeff raised on the list > in their disccusion on peep about how to talk to the dl. I would > really like to hear feedback on these docs so we can make them better. > These are just my attempts to do this from a marathon session of doc > writing. The html versions of these docs are in the distribution, and > pdf versions are at the university of georgia site. Cooooowel. I'll check it out. > I'm very excited, as this is taken us much closer to getting > piper integrated with Overflow--we've even got Overflow node types > being loaded up (now we just need a little GUI to go with 'em). *tries to sneak out of room without being noticed* Seriously, my (and our) goal is to make BL and PL network design and operation almost identical from the user's point of view. So, when do we want to put the Piper source on our sourceforge system? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jun 10 00:00:48 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. Message-ID: <200006100404.AAA130802@archa12.cc.uga.edu> Jarl wrote: > I tried to compile Overflow on OpenBSD, but got this during configuring. > Jean Mark, maybe you could > gimme a hint? [...snip...configure error...] Well, I can. I want to do my part to help with Overflow since Jean-Marc spent so much time helping me out getting it working on FreeBSD :-). The problem is that in the configure.in in the main directory, there is a part that looks like this: case "$host_os" in hpux*) OS=HPUX ;; dnl mv libtool libtool-bak dnl cat libtool-bak | perl -ne 's/\+h /\\\${wl}\+h/; s/ \+b / \\\${wl}\+b/; s/\"\/.*\/ld\"/\"$CXX\"/; print' > libtool;; linux*) OS=LINUX ;; freebsd*) OS=FREEBSD ;; esac AC_DEFINE_UNQUOTED(${OS}) dnl Initialize libtool. The problem is that it is trying to look for the OS, and not finding anything for OpenBSD, so then it generates an ugly looking file to test the C++ compiler, which ends up causing a compilation error, which makes configure think that the C++ compiler doesn't work. If you add: openbsd*) OS=OPENBSD ;; to this case statement, it should fix the problem (hopefully!). At least that's what worked for FreeBSD. All hail the great and mighty *BSD empire, Brad From bizzaro at geoserve.net Sat Jun 10 00:30:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:02 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <200006100404.AAA130802@archa12.cc.uga.edu> Message-ID: <3941C45D.F6E4CBD3@geoserve.net> Brad Chapman wrote: > > The problem is that it is trying to look for the OS, and not finding > anything for OpenBSD, so then it generates an ugly looking file to > test the C++ compiler, which ends up causing a compilation error, > which makes configure think that the C++ compiler doesn't work. If you > add: > > openbsd*) OS=OPENBSD ;; > > to this case statement, it should fix the problem (hopefully!). At > least that's what worked for FreeBSD. How come there aren't entries for these OSes? Is this a problem with autoconf? Anything we can fix? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Sat Jun 10 02:44:57 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> <39419F0B.8C274465@geoserve.net> Message-ID: <3941E3E9.2D2604F7@hermes.usherb.ca> > Seriously, one consideration is the reduction of dependencies (C/glib vs. > C++/STL) and the sharing of libraries. And I guess that since you need to > make many changes anyway, now might be the best time for a switch. > > But, it's your baby. I promise you, I won't pressure you anymore........today > ;-) I strongly suggest at least a 1st degree change to C++. By that I simply mean changing all the extensions from .c to .cc and using the C++ compiler. The advantage of this is: no problem linking with C++ stuff (which can be tricky from C). Now, whether or not to make the switch from glib to the STL is another question. However, I can say that once you've started using the STL, you never want to go back. It's so simple and intuitive to use. For example, you can use a "string" type as if it were an int, with all the operators and never caring about deleting pointers, ... Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Sat Jun 10 15:12:31 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> <39419F0B.8C274465@geoserve.net> <3941E3E9.2D2604F7@hermes.usherb.ca> Message-ID: <3942931F.B2B3B7F0@casema.net> > > But, it's your baby. I promise you, I won't pressure you anymore........today > > ;-) > wargl :-) > > I strongly suggest at least a 1st degree change to C++. By that I simply mean Yes, that is what I'm about to do. > question. However, I can say that once you've started using the STL, you never > want to go back. It's so simple and intuitive to use. For example, you can use a > "string" type as if it were an int, with all the operators and never caring > about deleting pointers, ... Hehe, this is the feeling I have with glib :) From bizzaro at geoserve.net Sat Jun 10 06:23:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> <39419F0B.8C274465@geoserve.net> <3941E3E9.2D2604F7@hermes.usherb.ca> <3942931F.B2B3B7F0@casema.net> Message-ID: <3942171C.457CA906@geoserve.net> jarl van katwijk wrote: > > > I strongly suggest at least a 1st degree change to C++. By that I simply mean > > Yes, that is what I'm about to do. I'm happy to hear that :-) I bet Brad is too. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jun 10 07:12:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs Message-ID: <200006101116.HAA41340@archa12.cc.uga.edu> Jeff wrote: > BTW, do you want the sockets API to be phased out? Well...I already blasted it away, so I guess so :-). Seriously, I don't want to have to maintain two APIs and I think the CORBA one is much more straightforward, so this is the new API for talking to the dl from a user interface. I'm quite sensitive to the concerns that Gary had about a CORBA interface being harder to learn, which is one of the reasons I started writing the docs. I also don't really think the XML API has that much less of a learning curve, because there you need to understand how to generate and parse XML, so you still have a learning curve, just a different one. I hope this is okay with people. > There was quite a bit of confusion between you and me about how to implement > this container. I eventually wanted to make container == workspace of > unconnected loci, and we argued about that for a while. This is all your baby since it deals with GUI stuff. My only point, which you echo below, is that it is kind of a pain to use the "workspace" view to represent things like filesystems and databases, which can have a lot of loci. > I still want container == workspace (network) of unconnected loci (nodes) for > MOST types of containers. But, a database "container" is a special case, > particularly since there are so many database "items" to consider (we can't > make one node per database item when some databases are huge). So, perhaps > databases should not be workspaces but instead treated like any other > external > program. My plan was to make filesystems and databases separate locus types, so I think we are on the save wavelength here. [...stuff about DOM...] > Do they still use "node" in the namespace? "Node" is part of the spec and is never doing away. This is just a packaging change so that the 4DOM stuff can now be integrated into the XML-SIG package, so now we will have one less dependency! Yay, I'm doing my part to reduce dependencies :-). >> I also updated the dl documentation and added two new docs, "How >> to Plug a Program into Piper" > > Super. But maybe this should be part of the BL or PL docs. > >> and "How to write a UI for Piper." > > And this should be part of the UIL docs. Well, I think of all the docs as "Piper" docs, and I'm definately not trying to take over anyone elses doc writing responsibilities. What I'm trying to do is have actual written things about how things work (instead of just mailing list archives) so that we can all get on the same page and also have something to show people if they get interested in Piper. Since I just changed the user interface to dl commmunication to use CORBA, no one else presumedly knows what I am doing here (unless they can read my mind :-), so I wanted to try and explain that. The "how to write a user interface doc" is more designed to explain the thoughts behind the uil to definition layer communication, so that you and Deanne can use it. I was hoping this might clear up some of the questions you guys had about how to talk to the dl (when you were mailing back and forth about Peep). > Seriously, my (and our) goal is to make BL and PL network design and > operation > almost identical from the user's point of view. Well, we want to have everyone using the same GUI as soon as possible, so that we can hack on the same source. Jean-Marc's point in keeping his GUI was that he needs to use Overflow for his master's work, so it doesn't make any sense to switch to using Piper, which doesn't even work yet. So the sooner we can get Overflow functionality into Piper so that Jean-Marc can do everything he wants to, the sooner we can start working off the same source. Then we will only have one (set) of GUIs to maintain, so hopefully this can make us all a lot more productive, and also free most of us from having to do GUI coding :-) > So, when do we want to put the Piper source on our sourceforge system? As soon as it is ready! Seriously, I'm very ready to get it into cvs so that I don't have to make tarballs and everything anymore and so that we can all coordinate things and more people can hack on this. If Deanne could send me her most current Peep stuff, I can also put this in there and then import it all of it into CVS, if it is set up. Thanks for getting back with me on all this, Jeff. Brad From bizzaro at geoserve.net Sat Jun 10 08:03:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs References: <200006101116.HAA41340@archa12.cc.uga.edu> Message-ID: <39422EA1.CFAE2076@geoserve.net> Brad Chapman wrote: > > As soon as it is ready! Seriously, I'm very ready to get it into cvs > so that I don't have to make tarballs and everything anymore and so > that we can all coordinate things and more people can hack on this. > If Deanne could send me her most current Peep stuff, I can also > put this in there and then import it all of it into CVS, if it is set > up. Okay, I added the following users to the Piper project on alpha.bioinformatics.org (soon to be www): Brad (chapmanb) Jarl (jarl) Deanne (theoriste) I haven't added Gary, because I don't know which of his many login names to use. Hello, Gary?! I haven't added Jean-Marc either, because he hasn't made an account yet. Tsk, tsk. Jean-Marc, just browse over to alpha.bioinformatics.org and click on "Join The Open Lab". It's just like SourceForge. Anyone else want to join? Brad, do you have a newer tarball for me to put in CVS? Or should I put 0.0.1 in? You should let me do the import, since I am the project administrator. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jun 10 08:46:33 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs Message-ID: <200006101250.IAA95650@archa10.cc.uga.edu> Jeff wrote: > Brad, do you have a newer tarball for me to put in CVS? Or should I put > 0.0.1 > in? You should let me do the import, since I am the project administrator. Well, I'd like to get Peep integrated so that this will be ready in cvs as well, and then I can send you a new tarball to import. One question along these lines is: how should we work with the multiple user interfaces? Should you start piper with a command like 'piper pied' or 'piper peep' and then it will start the appropriate user interface? Or you you want to have separate --pied=on, --peep=off type command line options like we have right now? Also, maybe we should have an option in the configuration file for the default user interface if no option is passed on the command line, so that 99% of the time you can just start up piper with 'piper' and get what you want. A big thing we want to be careful of, especially when importing the original project, is to avoid getting autoconf cruft in CVS. The only things from autoconf/make that we should need in CVS are the configure.in and Makefile.am files, plus a few extra shell scripts. I'll try to send you a clean tarball that is ready for import directly, but I just wanted to mention this in general since autoconf generates a lot of junk that we don't want in cvs. Also, do you (or anyone else) have any changes you need me to merge by hand prior to importing? Sounds cool, tho, I'll be happy to have it back in cvs :-). Brad From deanne at density.biop.umich.edu Sat Jun 10 09:00:23 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs In-Reply-To: <200006101116.HAA41340@archa12.cc.uga.edu> Message-ID: Brad escrit: > As soon as it is ready! Seriously, I'm very ready to get it into cvs > so that I don't have to make tarballs and everything anymore and so > that we can all coordinate things and more people can hack on this. > If Deanne could send me her most current Peep stuff, I can also > put this in there and then import it all of it into CVS, if it is set > up. > Thanks for getting back with me on all this, Jeff. Can we wait to put Peep into the CVS for a little while? I still have some things I want to do to it, vis-a-vis the last list conversation we had about Peep. D From bizzaro at geoserve.net Sat Jun 10 09:08:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs References: <200006101250.IAA95650@archa10.cc.uga.edu> Message-ID: <39423DE6.FAF88F58@geoserve.net> Brad Chapman wrote: > > Well, I'd like to get Peep integrated so that this will be ready in > cvs as well, and then I can send you a new tarball to import. One > question along these lines is: how should we work with the multiple > user interfaces? Should you start piper with a command like 'piper > pied' or 'piper peep' and then it will start the appropriate user > interface? Or you you want to have separate --pied=on, --peep=off type > command line options like we have right now? That's a good question. But, actually, I recall you suggested having the UI start the DL (or front start the middle, since we were working on Loci back then). Should we have "pied" and "peep" executables that, when started, let you connect to (and/or start) a DL session? This means that the DL is not started directly by the user. > Also, maybe we should > have an option in the configuration file for the default user > interface if no option is passed on the command line, so that 99% of > the time you can just start up piper with 'piper' and get what you > want. I guess this idea doesn't mesh with the one I mention above. We could have it either way. I think the approach above would be simpler for the user, especially when multiple sessions can be started. > A big thing we want to be careful of, especially when importing > the original project, is to avoid getting autoconf cruft in CVS. The > only things from autoconf/make that we should need in CVS are the > configure.in and Makefile.am files, plus a few extra shell scripts. > I'll try to send you a clean tarball that is ready for import > directly, but I just wanted to mention this in general since autoconf > generates a lot of junk that we don't want in cvs. Yeah, and all those pesty .pyc files. > Also, do you (or anyone else) have any changes you need me to > merge by hand prior to importing? Not I. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat Jun 10 09:21:44 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs References: Message-ID: <394240E8.3B0EB1BF@geoserve.net> deanne@density.biop.umich.edu wrote: > > Can we wait to put Peep into the CVS for a little while? I still have some > things I want to do to it, vis-a-vis the last list conversation we had > about Peep. I also want to give everyone a "heads up" on a plan of mine for Pied. I didn't want to mention it before since Peep didn't exist and things were too chaotic. Well, things aren't much better now, but maybe we could implement it sooner (before the CVS import) rather than later (0.0.2 or 0.0.3). "Get on with it", you say. Okay, in the spirit of making the main distribution simpler and requiring less dependencies, I think Pied should be distributed separately: separate CVS module and tarball. You may have thought that my argument to remove Gnome dependencies from the core was flawed if we were to keep Pied (a Gnome application) in with the core. Thus, you may have seen this coming. The question is how to implement it...and when. Of course, Brad is designing the install scheme to handle additional UI's. I don't know if it is ready yet, but Pied would be one of those additional UI's. Peep is the default. And not to put pressure on Deanne, but this can't be done until Peep is as functional as Pied is now. Comments? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jun 10 09:57:58 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs Message-ID: <200006101401.KAA80768@archa12.cc.uga.edu> Jeff wrote: > "Get on with it", you say. Okay, in the spirit of making the main > distribution simpler and requiring less dependencies, I think Pied should be > distributed separately: separate CVS module and tarball. Well, this is easy enough to do. Pied (and Peep and the DL) already have a separate configure.in, so you can configure, make and install only Pied if you so desire. This means it can be a separate CVS module and tarball. There are also top level configure options like --with-pied/--without-pied, so you can optionally install it or not. I agree that it is a good goal to remove dependencies and have a simple Piper core that you can install and will be functional with "minimal libraries." However, I don't think we are ready to start fragmenting up Piper just yet. Right now, User interface coding is probably the most important thing that we need to test and work with the underlying code, and Deanne is just getting started on Peep and probably still learning to grok all of the crazy terminology we use, so I wouldn't count on Peep being ready too soon. In addition, the gnome ui will be very important to Jean-Marc and Jarl, since they had this previously and want to see this kind of functionality in Piper as soon as possible. So what I'm trying to say is that the gnome ui should remain our default UI for a while, so that we can have something to work with. It will be really easy to get it out of the "default" Piper cvs directory later--we just need to drop the pied directory out of Piper. I agree that reducing dependencies is important, but right now what I care about most is having a working implementation. Towards that goal, I propose that we stick with what we've got and look at having pied be separated out later when other UIs are more ready. Plus, this takes pressure for ui design off of Deanne and puts it back on the project coordinator, where it belongs :-). Brad From deanne at density.biop.umich.edu Sat Jun 10 10:04:54 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs In-Reply-To: <394240E8.3B0EB1BF@geoserve.net> Message-ID: > And not to put pressure on Deanne, but this can't be done until Peep is as > functional as Pied is now. Heh. Okay. Tell you what, let me work on this over the weekend. I probably can devote several hours to trying to get peep up and running, if Jeff and/or Brad will be around for me to bounce ideas/questions off generally, this weekend? I might be able to get it to a nice state before Sunday night. It depends on how organized I can be this weekend. D From chapmanb at arches.uga.edu Sat Jun 10 10:02:41 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs Message-ID: <200006101406.KAA106296@archa10.cc.uga.edu> > That's a good question. But, actually, I recall you suggested having the UI > start the DL (or front start the middle, since we were working on Loci back > then). Should we have "pied" and "peep" executables that, when started, let > you connect to (and/or start) a DL session? This means that the DL is not > started directly by the user. Yeah, this is how it works right now. When you type 'piper' it tries to start up the dl (and only does this if the dl is not started) and then starts up the user interface. You would have to pass a command line option not to turn on the dl for it to not try to start up. >> Also, maybe we should >> have an option in the configuration file for the default user >> interface if no option is passed on the command line, so that 99% of >> the time you can just start up piper with 'piper' and get what you >> want. > > I guess this idea doesn't mesh with the one I mention above. We could have > it > either way. I think the approach above would be simpler for the user, > especially when multiple sessions can be started. I'm not sure that I understand how my approach and yours don't mesh. If we added the "default user interface" thing to the configuration file, then you could just type 'piper' to start up the ui of your choice and the dl would get started transparently (which makes sense to me, since most users won't care about starting the dl by hand). Then if you type 'piper' again, you'll get another user interface (of your default choice). And so on... Is this what you were thinking of? Brad From deanne at density.biop.umich.edu Sat Jun 10 10:09:48 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs In-Reply-To: <200006101401.KAA80768@archa12.cc.uga.edu> Message-ID: > Plus, this takes pressure for ui design off of Deanne and puts it back > on the project coordinator, where it belongs :-). Well, I really wanted to do more work on Peep before this, but I had another job interview this Thursday. Heh. Imagine this: Me: "So, do you want me to do a presentation to your group on my work?" Them: "Do you have something ready?" Me: "Yes, but...well, it's on my dissertation work, which has little to do with what you're group is doing, so..." Them: "Do you have any software projects you've worked on, in a presentation?" Me: "Well, I have this GeneGnome project I'm still planning, but it's still vaporware. I suppose I could present that." Them: "Oh, very cool. Okay, see you in a few days." Me: . o O (How am I going to get an hour's worth of talk out of GeneGnome?" -- Good news is, I *did* present Piper to a group of 50 bioinformaticists, as part of the GeneGnome talk. Your names were emblazoned in 2-foot-high letters across the top of the project slide. :) Deanne From jarl at casema.net Sat Jun 10 20:14:47 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> <39419F0B.8C274465@geoserve.net> <3941E3E9.2D2604F7@hermes.usherb.ca> <3942931F.B2B3B7F0@casema.net> <3942171C.457CA906@geoserve.net> Message-ID: <3942D9F7.D4461368@casema.net> > > > > > > I strongly suggest at least a 1st degree change to C++. By that I simply mean > > > > Yes, that is what I'm about to do. > > I'm happy to hear that :-) I bet Brad is too. It's really not a big deal, only a few changes in the compiling command. From jean-marc.valin at hermes.usherb.ca Sat Jun 10 13:44:13 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> <39419F0B.8C274465@geoserve.net> <3941E3E9.2D2604F7@hermes.usherb.ca> <3942931F.B2B3B7F0@casema.net> Message-ID: <39427E6D.29196494@hermes.usherb.ca> > > question. However, I can say that once you've started using the STL, you never > > want to go back. It's so simple and intuitive to use. For example, you can use a > > "string" type as if it were an int, with all the operators and never caring > > about deleting pointers, ... > > Hehe, this is the feeling I have with glib :) Here are a couple things you can do with the STL: int main() { map months; months["january"] = 31; months["february"] = 28; ///and so on cout << "january has " << january["january"] << " days" << endl; } Note that this program doesn't leak. Also, unlike glib, the STL can have vectors and lists of objects (like vector) and not only lists of object pointers. Also, because of destructors objects automatically delete their resources when they go out of scope. I think that all (almost) everything in glib has a STL equivalent that's also likely to be simpler to use. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jean-marc.valin at hermes.usherb.ca Sat Jun 10 14:40:46 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] GConf, Loci, pickles, etc. References: <3934719F.4EFBCF7D@geoserve.net> <39349198.D260A6EB@hermes.usherb.ca> <393550DE.6C7DC044@casema.net> <39356ACF.90ED2288@geoserve.net> <39369301.A1ABB72A@casema.net> <39369684.43399ABD@geoserve.net> <3936B09F.ED0E5888@hermes.usherb.ca> <3941DCBF.925DF824@casema.net> <394162BD.F410E65D@hermes.usherb.ca> <39421189.119B29BD@casema.net> <39419F0B.8C274465@geoserve.net> <3941E3E9.2D2604F7@hermes.usherb.ca> <3942931F.B2B3B7F0@casema.net> <39427E6D.29196494@hermes.usherb.ca> Message-ID: <39428BAE.1E8BECB0@hermes.usherb.ca> > cout << "january has " << january["january"] << " days" << endl; sorry, this should read: cout << "january has " << months["january"] << " days" << endl; -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Sun Jun 11 00:02:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:03 2006 Subject: [Pipet Devel] New piper version + docs References: <200006101401.KAA80768@archa12.cc.uga.edu> Message-ID: <39430F66.6E1F0766@geoserve.net> Brad Chapman wrote: > > Well, this is easy enough to do. Pied (and Peep and the DL) already > have a separate configure.in, so you can configure, make and install > only Pied if you so desire. This means it can be a separate CVS module > and tarball. There are also top level configure options like > --with-pied/--without-pied, so you can optionally install it or not. Is there a general option like... --with-ui=pied > I agree that reducing dependencies is important, but right now > what I care about most is having a working implementation. Towards > that goal, I propose that we stick with what we've got and look at > having pied be separated out later when other UIs are more ready. > Plus, this takes pressure for ui design off of Deanne and puts it back > on the project coordinator, where it belongs :-). Darn! I was hoping Deanne would do my work for me ;-) Okay, I just wanted to know if this should be done sooner or later. I guess it's later. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 00:19:52 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] New piper version + docs References: <200006101406.KAA106296@archa10.cc.uga.edu> Message-ID: <39431368.39C9AF01@geoserve.net> Brad Chapman wrote: > > > We could have it either way. I think the approach above would > > be simpler for the user, especially when multiple sessions can > > be started. > > I'm not sure that I understand how my approach and yours don't mesh. > If we added the "default user interface" thing to the configuration > file, then you could just type 'piper' to start up the ui of your > choice and the dl would get started transparently (which makes sense > to me, since most users won't care about starting the dl by hand). > Then if you type 'piper' again, you'll get another user interface (of > your default choice). And so on... > Is this what you were thinking of? For some reason, I was thinking "piper" started the DL directly. Yeah, I suppose if "piper" is just a UI launcher, then we can have it work as you suggest: "piper" starts the default UI, unless "piper --ui=" is ran. The UI then starts the DL and creates a new session, or joins an existing session if the DL is already running. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 00:21:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] New piper version + docs References: Message-ID: <394313E2.DD51224F@geoserve.net> deanne@density.biop.umich.edu wrote: > > Heh. Okay. Tell you what, let me work on this over the weekend. I probably > can devote several hours to trying to get peep up and running, if Jeff > and/or Brad will be around for me to bounce ideas/questions off generally, > this weekend? I'll be here. Like I have anything to do on the weekends :-P Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 00:22:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] New piper version + docs References: Message-ID: <39431420.82412A96@geoserve.net> deanne@density.biop.umich.edu wrote: > > Good news is, I *did* present Piper to a group of 50 bioinformaticists, as > part of the GeneGnome talk. Your names were emblazoned in 2-foot-high > letters across the top of the project slide. :) Now I am famous. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 00:52:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] dLoo BlueBox Message-ID: <39431B12.ABF4F72E@geoserve.net> This sounds a bit like how I planned to implement UI's in Piper: ---------------------------------------------- Basically, we've extended the GNOME communities ideas in libglade. Libglade, as you know, reads in an XML file for an application describing its interface and uses it to display the application. A major innovation since this allows users to customize programs without recompiling. What we've done is two things: 1) moved the signal handling from the program to BlueBox (our version of libglade). This means that the program doesn't need to have any GNOME or GTK dependencies. It also means that the program and the interface are completely separated. 2) Handle communications between the program and the interface with network calls, right now SOAP, but it could just as easily be CORBA or XML-RPC. So, what's this mean. It means that BlueBox loads an XML file just like libglade does and displays the buttons, toolbars, etc. using the native toolkit of whatever environment it is in, i.e., GTK, QT, Win32, etc. This is possible because there are no signal handling dependencies. Then, when a user interacts with the interface, BlueBox sends network calls to the program to the effect that "Hey, this button has been pressed," etc. The program then signals back-again in SOAP (but it could be CORBA)-"Well, then change this." All of this is very similar to how web pages work: A platform independent interface (HTML) and an intemediary talking to the server. It requires extremely low network traffic and allows GNOME to serve programs over an intranet or the Internet. This in turn means that GNOME can be the platform of choice for both centralized software management and ASP. ---------------------------------------------- >From a Gnotices announcement http://news.gnome.org/gnome-news/960578167/index_html about dLoo BlueBox http://www.dloo.com/ Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 01:01:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] dLoo BlueBox References: <39431B12.ABF4F72E@geoserve.net> Message-ID: <39431D1C.1144D819@geoserve.net> You guys might want to check out the web site: http://www.dloo.com/ It is strikingly similar to many aspects of Piper, except for the piping part :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 01:45:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] dLoo BlueBox References: <39431B12.ABF4F72E@geoserve.net> <39431D1C.1144D819@geoserve.net> Message-ID: <39432773.A2A89A3B@geoserve.net> "J.W. Bizzaro" wrote: > > You guys might want to check out the web site: > > http://www.dloo.com/ > > It is strikingly similar to many aspects of Piper, except for the piping part > :-) Please read this: http://www.dloo.com/bluebox_developer/dev_model.html If that doesn't ring a bell, then you haven't read my long-winded explanations of how Loci was supposed to serve up a UI. If you understand what they're saying but never understood me, now you do :-) IOW, it's the same idea. I sent a message to the person who posted the announcement to Gnotices. They're stuff is supposedly GPL, LGPL or Apache (it's also vaporware at the moment, so don't bother trying to download it). My thoughts are that we can use BlueBox's XML API's, widgets sets, and even tools and save ourselves a TON of work on the UI side. Comments? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun Jun 11 19:09:22 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper Message-ID: Hey all, Jean-Marc and I were chatting up a few design things on IRC. Here's the log if anyone is interested :-) jm: I've looked at your node definition and I think we agree on most things. I just don't think the "id" property would be necessary. brad: Well, actually I use the id propery quite a bit, so I know what input and outputs are connected together... jm: I prefer naming the inputs and outputs instead of having ids jm: mostly when you have variable number of inputs/outputs jm: Also, what's the path in: brad: naming <- That's fine. So if a user creates a new input or output, they need to create a unique name for it? jm: exactly... for instance in the AND node, there's no defined input. You can add "ThisCondition" and "ThatCondition", ... when you use it brad: <- That's the reference to the DTD. I'm using a validating parser to check the xml so now we can have a DTD and do things the proper way :-). This also helps me pick up bugs when I make dom mistakes... brad: names <- Okay, that sounds good to me. I'll drop the id stuff and start using the name as the id. I'll look into how to fix this up... jm: Well, I don't really like to hardcode paths (even relative ones). brad: path <- Well, that is actually just a placeholder for the real path. When I copy a file into "use." I adjust this to point to the actual place that DTDs were installed. So it is not "really" hardcoded, it is just in place until I can put it to the right thing :-) jm: Can't the parser look for that file? That way, there's no need for it in the definition. brad: parser <- No, we need to tell the parser where to find it. The best solution will actually be to put the dtd on the web and then hardcode the definition to point to it. jm: Then you can't use piper without an Internet connection? brad: Oh right, that's a problem :-< brad: Okay, I guess I'll have to stick with the local stuff... jm: I'd like to be able to move those files around like in matlab where you can put the .m files anywhere and they'll still work. jm: Isn't there any way to tell the parser to take that .dtd file for this document? brad: Move around <- I don't _think_ this will be too much of a problem. When piper loads up a file, it could then convert the dtd ref to point to the right place (since it will know it)... I need to think about this, you are right. brad: parser <- Maybe! Good idea :-). I look into the code and see if I can find anything... That would make it more flexible. jm: Otherwise, it's like a word document that needs to be in a specific directory to load. jm: BTW, what's going to be the "official" name for Node or locus? brad: Right, I agree. Since I haven't touched "creating new .n" (or .cls, what do you want?) I hadn't thought about it yet... brad: official name <- Do you hate "locus"? I mentioned why node is a problem for me... jm: I like the .n extension (fits for both 'node' and 'network'). However, I don't really like Locus and you don't like Node... any other idea? brad: Okay, we can use '.n', I'll drop '.cls' from now on... brad: ideas <- Not sure. That is why I've just been sticking with locus. My creativity level is not that high :-) jm: There's two things here: the "internal" names and the way we'll call it in the user manual. brad: Agreed, but I'd like to keep those the same, so people can look at the code (and help hack on it :-), without it being too confusing... jm: My problem is that "Locus" won't tell much to most people. As for Node, well, you know the implications better than I do. jm: Also, Overflow defines the Node (base) class and I'm not sure I want to change that. jm: Is that a problem? brad: The problem is that we are kind of just referring to everything as a "thing." To me, that is what node means :-). Maybe we should just refer to everything as "thing." I don't know, what are some synonyms for node? What does it mean to you? brad: Overflow code <- No, I don't think it is worth messing around with old code for a dumb reason like a name change. I would never force that on anyone. It would just be nice to be able to be consistent from now on... jm: I don't know, after all, English is not my first language ;-) brad: Maybe there is a good French word? :-) jm: What about "Patente a gosse" brad: There you go! jm: The problem is that you need to be from Quebec to understand. brad: Actually, I wouldn't even care if we had a French word whose meaning I didn't know, as long as it was consistent... jm: The reason I like Node is that I like to think of the program as a network that's made of nodes. Is the problem with Node only in the XML? brad: Yeah, that's it. It is just really confusing to be referring to DOM nodes and Piper nodes at the same time. It even makes it hard to look at for me, and I'm the one coding it. Maintance will probably be a nightmare... jm: Maybe Atom? brad: Sure, atom would be fine! jm: or processor? brad: Atom is shorter :-) jm: or even "function" since that's what it is. brad: Well, that is kind of confusing too. Especially for nodes representing programs... jm: I like to keep the matlab analogy, since after all is a similar language, with an added visual part. brad: So matlab uses node? (I've never used it, so I'm not positive what analogies you are drawing...) jm: No, matlab uses "functions". Also, if we are to replace "Node" with something else in the UI* classes, I would help a lot to have the classes still understand the "old XML", otherwise, the switch would be a pain for me. brad: It's up to you. Mostly "node" is the most confusing in my opinion (although it is the best :-<. We can just make an arbitrary decision now, or we can throw it out to the list or whatever you want... brad: old XML <- We should do this. Once we get the "new XML" style firm, I'll look at a way to load up old XML, or convert it to "new XML." I kind of wanted to play with XSLT transforms anyways... jm: I suggest a vote. We could use the new name in the code, but keep the "Node" tags in the .n files until piper is ready. jm: BTW, I had a couple coments about the screenshot. First, we'll need to name the inputs/outputs when there is more than one (as in vflow). brad: vote <- Sounds fine. I can send an e-mail, if you tell me the candidates you want :-). jm: Also, maybe we can add an "icon" tag for some nodes. For instance, add could be represented as a "+" sign. brad: screenshot <- Yeah, I just wrote to Jeff about the exact same thing. The way it will work is that each little dot will have a little windowlet associated with it that can be opened up to display this information... jm: I see "Node", "Locus", "Atom", "Processor". Maybe we should just raise hands ;-) brad: :-) jm: I much rather see the input/output names without opening a dialog. Otherise, there's no way you could connect, say NetExec, without opening this dialog. jm: Or it could be in the preferences. brad: dialog <- Well, it is not so much a dialog window as a little window that moves along with dot. This should work in the same way as the windows for each "node." Have you run Piper/Loci yet and seen what it looks like? Of course, this is all Jeff's design plans, so this is definately stuff you and he should hash out if you want to change it... jm: Take a look at the new .n for constant I sent you (I didn't bother to change Node yet). jm: I haven't been able to start piper (and not much time to investigate yet). What I'm saying is that I prefer the vflow way: inputs are named and you popup a window for dialogs. I think it's simpler if you have many nodes in a network. I have some programs that have 20-30. jm: Well, it's dinner time for me. We can continue later if you like. brad: new .n <- That looks good. I'll send comments on it by e-mail if it's time to eat :-) jm: ttyl. brad: ttyl! Have a nice dinner :-) From chapmanb at arches.uga.edu Sun Jun 11 19:17:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name Message-ID: <200006112321.TAA21884@archa12.cc.uga.edu> Hello all; One thing we've been having problems with is coming up with a name to define the main "thing" in Piper. In loci we had been using "locus", and in Overflow Jean-Marc and Dominic had been using "node." But, I don't like "node" because I think it is confusing when dealing with DOM (to manipulate XML) which also uses node, and Jean-Marc doesn't like locus because he doesn't think it is clear about what it refers to. So, we were brainstorming for some names, and Jean-Marc came up with the following, which we'd like to get a vote out on. I would encourage everyone to vote, especially if you aren't involved in coding and just like to lurk, as this is more about making things clear both to users and coders then about a specific design issue. So here are the candidates, please vote for just one: 1. Node 2. Locus (plural -> Loci) 3. Atom 4. Processor 5. Your own write in candidate -> ____________ Just remember, your voice isn't heard unless you excercise your open-source given right to vote. Oh, and one vote per person please -- No stuffing the ballot box :-). Brad From jarl at casema.net Mon Jun 12 04:34:33 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Re: Vote for Thing Name References: <200006112321.TAA21884@archa12.cc.uga.edu> Message-ID: <3944A099.9EB89B3B@casema.net> > Top 3 names > 1. Node > 2. Your own write in candidate -> Agent 3. Atom From jean-marc.valin at hermes.usherb.ca Sun Jun 11 19:44:38 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name References: <200006112321.TAA21884@archa12.cc.uga.edu> Message-ID: <39442466.4391B52C@hermes.usherb.ca> 1. Node 2. Function 3. Atom -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Sun Jun 11 20:26:35 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name Message-ID: <200006120030.UAA31614@archa12.cc.uga.edu> Ooops, forgot to vote :-) 1. Atom 2. Locus 3. Write in candidate -> Agent (from Jarl) Brad From deanne at density.biop.umich.edu Sun Jun 11 20:46:10 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name In-Reply-To: <200006112321.TAA21884@archa12.cc.uga.edu> Message-ID: The one advantage to "loci" is that bioinformatics people will understand what that means. :) > 5. Your own write in candidate -> ___nodule_______ However, this sounds too much like "module". I looked around for a kind of synonym to this in dictionaries and thesauruses and no luck. D From deanne at density.biop.umich.edu Sun Jun 11 20:50:31 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Locus (meaning, etc). In-Reply-To: <200006112321.TAA21884@archa12.cc.uga.edu> Message-ID: BTW, "Locus" is not strictly a biological word, and only recently "became" a word to mean a location of a chromosome. It's a Latin word, which means "locality". This is the actual meaning of locus, from Webster's... LOCUS 1.A locality; a place. 2.A center or focus of great activity or intense concentration: the cunning exploitation of loci of power; the insulation from normal American society (Clifton Fadiman). 3.Mathematics. The set or configuration of all points whose coordinates satisfy a single equation or one or more algebraic conditions. 4.The position that a given gene occupies on a chromosome. From bizzaro at geoserve.net Sun Jun 11 21:29:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name References: <200006112321.TAA21884@archa12.cc.uga.edu> Message-ID: <39443CF8.9B88BF76@geoserve.net> Brad Chapman wrote: > > 1. Node > > 2. Locus (plural -> Loci) > > 3. Atom > > 4. Processor > > 5. Your own write in candidate -> ____________ I'm going to suggest some more, since I'm special :-P 6. Locale 7. Sink 8. Tank 9. BLnode and PLnode 10. Object 11. Thing or Thingy :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 11 21:33:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name References: Message-ID: <39443DFD.9D1D8744@geoserve.net> deanne@density.biop.umich.edu wrote: > > > 5. Your own write in candidate -> ___nodule_______ Good suggestion, but it reminds me of some disease symptom, like cyst or pustule ;-) > However, this sounds too much like "module". I looked around for a kind of > synonym to this in dictionaries and thesauruses and no luck. Module is a good candidate too. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Sun Jun 11 22:03:48 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] Vote for Thing Name References: <200006112321.TAA21884@archa12.cc.uga.edu> <39443CF8.9B88BF76@geoserve.net> Message-ID: <39444504.BAD3DFDA@hermes.usherb.ca> I think BLNode and PLNode are a good idea. I like the fact that it has node in it, wet it won't cause problems with CORBA/DOM/... Anybody else agrees? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Sun Jun 11 22:25:40 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] [Fwd: GNU Piper] Message-ID: <39444A24.90AA59E6@geoserve.net> This is a reply from Nile Geisinger of the BlueBox project (what I mentioned yesterday). READ! :-) -------------- next part -------------- An embedded message was scrubbed... From: Nile Geisinger Subject: Re: GNU Piper Date: Sun, 11 Jun 2000 18:59:02 -0700 (PDT) Size: 7194 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000612/fa9f10fb/attachment.mht From bizzaro at geoserve.net Sun Jun 11 23:18:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: Message-ID: <3944568D.3519D700@geoserve.net> Brad Chapman wrote: > > jm: I've looked at your node definition and I think we agree on > most things. I just don't think the "id" property would be necessary. > brad: Well, actually I use the id propery quite a bit, so I know what > input and outputs are connected together... > jm: I prefer naming the inputs and outputs instead of having ids > jm: mostly when you have variable number of inputs/outputs > brad: naming <- That's fine. So if a user creates a new input or > output, they need to create a unique name for it? > jm: exactly... for instance in the AND node, there's no defined > input. You can add "ThisCondition" and "ThatCondition", ... when you use it > brad: names <- Okay, that sounds good to me. I'll drop the id stuff > and start using the name as the id. I'll look into how to fix this up... Are you guys talking about node ID's or I/O ID's? For I/O's, I agree that a name may be better than some randomly assigned number. And you certainly don't need a URI for each I/O, since it's the node (that the I/O's are attached to) that has the URI. But for nodes, I thought we needed an ID that contains the URI. This way, no 2 nodes on the Internet have the same ID. Is this no longer the plan? > jm: The reason I like Node is that I like to think of the program > as a network that's made of nodes. Is the problem with Node only in the XML? > brad: Yeah, that's it. It is just really confusing to be referring to > DOM nodes and Piper nodes at the same time. It even makes it hard to look > at for me, and I'm the one coding it. Maintance will probably be a > nightmare... We've been through this before, and I seriously don't understand why we can't just create our own namespace and use... piper_node ??? Can someone explain what is wrong? Then in the documentation, we can still say plain old "node". > jm: BTW, I had a couple coments about the screenshot. First, we'll > need to name the inputs/outputs when there is more than one (as in vflow). > jm: Also, maybe we can add an "icon" tag for some nodes. For > instance, add could be represented as a "+" sign. > brad: screenshot <- Yeah, I just wrote to Jeff about the exact same > thing. The way it will work is that each little dot will have a little > windowlet associated with it that can be opened up to display this > information... > jm: I much rather see the input/output names without opening a > dialog. Otherise, there's no way you could connect, say NetExec, without > opening this dialog. > brad: dialog <- Well, it is not so much a dialog window as a little > window that moves along with dot. This should work in the same way as the > windows for each "node." Have you run Piper/Loci yet and seen what it looks > like? Of course, this is all Jeff's design plans, so this is definately > stuff you and he should hash out if you want to change it... Besides the pipe (connector) windowlet, there is a dot at the end of each pipe that can hold a SHORT name or number. The problem with having names tag along with the ENDS of the pipes, is that the ends are connected together, thus names will overlap and be obscured. I could also position names along the center of the pipes. I'll think about it. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun Jun 11 23:49:21 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:04 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper Message-ID: <200006120353.XAA15832@archa12.cc.uga.edu> > Are you guys talking about node ID's or I/O ID's? For I/O's, I agree that a > name may be better than some randomly assigned number. And you certainly > don't need a URI for each I/O, since it's the node (that the I/O's are > attached to) that has the URI. We were talking about node IDs. And, yup, I think names are better, as Jean-Marc suggested. I'll switch stuff over to using this and phase out ids. And nope, we don't need anything fancy like URIs for inputs. > But for nodes, I thought we needed an ID that contains the URI. This way, no > 2 nodes on the Internet have the same ID. > > Is this no longer the plan? That's true, but I haven't really worried about it too much since we were concentrating on local communication right now. But I guess the way I was thinking about doing it was just by prefixing an id with the URI or whatever, the way that namespaces work right now in python. So now we've got: ('random_id') and for remote nodes we'd have: ('some kind of URI', 'remote_id') > We've been through this before, and I seriously don't understand why we can't > just create our own namespace and use... > > piper_node > > ??? > > Can someone explain what is wrong? Then in the documentation, we can still > say plain old "node". Okay, since I'm the only one that is always complaining about this and fighting against the use of node I'll try to explain again. It doesn't have anything to do with the fact that our use of node will "clash" with the use of node in DOM and cause variable/namespace problems. Prefixing our piper nodes (let's say with Pnode for right now), would solve this. The problem I think is that it is *really* confusing to me in the code to be dealing with both DOM nodes and Piper nodes at the same time. So in DOM code I would be doing things like: dom_iterator = dom_tree.createNodeIterator(dom_tree, NodeFilter.SHOW_ELEMENT, None, 0) cur_node = dom_iterator.nextNode() So dealing with DOM nodes and calling functions like nextNode. Then I would be working in Piper code and doing things like: a_container_Pnode.add_node(some_Pnode) a_list_of_Pnodes = a_container_Pnode.get_children_nodes() I just think it not always very clear which functions are dealing with dom nodes and which are dealing with Piper nodes. So, I mean, maybe I'm stupid that I have a difficult time dealing with two different "node" systems at the same time. But I just think this will make my code confusing for me, and I'm the one writing it. I can't really imagine how it will be for other people looking at it. This confusion is also doubled by the fact that the dl deals with corba "nodes" connecting to the UI and corba "nodes" to the bl, and ugh, it makes my head feel about ready to explode thinking about it. I am really for a term that describes Piper "things" and it always makes complete sense that it is a function manipulating a piper "thing" and not a function manipulating a dom node. Does this make any sense at all? Of course, it is all up to the powers of voting now, but I don't think I am being a complete space cadet in having some problems with node :-). Brad From chapmanb at arches.uga.edu Mon Jun 12 00:14:32 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] [Fwd: GNU Piper] Message-ID: <200006120418.AAA23552@archa11.cc.uga.edu> > This is a reply from Nile Geisinger of the BlueBox project (what I mentioned > yesterday). READ! :-) Ay ay, sire. Jeff, I'm really happy that we could team up with more people, so that is definately super snazzy news :-). You are the man. Do you know what the deal is with their code? What language is it written in? When will it be available? It would be cool to be able to look at how things work on the innards of BlueBox/dLoo to see how Piper could fit in with it. Nile wrote: > If we do decide to collaborate, we will probably > want to provide you and other developers with equity > in our company as a means of supporting your efforts, Would that mean I would have money again? I've been wanting to follow this exceptionally hot stock tip that a friend of mine gave me and buy tons of shares of Pabst, the makers of that fine brew "Colt 45." Apparently, the malt liquour industry is really going to be taking off, and I'd like to get in on the ground level of that. Then I can also drink 40s continually and be doing it "to help my stocks." Okay, sorry, not enough sleep over here :-). Brad From jean-marc.valin at hermes.usherb.ca Mon Jun 12 00:11:53 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> Message-ID: <39446309.6F7BF003@hermes.usherb.ca> > > Are you guys talking about node ID's or I/O ID's? For I/O's, I > agree that a > > name may be better than some randomly assigned number. And you > certainly > > don't need a URI for each I/O, since it's the node (that the I/O's > are > > attached to) that has the URI. > > We were talking about node IDs. And, yup, I think names are better, as > Jean-Marc suggested. I'll switch stuff over to using this and phase > out ids. And nope, we don't need anything fancy like URIs for inputs. Perhaps we were discussing two different things at once. I was talking about inputs ids for nodes. I don't care about nodes having a name of ID (in Overflow, nodes have a name, which is usually node1, node2, ...). However, it is important that we can connect nodes using an input (or output) name, and not an id. Jeff Wrote: > Besides the pipe (connector) windowlet, there is a dot at the end of each pipe > that can hold a SHORT name or number. > The problem with having names tag along with the ENDS of the pipes, is that > the ends are connected together, thus names will overlap and be obscured. > I could also position names along the center of the pipes. I'll think about > it. I'm not exactly sure what you're talking about. ...but what I mean by input/output name can be seen at http://freespeech.on.openprojects.net/08-03-00_023954_screenshot.jpg for the FDSaveFrame screenshot. For example, if we have a Divide node, it's important to show which input is the numerator and which one is the denominator. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Mon Jun 12 00:37:35 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper Message-ID: <200006120441.AAA26952@archa11.cc.uga.edu> Jeff wrote: >> > Are you guys talking about node ID's or I/O ID's? For I/O's, I >> agree that a >> > name may be better than some randomly assigned number. And you >> certainly >> > don't need a URI for each I/O, since it's the node (that the I/O's >> are >> > attached to) that has the URI. I wrote: >> We were talking about node IDs. And, yup, I think names are better, as >> Jean-Marc suggested. I'll switch stuff over to using this and phase >> out ids. And nope, we don't need anything fancy like URIs for inputs. Jean-Marc wrote: > Perhaps we were discussing two different things at once. I was talking about > inputs ids for nodes. I don't care about nodes having a name of ID (in > Overflow, > nodes have a name, which is usually node1, node2, ...). However, it is > important > that we can connect nodes using an input (or output) name, and not an id. Ooops, sorry. That first sentence of mine should say: 'We were talkign about I/O IDs.' We were talking about the same thing, Jean-Marc, I just wrote the wrong thing in my reply to Jeff. *smack self on forehead*. I apologize for being confusing. In our discussion we were talking about naming I/Os, and didn't talk about naming Nodes at all (at least, I wasn't talking about it :-). I'm completely on the same page with you in terms of using input/output names and not ids. Okay, stop writing now Brad, before you screw up again... Brad From bizzaro at geoserve.net Mon Jun 12 00:47:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120441.AAA26952@archa11.cc.uga.edu> Message-ID: <39446B69.AEA3F208@geoserve.net> Brad Chapman wrote: > > Ooops, sorry. That first sentence of mine should say: 'We were talkign > about I/O IDs.' We were talking about the same thing, Jean-Marc, I > just wrote the wrong thing in my reply to Jeff. *smack self on > forehead*. I apologize for being confusing. In our discussion we were > talking about naming I/Os, and didn't talk about naming Nodes at all > (at least, I wasn't talking about it :-). I'm completely on the same > page with you in terms of using input/output names and not ids. Okay, > stop writing now Brad, before you screw up again... Okay, then all 3 of us are on the same page (I agree). Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 12 01:21:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> <39446309.6F7BF003@hermes.usherb.ca> Message-ID: <39447372.701D7D05@geoserve.net> Jean-Marc Valin wrote: > > > I could also position names along the center of the pipes. I'll think about > > it. > > I'm not exactly sure what you're talking about. ...but what I mean by > input/output name can be seen at > http://freespeech.on.openprojects.net/08-03-00_023954_screenshot.jpg > for the FDSaveFrame screenshot. For example, if we have a Divide node, it's > important to show which input is the numerator and which one is the denominator. I'm talking about anchoring the text at half the span of the I/O line. See the attached mockup. A fundamental difference between our GUI's is in the use of I/O lines. In Loci's GUI, the lines come with and stay attached to the node. So, line names would tend to get moved around a bit and obstructed by other things. I think anchoring the name half-way down the line may work best. But, if I show the names only when the lines are unconnected (as Overflow does), I could probably put the name under the dot at the end of the line (something like what is already done with the node itself). Hmmm. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: io-names-mockup.gif Type: image/gif Size: 3307 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000612/42386e9e/io-names-mockup.gif From bizzaro at geoserve.net Mon Jun 12 02:46:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] Re: GNU Piper References: <20000612015902.24024.qmail@web216.mail.yahoo.com> Message-ID: <3944875E.E68362C7@geoserve.net> Nile Geisinger wrote: > > We've been very > excited about this and I can tell from your email > you're excited about it as well. The idea of > graphically assembling these connections is a > remarkably beautiful addition, though, I must say. Well, once you realize how pervasive tree structures and flow charts are in computing, you start seeing how all sorts of stuff can be done with a single program that lets you graphically manipulate the structures. We've picked up on all sorts of jewels over the past couple years, for example... How about database management and mining: http://www.spss.com/clementine/newshow/sld001.htm http://www.cerebellumsoft.com/product/designer.html Data visualization: http://www.avs.com/products/expdev/netedit.htm http://www.research.ibm.com/dx/csfig21s.gif CLI -> GUI conversion and GUI construction: http://www.cnb.uam.es/~bioinfo/Colimate/Extra_Docs/snapshot.html http://www.geocities.com/SiliconValley/Bay/5371/gchip.html Or how about using these structures to describe SVG/vector and OpenGL graphics: http://www.levien.com/svg/ http://asterix.jci.tju.edu/weber/model.html But these are special-purpose systems. No one, to my knowledge, has made a general-purpose system that is basically a framework for doing all this neat stuff...until now :-) Yes, we're excited! > I've spent some time studying your project since > reading the email. What I've found fascinating is > that, even though we were working from two different > visions, we ended up with very similar results. Indeed. I'm fascinated by how we both have birds for mascots ;-) > Our goal was to bring the network effects to > programming that the web brought to publishing. In > pursuit of this goal, we created a simple, > cross-platform, HTMLish, language that ordinary people > could use to build programs. It allows them to: > > 1) Describe interfaces in XML (just as one does in > HTML) > 2) Link to interfaces and components (again like HTML) > 3) Describe component interactions with each other > (not like HTML but still simple). We call this > linking, you call this piping. You'd have fun digging through our e-mail archive and finding how we developed a similar plan. BTW, we call it too many different things. Agreeing on names, when we're working between several different countries, has been difficult. But we all thought "Piper" was a cool project name :-) > In this way, the whole program is described in a set > of XML pages. This allows sites to publish XML pages > that linked to XML pages on other sites, create XML > links that link two component together, dynamically > generate programs in XML, etc. > > In short, just like the web. Exactly like Piper :-) We even discussed plans for a directory service so that users can locate nodes/applications across the Internet. We thought about a Napster-like (centralized) system, but our plan is now for something like Gnutella (distributed). > Piper's goal, to my understanding, is to bring UNIX > piping up to the GUI level. You may have noticed that we plan on having MULTIPLE user interfaces. The default is, in fact, console-based since it allows installation and execution without a desktop running (i.e., on a server). My personal part in this project (besides being a coordinator) is to integrate Piper with the desktop. I guess I'm the GUI guy on the team. Also, Piper is meant to add an extra dimension to I/O redirection. The UNIX shell lets you connect output to input between 2 programs sharing the same protocol, but it's not very good at dealing with multiple I/O's and multiple protocols between multiple programs. Typically, in such a complex situation in UNIX, you write a shell script. This means typing in a text editor. But the Piper approach, regardless of user interface, is to treat a network of applications like a file system (Ah-ha! Another tree!) or even the web. So, the user browses around the network hierarchy (in the Build-Time Subsystem) telling Piper essentially "Connect this" and "Disconnect that". > It's primary focus is with > piping data and has built a great graphical > environment/SDK around this. Piper has also seperated > out "Interface and how the Interface links to > components" with "How components link to each other". > A nice design choice that is missing from our model. Thanks :-) > What our different visions mean in practice is that in > terms of priorities, Piper is heavily focused on 3., > while we are heavily focused on 1 and 2, with 3 > planned for a later release. All three components are > important in both of our models. The metaphors we have > been working from have just put a different emphasis > on the problems we try to solve first. Piper is certainly interested in 1 and 2, with 3 planned FIRST. As you say, we're working at this from different ends. > As you noted in your mailing list, Are you on the list? > BlueBox could serve > as your UI. In the same way, if we used your piping > work, we would not have to do component assemblage at > all in our language. And we would have a nice > seperation between interface and component > interactions. Piper and BlueBox could work very well > together. Piper is actually the merger of 3 other projects that complement each other: Loci, GMS, and Overflow. So, we know the advantage of joining forces :-) It is rare too, these days, when it seems everyone in Open Source development is making "Yet Another E-Mail Client" or "Yet Another Clone of a M$ Product". Have you noticed how many gnotepads there are? Three share the same name but not any code ;-) > To make sure that we are on the same page, here is how > I envision user experience with Piper, BlueBox, and > DSML directory services: > > 1) A user opens a file browser (whether Nautilus or > Konqueror) and browses to whatever directory of files, > programs, or piper components that they want. These > files, programs, etc. can be located anywhere on the > network (a directory server has some duplicate work > with Piper here). If there are piper components in a > directory then the user can link them together using > piper tools built into the browser(i.e., it has the a > piper toolbar or the right click mouse option). Yeah, I guess you're talking about having the native file manager select the raw (un-piped) components, and then the user can drag them into Piper somehow to work with them. Right now, we have the workspace but haven't added any interaction with a file manager. It is planned though. > 2) Files when clicked on launch the program they are > associated with. ...even withing the Piper workspace. We will be using both windowlets (stay attached to the icon) and full-fledged windows. > 3) Programs have three different ways of being > selected. They can be doubleclicked or right clicked > with "Edit Interface" or "Edit components" selected. > > A) If double clicked program launches ...or opens window/let. For some programs, that may be the same thing. > B) If Edit interface Glade (or the like) launches to > edit BlueBox interface. In this way a user can change > the interface at runtime. Yes. For low-level changes (intra-widget changes), we were also planning on using Glade. What a coincidence :-) > C) If Edit components, a seperate piper window > launches with all of the programs components that the > user can connect and change with piper. In this way a > user can change the program itself at runtime. Yes. For rearrangement of widgets (inter-widget changes), we were going to use the hierarchy or arrangement of nodes in the network to determine that. (I really need to write something about that, because most people don't know what I mean and how it can be implemented.) > In this view of the world, Piper would be an integral > part of the KDE/GNOME environment. As would BlueBox. > As would the DSML directory server. With XML tying us > all together. They certainly could be integral. It will just take some time for people to see the value in them. Also, it is a good idea to include KDE our plans (although I am a Gnome/Gtk/GNU advocate), because any exclusion will cause that camp to re-invent our efforts, either intentionally or not. > There are obviously different questions to be answered > about how the projects would interface and there are > several factors involved that we have to carefully > consider over here. As long as we don't have to change the name again. Count so far, including projects that merged: Tulip, Loci, vflow, Overflow, gMessaging/GMS, VSh, and Piper :-) > However, there is the potential > for us each to save the other a tremendous amount of > work, not to mention the excitement of working on a > similar goal. Let me talk to the other team members > here. If we do decide to collaborate, we will probably > want to provide you and other developers with equity > in our company as a means of supporting your efforts, Well, we look forward to hearing back from you. 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 Mon Jun 12 02:13:24 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> <39446309.6F7BF003@hermes.usherb.ca> <39447372.701D7D05@geoserve.net> Message-ID: <39447F84.19679D5E@hermes.usherb.ca> > I'm talking about anchoring the text at half the span of the I/O line. See > the attached mockup. > > A fundamental difference between our GUI's is in the use of I/O lines. In > Loci's GUI, the lines come with and stay attached to the node. So, line names > would tend to get moved around a bit and obstructed by other things. I think > anchoring the name half-way down the line may work best. > > But, if I show the names only when the lines are unconnected (as Overflow > does), I could probably put the name under the dot at the end of the line > (something like what is already done with the node itself). Hmmm. Here are examples of real networks I use. The first has 17 nodes, but I have some with around 50 nodes. I find the vflow layout a bit easier to follow (If I extrapolate from your mockup, the MAIN_LOOP and NNetSetTrainDBD nodes would be a real mess). It isn't as pretty as Loci, but maybe we can find something in the middle. Of course, my screenshots also prove that spaghetti code is still possible with Overflow/Piper :-) Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca -------------- next part -------------- A non-text attachment was scrubbed... Name: 2000_06_12_015658_shot.jpg Type: image/jpeg Size: 100135 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000612/ec2c08be/2000_06_12_015658_shot.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: 2000_06_12_020941_shot.jpg Type: image/jpeg Size: 132273 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000612/ec2c08be/2000_06_12_020941_shot.jpg From bizzaro at geoserve.net Mon Jun 12 03:50:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> <39446309.6F7BF003@hermes.usherb.ca> <39447372.701D7D05@geoserve.net> <39447F84.19679D5E@hermes.usherb.ca> Message-ID: <39449631.F00E72C4@geoserve.net> Jean-Marc Valin wrote: > > Here are examples of real networks I use. The first has 17 nodes, but I have > some with around 50 nodes. I find the vflow layout a bit easier to follow (If I > extrapolate from your mockup, the MAIN_LOOP and NNetSetTrainDBD nodes would be a > real mess). It isn't as pretty as Loci, but maybe we can find something in the > middle. Of course, my screenshots also prove that spaghetti code is still > possible with Overflow/Piper :-) Overflow does present the information in a very straight-forward way (more like console vs. desktop). Since Loci (Pied) and Overflow use nearly all the same graphical objects, I should be able to make a theme for Pied that looks a lot more like Overflow. You may prefer that. But, Pied is meant to be either tied in with the desktop or be a desktop itself (I even want a trash node). So, being graphical and pretty is important to Pied. It helps draw the desktop user into using Piper too. Also, you may not have noticed this, but Pied allows 2 connected lines to be bent and even dragged out of the way by the connecting point (the dot). I'm not criticizing Overflow's GUI, but in the screenshot with the "spagetti code", being able to bend lines may help neaten up the diagram. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 12 04:33:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] [Fwd: GNU Piper] References: <200006120418.AAA23552@archa11.cc.uga.edu> Message-ID: <3944A046.D8190333@geoserve.net> Brad Chapman wrote: > > Do you know what the deal is with their code? What language is it > written in? Nobody knows ;-) I guess it's C/C++ since it's supposed to run on Linux, Win, Mac and even Palm. Maybe it's Java. They do have libraries for Python, C/C++, and.....hmmm....some obscure language.......what's it called......Pearl or something? ;-) But no Java, so maybe it isn't written in Java :-P > When will it be available? It looks like they'll have several releases during the 3rd quarter. > It would be cool to be able to look at how things work on the > innards of BlueBox/dLoo to see how Piper could fit in with it. It would be, especially if we're going to collaborate ;-) (I'm on a roll.) > Would that mean I would have money again? I've been wanting to follow > this exceptionally hot stock tip that a friend of mine gave me and buy > tons of shares of Pabst, the makers of that fine brew "Colt 45." > Apparently, the malt liquour industry is really going to be taking > off, and I'd like to get in on the ground level of that. Then I can > also drink 40s continually and be doing it "to help my stocks." Okay, > sorry, not enough sleep over here :-). Standin' next to the piano with the fine, beautiful ladies, sippin' on a COLT-----45! 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 Mon Jun 12 04:06:56 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> <39446309.6F7BF003@hermes.usherb.ca> <39447372.701D7D05@geoserve.net> <39447F84.19679D5E@hermes.usherb.ca> <39449631.F00E72C4@geoserve.net> Message-ID: <39449A20.32B367D2@hermes.usherb.ca> > Overflow does present the information in a very straight-forward way (more > like console vs. desktop). Since Loci (Pied) and Overflow use nearly all the > same graphical objects, I should be able to make a theme for Pied that looks a > lot more like Overflow. You may prefer that. > > But, Pied is meant to be either tied in with the desktop or be a desktop > itself (I even want a trash node). So, being graphical and pretty is > important to Pied. It helps draw the desktop user into using Piper too. > > Also, you may not have noticed this, but Pied allows 2 connected lines to be > bent and even dragged out of the way by the connecting point (the dot). I'm > not criticizing Overflow's GUI, but in the screenshot with the "spagetti > code", being able to bend lines may help neaten up the diagram. Of course, I really didn't put much effort in vflow, and I know it looks ugly. The only reason why there's no option to bend lines is because I'm too lazy! Also, I think we could associate icons to different nodes, like in Loci. Actually, the only thing I prefer in vflow is that the way to label the inputs/outputs is clearer (plus, I think I can pack more nodes per square inch!). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Mon Jun 12 05:59:36 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> <39446309.6F7BF003@hermes.usherb.ca> <39447372.701D7D05@geoserve.net> <39447F84.19679D5E@hermes.usherb.ca> <39449631.F00E72C4@geoserve.net> <39449A20.32B367D2@hermes.usherb.ca> Message-ID: <3944B488.FBABA3EA@geoserve.net> Jean-Marc Valin wrote: > > (plus, I think I can pack more nodes per square inch!). I may take you up on that challenge :-) All I have to do with Pied is remove the icons and I'm left with teeny white dots representing the nodes :-P Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Mon Jun 12 06:11:46 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] Peep update In-Reply-To: <3944A046.D8190333@geoserve.net> Message-ID: I spent some time talking with Brad on Sunday about the DL and peep. As I understand it, the DL will, exclusively: 1) Accept input from peep thru CORBA. This input will be (loosely), "User wants [xxx] node in [yyy] position" where "xxx" includes type of node and name of node, and "yyy" includes network-order and URI of node. 2) Store information on the structure of the user-defined network according to what the UI has fed it. This is not only dynamic storage but also filesystem-storage so it can re-inform peep in case of local crashes or exit of program. 3) Regurgitate everything the UI has fed it, on command, so that the UI (peep) can form a nice, tidy list out of the information. --- The UI (peep) will, exclusively: 1) Act as a "sanity broker" to the DL so the DL always gets something it's expecting. I've chosen to use the Cmd.cmd class which simply doesn't accept input unless it matches our internal "list" of commands. 2) Feed the DL information. HOW this is done is still up for debate (see below). 3) Take regurgitated DL information and arrange it in a neat, referential, and tidy way so users can easily manipulate it at the UI. --- How peep feeds information to the DL As I see it, peep could feed info to the DL in two methods: 1) Dynamic and Transparent. Peep would automagically execute an update to the DL every time a user defines a pnode, etc. This is nice for run-time tweaks, I guess. It's dynamic because it automatically updates. It's transparent because it gives the DL the job of handling the structure of the network...in this case, the UI is "transparent" to the DL, and is simply acting as a real-time information broker to the DL during its use. Pros: Dynamic updating to the DL. Cons: All the work is done by the DL, the UI is just the interface to the DL. Therefore, the DL will have to notice when shite does not make sense. 2) Static/Opaque. Peep would allow the user to define the entire network (or pieces of it) and store all the information locally in and with the UI. It would only "inform" the DL when the user selects to 'execute' at which time the DL gets all of the UI information all at once. This is static because the UI only accesses the DL when the UI is ready to, based on what the user says. Pros: All the "playing" in the network is done in the UI. The DL isn't ever "bothered" until the structure is built and any craziness is handled. Cons: The UI is now less of an interface to the DL than a structure-builder in its own right. It duplicates some of the functionality of the DL and is probably going to be "bigger" and less sleek. ---- My choice is #1, for the following reason: I believe that any program which utilizes piper as part of its execution (like GeneGnome will) would like to have piper's DL do all the figuring and have its UI/Code Interface simply feed information back and forth. If we believe in seperable UIs, then the UIs should only be the *interface* to the DL, but not expected to do much more than check for validity in some very simple ways. Yes, no, thoughts? Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From bizzaro at geoserve.net Mon Jun 12 06:12:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:05 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: <200006120353.XAA15832@archa12.cc.uga.edu> <39446309.6F7BF003@hermes.usherb.ca> <39447372.701D7D05@geoserve.net> <39447F84.19679D5E@hermes.usherb.ca> <39449631.F00E72C4@geoserve.net> <39449A20.32B367D2@hermes.usherb.ca> <3944B488.FBABA3EA@geoserve.net> Message-ID: <3944B797.A507A77E@geoserve.net> "J.W. Bizzaro" wrote: > > Jean-Marc Valin wrote: > > > > (plus, I think I can pack more nodes per square inch!). > > I may take you up on that challenge :-) All I have to do with Pied is remove > the icons and I'm left with teeny white dots representing the nodes :-P This is actually one of the 4 "views" I'm planning for each window/let. Removing the icons and names will allow the user to see the whole network, even if it is very large. (1) Network Normal View: Icons, names, windowlets, etc. can be seen. (2) Network World View: Only dots and lines can be seen. No scrolling either. (3) GUI View: Network-described GUI is seen (per conversation with BlueBox). (4) Informational View: Details about the node (location, name, etc.) are seen and can be changed. I mentioned this on either the Loci or Piper list around the time we merged. I can't recall. 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 Jun 12 06:16:57 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper In-Reply-To: <39449A20.32B367D2@hermes.usherb.ca> Message-ID: Has anyone looked at the interface in Oregano? I just wanted to comment that it's a very cute interface, and itself acts as an interface to SPICE. Screenshot: http://www.dtek.chalmers.se/~d4hult/oregano/images/schematic.jpg Homepage: http://www.dtek.chalmers.se/~d4hult/oregano/ Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From bizzaro at geoserve.net Mon Jun 12 06:26:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update References: Message-ID: <3944BACE.68608E98@geoserve.net> deanne@density.biop.umich.edu wrote: > > 1) Accept input from peep thru CORBA. This input will be (loosely), "User > wants [xxx] node in [yyy] position" where "xxx" includes type of node and > name of node, and "yyy" includes network-order and URI of node. Yeah, or "Do this with that". (I think the syntax of the Tcl scripting language would be good for you and Brad to take a look at.) > 3) Regurgitate everything the UI has fed it, on command, so that the UI > (peep) can form a nice, tidy list out of the information. And this is important (maybe more so for Pied than Peep): The UI never really does what the user says, only what the DL says. This is not only for error checking, but it allows one UI to be controlled by another. > 1) Act as a "sanity broker" to the DL so the DL always gets something it's > expecting. I've chosen to use the Cmd.cmd class which simply doesn't > accept input unless it matches our internal "list" of commands. Good point. But this may be more important for Peep than Pied ;-) > 3) Take regurgitated DL information and arrange it in a neat, referential, > and tidy way so users can easily manipulate it at the UI. Yep. You'll largely be stripping off the XML tags. > How peep feeds information to the DL > > As I see it, peep could feed info to the DL in two methods: > > 1) Dynamic and Transparent. Peep would automagically execute an update to > the DL every time a user defines a pnode, etc. This is nice for run-time > tweaks, I guess. It's dynamic because it automatically updates. It's > transparent because it gives the DL the job of handling the structure of > the network...in this case, the UI is "transparent" to the DL, and is > simply acting as a real-time information broker to the DL during its use. > Pros: Dynamic updating to the DL. > Cons: All the work is done by the DL, the UI is just the interface to the > DL. Therefore, the DL will have to notice when shite does not make sense. THIS /IS/ THE METHOD WE WANT. > 2) Static/Opaque. Peep would allow the user to define the entire network > (or pieces of it) and store all the information locally in and with the > UI. It would only "inform" the DL when the user selects to 'execute' at > which time the DL gets all of the UI information all at once. This is > static because the UI only accesses the DL when the UI is ready to, based > on what the user says. > Pros: All the "playing" in the network is done in the UI. The DL isn't > ever "bothered" until the structure is built and any craziness is handled. > Cons: The UI is now less of an interface to the DL than a > structure-builder in its own right. It duplicates some of the > functionality of the DL and is probably going to be "bigger" and less > sleek. THIS IS /NOT/ THE METHOD WE WANT. > My choice is #1, for the following reason: Whew. Good :-) > I believe that any program which utilizes piper as part of its execution > (like GeneGnome will) would like to have piper's DL do all the figuring > and have its UI/Code Interface simply feed information back and forth. If > we believe in seperable UIs, then the UIs should only be the *interface* > to the DL, but not expected to do much more than check for validity in > some very simple ways. > > Yes, no, thoughts? By George, I think you've got it! :-) 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 Jun 12 06:36:48 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update In-Reply-To: <3944BACE.68608E98@geoserve.net> Message-ID: > > Cons: All the work is done by the DL, the UI is just the interface to the > > DL. Therefore, the DL will have to notice when shite does not make sense. > > THIS /IS/ THE METHOD WE WANT. Yes, well, the impression I got from one of your earlier emails was that you wanted the UI to have some functionality that the DL didn't... ((( > nodeset > > Enter the number of the new node: 2 Okay, maybe this is just a test/example, but node numbering should be automatic...probably handled by the UI (not the DL). ))) ..but I can see here that you could have also meant that the UI processes the information AFTER the DL feeds it to the UI. I took it to mean that you wanted the UI to do the numbering for the DL. D From bizzaro at geoserve.net Mon Jun 12 06:36:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] IRC log on XML design/Overflow inclusion in Piper References: Message-ID: <3944BD27.AF178855@geoserve.net> deanne@density.biop.umich.edu wrote: > > Has anyone looked at the interface in Oregano? > I just wanted to comment that it's a very cute interface, and itself acts > as an interface to SPICE. Yeah, I've got that in my collection of "Workflow Diagram Examples". Circuit drawing is an example of a nice way to draw out a diagram, especially with those stepped lines. But the focus has traditionally been on readability: You want to draw a circuit that you or someone else will make. IOW, it has to look nice for printing and for sharing the printouts. But, the drawback is that it takes time and planning to get a readable diagram. You certainly don't want to quickly add, remove, and "toss around" the nodes and lines like you may want to with Pied/Piper. In Pied/Piper, you really don't care how the diagram looks, because you're not going to print it out and show somebody.......well, probably not. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 12 06:50:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update References: Message-ID: <3944C06F.939A3AD3@geoserve.net> deanne@density.biop.umich.edu wrote: > > ((( > nodeset > > > > Enter the number of the new node: 2 > > Okay, maybe this is just a test/example, but node numbering should be > automatic...probably handled by the UI (not the DL). ))) > > ..but I can see here that you could have also meant that the UI processes > the information AFTER the DL feeds it to the UI. I took it to mean that > you wanted the UI to do the numbering for the DL. I was talking about pure presentation, not anything that means anything to the DL. For example, the DL tells Peep that a certain node has an output pipe called... supercalifredulisticipsialidocious But, for the sake of making things simple for the user, Peep shows the pipe as being named... 2 So, the user says... "Do this with 2" And Peep tells the DL... "Do this with supercalifredulisticipsialidocious" Yes, the UI's can do a little bit beyond relaying messages between user and DL, but still, 99% of what the UI's do is PRESENTATION. (Don't ask what the other 1% is; I just don't want to put it in absolute terms ;-)) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 12 06:52:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update References: Message-ID: <3944C0E5.7C4C997A@geoserve.net> deanne@density.biop.umich.edu wrote: > > I took it to mean that > you wanted the UI to do the numbering for the DL. The numbering is for the USER. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 12 07:59:53 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] XMLterm: A Mozilla-based Semantic User Interface Message-ID: <3944D0B8.CE05F495@geoserve.net> I think this is very interesting and relevant: "XMLterm is a terminal emulator application providing a command line interface (CLI), like an Xterm or an MS-DOS window. It uses the Mozilla layout engine as its front end and a Unix shell program as its back end. An XMLterm window can display any marked-up content that can be rendered by the Mozilla layout engine, including HTML, XML, MathML, and, in the near future, even SVG. XMLterm is implemented as a component of Mozilla, and is currently at the alpha stage of development." http://www.xml.com/pub/2000/06/07/xmlterm/index.html Jeff From chapmanb at arches.uga.edu Mon Jun 12 08:10:58 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update Message-ID: <200006121214.IAA109658@archa10.cc.uga.edu> Deanne wrote: > 1) Accept input from peep thru CORBA. This input will be (loosely), "User > wants [xxx] node in [yyy] position" where "xxx" includes type of node and > name of node, and "yyy" includes network-order and URI of node. Well, I think it is even simpler than that right now. All you should need to do is present a list of the "types" of nodes available (which you can get from the DL through the CORBA interface). Then the user will choose a type, and the DL makes it for 'em. URIs and remote nodes and all of that stuff are for the future, and the location of remote nodes should probably be semi-transparent to the user interface, since the DL will end up handling most of that. So, for at least right now all you need is xxx = node name, and we can forget aobut the yyy :-). Deanne wrote: > 3) Take regurgitated DL information and arrange it in a neat, referential, > and tidy way so users can easily manipulate it at the UI. Jeff wrote: > Yep. You'll largely be stripping off the XML tags. This is not really true since there are no XML tags. The DL talks with the user interface exclusively through CORBA now, so there is no need to be giving the user interface XML, when it can just give it functions to call. Have you had a chance to look at the "How to Write a UI for Piper" thingy? Are you opposed to what I'm doing with the UIL/DL interface? Deanne wrote: > 1) Dynamic and Transparent. Peep would automagically execute an update to > the DL every time a user defines a pnode, etc. This is nice for run-time > tweaks, I guess. It's dynamic because it automatically updates. It's > transparent because it gives the DL the job of handling the structure of > the network...in this case, the UI is "transparent" to the DL, and is > simply acting as a real-time information broker to the DL during its use. > Pros: Dynamic updating to the DL. > Cons: All the work is done by the DL, the UI is just the interface to the > DL. Therefore, the DL will have to notice when shite does not make sense. Yeah, this is the right way, even tho it means more work for me :-). > Yes, no, thoughts? That's all the way I'm thinking about it. Congrats on managing to get up to speed so fast, it took me forever to figure out what was going on... Brad From bizzaro at geoserve.net Mon Jun 12 08:30:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update References: <200006121214.IAA109658@archa10.cc.uga.edu> Message-ID: <3944D7E4.7D629522@geoserve.net> Brad Chapman wrote: > > Jeff wrote: > > Yep. You'll largely be stripping off the XML tags. > > This is not really true since there are no XML tags. The DL talks with > the user interface exclusively through CORBA now, so there is no need > to be giving the user interface XML, when it can just give it > functions to call. Have you had a chance to look at the "How to Write > a UI for Piper" thingy? Are you opposed to what I'm doing with the > UIL/DL interface? I meant the XML tags from XML-specified (and stored) user interface components. So, if a set of components is specified as... The quick brown fox jumped over the lazy dog. What color is the fox? Peep strips off the tags and prints... The quick brown fox jumped over the lazy dog. What color is the fox? _ I'm not opposed to your UIL/DL API, Brad! :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Jun 12 08:42:35 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update Message-ID: <200006121246.IAA98606@archa10.cc.uga.edu> Jeff wrote: > I meant the XML tags from XML-specified (and stored) user interface > components. So, if a set of components is specified as... > [...snip...example XML for a UI component...] Okay, I gotcha. I guess it's just important to mention that none of this is implemented yet, otherwise it is probably kind of confusing (especially since it was confusing to me and I'm supposed to know what is going on :-). Brad From bizzaro at geoserve.net Mon Jun 12 09:05:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] Peep update References: <200006121214.IAA109658@archa10.cc.uga.edu> <3944D7E4.7D629522@geoserve.net> Message-ID: <3944E034.B5867F85@geoserve.net> "J.W. Bizzaro" wrote: > > Ooops. I really wanted to give a generic description of an interface, so nix the owner=peep part. As we mentioned before, ownership is assigned to things that are specific to a certain UI. For example: Brad wrote: > Okay, I gotcha. I guess it's just important to mention that none of > this is implemented yet, otherwise it is probably kind of confusing > (especially since it was confusing to me and I'm supposed to know what > is going on :-). Well, this is what I'm hoping BlueBox will do for Piper. But we haven't see their specification yet. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 12 21:10:35 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:06 2006 Subject: [Pipet Devel] [Fwd: GNU Piper] Message-ID: <39458A0B.48E2D7D4@geoserve.net> It certainly looks promising :-) Jeff -------------- next part -------------- An embedded message was scrubbed... From: Nile Geisinger Subject: Re: GNU Piper Date: Mon, 12 Jun 2000 16:23:23 -0700 (PDT) Size: 2317 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000613/d9fb63b9/attachment.mht From bizzaro at geoserve.net Mon Jun 12 22:35:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] Re: GNU Piper References: <20000612232323.7603.qmail@web213.mail.yahoo.com> Message-ID: <39459DEB.24B64531@geoserve.net> Hi Nile! Thanks for the quick reply. Nile Geisinger wrote: > > We're working on a gray paper (not quite white) right > now on how the different systems could work together. > This is very important if we are to continue pursuing > collaboration. When we finish (tommorow or Wednesday), > we will send it over to you for review, comments, > corrections, rewrites, etc.. Our hope is that, by > working on a common paper detailing our visions, we > will be able to see if collaboration is possible. Great. We look forward to seeing it. > P.S. One thing we also talked about is adopting the > word piping over linking in our programs and > development docs. We will still have to keep the word > "linking" for investors (because of our goal to bring > to programming what the web brought to publishing), > but this would allow us to communicate better. It > would also make the interaction between BlueBox and > Piper more coherent to interested parties. If we > collaborate, it will probably make sense for us to do I don't think there is any need for you to change your terminology. A "pipe" is a type of "link", an element in the set of all links. For example, there are hyperlinks used on the web. And, Overflow, the system that works in our Processing Layer (PL), makes procedure-level connections that probably couldn't be called "pipes" in the UNIX sense. Overflow even concatonates "linked" strings, which is certainly not piping. We just think "Piper" is a better name than "Linker", which would probably be confused for a dynamic linker. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 13 08:00:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] nautilus screenshots Message-ID: <39462246.60551E99@geoserve.net> Here's a nice set of Nautilus (Gnome file manager) screenshots: http://www.ifrance.com/ardantz/linux/nautilus/nautilus.htm The plugins are interesting. It seems that when you hit a certain directory, Nautilus can switch to a plugin for managing the contents. Look at the music plugin, for an example. I wonder if Pied/Piper can work within Nautilus in such a fashion. The user can browse to a Piper directory and then have Pied show up for working with the contents. Hmm. Jeff From bizzaro at geoserve.net Tue Jun 13 11:02:44 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] web page updated Message-ID: <39464D14.6F237FC9@geoserve.net> Go check 'er out: http://bioinformatics.org/piper Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From nile at dloo.com Tue Jun 13 21:35:14 2000 From: nile at dloo.com (Nile Geisinger) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] Greetings from dLoo Message-ID: <3946E152.4DB2399C@dloo.com> Greetings from dLoo, As you have heard from Jeff, we are working on similar technologies! The model we were working from was different, but the problems we had to solve were similar. The exciting news is that, because of our models, both teams have been attacking different ends of the puzzle first. This means that there is a great possibility for both projects to benefit from each other and tighten their scope. ---On the Gray Papers--- What we have been doing over here the last two days is putting together a set of gray papers (not white) on how BlueBox works, how we understand Piper to work, and how they could work together with directory services. These papers are meant to be introductions that are "basic but technical enough" that GNOME and KDE people can understand the hows, whats, and whys of what we both are working on. The papers are posted at http://dloo.com/piper/ (not www). Please consider them to be mutually owned. Read them, rip them apart, correct any mistakes we make, etc.. Assuming that they look good to you (after all corrections), we can then agree to collaborate and publish the news to GNOME along with the Gray Papers on both of our websites Thursday/Friday . ---On Collaborating as a Whole--- We have a great graphic artist who can provide artwork if you need it. Feel free to use the Gray Papers and all images (excepting dLoo logos) on them in any way you wish. We believe in sharing the success of our company with those who work with us in the open source community. Our lawyers are still working on the equity plan. It will be a few weeks before we know the exact details. look forward to working with you, the dLoo team. After notes: Everything on Piper is from what we understand from your website. We did not use any terminology from our model. We did, however, change two terms to make it easier to understand. We changed "object" to "component" because that is the terminlogy that KDE and GNOME developers use. We changed parts of the the definition layer to "directory services." From chapmanb at arches.uga.edu Thu Jun 15 05:11:01 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] Greetings from dLoo + answers to questions Message-ID: <200006150914.FAA137632@archa12.cc.uga.edu> [...trying to move the whole dLoo thread to the mailing list where it belongs, sorry to be so disjointed and include messages from everywhere...] Nile wrote: > Greetings from dLoo, Hey Nile. Thanks much for writing and for the time you guys took in preparing the "gray papers." It is very nice to have someone spending time looking at Piper ideas enough to write up documents like those, so that is very cool, and much appreciated. In addition, thanks for all of your responses to Jeff's questions concerning licensing and your company and all of that stuff. I'll admit that I'm one of the people with a lot of concerns about working with a company. In general, companies and business in general make me feel sick to my stomach, but dLoo's hands off approach sounds very cool, and since you guys aren't that big, I guess I can leave you off my list of companies to destroy and burn :-). Seriously, the kind of informal relationship Nile was proposing sounds really good. Nile wrote: > So, I have a serious question for you. We're looking at the "gifts"/"grants" > approach to avoid these effects? What do you think of this? Is it > sufficient? In > short, what is the best way for a cash-poor company to support open source > developers? I don't really know if I am a good person to be answering this type of question, since I don't need to make any cash from open-source programming (at least right now :-). In addition, I'm not too positive I feel very comfortable speaking for any part of the open source community. Maybe stuff like this would be good to bring up on some KDE and Gnome lists? It seems like there are always lot of people ready to spout off about their open source ideas, and this might manage to grab people more from the "mainstream" open source community, whereas I feel like I am kind of on the fringe. Nile wrote: > We are learning a lot over here. One thing the community really lacks right > now is a document that explains how companies should work with Open > Source. E.g., a FAQ that has answers to the question "How should a > company contribute to an open source project?" or "How should a company > collaborate with an open source team?" This is a hard question to answer in general since it probably varies a lot from person to person and project to project. For me, I would just be happy to be coding on open source projects alongside people from companies. I don't really understand any of the details of how a buisness works and stuff, but it seems like the best way to have a company collaborate with an open source "team" is just to have people from the company coding/talking about the project, just like any other random person. One thing about open source is that no-one should really "control" it (of course, as Nile mentioned, this doesn't always happen, like in the case of Mozilla). The project is more about a bunch of people with similar ideas coming together, coding, and producing a product without any restrictions on it. So I would be more than happy to code along any with anyone, even if they are from a company. I guess the mess comes in when people need to use the product to make money, and this is where I am not really 100% sure what the company needs to do and how this will affect the relationship of a person from a company and an open source team. So I don't know if any of that rambling was any help on that, but now I'll talk about something more important, Piper and dLoo/BlueBox collaboration :-) > ---On Collaborating as a Whole--- Gary wrote: > So here we are considering another > collaboration, which means another rewrite of our defiinition layer to > hook into the bluebox system. Gawd no! Excuse me for a second while I get a couple of shots of "Old Crow" to deaden the pain here.... Seriously, I do not mind rewriting the dl to incorporate new code (even tho I bitch and moan about it all of the time). I have got so many cool ideas from Jarl and Jean-Marc's stuff and I think Piper is benefiting greatly already from their contributions. Hopefully soon we'll have hooked a lot more of their code into all of this and this will be really apparent in actual functionality :-). But the dl is written in python, which is meant for re-writing and messing around with things (if it was in C++, I definately would have gone completely insane by now), and we should take advantage of that to try to hook more stuff in, if we can. Sigh, did I really say that? :-) Gary wrote: > We stand to benefit from the expertise of > the dLoo programming team, and the codebase that they have produced. Agreed, there are tons of good ideas there, and it is definately easier to hook in good ideas than to write 'em from scratch. I don't really 100% understand what dLoo "wants" from Piper, but if we can take advantage of code they have, this is really super. Gary wrote: > But > without having a good look at that codebase, it is hard to guage how much > work we would be required to do in order to justify the collaboration. So > before we can commit to a collaboration, I think we need to have some idea > of the extent of revision we will have to do in order to integrate > bluebox and piper. Agreed completely. It is hard to talk about anything without seeing actual code and functionality and figuring out where it'll go. I'm presuming that BlueBox is written in C++, and I've already gotten SWIG to generate working bindings for Jean-Marc's code, so technically this hopefully won't be too much of a problem (as long as they don't use too much STL, ugh!). However, I think our number one priority should be getting Overflow and GMS integrated with what we've got in Piper. This is really coming along thanks to Jarl and Jean-Marc's hard work, and I want them to be able to have something working as soon as we can. It seems like this isn't too bad with BlueBoxes time frame, since there won't even be an initial release until later this month. So that should give us time to figure out how we are going to actually work on integrating the two projects together while we work more on getting Overflow, GMS and Loci all together into Piper. It would definately be great to see BlueBox code as soon as we can, so we can try to migrate what we have to fit it, and make things less painless. But, damn, who is going to do all this work I just talked about? :-) Nile wrote: > ---On the Gray Papers--- > > What we have been doing over here the last two days is putting together > a set of gray papers (not white) on how BlueBox works, how we understand > Piper to work, and how they could work together with directory services. Again, thanks for doing this! It seems like quite a bit of work and is much appreciated. Here's my thoughts/comments on particular pages: 1. The Piper screenshots on dev_graypapers_piper.html and dev_graypapers_user.html -> These screenshots are crustily old (did Piper/Loci ever even look like this, or is this all just mockup?). Can we give the dLoo guys some real screenshots from what we have now that shows the same stuff? I can do this, but am probably not the best person to since my artistic skills are nearly nonexistant. This way we can also show multidimensional components in action and everything. Another point on this. I *hate* the screenshot/mock-up with the "MultiSeq" sequence alignment node on it, just because it isn't even close to a good reflection of the functionality we have in Piper right now. If we want to use this, I would be much happier if it was clearly labelled as just being a photoshop job and not reflecting current functionality. I just think it gives people the wrong idea about what we've got. 2. The mention of a "XML component language" at the top of 'dev_graypapers_piper.html' and 'dev_graypapers_user.html' -> I am kind of nervous about calling this "a complete language" since the XML here is really simplistic. Right now we are just modeling each node/locus as having three items: Parameters, Inputs, and Outputs, and trying to make things fit in as having only these three items. I don't know if we can make any promises that this is scalable to incorporate "any component" that exists, since we just started using this new language a couple of weeks ago :-). This is all based on functionality that already exists in Overflow, so it is very promising to work well (at least, I hope so), but maybe we could talk a bit about this "three component model" or whatever and mention that is what we are doing. I could write something short up on this if you all want... 3. On the DSML stuff at 'dev_graypapers_dsml.html' -> For the Status part, unfortunately no actual code exists in Piper to support networked connections and sharing of directory services :-<. Sorry to disappoint. Right now we've been focusing on local stuff only (even though my real interest in this is in the networking). How the networked stuff is proposed to work is semi-sketeched out in the docs on the Definition Layer. I was hoping this wouldn't be too horrible to implement since it would be built off the framework that already exists in the definition layer (so at least it wouldn't be from scratch) but I'm afraid I can't claim that a single line of code is specifically devoted to networked connections :-<. Since this is the case, I had a nice read through the DSML spec that Nile et al. reference on this page (Minor rant--why can't they have one example in this stupid spec that doesn't have ugly namespaces cluttering it up? :-) and it seems like a really cool way to mark-up available directories (well, nodes or loci in the case of Piper) and what kind of functionality they have. If you guys at dLoo have a plan sketched out for how you want to incorporate the remote directory services, it would be really nice to be able to talk through this and see if we can bounce ideas off of each other. Okay, I'm going to stop writing now. If you made it all the way to here, you should definately give yourself a bit fat gold star. Thanks much for reading. Brad From bizzaro at geoserve.net Thu Jun 15 10:16:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] directory structure Message-ID: <3948E532.BF5B4C68@geoserve.net> Brad, I've got a question for ya: In the PACKAGE directory, the UI's sit in the root directory: piper/pied piper/peep While in the INSTALLATION dir, they sit in a UIL directory: piper/uil/pied piper/uil/peep Correct? (That's not the question.) But, what if we have modules common to all UI's. There should probably then be a piper/uil/modules directory in the INSTALLATION directory, right? (not the question either) So (here it is), should there be a piper/uil directory in the PACKAGE directory? I'm getting ready to put it in CVS, and I just wanted to ask this first. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Jun 15 10:52:32 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] directory structure Message-ID: <200006151456.KAA92688@archa12.cc.uga.edu> > Correct? (That's not the question.) Right! Okay, talk to you later. Oh wait, that wasn't the question :-) > But, what if we have modules common to all UI's. There should probably then > be a > > piper/uil/modules > > directory in the INSTALLATION directory, right? (not the question either) Well, even though this isn't the question either, I'll answer it anyways :-). I don't really see that there will be a need to share modules between uils. In the first place, hopefully too many more people aren't going to write uils in python (so that we can demonstrate that other languages work). Secondly, if there is a lot of share functionality between uils, then it should go in the dl, right? Common modules is just kind of inviting a mess, IMO, especially when people are installing just one UI (how many people besides developers are going to have multiple ones). Where do you see the need for such common modules? > So (here it is), should there be a > > piper/uil > > directory in the PACKAGE directory? > > I'm getting ready to put it in CVS, and I just wanted to ask this first. The reason I decided to have each different uil (peep or pied or whatever else there will be) in the top level directory if because of the reason you mentioned earlier, about having uil modules be separate in cvs from the main piper distribution. That way, if a user wants Pied and it is not included in the main distribution, the only have to get the Pied tarball and stick it in the main directory of piper, and then run configure with the option --with-pied. On the other hand, if pied also depends on this shared modules, and they don't have that installed yet, then they need to get that also, and whatever, it just seems like a bigger pain to deal with. Does this make sense? Whadda you think? Is this way okay? Brad From bizzaro at geoserve.net Thu Jun 15 12:20:41 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] directory structure References: <200006151456.KAA92688@archa12.cc.uga.edu> Message-ID: <39490259.16CA1D58@geoserve.net> Brad Chapman wrote: > > Well, even though this isn't the question either, I'll answer it > anyways :-). I don't really see that there will be a need to share > modules between uils. In the first place, hopefully too many more > people aren't going to write uils in python (so that we can > demonstrate that other languages work). Secondly, if there is a lot of > share functionality between uils, then it should go in the dl, right? > Common modules is just kind of inviting a mess, IMO, especially when > people are installing just one UI (how many people besides developers > are going to have multiple ones). > Where do you see the need for such common modules? The last time we talked about UI widgets (particularly Gtk GUI widgets), we were thinking about them being "Bonobo widgets" (that is, widgets that have Bonobo bindings or whatever). The thought was that Bonobo provided a language-independent way to display widgets. So, I thought there might be a... piper/uil/bonobo directory. /BUT/ that was before we found out about BlueBox. This is what I'm now hoping BlueBox will provide: our widget set. Yeah, I suppose then we won't be putting any BlueBox stuff directly into the package directory, so maybe this is not an issue right now...at least not until we find out more about BlueBox. > The reason I decided to have each different uil (peep or pied or > whatever else there will be) in the top level directory if because of > the reason you mentioned earlier, about having uil modules be separate > in cvs from the main piper distribution. That way, if a user wants > Pied and it is not included in the main distribution, the only have to > get the Pied tarball and stick it in the main directory of piper, and > then run configure with the option --with-pied. They could just stick it in the piper/uil directory too. But, if the only things that go in piper/uil are the UI's AND /NO/ SHARED COMPONENTS (which will always be present in the package), then maybe dropping the UI's in root is simplest. I don't know. Besides, Peep will always come with the package.......it's not like it has been dropped in by the user. > On the other hand, if > pied also depends on this shared modules, and they don't have that > installed yet, then they need to get that also, and whatever, it just > seems like a bigger pain to deal with. > Does this make sense? Whadda you think? Is this way okay? If my unconvincing argument doesn't convince you, then I'll put it in as is. What do you say? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Jun 15 12:28:47 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] directory structure Message-ID: <200006151632.MAA102394@archa12.cc.uga.edu> > The last time we talked about UI widgets (particularly Gtk GUI widgets), we > were thinking about them being "Bonobo widgets" (that is, widgets that have > Bonobo bindings or whatever). The thought was that Bonobo provided a > language-independent way to display widgets. So, I thought there might be > a... > > piper/uil/bonobo Yeah, but again, this would only be for a select subset of uis, since I wouldn't expect a Java UI or a Common Lisp UI or whatever to support bonobo interfaces or necessarily use the Gtk toolkit at all. I think bonobo is good for interoperating within Gnome, but don't really know how spiffy it is beyond that (since it wasn't designed with this in mind). > directory. /BUT/ that was before we found out about BlueBox. This is what > I'm now hoping BlueBox will provide: our widget set. Yeah, I suppose then we > won't be putting any BlueBox stuff directly into the package directory, so > maybe this is not an issue right now...at least not until we find out more > about BlueBox. Yeah, well, BlueBox will do everything for us :-). I don't know, since we have no clue how this will work, we can't really speculate what'll be good and what'll be bad. Chances are we'll end up modifying the directory structure yet again. Sigh. > They could just stick it in the piper/uil directory too. But, if the only > things that go in piper/uil are the UI's AND /NO/ SHARED COMPONENTS (which > will always be present in the package), then maybe dropping the UI's in root > is simplest. I don't know. Besides, Peep will always come with the > package.......it's not like it has been dropped in by the user. Well, I think that's a good argument for it. Root directory = simpler. Since I'm simple-minded, I like that. > If my unconvincing argument doesn't convince you, then I'll put it in as is. > What do you say? I say okay. I'm not really for rearranging around autoconf/make again, so let's just stick with it. As you said, without knowing what shared components will be, this way is simplest. Brad From bizzaro at geoserve.net Thu Jun 15 12:53:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] directory structure References: <200006151632.MAA102394@archa12.cc.uga.edu> Message-ID: <394909F4.F88DBEE6@geoserve.net> Brad Chapman wrote: > > I say okay. I'm not really for rearranging around autoconf/make again, > so let's just stick with it. As you said, without knowing what shared > components will be, this way is simplest. Okay, I'll put it in CVS as soon as I hear back from Gary about where in the new server it will go. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 15 22:48:57 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] piper on new server Message-ID: <39499599.3BC8218C@geoserve.net> I re-imported piper, but this time to the new server. Note that this server is TEMPORARILY at... alpha.bioinformatics.org It will soon become... www.bioinformatics.org But, in the meantime, be sure to use the hostname alpha. Here are instructions on using CVS on the server (remember to change addresses to alpha!): http://alpha.bioinformatics.org/docs/cvs/ Anonymous access isn't working quite yet. directoryname is "piper". loginname is your shell account login name. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Jun 15 23:58:41 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] piper on new server Message-ID: <200006160402.AAA163410@archa10.cc.uga.edu> Jeff wrote: > I re-imported piper, but this time to the new server. Ooops, it wasn't very happy with me trying to connect: $ export CVS_RSH='ssh' $ export CVSROOT=':ext:chapmanb@alpha.bioinformatics.org:/cvsroot' $ cvs checkout piper chapmanb's password: cvs server: Updating piper cvs server: failed to create lock directory in repository `/cvsroot/piper': Permission denied cvs server: failed to obtain dir lock in repository `/cvsroot/piper' cvs [server aborted]: read lock failed - giving up Not sure what the problem is. Any thoughts? Brad From bizzaro at geoserve.net Fri Jun 16 00:13:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] piper on new server References: <200006160402.AAA163410@archa10.cc.uga.edu> Message-ID: <3949A953.14866BB9@geoserve.net> Brad Chapman wrote: > > Ooops, it wasn't very happy with me trying to connect: > > $ export CVS_RSH='ssh' > $ export CVSROOT=':ext:chapmanb@alpha.bioinformatics.org:/cvsroot' > $ cvs checkout piper > chapmanb's password: > cvs server: Updating piper > cvs server: failed to create lock directory in repository > `/cvsroot/piper': Permission denied > cvs server: failed to obtain dir lock in repository `/cvsroot/piper' > cvs [server aborted]: read lock failed - giving up > > Not sure what the problem is. Any thoughts? You weren't in the group "cvs". I just fixed that, so give 'er another go. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 16 00:31:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:07 2006 Subject: [Pipet Devel] piper on new server References: <39499599.3BC8218C@geoserve.net> Message-ID: <3949ADAF.93392804@geoserve.net> I got CVSWeb working: http://alpha.bioinformatics.org/cgi-bin/cvsweb.cgi/ BTW, Gary, I had to re-install the config files, so the changes you made to the appearance are *poof* Sorry :-( Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 16 14:14:04 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] [Fwd: Answers to remaining questions] Message-ID: <394A6E6C.7358EB8C@geoserve.net> Thank you for the reply, Nile. I still have to get back to you with some comments of my own. I'm forwarding this message to the list, because it doesn't contain anything confidential. As Brad said, most of our conversations should be on the list. We actually have more non-developers on it than developers, which is pretty good considering we haven't made a formal announcement about Piper yet. Jeff -------------- next part -------------- An embedded message was scrubbed... From: Nile Geisinger Subject: Answers to remaining questions Date: Fri, 16 Jun 2000 10:46:57 +0100 Size: 3450 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000616/9da111c2/attachment.mht From nile at dloo.com Fri Jun 16 07:23:13 2000 From: nile at dloo.com (Nile Geisinger) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] Piper's Importance and Resources References: <200006160402.AAA163410@archa10.cc.uga.edu> Message-ID: <394A0E21.1E5DA55C@dloo.com> Hi All, I just sent out an answer to Brad and Gary's questions. My mail client died in the middle of transfer so if you didn't get it, let me know. I'm about to go down the rabbit hole for the next two weeks to get out the early adopter release of BlueBox. In the meantime, if you need high quality graphics work send an email describing what you need done to developer@dloo.com and we'll put Alex on it. Alex is really talented and can produce pretty amazing results if you give him a description of what you need. He might be working on clip art graphics for GNOME and KDE (sorely needed). We redid the Piper stuff so that it would integrate more into your site if you're interested. Again, feel free to do anything you like with it. Graphics and HTML are at http://dloo.com/piper/revised.tgz. I answered in the last email part of the reason dLoo is excited about Piper in answer to a question. We're really surprised, to be honest, that the rest of the open source movement isn't excited about it. Right now, programs in KDE and GNOME are both static and opaque. Their internals cannot be changed or seen by users. Piper offers a new way to program. Rather than statically binding components together, it offers a simple linking language that binds program components together at run time. In this way, uses can instantly get a graphical display of the internals of programs in pretty graphics that they can manipulate. This has the potential to completely revolutionize the KDE/GNOME development model in a very profound way. Piper also allows users to manage workflow across a network. Again, very revolutionary. Finally, Piper allows users to build distributed applications (some time in the future). Of these, I could easily see a dozen KDE/GNOME people wanting to contribute if they just understood the potential of your work. Have you considered publishing a press release to GNOTICES or linuxtoday or even slashdot regarding, in particular, how Piper can make programs transparent and modifiable? There are a lot of people who would find this fascinating and I bet they would be interested in contributing. Let us know if you need anything for you work. Again, thanks for all of your responses, Nile From bizzaro at geoserve.net Fri Jun 16 16:21:04 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] Piper's Importance and Resources References: <200006160402.AAA163410@archa10.cc.uga.edu> <394A0E21.1E5DA55C@dloo.com> Message-ID: <394A8C30.EBD11B50@geoserve.net> Nile Geisinger wrote: > > I just sent out an answer to Brad and Gary's questions. My mail client > died in the middle of transfer so if you didn't get it, let me know. Do you mean the one I forwarded to the list a couple hours ago? > I'm about to go down the rabbit hole for the next two weeks to get out > the early adopter release of BlueBox. In the meantime, if you need high > quality graphics work > send an email describing what you need done to developer@dloo.com and > we'll put Alex on it. > > Alex is really talented and can produce pretty amazing results if you > give him a description of what you need. He might be working on clip art > graphics for GNOME and KDE (sorely needed). Well, Brad has been grumbling about the lack of icons for the Pied/Piper user interface. Has Alex worked with alpha transparencies and PNG's before? Actually, I was a graphic artist before becoming a scientist (I know, covering the spectrum). But I try to avoid it as much as I can now :-), especially when I need to do a lot more programming on Pied. > We redid the Piper stuff so that it would integrate more into your site > if you're interested. Again, feel free to do anything you like with it. > Graphics and HTML are at http://dloo.com/piper/revised.tgz. I'm surprised and thrilled by how well you've been able to grasp the concepts and put them in writing. I most certainly will consider using what you have for our web page. > I answered in the last email part of the reason dLoo is excited about > Piper in answer to a question. We're really surprised, to be honest, > that the rest of the open source movement isn't excited about it. Well, we haven't had an all-out campaign yet, and the main reason is that Open Source developers HATE "vaporware". I guess I thought we should have something people can actually use so that they don't get too excited over nothing. > Right now, programs in KDE and GNOME are both static and opaque. Their > internals cannot be changed or seen by users. > > Piper offers a new way to program. Rather than statically binding > components together, it offers a simple linking language that binds > program components together at run time. In this way, uses can instantly > get a graphical display of the internals of programs in pretty graphics > that they can manipulate. This has the potential to completely > revolutionize the KDE/GNOME development model in a very profound way. When Piper started coming together, I became a bit bewildered by other UNIX GUI's, old and new. I realized that Piper actually brought the UNIX paradigm (the USER can do complex tasks by connecting simple tools) to the GUI (and desktop) and that NO OTHER SYSTEM (that I know of) has ever really attempted this. GNOME, KDE, Enlightenment, NeXT, CDE, and so on, ARE ALL DERIVATIVES OF WINDOWS AND THE MAC, meaning no-one has rethought the concept of the GUI since the Lisa and Xerox Star! I just don't understand it. The concepts behind Piper seem rather obvious. > Of these, I could easily see a dozen KDE/GNOME people wanting to > contribute if they just understood the potential of your work. In addition to not wanting to announce vaporware, I thought we needed to define Piper's function and implementation before a lot of REAL heavy-weights in the community came in and faught over it.....potentially splitting the project and/or taking it out of my hands (think bulls in a china shop). So, this has been an incubation period for Piper. Even during the incubation, source and development have been open. Piper just hasn't been well known. But, now that it is maturing, I think it can stand for some publicity.....and even some fighting over. > Have you considered publishing a press release to GNOTICES or linuxtoday > or even slashdot regarding, in particular, how Piper can make programs > transparent and modifiable? There are a lot of people who would find > this fascinating and I bet they would be interested in contributing. I thought about writing an article titled something like, "The UNIX Way Finally Comes to the GUI". But I still want to wait until there is something useful for people to play with, which may be around the time you release a full version of BlueBox (August?) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From nile at dloo.com Fri Jun 16 10:17:15 2000 From: nile at dloo.com (Nile Geisinger) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] Piper's Importance and Resources References: <200006160402.AAA163410@archa10.cc.uga.edu> <394A0E21.1E5DA55C@dloo.com> <394A8C30.EBD11B50@geoserve.net> Message-ID: <394A36EB.32317561@dloo.com> Hey Jeff, > Well, Brad has been grumbling about the lack of icons for the Pied/Piper user > interface. Has Alex worked with alpha transparencies and PNG's before? Alex has worked with everything. > Well, we haven't had an all-out campaign yet, and the main reason is that Open > Source developers HATE "vaporware". I guess I thought we should have > something people can actually use so that they don't get too excited over > nothing. More than just hate it. Hate anything they can't download NOW. Three weeks out is hardly vaporware, but some people on GNOME were a little upset that BlueBox wasn't available the day it was announced!?!? I guess open source companies are the only ones that can warn people that software is about to be released. > When Piper started coming together, I became a bit bewildered by other UNIX > GUI's, old and new. I realized that Piper actually brought the UNIX paradigm > (the USER can do complex tasks by connecting simple tools) to the GUI (and > desktop) and that NO OTHER SYSTEM (that I know of) has ever really attempted > this. GNOME, KDE, Enlightenment, NeXT, CDE, and so on, ARE ALL DERIVATIVES OF > WINDOWS AND THE MAC, meaning no-one has rethought the concept of the GUI since > the Lisa and Xerox Star! I just don't understand it. The concepts behind > Piper seem rather obvious. Good ideas always seem obvious in retrospect. > > Of these, I could easily see a dozen KDE/GNOME people wanting to > > contribute if they just understood the potential of your work. > > In addition to not wanting to announce vaporware, I thought we needed to > define Piper's function and implementation before a lot of REAL heavy-weights > in the community came in and faught over it.....potentially splitting the > project and/or taking it out of my hands (think bulls in a china shop). So, > this has been an incubation period for Piper. The ASP model is hot. Distributed architecture is hot. Easy interfaces are hot. Too many ducks are in a row and the fact that two groups already went down a similar path, probably means that there is a third. I hope you guys get credit for the ideas in Piper. One always hears that Open Source only knows how to copy: which is not true. And here, along with FreeVSD, Freenet, 3dsia, etc., is a clear example of innovation. > Even during the incubation, source and development have been open. Piper just > hasn't been well known. But, now that it is maturing, I think it can stand > for some publicity.....and even some fighting over. > Multiple visions for a project are often a good thing too. Shows a broad idea that several people want to use in a variety of ways: witness all the modules in Apache. I suspect, when the open source community does becomes aware of it, there'll be very little fighting, but lots of unintended ways in which Piper evolves, cheers, Nile From bizzaro at geoserve.net Sat Jun 17 16:17:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] more changes to web page Message-ID: <394BDCEA.C8DAAD5B@geoserve.net> I further modified the web page so that there is one page per topic/section. And I included dLoo's grey paper on Piper as an introduction. http://bioinformatics.org/piper Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From gvd at penguin.pharmacy.ualberta.ca Sat Jun 17 22:27:24 2000 From: gvd at penguin.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] more changes to web page In-Reply-To: <394BDCEA.C8DAAD5B@geoserve.net> Message-ID: Looks very good! g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ On Sat, 17 Jun 2000, J.W. Bizzaro wrote: > I further modified the web page so that there is one page per topic/section. > And I included dLoo's grey paper on Piper as an introduction. > > http://bioinformatics.org/piper > > 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 chapmanb at arches.uga.edu Mon Jun 19 10:48:54 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] NetInputs and NetOutputs Message-ID: Hello all; I've been working on getting Overflow ideas and concepts worked into Piper, but am not sure how we are planning on integrating the concept of NetInputs and NetOutputs from Overflow. So, first let me try to explain what NetInputs and NetOutputs are. Overflow has the ideas of Networks, which are equivalent to Workspaces in Loci, and the idea of Subnets, which are equivalent to composite loci in Loci. The idea is that Subnets are like little functions, that take some kind of input, process it, and then generate some kind of output. This is cool since it lets you simplify the overall workflow diagram, and also lets you reuse useful internal functions. One of the key concepts that goes along with this is the ideas of the Inputs that flow into a subnet, and the Outputs that go out (which are just like the parameters and return values of a function). Now, I'm trying to think of how to make this work in Piper, using the gnome GUI (pied) from Loci. I attached a screenshot from the current Piper which shows what this looks like. In the simple example, we have a Constant value putting its input into a composite (which is analagous to a Subnet in Overflow), and a TextViewer recieving the output from the composite. Inside the composite, we just have a NetExec locus, which will process the input, and return the output. Now, the question is, what is the process by which we will direct the input from the Constant into, say, input connector 1 of the NetExec. Similarly, how will we direct the output of say, output connector 1 of the NetExec into the TextViewer? I am not sure at all how this is concieved to work in GUI, so I'm having a hard time visualizing how to model it in the definition layer. Does anyone have any ideas about how to do this, so that I can get a better grasp on what do ? Thanks much! Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: net_ex.jpg Type: image/jpeg Size: 15865 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000619/8bdb68ae/net_ex.jpg From jarl at casema.net Mon Jun 19 11:26:00 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: Message-ID: <394E3B88.62305EC2@casema.net> > Now, the question is, what is the process by which we will direct > the input from the Constant into, say, input connector 1 of the NetExec. > Similarly, how will we direct the output of say, output connector 1 of the > NetExec into the TextViewer? Dont know if this is even near an answer to your problem, this is how GMNS\BL handles streams: 1. input into the system (from the DL, the PL or a plugin) is gathered by "Sensors", this means the BL knows dataflows from a sensor node type are new\unsecure\un-marchalled\etc. 2. every data going out of the BL ends into a "visual", after which the datastream will not be handled by the BL anymore. The relation of 1. and 2. with your problem is this: 1. All output-from-the DL\UI is going into a BL-node which is requested as a input node, cq a sensor. 2. All nodes the UI wants to have the output from are marked too, this time as visuals. So the datastreams up and down into the UI\DL\BL\PL hiarchy will be without much overhead. This is why we have a BL anyway :-) I'm I making any sense? [I've the feeling my dutch thoughts arn't very well translated :)] bye, jarl From bizzaro at geoserve.net Mon Jun 19 12:02:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: Message-ID: <394E442B.E0E69A88@geoserve.net> Brad Chapman wrote: > > Subnets, which are equivalent to composite loci in Loci. For Piper, we should probably just stick to Overflow's terminology of "networks" and "subnets". It goes to show how compatible Overflow and Loci concepts were. > Now, the question is, what is the process by which we will direct > the input from the Constant into, say, input connector 1 of the NetExec. > Similarly, how will we direct the output of say, output connector 1 of the > NetExec into the TextViewer? I'm not sure if you're asking how this can be done conceptually or graphically (in which case, I can answer the question), or how this can be implemented (in which case, Jarl should answer the question). > I am not sure at all how this is concieved to work in GUI, so I'm > having a hard time visualizing how to model it in the definition layer. > Does anyone have any ideas about how to do this, so that I can get a better > grasp on what do ? Thanks much! Conceptually and graphically, it's very simple: Unconnected pipes in a subnet mean the I/O is redirected from/to the parent network. In Pied/Piper, all "dangling" pipes are reproduced at (mapped onto) the parent node's icon (this is not implemented yet). To "close" a pipe or create a "dead end", the user must "hide" it (also not implemented). In Peep, the user will need to issue a "close" or "cap" command to do the equivalent. In your screenshot/mockup, you show the subnet containing a node with 4 unconnected pipes (2 in and 2 out). When Pied is working properly, ALL 4 PIPES will be mapped onto the parent node's icon. You are only showing 2 pipes on the parent (1 in and 1 out). The unconnected pipes should also have names, as Jean-Marc suggested, which will help the user see what pipe pipes what kind of data (not implemented either!). I need to get to work :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 19 13:38:11 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] old messages Message-ID: <394E5A82.7AF58B22@geoserve.net> This morning you may have gotten some messages from this list dated back a couple months. Just ignore them. It's some sendmail bug on the older system. 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 Mon Jun 19 14:10:06 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: Message-ID: <394E61FE.FB4F122@hermes.usherb.ca> > I've been working on getting Overflow ideas and concepts worked > into Piper, but am not sure how we are planning on integrating the concept > of NetInputs and NetOutputs from Overflow. NetInputs, NetOutputs and NetConditions are used to specify what goes in and out of the subnet. Since every subnet has at least one output, it needs at least on e NetOutput. All non-toplevel networks can also have NetInputs, that take data from outside. Iterators must have ONE NetCondition. These Net* can be added by shift-clicking (or ctrl-clicking) in the node terminals. When you include a subnet in another network, it will appear as a regular node. The inputs of this node will be the NetInputs tags, the same applies to NetOutputs (You don't see NetConditions however, since it is used "internally" by the Iterator) > So, first let me try to explain what NetInputs and NetOutputs are. > Overflow has the ideas of Networks, which are equivalent to Workspaces in > Loci, and the idea of Subnets, which are equivalent to composite loci in > Loci. The idea is that Subnets are like little functions, that take some > kind of input, process it, and then generate some kind of output. This is > cool since it lets you simplify the overall workflow diagram, and also lets > you reuse useful internal functions. One of the key concepts that goes > along with this is the ideas of the Inputs that flow into a subnet, and the > Outputs that go out (which are just like the parameters and return values > of a function). > Now, I'm trying to think of how to make this work in Piper, using > the gnome GUI (pied) from Loci. I attached a screenshot from the current Did I mention that "pied" in french (with the same spelling) means "foot". It's pronounced "pi?". > Piper which shows what this looks like. In the simple example, we have a > Constant value putting its input into a composite (which is analagous to a > Subnet in Overflow), and a TextViewer recieving the output from the > composite. Inside the composite, we just have a NetExec locus, which will > process the input, and return the output. > Now, the question is, what is the process by which we will direct > the input from the Constant into, say, input connector 1 of the NetExec. > Similarly, how will we direct the output of say, output connector 1 of the > NetExec into the TextViewer? If I understand correctly, that's exactly where NetInputs and NetOutputs are used. If you compare subnets to C functions, then NetInputs are the arguments and NetOutputs are the return value(s). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Mon Jun 19 14:22:01 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: <394E61FE.FB4F122@hermes.usherb.ca> Message-ID: <394E64C9.12460C5B@geoserve.net> Jean-Marc Valin wrote: > > Did I mention that "pied" in french (with the same spelling) means "foot". It's > pronounced "pi?". Do the French-Canadians know the story of the "Pied Piper"? Jarl, are there any "Foot Pijpers" over there in the Netherlands? ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 19 14:26:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: <394E61FE.FB4F122@hermes.usherb.ca> Message-ID: <394E65EE.AF5F4F21@geoserve.net> Jean-Marc Valin wrote: > > If I understand correctly, that's exactly where NetInputs and NetOutputs are > used. If you compare subnets to C functions, then NetInputs are the arguments > and NetOutputs are the return value(s). Brad, these are exactly the same as the inputs and outputs of a Loci "composite locus". I see no difference. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jun 19 16:44:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] THE SECOND COMING - A MANIFESTO Message-ID: <394E864B.7AF07231@geoserve.net> I found this interesting and relevant: ``"Second Coming," a 10,000-word essay, contends that rather than remaining a world that Microsoft or any company might dominate, computing is actually shifting to a world in which data and computer processing will be increasingly spread across thousands, if not millions, of interconnected computers. "Information travels through a sea of anonymous, interchangeable computers like a breeze through tall grass," Mr. Gelernter wrote.'' Sound familiar? NY Times article: http://www.nytimes.com/library/tech/00/06/biztech/articles/19gale.html David Gelernter's (a very well-known Yale comp-sci prof) essay: http://www.edge.org/3rd_culture/gelernter/gelernter_p1.html Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Jun 19 18:18:33 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs Message-ID: <200006192218.SAA137044@archa11.cc.uga.edu> Jeff wrote: > I'm not sure if you're asking how this can be done conceptually or > graphically > (in which case, I can answer the question), or how this can be implemented > (in > which case, Jarl should answer the question). Well, I was kind of asking both, but since you both answered, all of my dreams have come true :-) ** The conceptual part ** Jeff wrote: > Conceptually and graphically, it's very simple: Unconnected pipes in a subnet > mean the I/O is redirected from/to the parent network. In Pied/Piper, all > "dangling" pipes are reproduced at (mapped onto) the parent node's icon (this > is not implemented yet). To "close" a pipe or create a "dead end", the user > must "hide" it (also not implemented). In Peep, the user will need to issue > a > "close" or "cap" command to do the equivalent. Okay, this makes complete sense. Thanks! I'll work on adding support for this in the dl so that the xml files model this kind of behavior. Jean-Marc wrote: > If I understand correctly, that's exactly where NetInputs and NetOutputs are > used. If you compare subnets to C functions, then NetInputs are the arguments > and NetOutputs are the return value(s). Jeff wrote: > Brad, these are exactly the same as the inputs and outputs of a Loci > "composite locus". I see no difference. Okay, it seems like we're all on the same page (for once :-), so that is really exciting. I think I've got what's going on and understand how to integrate it with what Overflow already has, so I'll move forward on that... ** The implementation part ** To preface this, I haven't been worry about the implementation details about this a whole lot, since what I'm working on doing is making the dl produce xml that is compliant with what Overflow current has (I judge this by the ability to open up the produced xml in Overflow). I'm presuming that this document is going to be what I'll submit to the bl, and then the bl/pl will be able to deal with it from there. Hopefully these are the same thoughts Jarl and Jean-Marc are having :-). Jarl wrote: [...snip...explanation of how GMS works...] > The relation of 1. and 2. with your problem is this: > 1. All output-from-the DL\UI is going into a BL-node which is requested > as a input node, cq a sensor. > 2. All nodes the UI wants to have the output from are marked too, this > time as visuals. > So the datastreams up and down into the UI\DL\BL\PL hiarchy will be > without much overhead. This is why we have a BL anyway :-) > > I'm I making any sense? [I've the feeling my dutch thoughts arn't very > well translated :)] I think so... If I'm with you, it seems like you're saying that the flow of data in the bl and pl should occur independently of how weird the nodes are structured in the user interface and definition layer. So, as long as I can let you know what the connections are, you can run through them okay... Am I thinking along the right lines? If I am, then this seems to be an example of the separation between build time and run time that Jeff has been talking about. This way we can have a user interface that is easier to understand, and still have a rapid flow during execution. Sounds cool to me :-). ** Iterator and NetParameter part ** > Iterators must have ONE NetCondition. These Net* can be added > by shift-clicking (or ctrl-clicking) in the node terminals. When you include a > subnet in another network, it will appear as a regular node. The inputs of > this node will be the NetInputs tags, the same applies to NetOutputs (You > don't see > NetConditions however, since it is used "internally" by the Iterator) Right, I still need to add stuff for handling Iterators and haven't even gotten into this yet. I guess we should stick with the simple connection and subnet stuff for now, since that already gives us enough to do in the GUI. Then once we've got that settled, we should attack having iterators and thinking of a way to set the NetConditions for them. Thanks much for everyone's insight on this! Brad From bizzaro at geoserve.net Mon Jun 19 18:54:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: <200006192218.SAA137044@archa11.cc.uga.edu> Message-ID: <394EA4BE.6CFD00D4@geoserve.net> Brad Chapman wrote: > > Jeff wrote: > > Conceptually and graphically, it's very simple: Unconnected pipes > > in a subnet mean the I/O is redirected from/to the parent network. > > In Pied/Piper, all "dangling" pipes are reproduced at (mapped > > onto) the parent node's icon (this is not implemented yet). To > > "close" a pipe or create a "dead end", the user must "hide" it > > (also not implemented). In Peep, the user will need to issue a > > "close" or "cap" command to do the equivalent. > > Okay, this makes complete sense. Thanks! I'll work on adding support > for this in the dl so that the xml files model this kind of behavior. About DL support: We'll need commands like "create_link" and "destroy_link" ("link" is Overflow terminology, which we should use, and a "pipe" is a type of link). As an example of why the UI needs to follow the commands of the DL (although that may seem backward), imagine the user entering a subnet and disconnecting a link. The UI tells the DL...... UI: "DL, disconnect this link" But, now that there is an unconnected link in a subnet, the subnet's parent node (the node that represents the subnet -- contained in the "supernet") gets that link added to it (for Pied, the link is added to the icon). (This is what I described to you earlier.) So, what happens? First, the DL tells the UI to go ahead and disconnect the link: DL: "UI, disconnect this link" The UI does it, but THE PARENT NODE NEEDS A LINK ADDED: DL: "UI, create a link on the parent" THIS IS NOT MERELY ECHOING BACK THE COMMANDS BY THE DL AS A CONFIRMATION! This is something the DL has come up with on its own. This is why the DL is smart while the UI is dumb, and why the UI has to listen to the DL! > > (You don't see NetConditions however, since it is used "internally" > > by the Iterator) > > Right, I still need to add stuff for handling Iterators and haven't > even gotten into this yet. About iterations: The idea of using iterators with data passed around the Internet (not just within the Overflow system) is interesting. Say that you want to pass some data to a remote processor in a loop until a condition is met. But, where should the logic/controller for this reside? Do we need to (re)implement this in the BL layer, or should the user make a PL subnet to handle this? Thoughts? Talk amongst yourselves :-) 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 Mon Jun 19 19:47:07 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: <200006192218.SAA137044@archa11.cc.uga.edu> <394EA4BE.6CFD00D4@geoserve.net> Message-ID: <394EB0FB.E8FC7146@hermes.usherb.ca> > About DL support: We'll need commands like "create_link" and "destroy_link" > ("link" is Overflow terminology, which we should use, and a "pipe" is a type > of link). As an example of why the UI needs to follow the commands of the DL > (although that may seem backward), imagine the user entering a subnet and > disconnecting a link. The UI tells the DL...... I'd be tempted to use "Link" in the PL and "Pipe" for the BL. A link is implemented through the getOutput() call and the exchenge is made in memory, while a "Pipe" is implemented through the BL and uses CORBA/sockets/... > About iterations: The idea of using iterators with data passed around the > Internet (not just within the Overflow system) is interesting. Say that you > want to pass some data to a remote processor in a loop until a condition is > met. But, where should the logic/controller for this reside? Do we need to > (re)implement this in the BL layer, or should the user make a PL subnet to > handle this? Thoughts? Talk amongst yourselves :-) Just like in Overflow a Network is a Node, and just like the BL can wrap Overflow, we could have a PL node that "wraps" the BL (maybe by executing another BL on the local machine). Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Mon Jun 19 20:11:15 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs Message-ID: Jeff wrote: > About DL support: We'll need commands like "create_link" and "destroy_link" > ("link" is Overflow terminology, which we should use, and a "pipe" is a type > of link). Yup, you've already got addInput, addOutput, removeInput, removeOutput to call (althought I still need to implement 'em, but that's coming soon...). > As an example of why the UI needs to follow the commands of the DL > (although that may seem backward), imagine the user entering a subnet and > disconnecting a link. [...snip...description of UI talking to the DL and recieving commands back to do things...] Okay, this is *not* how things work currently, although I think this is a good idea and we should probably make the move to do this. The basic idea seems to be that of the Model-View-Controller (MVC) pattern, which is something Rick mentioned earlier on the Loci list, and is also what is used in the Berlin project. I'm not really an expert on this at all, but I think I understand the basic idea. I attached a gif I stole off the web that descibes how this pattern works (man, I am attaching lots of stuff, sorry 'bout the bandwidth), so maybe you can follow along with what I say next (hopefully :-). So basically what we've got a corba idl for now is the controller, which allows the user interface to manipulate the Model (the xml in the definition layer). What Jeff is talking about (I think) is implementing the View part, so that the definition layer can automatically update the user interface when something exciting happens in the XML. Using this model, the user would only be able to do cosmetic things with the user interface (move stuff around, open and close windowlets) and then would call the Controller (the idl we have now) when it wants to do something more exciting, like connect or add nodes, the Changes are made by the Model updating the View. Does this make sense with what you were thinking about, Jeff? Make sense to anyone else? If so, I can start working on setting things up to work like this. It would make a lot of sense, and would help make the loading of Overflow xml files into Piper I'm working on now much easier. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: mvcfigure1.gif Type: image/gif Size: 4201 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000619/87a9708a/mvcfigure1.gif From deanne at density.biop.umich.edu Mon Jun 19 22:36:09 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] Legion, etc. In-Reply-To: Message-ID: Has anyone mentioned the "Legion project"? I can't remember if anyone said anything about this, but here's the URL if not... http://legion.virginia.edu/introduction.html Definitely not, say, GNOME or anything. Just an interesting read. Deanne Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor From deanne at density.biop.umich.edu Mon Jun 19 22:40:37 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] Greetings from hell. :) In-Reply-To: <392D1AE6.842E112F@geoserve.net> Message-ID: Peep is still not doing anything. i won't blame anyone if they grab it and do something with it, because I'm not going to be able to put any serious dev time into it for, oh, about 2 more weeks. I've been handed the reins of a project that essentially puts me in charge of the education of over 200 girls under the age of 17 at a three-week computer + science + engineering summer camp. While this is a big honor for me, it's one of those really twisted "honors"...I'm put in charge because I can get the work done, essentially, and nobody else seems capable or willing. Bleagh. Deanne http://www-personal.engin.umich.edu/~wisesp/excite/ I'm working on "Tuesday's curriculum". For tomorrow. D From bizzaro at geoserve.net Tue Jun 20 01:07:27 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: Message-ID: <394EFC0F.C28ACF02@geoserve.net> Brad Chapman wrote: > > Yup, you've already got addInput, addOutput, removeInput, removeOutput to > call (althought I still need to implement 'em, but that's coming soon...). Great. > So basically what we've got a corba idl for now is the controller, > which allows the user interface to manipulate the Model (the xml in the > definition layer). What Jeff is talking about (I think) is implementing the > View part, so that the definition layer can automatically update the user > interface when something exciting happens in the XML. Right! The UI needs to keep an ear tuned to the DL so that the SYSTEM (rather than the user) can directly affect the "view". AND, since the UI also needs confirmation of the validity of the requests, it seems to me that ALL of the "exciting" things happening in the UI should come from the DL. I don't think that the user should have DIRECT control over anything in the UI except for opening windowlets (Pied), listing the contents of a network (Peep), and the like. > Using this model, the > user would only be able to do cosmetic things with the user interface (move > stuff around, open and close windowlets) and then would call the Controller > (the idl we have now) when it wants to do something more exciting, like > connect or add nodes, the Changes are made by the Model updating the View. Zactly :-) > Does this make sense with what you were thinking about, Jeff? I think we're talking about the same thing. > Make > sense to anyone else? If so, I can start working on setting things up to > work like this. It would make a lot of sense, and would help make the > loading of Overflow xml files into Piper I'm working on now much easier. How so? How are you planning on making Piper "load" Overflow XML? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 01:10:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] Greetings from hell. :) References: Message-ID: <394EFCBE.1C13CEA9@geoserve.net> deanne@density.biop.umich.edu wrote: > > Peep is still not doing anything. i won't blame anyone if they grab it and > do something with it, because I'm not going to be able to put any serious > dev time into it for, oh, about 2 more weeks. I've been handed the reins > of a project that essentially puts me in charge of the education of over > 200 girls under the age of 17 at a three-week computer + science + > engineering summer camp. Great! Maybe for a project, they can work on Peep ;-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue Jun 20 01:11:35 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: Message-ID: <394EFD07.90684E09@hermes.usherb.ca> > > About DL support: We'll need commands like "create_link" and "destroy_link" > > ("link" is Overflow terminology, which we should use, and a "pipe" is a type > > of link). > > Yup, you've already got addInput, addOutput, removeInput, removeOutput to > call (althought I still need to implement 'em, but that's coming soon...). Are you refering to the addInput and addOutput methods defined in Node.h? If so, I don't think removeInput/removeOutput doesn't make much sense... or maybe we aren't talking about the same thing (which is likely) Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Tue Jun 20 04:46:15 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs Message-ID: <200006200846.EAA122184@archa12.cc.uga.edu> I wrote: >> Make >> sense to anyone else? If so, I can start working on setting things up to >> work like this. It would make a lot of sense, and would help make the >> loading of Overflow xml files into Piper I'm working on now much easier. Jeff wrote: > How so? How are you planning on making Piper "load" Overflow XML? Well, we need to have some kind of support for being able to save the state of a Piper program, and then retrieve it later, and the way I was planning on doing this was using the XML format that Overflow uses for it's '.n' files. As I mentioned, Piper can produce this format right now, so now I just need to learn to read it. This will also allow Jean-Marc to be able to re-use all his current stuff from Overflow, which is very important. I'm not really positive yet how the best way to read the format will be (I'll either wrap the Overflow classes that already do this, or just get the information from the file myself). But either way, I was then planning on converting this into the "build time" xml format (which is lots of XML files--one for each node). I just finished doing the stuff necessary to make it possible to load information from this xml format into the user interface (see the latest cvs for this), but this will definately change some when we add the "View" part, since then I can manipulate the UI directly, instead of the weird way I'm doing it now. Anyways, this is my plan. Hopefully I made some sense :-). Brad From chapmanb at arches.uga.edu Tue Jun 20 04:50:47 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs Message-ID: <200006200850.EAA90152@archa10.cc.uga.edu> I wrote: >> Yup, you've already got addInput, addOutput, removeInput, removeOutput to >> call (althought I still need to implement 'em, but that's coming soon...). Jean-Marc wrote: > Are you refering to the addInput and addOutput methods defined in Node.h? If > so, > I don't think removeInput/removeOutput doesn't make much sense... or maybe we > aren't talking about the same thing (which is likely) Yup, we're not talking about the same thing :-). The functions I was talking about are defined in the idl file describing communication between the user interface and the dl, and all of this has to do with manipulating the definition layer/build time xml and not the run time stuff. All of the inputs and outputs should be firmly in place by the time the info gets to the BL and PL (hopefully :-). Brad From bizzaro at geoserve.net Tue Jun 20 08:23:40 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: <200006200846.EAA122184@archa12.cc.uga.edu> Message-ID: <394F624C.F54B11BF@geoserve.net> Brad Chapman wrote: > > Well, we need to have some kind of support for being able to save the > state of a Piper program, and then retrieve it later, and the way I > was planning on doing this was using the XML format that Overflow uses > for it's '.n' files. As I mentioned, Piper can produce this format > right now, so now I just need to learn to read it. This will also > allow Jean-Marc to be able to re-use all his current stuff from > Overflow, which is very important. > I'm not really positive yet how the best way to read the format > will be (I'll either wrap the Overflow classes that already do this, > or just get the information from the file myself). But either way, I > was then planning on converting this into the "build time" xml format > (which is lots of XML files--one for each node). I just finished doing > the stuff necessary to make it possible to load information from this > xml format into the user interface (see the latest cvs for this), but > this will definately change some when we add the "View" part, since > then I can manipulate the UI directly, instead of the weird way I'm > doing it now. > Anyways, this is my plan. Hopefully I made some sense :-). So, let me get this straight. At this point, we have the ability to imbed PL (Overflow) XML (.n) into the XML describing a BL (world-wide) network? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 08:27:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] NetInputs and NetOutputs References: <200006200850.EAA90152@archa10.cc.uga.edu> Message-ID: <394F633F.3030505A@geoserve.net> Brad Chapman wrote: > > Yup, we're not talking about the same thing :-). > The functions I was talking about are defined in the idl file > describing communication between the user interface and the dl, and > all of this has to do with manipulating the definition layer/build > time xml and not the run time stuff. All of the inputs and outputs > should be firmly in place by the time the info gets to the BL and PL > (hopefully :-). This makes sense, because there is no need to "remove" a link during run-time. Right? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 08:53:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] KParts/Bonobo Merger Considered Message-ID: <394F693E.6B9950DD@geoserve.net> "Today was the most exciting day for me that I've had in a long long time. This is big news, relevent stuff, and if the plan goes through, it will change the world of KDE and Gnome forever. The plan is to either use Bonobo in KDE if it is sufficient, or for the developers of KParts and Bonobo to work together to create a new replacement that will be used by both desktop environments. There's no guarantee of success, however, and we need your support to help push this matter along. Here follows the complete story:" http://rivyn.derkarl.org/news/html/newsflash-17june2000.html Sounds hopeful. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 10:07:11 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] icons Message-ID: <394F7A8F.F0344377@geoserve.net> I'd like to make a list of the VERY BASIC node types in Piper so that we can make (or have made by dLoo's artist) some icons for Pied (and any other UI that can make use of icons). Off-hand, I'll list some BL nodes: (* means that the node can have its type changed (icon changed) by the USER and that the change does not reflect a change in basic functionality.) BL Network/Subnet* PL Network/Subnet:* - Processor: Generic* - Processor: Filter/Format Converter* - Viewer: Generic* - Viewer: SVG* Document: - Empty - Filled Container: - Database - Filesystem <-- I know what you're thinking, Brad Unknown Jean-Marc and Brad, could you list the basic Overflow nodes not listed above? Interator Decision? ? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 10:23:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <394F7A8F.F0344377@geoserve.net> Message-ID: <394F7E6B.80E0F2D1@geoserve.net> "J.W. Bizzaro" wrote: > > BL Network/Subnet* > PL Network/Subnet:* > - Processor: Generic* > - Processor: Filter/Format Converter* > - Viewer: Generic* > - Viewer: SVG* > Document: > - Empty > - Filled > Container: > - Database > - Filesystem <-- I know what you're thinking, Brad > Unknown I was just thinking about how this is laid out, and I don't think we've ever discussed (or reached a conclusion about) a very basic aspect of the BL-PL relationship, as represented in both BT and RT subsystems. Question: Exactly WHAT can a /BL/ network/subnet contain? A. Only BL subnets and PL networks B. Option A plus a couple nodes such as documents and containers (as in the icon list) C. Anything If we let Overflow handle LOCAL connectivity with EVERYTHING, then we choose option A. But, Jarl will argue that GMS can do more than just talk to Overflow. Do we NEED the BL to talk to a node other than Overflow??? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 10:36:50 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:10 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> Message-ID: <394F8182.2C5DFF8E@geoserve.net> "J.W. Bizzaro" wrote: > > But, Jarl will argue that GMS can do more than just talk to Overflow. Do we > NEED the BL to talk to a node other than Overflow??? ........other than Overflow and a remote instance of another BL. Let's think about how a "document" or "database" is implemented in Piper. Can/should these be implemented by Overflow? If they are implemented by GMS, is there a duplication of functionality that would lead to confusion for the user? Actually, I vote for option A in the first e-mail. I think it would be simplest for us and for the user. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Tue Jun 20 10:37:13 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] NetInputs and NetOutputs Message-ID: <200006201437.KAA99472@archa12.cc.uga.edu> Jeff wrote: > So, let me get this straight. At this point, we have the ability to imbed PL > (Overflow) XML (.n) into the XML describing a BL (world-wide) network? Okay, I only sort of know what you are talking about here :-). To the best of my knowledge the development plan right now is to focus on local nodes, so that Piper will end up being kind of a clone of Overflow functionality, with the added features to expand to include all of the other ideas we want to incorporate. So, since this is the initial goal, the plan was to have the document that will be submitted to the BL just be the Overflow XML ('.n') files. So the role of the BL is very simple right now, just talk with the DL, pass the XML file on to the PL, and then collect the information that it spits out. So there really is no "BL XML" yet, and I guess the role of the BL will expand slowly as Jarl is ready for it, and as things progress. My initial goal is to make Piper compatible with Overflow, so that Jean-Marc can switch to using Piper exclusively (if he likes it :-) for his work. This will give us a good base functionality, since Overflow already does a lot of cool stuff, and then will give us something to expand off of. Does this answer your question? If not, I'm not sure what your question was :-). Brad From chapmanb at arches.uga.edu Tue Jun 20 10:49:43 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons Message-ID: <200006201449.KAA150070@archa10.cc.uga.edu> Jeff wrote: > I'd like to make a list of the VERY BASIC node types in Piper so that we can > make (or have made by dLoo's artist) some icons for Pied (and any other UI > that can make use of icons). [...Jeff lists a bunch of nodes from Loci he wants to keep...] > Jean-Marc and Brad, could you list the basic Overflow nodes not listed above? > > Interator > Decision? > ? Jeff, there are a whole ton of them, especially if you start including the speech/sound processing stuff that Jean-Marc is using. To get a full list, fire up a recent Overflow and look pop-up menu for 'new-node's you can add. Since there are so many, I don't really think it would be very feasible or productive to start thinking about icons for all these right now, especially since we need a lot of pure functionality (like all the stuff you talked about yesterday :-) out of the GUI. Can we put off having a million icons for a while and just stick with a default for most stuff? I know it's not the prettiest, but I personally would rather focus on getting this thing off the ground. What do you think? Brad From jean-marc.valin at hermes.usherb.ca Tue Jun 20 11:04:32 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <200006201449.KAA150070@archa10.cc.uga.edu> Message-ID: <394F8800.D60E3E73@hermes.usherb.ca> > > Jean-Marc and Brad, could you list the basic Overflow nodes not > listed above? > > > > Interator > > Decision? > > ? > > Jeff, there are a whole ton of them, especially if you start including > the speech/sound processing stuff that Jean-Marc is using. To get a > full list, fire up a recent Overflow and look pop-up menu for > 'new-node's you can add. Since there are so many, I don't really think > it would be very feasible or productive to start thinking about icons > for all these right now, especially since we need a lot of pure > functionality (like all the stuff you talked about yesterday :-) out > of the GUI. > Can we put off having a million icons for a while and just stick > with a default for most stuff? I know it's not the prettiest, but I > personally would rather focus on getting this thing off the ground. > What do you think? As Brad is saying, there are currently 120 implemented node types, so doing an icon for each is not feasable in short-term. What could be done is having an icon for some of the most common nodes (Add, Bub, Mul, AND, OR, Constant, Load, Save, ...) and then we can have "category" icons like "DSP", "neural nets", "Vector quantization", ... There are about 15 categories. Also, when building a subnet, we should have the option to assign an icon to it. I'd like the whole thing to look a bit like Simulink. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Tue Jun 20 21:46:15 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] a /BL/ network/subnet References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> Message-ID: <39501E67.698C5D72@casema.net> > Exactly WHAT can a /BL/ network/subnet contain? > > A. Only BL subnets and PL networks > > B. Option A plus a couple nodes such as documents and > containers (as in the icon list) > > C. Anything > > If we let Overflow handle LOCAL connectivity with EVERYTHING, then we choose > option A. Yep, A. But.. GMS has the ability to wrap non textmode applications. It's done by having a specialisted plug-in for an application you want to embed. And it has the ability to let graphical applications dock into a gms window. I never brought this to attension I think, but it's already fully functional. I'll write a plugin 'around' the PL, do one for BL->BL communication, one for data-encryption, etc, etc. I can disable appications wrapping in Piper-mode to keep everybody happy :) > > > But, Jarl will argue that GMS can do more than just talk to Overflow. Do we > NEED the BL to talk to a node other than Overflow??? To another instance of a BL, to\from the localhost to determine the system load to name a few. From jarl at casema.net Tue Jun 20 21:47:45 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <394F8182.2C5DFF8E@geoserve.net> Message-ID: <39501EC1.59544532@casema.net> > > Actually, I vote for option A in the first e-mail. I think it would be > simplest for us and for the user. I would be very happy when a non-techy user wont ever notices there's a BL :) From bizzaro at geoserve.net Tue Jun 20 19:46:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <200006201449.KAA150070@archa10.cc.uga.edu> <394F8800.D60E3E73@hermes.usherb.ca> Message-ID: <39500269.6CF9D1AC@geoserve.net> Jean-Marc Valin wrote: > > As Brad is saying, there are currently 120 implemented node types, so doing an > icon for each is not feasable in short-term. What could be done is having an > icon for some of the most common nodes (Add, Bub, Mul, AND, OR, Constant, Load, > Save, ...) and then we can have "category" icons like "DSP", "neural nets", > "Vector quantization", ... There are about 15 categories. This is what I meant. I'm aware that there are 100's of actual nodes and many more to come. What I meant by "types" is "categories", classes, etc. 15 or so may be doable. > Also, when building a > subnet, we should have the option to assign an icon to it. Right. Since a subnet can be made to do anything, subnet icons should be changable. > I'd like the whole thing to look a bit like Simulink. I'm not sure I've heard of Simulink. Do you have a URL? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 19:53:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <200006201449.KAA150070@archa10.cc.uga.edu> Message-ID: <395003EC.7A0B5C8@geoserve.net> Brad Chapman wrote: > > Since there are so many, I don't really think > it would be very feasible or productive to start thinking about icons > for all these right now, especially since we need a lot of pure > functionality (like all the stuff you talked about yesterday :-) out > of the GUI. > Can we put off having a million icons for a while and just stick > with a default for most stuff? I know it's not the prettiest, but I > personally would rather focus on getting this thing off the ground. > What do you think? Sir, yes sir! ;-) I know you don't like it when I say "dLoo will do it", but, actually, Nile offered to have his graphic artist (Alex) work on this for us. If we come up with a list of major node "categories", and discuss it a little with Alex, we should get something nice without ever having to start up GIMP. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue Jun 20 19:55:26 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <200006201449.KAA150070@archa10.cc.uga.edu> <394F8800.D60E3E73@hermes.usherb.ca> <39500269.6CF9D1AC@geoserve.net> Message-ID: <3950046E.B5468D89@hermes.usherb.ca> > This is what I meant. I'm aware that there are 100's of actual nodes and many > more to come. What I meant by "types" is "categories", classes, etc. 15 or > so may be doable. Then we agree. We should still have the ability to override category icons for nodes that have an icon... Or simply specify an icon for every nodes, though many can point to the same icon. I prefer the secondoption. > > > Also, when building a > > subnet, we should have the option to assign an icon to it. > > Right. Since a subnet can be made to do anything, subnet icons should be > changable. Actually, the user shouldn't even be able to tell the difference between a subnet and a builtin node. > > > I'd like the whole thing to look a bit like Simulink. > > I'm not sure I've heard of Simulink. Do you have a URL? It's a Matlab toolbox that uses connected blocks to simulate systems http://www.mathworks.com/products/simulink/ -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Tue Jun 20 21:17:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <200006201449.KAA150070@archa10.cc.uga.edu> <394F8800.D60E3E73@hermes.usherb.ca> <39500269.6CF9D1AC@geoserve.net> <3950046E.B5468D89@hermes.usherb.ca> Message-ID: <395017BA.CCA25F3A@geoserve.net> Jean-Marc Valin wrote: > > Then we agree. We should still have the ability to override category icons for > nodes that have an icon... Or simply specify an icon for every nodes, though > many can point to the same icon. I prefer the secondoption. I do too. Then every node can have its icon changed. Actually, something I haven't mentioned is that, with Gnome-compatibility and DnD, a lot of icons will come from Gnome itself. > Actually, the user shouldn't even be able to tell the difference between a > subnet and a builtin node. Correct. I want every node to look (except for the specific icon used) and act alike. > It's a Matlab toolbox that uses connected blocks to simulate systems > > http://www.mathworks.com/products/simulink/ It looks like a cross between Overflow and a circuit diagram editor. It's nice: simple and legible. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 20 21:21:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] a /BL/ network/subnet References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <39501E67.698C5D72@casema.net> Message-ID: <395018AC.290110F8@geoserve.net> jarl van katwijk wrote: > > Yep, A. But.. > > GMS has the ability to wrap non textmode applications. It's done by having a > specialisted plug-in for an application you want to embed. And it has the > ability to let graphical applications dock into a gms window. I never brought > this to attension I think, but it's already fully functional. I'll write a > plugin 'around' the PL, do one for BL->BL communication, one for > data-encryption, etc, etc. > I can disable appications wrapping in Piper-mode to keep everybody happy :) If it isn't needed, perhaps it should be disabled......but maybe we'll find a use for it later. I'm happy with your code, either way, Jarl ;-) > > But, Jarl will argue that GMS can do more than just talk to Overflow. Do we > > NEED the BL to talk to a node other than Overflow??? > > To another instance of a BL, to\from the localhost to determine the system load > to name a few. ....but not anything that would be represented as a node in the UI, right? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue Jun 20 22:33:03 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <200006201449.KAA150070@archa10.cc.uga.edu> <394F8800.D60E3E73@hermes.usherb.ca> <39500269.6CF9D1AC@geoserve.net> <3950046E.B5468D89@hermes.usherb.ca> <395017BA.CCA25F3A@geoserve.net> Message-ID: <3950295F.2E0EB413@hermes.usherb.ca> > It looks like a cross between Overflow and a circuit diagram editor. It's > nice: simple and legible. Do you think we could build something that looks like it? I think it's the best-looking of the options. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Wed Jun 21 11:22:39 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] a /BL/ network/subnet References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <39501E67.698C5D72@casema.net> <395018AC.290110F8@geoserve.net> Message-ID: <3950DDBF.1E7CDF72@casema.net> > If it isn't needed, perhaps it should be disabled......but maybe we'll find a > use for it later. I'm happy with your code, either way, Jarl ;-) > hehehe :) > > > > But, Jarl will argue that GMS can do more than just talk to Overflow. Do we > > > NEED the BL to talk to a node other than Overflow??? > > > > To another instance of a BL, to\from the localhost to determine the system load > > to name a few. > > ....but not anything that would be represented as a node in the UI, right? > Correct. Last monday I started on a new project http://www.zed.com, which has much similarities with gms. Big diff. is this is a system that's about to go into production. bye, jarl From bizzaro at geoserve.net Wed Jun 21 08:23:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] a /BL/ network/subnet References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <39501E67.698C5D72@casema.net> <395018AC.290110F8@geoserve.net> <3950DDBF.1E7CDF72@casema.net> Message-ID: <3950B3DA.C7215BC3@geoserve.net> jarl van katwijk wrote: > > Last monday I started on a new project http://www.zed.com, which has much > similarities with gms. Big diff. is this is a system that's about to go into > production. Are you employed by Zed? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Wed Jun 21 20:11:09 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] a /BL/ network/subnet References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <39501E67.698C5D72@casema.net> <395018AC.290110F8@geoserve.net> <3950DDBF.1E7CDF72@casema.net> <3950B3DA.C7215BC3@geoserve.net> Message-ID: <3951599D.7491C935@casema.net> > > > > Last monday I started on a new project http://www.zed.com, which has much > > similarities with gms. Big diff. is this is a system that's about to go into > > production. > > Are you employed by Zed? No, they hired me for a few months to get their system up and running. I'll be in Helsinki finland this weekend, to visit their development site. They've used Portal's Infranet system as a basis for Zed. Infranet is a very simplistic piece of software compared to Piper :) Bye, jarl From jeff at alpha.bioinformatics.org Wed Jun 21 11:02:30 2000 From: jeff at alpha.bioinformatics.org (jeff@alpha.bioinformatics.org) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] this is what's wrong with the world Message-ID: <200006211502.KAA07879@alpha.bioinformatics.org> "The company said it has held a patent for linking online documents since 1976." http://news.cnet.com/news/0-1005-200-2115385.html Jeff From bizzaro at geoserve.net Thu Jun 22 09:33:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question Message-ID: <395215B3.9B77F0A@geoserve.net> Question: Is Overflow (PL) going to communicate with the BL through InputStream and OutputStream? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Jun 22 09:44:04 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <394F7A8F.F0344377@geoserve.net> Message-ID: <39521824.2FA350C5@geoserve.net> Here are 9 Overflow (PL) categories which probably should get icons. Jean-Marc, you said 15. What is missing? Network/Subnet Interator Logic Flow General IO Probe Math Signal Here are some additional icons that may be used to replace the Network/Subnet icon: Generic Processor Filter/Format Converter Generic Viewer Empty Document Filled Document Database Filesystem Unknown Feel free to send comments or add and remove icons from this list. 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 Jun 22 11:28:53 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question References: <395215B3.9B77F0A@geoserve.net> Message-ID: <395230B5.72F69E7E@hermes.usherb.ca> > Is Overflow (PL) going to communicate with the BL through InputStream and > OutputStream? If could, but it doesn't have to. Let me explain what those are. An InputStream node takes a string (generally a file name) as input, opens it and returns a C++ ifstream that can be used by other nodes to read info. The same for OutputStream. I think the best way to communicate is simply via function calls: the BL calls Overflow functions and get the result. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jean-marc.valin at hermes.usherb.ca Thu Jun 22 11:32:30 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] icons References: <394F7A8F.F0344377@geoserve.net> <39521824.2FA350C5@geoserve.net> Message-ID: <3952318E.6D562C20@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > Here are 9 Overflow (PL) categories which probably should get icons. > Jean-Marc, you said 15. What is missing? > > Network/Subnet > Interator > Logic > Flow > General > IO > Probe > Math > Signal VQ (vector quantization) NNet (neural networks) plus, Signal is divided in Base, DSP, Audio, Manip, Misc and IO (this will be reorganized) Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Thu Jun 22 21:56:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question References: <395215B3.9B77F0A@geoserve.net> <395230B5.72F69E7E@hermes.usherb.ca> Message-ID: <3952C3B1.F299619B@casema.net> Jean-Marc Valin wrote: > > Is Overflow (PL) going to communicate with the BL through InputStream and > > OutputStream? > > If could, but it doesn't have to. Let me explain what those are. An InputStream > node takes a string (generally a file name) as input, opens it and returns a C++ > ifstream that can be used by other nodes to read info. The same for > OutputStream. I think the best way to communicate is simply via function calls: > the BL calls Overflow functions and get the result. The PL will notify the BL once the data is ready I hope :) The way I see it the InputStream and OutputStream remain INSIDE the PL untill the network has ended execution OR the next PLnode is not at localhost. bye, jarl From jean-marc.valin at hermes.usherb.ca Thu Jun 22 13:11:54 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question References: <395215B3.9B77F0A@geoserve.net> <395230B5.72F69E7E@hermes.usherb.ca> <3952C3B1.F299619B@casema.net> Message-ID: <395248DA.3DD0626C@hermes.usherb.ca> jarl van katwijk a ?crit : > > Jean-Marc Valin wrote: > > > > Is Overflow (PL) going to communicate with the BL through InputStream and > > > OutputStream? > > > > If could, but it doesn't have to. Let me explain what those are. An InputStream > > node takes a string (generally a file name) as input, opens it and returns a C++ > > ifstream that can be used by other nodes to read info. The same for > > OutputStream. I think the best way to communicate is simply via function calls: > > the BL calls Overflow functions and get the result. > > The PL will notify the BL once the data is ready I hope :) > > The way I see it the InputStream and OutputStream remain INSIDE the PL untill the > network has ended execution OR the next PLnode is not at localhost. I think you don't understand what InputStream is. It's nothing more the the "Open" call. It returns an ifstream, which is the C++ equivalent of a (FILE *). Here's how I think it should work: the BL calls teh getOutput(...) method on the last node(s) of the PL network and the result is returned in the return value of the call. Because Overflow works by "pulling" in data, the getOutput call won't return until everything is done. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Thu Jun 22 22:32:55 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question References: <395215B3.9B77F0A@geoserve.net> <395230B5.72F69E7E@hermes.usherb.ca> <3952C3B1.F299619B@casema.net> <395248DA.3DD0626C@hermes.usherb.ca> Message-ID: <3952CC57.B6E5BAA8@casema.net> > > I think you don't understand what InputStream is. It's nothing more the the > "Open" call. It returns an ifstream, which is the C++ equivalent of a (FILE *). > > Here's how I think it should work: the BL calls teh getOutput(...) method on the > last node(s) of the PL network and the result is returned in the return value of > the call. Because Overflow works by "pulling" in data, the getOutput call won't > return until everything is done. > ic. Why does Overflow use pulling? Nodes pushing data into the next seems more logical to me at first. From jean-marc.valin at hermes.usherb.ca Thu Jun 22 13:47:10 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question References: <395215B3.9B77F0A@geoserve.net> <395230B5.72F69E7E@hermes.usherb.ca> <3952C3B1.F299619B@casema.net> <395248DA.3DD0626C@hermes.usherb.ca> <3952CC57.B6E5BAA8@casema.net> Message-ID: <3952511E.77ABE35F@hermes.usherb.ca> > ic. Why does Overflow use pulling? Nodes pushing data into the next seems more logical > to me at first. One word: dependencies. Here's an audio processing example: we normally divide audio in frames of 100-500 samples. Each frame is treated separatly, but (very) often, a node (eg. filters) needs to look at previous frames and (even) next frames (non-causal filters). Using a pull, every node tells its inputs (by calling getOutput) what data it needs in order to compute its result. Values that aren't used aren't computed. Also, there is a buffering system that keeps the last N computed results. The number N is determined at initialization using the dependencies of each node. This system can only be implemented using a pull. The whole system makes sure that we only use the minimum amount of memory. BTW, the user shouldn't be able to tell whether we're using a pull or a push. It's just that the pull is so much cleaner and easier to implement for more complex processing. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Thu Jun 22 15:48:12 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:11 2006 Subject: [Pipet Devel] overflow question Message-ID: <200006221948.PAA61124@archa12.cc.uga.edu> Jarl wrote: > ic. Why does Overflow use pulling? Nodes pushing data into the next seems > more logical > to me at first. Jean-Marc wrote: > It's just that the pull is so much cleaner and easier to implement for more > complex processing. Jarl, I was thinking the same way as you when I first starting thinking about the pull stuff. I am probably simple minded, but the first way I think to move through a data structure or anything is from the front, using a push type system like you are describing, ie. 1. Calculate some data. 2. Pass the data on to the outputs. 3. Repeat until there are no more outputs to push the data on to. 4. Collect the results from the final outputs However, I've been using the pull type system for stuff in the dl, and it is really clean and easy to use, as Jean-Marc mentioned. Using the pull scheme really falls naturally into some very nice recursion ie. (example in python, sorry!): def __main__(): the_nodes_that_need_results calculate_data(the_nodes_that_need_results) def calculate_data(node_to_calculate): all_input_data = list(()) for input_node in node_to_calculate.all_input_nodes: input_data = calculate_data(input_node) all_input_data.append(input_data) return node_to_calculate.do_calculation(all_input_data) It took me a while to get into this, since I'm slow in the head, but I really like this way of doing things. It makes traversing a big old crazy graph structure really easy. Just my 2 cents. Thanks for writing on this. Brad From jarl at casema.net Fri Jun 23 01:04:48 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] overflow question References: <200006221948.PAA61124@archa12.cc.uga.edu> Message-ID: <3952EFF0.28056ABE@casema.net> > > However, I've been using the pull type system for stuff in the dl, and > it is really clean and easy to use, as Jean-Marc mentioned. Using the > pull scheme really falls naturally into some very nice recursion ie. > > It took me a while to get into this, since I'm slow in the head, but I > really like this way of doing things. It makes traversing a big old > crazy graph structure really easy. It's very simple and the result is very nice indeed. People who know the term autopioesis will know why. I'll have a look how (and when) to have to BL use this methode too. bye, jarl From jean-marc.valin at hermes.usherb.ca Fri Jun 23 01:30:17 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] Overflow and real-time audio processing Message-ID: <3952F5E9.414BB894@hermes.usherb.ca> Hello all, I just thought this might be interesting to some of you, as a demo of what Overflow can do. I just "wrote" an Overflow program (.n) that performs real-time audio processing. It reads the soundcard input, normalized the volume (lowers louder sounds, amplifies lower sounds), and sends the result back to the soundcard output. It takes less than 5% CPU on my Athlon 500 at 44.1kHz/stereo (I use chunks of ~10 ms). Note, you need a full-duplex soundcard and the latest version in CVS to try it. Any electric guitar player here would like to help me write distortions and other effects? Comments are welcome. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca -------------- next part -------------- From bizzaro at geoserve.net Fri Jun 23 13:14:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] micro$oft.NET Message-ID: <39539AFA.4F559BDC@geoserve.net> It looks like we may be competing against Micro$haft now: "These problems are multiplied if you use more than one PC or mobile device. To access your online information, e-mail, offline files and other data, you have to struggle with multiple (and often incompatible) interfaces, varying levels of data access, and only intermittent synchronization of all the information you need (i.e., when you physically link your device with your PC). Online data is presented in an incomplete and predefined format, greatly limiting its usefulness. The concept of a customized "personal information space" that adapts to your needs is still a dream." [...] "For developers, Microsoft is creating an entirely new set of Microsoft .NET development tools, designed from the ground up for the Web, and spanning client, server and services. These tools will enable developers to transform the Web from today's static presentation of information into a Web of rich interactive services. Microsoft's breakthrough next-generation Visual Studio tool suite automates development of Web Services via the drag-and-drop rapid-application development paradigm pioneered by the Visual Basic? development system -- services that can be consumed on any platform that understands XML. Visual Studio even automatically generates XML code." [...] "The Microsoft .NET programming model gives independent developers the opportunity to focus fewer resources on where or how an application runs and more on what it does -- on where they can add real value. Microsoft .NET addresses some of the biggest challenges facing developers, who today are wrestling with the tradeoff between functionality and manageability. It takes ASPs and application hosting to a new level, enabling the integration of hosted applications with other applications, whether hosted or not; the customization of those applications; the ability to program against those applications; and the option to run the applications offline." http://www.microsoft.com/presspass/topics/f2k/whitepaper/default.asp What do you think? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri Jun 23 14:43:10 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] micro$oft.NET In-Reply-To: <39539AFA.4F559BDC@geoserve.net> Message-ID: Jeff wrote: > It looks like we may be competing against Micro$haft now: [...snip..Microsoft stealing our ideas...] > What do you think? 1. I think we should have patented our ideas :-). 2. I wish that I knew someone in Microsoft working on their project so we could share code and ideas (not that would actually happen, but I can dream). 3. I think that Bill Gates and other big Microsoft execs should take some of their billions of dollars, rent a helicopter and then airdrop big bundles of money over poverty ridden ghettos. 4. I think this is a very positive sign that we are on the right track with Piper (and integrating with BlueBox), and is a good justification of the ideas here. Hey, imitation is the sincerest form of flattery, right? Brad From chapmanb at arches.uga.edu Fri Jun 23 14:55:16 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] Overflow and real-time audio processing Message-ID: Jean-Marc wrote: > I just thought this might be interesting to some of you, as a demo of > what Overflow can do. I just "wrote" an Overflow program (.n) that > performs real-time audio processing. > It reads the soundcard input, normalized the volume (lowers > louder sounds, amplifies lower sounds), and sends the result back to the > soundcard output. It takes less than 5% CPU on my Athlon 500 at > 44.1kHz/stereo (I use chunks of ~10 ms). > Note, you need a full-duplex soundcard and the latest > version in CVS to try it. Jean-Marc, this sounds very cool and I would like to try it out, although I will admit to having a soundcard sitting in my machine which is not even set up to work (the annoying beeps my FreeBSD machine makes have always been musical enough for me, I guess :-). Do you have any pointers to good places to go to learn about setting up soundcards and just read about sound stuff on UN*X machines in general? I will look for FreeBSD specific info and try to get this working, but I should probably learn the very basics first (hey, I'm not afraid to admit to being clueless :-). Thanks for posting this stuff, tho. Overflow is very nice, and hopefully in a little while you will be able to post about doing all of this stuff in Piper :-) Brad From bizzaro at geoserve.net Fri Jun 23 15:24:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] micro$oft.NET References: Message-ID: <3953B963.6DCC683B@geoserve.net> Brad Chapman wrote: > > 1. I think we should have patented our ideas :-). The problem is Micro$oft patenting our ideas :-/ > 2. I wish that I knew someone in Microsoft working on their project so we > could share code and ideas (not that would actually happen, but I can > dream). Jeez, and you were hesitant about working with dLoo?! > 3. I think that Bill Gates and other big Microsoft execs should take > some of their billions of dollars, rent a helicopter and then airdrop > big bundles of money over poverty ridden ghettos. Yeah. > 4. I think this is a very positive sign that we are on the right track > with Piper (and integrating with BlueBox), and is a good justification of > the ideas here. Hey, imitation is the sincerest form of flattery, right? I'm gald you see it that way. I hope too that now Free Software developers will understand Piper better and see why it is urgent that they collaborate with us. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 16:08:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> Message-ID: <3953C3A9.5A2AD889@geoserve.net> "J.W. Bizzaro" wrote: > > Question: > > Exactly WHAT can a /BL/ network/subnet contain? > > A. Only BL subnets and PL networks > > B. Option A plus a couple nodes such as documents and > containers (as in the icon list) > > C. Anything >From the few comments I got back, it looks like Option A is what we should go with. IOW, BL and PL subnets are the only user-seen components that the BL manages directly. Option A might mean that we have 2 workspaces (networks): 1 BL workspace and 1 PL workspace, where PL workspaces are always contained within BL workspaces. This is what I thought we should have at first, but after thinking about it for some time now, I think we can have something even better. I'll call it "Option A1": Like Option A, Option A1 makes the BL responsible for only BL and PL subnets. But, let's do something magical: Let's make BL subnets INVISIBLE to the user! Imagine using Pied with 2 types of workspaces (Option A above). You start off with a /BL/ workspace where you can add a node representing another BL workspace, or a node representing a PL workspace. Say, for example, you add a node representing a PL workspace. You open the windowlet, and there you pretty much have Overflow (at some remote location) to work with. But, how do you connect 2 PL workspaces together? It can only be done by connecting the nodes that represent the PL workspaces, not from WITHIN the PL workspace. Now, let's say we merge the 2 workspaces (or make the BL workspace transparent to the user). You start up Pied/Piper, and you essentially have a /PL/ (Overflow) workspace. This is on your local host. You start connecting all sorts of PL nodes together and then decide, "Hey, it'd be nice if I could connect to a PL node on Brad's computer". So, you subscribe to Brad's computer, find the node (or subnet) you want and place it on your /PL/ workspace. Everything looks like Overflow operating locally, but Piper knows where everything really resides. Implementation shouldn't be difficult at all, since we are abstracting the Build-Time Subsystem (even abstracting "View" and "Model" within the BTS) and Run-Time Subsystem. The user may think all nodes and subnets are local, but Piper knows otherwise. Comments? This may be how some people envisioned Piper to begin with, but in my mind, there were some competing models (options A, A1, B and C), and I wasn't quite sure which would be best. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 18:22:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] icons References: <394F7A8F.F0344377@geoserve.net> <39521824.2FA350C5@geoserve.net> <3952318E.6D562C20@hermes.usherb.ca> Message-ID: <3953E327.62680A7@geoserve.net> The saga continues. Below are 17 icons we should probably have made for Pied/Piper. We need to give some idea as to what each icon should look like. Feel free to provide a descriptions where needed. Jean-Marc, about categorization, do you think we could put some of the more special-purpose nodes (like VQ and NNet) in a "Misc" category? (I'm going with a "water" theme here) 1. Network/Subnet Tangled pipes 2. Processor A waterwheel 3. Format Converter 2 pipes, different colors, connected in the middle, but bending to point in opposite directions (left & right), forming an "S" shape 4. Viewer An aquarium? :-) 5. Empty Document An empty sink 6. Filled Document A sink full of water 7. Database & Filesystem barrel or metal drum 8. Iterator 3 pipes in circle, something like the "recycle" logo 9. Logic A water valve (like on a faucet) 10. Flow A drop of water 11. General/Misc/Unknown A monkey wrench 12. IO An open-ended pipe 13. Probe ? 14. Math Arithmatic symbols 15. VQ (vector quantization) ? 16. NNet (neural networks) ? 17. Signal Water waves There are also signal types, but do we really need separate icons for them right now? 18. Base 19. DSP 20. Audio 21. Manip 22. Misc 23. IO Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 18:38:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <3953C3A9.5A2AD889@geoserve.net> Message-ID: <3953E6D2.95C9E98C@geoserve.net> I'll reword the Option list: Exactly what does the BL connect to directly (that the user can see)? A. Only BL and PL nets A1. Option A, but BL nets are transparent B. Option A, plus a couple nodes such as documents and containers C. Anything I say we go for Option A1. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 20:05:41 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] announcements Message-ID: <3953FB55.1A75DFAF@geoserve.net> I think we should make some announcements about Piper now to get the attention of developers. I'd like to make general announcements about the project (not saying we have a release) on Gnotices and Freshmeat. What do you think? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri Jun 23 22:21:31 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) Message-ID: <200006240221.WAA139452@archa11.cc.uga.edu> Jeff wrote: * the revised options * > I'll reword the Option list: > > Exactly what does the BL connect to directly (that the user can see)? > > A. Only BL and PL nets > > A1. Option A, but BL nets are transparent > > B. Option A, plus a couple nodes such as documents and > containers > > C. Anything >From the few comments I got back, Jeff, I don't know if I am the only dumb one, but I haven't been commenting on this thread because I really don't understand what is going on :-). I understand what PL networks are because these are the networks that Overflow uses right now. The way I have been working with things is to make an Overflow network map directly onto the Loci "workspace" and dealing with things like this. What I don't understand is: 1. What exactly is a BL network? 2. How does a BL network differ from a PL network? Does it have to do with network location? 2a. If it has to do with network location, I am really confused about what is going on, because I thought the dl would be mostly responsible for remote communication. In the documentation for the definition layer (http://bioinformatics.org/piper/documentation/dl_info.pdf) I wrote up with diagrams about how I thought remote communication would work, and this doesn't involve the bl communicating remotely. I thought this was how we were working, but maybe not. Do people not like this? Is this thinking incorrect? Please let me know so I can not only change it, but modify my thinking as well. 3. Shouldn't the whole entire implementation system of Piper be invisibile to the user? I thought this was the point of separating out the build time and run time layers. Why should the user have to worry about whether they are adding a bl or pl network or whatever? 4. What is the point of the PL and BL, exactly, in other people's minds? I thought that the PL handled application wrapping and basic piping between internal nodes, and that the BL would handle "organizing the workflow diagram" into a fast model, and implementing cool genetic algorithms to think of ways to make connected nodes run faster. Am I totally off? Maybe someone could clarify what is going on here if I am :-) 5. Shouldn't dealing with the filesystem (like loading documents) or dealing with databases be done by the "build time system" and thus be handled by the definition layer? It seems like the run time system only cares about having data and manipulating it, and not having to deal with stuff like connecting to different databases, etc. 6. What are people's immmediate development goals for Piper? What I have been working towards is adding all of the functionality from Overflow into Piper, using the Piper framework. So when the system is done, we would have something with mostly Overflow functionality, but with the added advantage of one user interface, dealing with remote connections, having genetic algorithsm to improve running speed in the BL, etc. Does this BL/PL network stuff that you are talking about affect how I should be coding right now? If so, what should I be doing differently? Okay, I guess all of that is enough to show that I am thoroughly confused about what is going with this whole discussion :-). I apologize for being so dense about all of this... Brad From chapmanb at arches.uga.edu Fri Jun 23 22:34:30 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] announcements Message-ID: <200006240234.WAA146598@archa11.cc.uga.edu> > I think we should make some announcements about Piper now to get the > attention > of developers. I'd like to make general announcements about the project (not > saying we have a release) on Gnotices and Freshmeat. What do you think? Well, Jeff, I don't think I need to write to tell you what I think about making announcments without having code :-). Seriously, I think if you are really excited about making announcements we need one of two things: 1. Actual code that people can download and play with. 2. Detailed information about what someone could do to help with the project if they wanted to. A good example of this that I like is in Berlin (has anyone figured out that I like Berlin yet :-). They have nice development info (http://www.berlin-consortium.org/devel.html) and also task lists for people interested in helping in different ways (http://www2.berlin-consortium.org/wiki/html/Berlin/TaskList.htm). The reason I say this is just based on how I feel about looking at pages. No offense to dLoo, but when you asked us to look at their page the first time I looked at it, said to myself "neat ideas" and then promptly forgot about it. The problem is that anyone in the whole world can spend a lot of time making a nice web page with all of their ideas on it, but this doesn't really mean anything unless I think the ideas will really be implemented. And there are two ways I think the ideas will be implemented: 1. They've already done it. 2. They have projects people can work on, and a project sounds cool enough to me that I will work on it and help implement it. I just think the first time people take some time to look at Piper, they should be able to feel like they can do something other than just read about it. Just me 2 bits... Brad From bizzaro at geoserve.net Fri Jun 23 23:21:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <200006240221.WAA139452@archa11.cc.uga.edu> Message-ID: <3954294F.EE953F9C@geoserve.net> Brad Chapman wrote: > > Jeff, I don't know if I am the only dumb one, but I haven't been > commenting on this thread because I really don't understand what is > going on :-). I understand what PL networks are because these are the > networks that Overflow uses right now. The way I have been working > with things is to make an Overflow network map directly onto the > Loci "workspace" and dealing with things like this. There's no real confusion here. > What I don't understand is: > > 1. What exactly is a BL network? A BL network is/was a collection of nodes where each node is an instance of the BL (or Piper) located on a different, remote computer. I was recently thinking that BL networks should have their own workspaces, but now I think remote nodes can be in the PL workspace (i.e., the BL network is transparent). So, we can nix the whole concept of any real "BL network". > 2. How does a BL network differ from a PL network? Does it have to do > with network location? Again, the BL network is transparent, so it doesn't really exist. > 2a. If it has to do with network location, I am really confused about > what is going on, because I thought the dl would be mostly responsible > for remote communication. In the documentation for the definition > layer (http://bioinformatics.org/piper/documentation/dl_info.pdf) I > wrote up with diagrams about how I thought remote communication would > work, and this doesn't involve the bl communicating remotely. I > thought this was how we were working, but maybe not. Do people not > like this? Is this thinking incorrect? Please let me know so I can not > only change it, but modify my thinking as well. The BL network that I mentioned before is/was a "collection of nodes where each node is an instance of the BL (or Piper) located on a different, remote computer". This means the nodes communicate via BL -> BL connection. It seems though, looking again at your whitepaper, that a BL -> BL connection is supposed to be a BL -> DL -> DL -> BL connection. Brad, can you explain why the BL's can't/shouldn't communicate directly, but instead should communicate back through the Build-Time Subsystem and the DL? > 3. Shouldn't the whole entire implementation system of Piper be > invisibile to the user? I thought this was the point of separating out > the build time and run time layers. Why should the user have to worry > about whether they are adding a bl or pl network or whatever? That's the point of my bringing up Option A1. > 4. What is the point of the PL and BL, exactly, in other people's > minds? I thought that the PL handled application wrapping and basic > piping between internal nodes, and that the BL would handle > "organizing the workflow diagram" into a fast model, and implementing > cool genetic algorithms to think of ways to make connected nodes run > faster. Am I totally off? Maybe someone could clarify what is going on > here if I am :-) Actually, I never thought the BL would tell the PL how to execute its own workflow. It seems Jarl agrees that Overflow's "pull" method is very good. I thought that the BL would manage PL network -> remote PL network communication, directly, with a remote BL. > 5. Shouldn't dealing with the filesystem (like loading documents) or > dealing with databases be done by the "build time system" and thus be > handled by the definition layer? It seems like the run time system > only cares about having data and manipulating it, and not having to > deal with stuff like connecting to different databases, etc. The BTS says where the data is, and the RTS goes and gets it. In that sense, they BOTH deal with filesystems and databases. > 6. What are people's immmediate development goals for Piper? What I > have been working towards is adding all of the functionality from > Overflow into Piper, using the Piper framework. So when the system is > done, we would have something with mostly Overflow functionality, but > with the added advantage of one user interface, dealing with remote > connections, having genetic algorithsm to improve running speed in the > BL, etc. I'm not sure how genetic algorithms in the BL will improve the execution of networks, when most of that responsibility lies with the PL. Remote (BL) connections will be less common. In any case, I think the PL and the BL need to use the same approach for executing networks. And, it seems like Jarl likes the pull approach. > Does this BL/PL network stuff that you are talking about > affect how I should be coding right now? If so, what should I be > doing differently? Perhaps we should take a look at direct BL -> BL communication (keep execution in the RTS). From what Jarl has said, it seems the BL is very capable of doing that. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 23:24:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] announcements References: <200006240234.WAA146598@archa11.cc.uga.edu> Message-ID: <395429D5.D51189B9@geoserve.net> Brad Chapman wrote: > > I just think the first time people take some time to look at Piper, > they should be able to feel like they can do something other than just > read about it. Just me 2 bits... We do have code available, but you're right, we need to put a TODO list on the web. Let's make an updated TODO list. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 23:30:52 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <200006240221.WAA139452@archa11.cc.uga.edu> <3954294F.EE953F9C@geoserve.net> Message-ID: <39542B6C.96F03614@geoserve.net> "J.W. Bizzaro" wrote: > > Perhaps we should take a look at direct BL -> BL communication (keep execution > in the RTS). From what Jarl has said, it seems the BL is very capable of > doing that. You know we already trimmed a lot of functionality out of the BL. If the BL is only supposed to communicate with the PL and the DL (sit right in the middle), and it doesn't need to tell the PL how to execute its network (the PL has its own approach), what's the purpose of the BL??? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jun 23 23:41:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <200006240221.WAA139452@archa11.cc.uga.edu> <3954294F.EE953F9C@geoserve.net> <39542B6C.96F03614@geoserve.net> Message-ID: <39542DDC.C43E04AB@geoserve.net> "J.W. Bizzaro" wrote: > > You know we already trimmed a lot of functionality out of the BL. If the BL > is only supposed to communicate with the PL and the DL (sit right in the > middle), and it doesn't need to tell the PL how to execute its network (the PL > has its own approach), what's the purpose of the BL??? In my view, the BTS designs the network that the RTS is supposed to execute. Once the network design is completed, and ONLY when the design is completed, the RTS is contacted, and the design is passed to it for execution. Communication back to the BTS only occurs for an update on the progress of the execution and to stream back viewable results. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jun 24 04:45:08 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] hierarchy (was: icons) Message-ID: <200006240845.EAA134058@archa11.cc.uga.edu> Jeff wrote: > So, we can nix the whole concept of any real "BL network". Okay dokee. It seems like this was kind of confusing terminology anyways. Maybe we should refer to remote stuff with the same terminology as local stuff, just with the word "remote" prepended to it? So we would have a "remote network" or a "remote node." > The BL network that I mentioned before is/was a "collection of nodes where > each node is an instance of the BL (or Piper) located on a different, remote > computer". This means the nodes communicate via BL -> BL connection. It > seems though, looking again at your whitepaper, that a BL -> BL connection is > supposed to be a BL -> DL -> DL -> BL connection. > > Brad, can you explain why the BL's can't/shouldn't communicate directly, but > instead should communicate back through the Build-Time Subsystem and the DL? I guess the idea to start with was that users wouldn't be creating workspaces like: Local Node -> Remote Node -> Local Node -> Remote Node ie. workspaces where there is a lot of switching between local and remote nodes. But rather, they would create networks all of which ran at a remote location. Thinking about it this way, the DL to DL communication was supposed to make more sense because it kept all of remote authentication and communication in a single layer. I think Jarl's point on this was that it was "good enough" to start with. Right now we are supposed to be focusing on a local implementation of Piper, though, so I think as long as we agree that remote and local nodes should be dealt with the same in the user interface (which I agree with) we are probably still good enough to move forward. Then we can come back to the whole remote communication thing when we can actually implement different ideas and try them out. > Actually, I never thought the BL would tell the PL how to execute its own > workflow. It seems Jarl agrees that Overflow's "pull" method is very good. > I > thought that the BL would manage PL network -> remote PL network > communication, directly, with a remote BL. Okay, when I was talking about this I was only talking about the fact that thinking about things as a "pull" was nicer than thinking about a "push" mentality. However, I don't think the current pull system the PL has will be sufficient for dealing with a network that is remotely distributed. The reason is that all it does is keep calling getOutput() on the input nodes for a given node. If you strictly stick with this way of doing things, then you'll get stuck on a long running node (while it is calculating it's getOutput()) and not be able to distribute two long running processes on different machines. This is why I thought the BL would be primarily responsible for breaking up the wfd into pieces that the PL would calculate via the getOutput() in some kind of fashion, and then would assemble these pieces back together. > I'm not sure how genetic algorithms in the BL will improve the execution of > networks, when most of that responsibility lies with the PL. Remote (BL) > connections will be less common. In any case, I think the PL and the BL need > to use the same approach for executing networks. And, it seems like Jarl > likes the pull approach. The idea behind the genetic algorithms stuff is that it is just a smarter way to execute a work flow diagram so that remote processes will run simultaneously and the whole processing thing will be done faster. Right now, the PL is responsible for having a way to wrap programs and a simple "pull" methodology for piping information between nodes. Since Jarl has a lot of good ideas about making a smarter system, this is kind of "in addition" to what already exists in the PL. Having a smart system that can manage simultaneously running programs on different systems is very important to me, and I think that these are the kind of things Jarl is interested in working on. This is *a lot* of functionality to be implemented. Hopefully Jarl will step in and smack me upside the head if I am misrepresenting what he wants to do. > Perhaps we should take a look at direct BL -> BL communication (keep > execution > in the RTS). From what Jarl has said, it seems the BL is very capable of > doing that. Sure, if Jarl thinks this is better, then maybe we should look at this. If we want to have all of the remote authentication occur at the level of the definition layer, then the definition layer can be responsible for fetching object references for remote nodes, and then the BL can do all of the calling directly. At any rate, I am for leaving this thread for the time being and focus on local stuff in our coding and discussions right now. > You know we already trimmed a lot of functionality out of the BL [..snip...] > what's the purpose of the BL??? I don't think it is very productive to be looking at things as "we should give the BL something to do because it doesn't do anything": 1. The BL is *very important*, IMO, because of all the things mentioned above. I really want the kind of functionality that Jarl was talking about for GMS, and I think this can be worked in with how Overflow works now. How we handle remote requests should be determined by where it makes the most sense (and we'll figure that out later). 2. Questioning the purpose of other people's code in Piper is a very good way to get people disillusioned about coding on Piper. When we were going through that endlessly long thread about "what is the puprose of the DL?," I know that I was very close to wanting to quit from sheer frustration. Now we are going through the exact same thing with the BL--suggesting Jarl code in a different language, trying to micromanage what libraries he uses, saying that the BL isn't important, blah, blah, blah. Since I think this sucks really hard, can I suggest that we cut it out? This is a very unproductive way to talk about things. The BL and Jarl's contributions to Piper are extremely important, and we should never have to question this. Please, let's keep things positively focused. Positive energy. I think in general we are probably not ready for this whole thread yet. When we were talking a while back about security stuff, I remember Jarl suggesting that we stick with a simple local communication model to start with, and then add onto this. I like this idea and think we should work towards it and not worry about remote communication until we are done with this. Another 2 bits for you all. Brad From jarl at casema.net Sat Jun 24 13:59:55 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:12 2006 Subject: [Pipet Devel] announcements References: <3953FB55.1A75DFAF@geoserve.net> Message-ID: <3954F71B.8576DB04@casema.net> > I think we should make some announcements about Piper now to get the attention > of developers. I'd like to make general announcements about the project (not > saying we have a release) on Gnotices and Freshmeat. What do you think? Fine to me From jarl at casema.net Sat Jun 24 14:02:41 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <394F7A8F.F0344377@geoserve.net> <394F7E6B.80E0F2D1@geoserve.net> <3953C3A9.5A2AD889@geoserve.net> Message-ID: <3954F7C1.D7B2C3E8@casema.net> > I'll call it "Option A1": Like Option A, Option A1 makes the BL responsible > for only BL and PL subnets. But, let's do something magical: Let's make BL > subnets INVISIBLE to the user! I quote meself (Message-ID: <39501EC1.59544532@casema.net>) "I would be very happy when a non-techy user wont ever notices there's a BL :)" seems we're on the same track bye, jarl From jarl at casema.net Sat Jun 24 14:33:42 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] hierarchy References: <200006240845.EAA134058@archa11.cc.uga.edu> Message-ID: <3954FF06.25437D5@casema.net> > HI all, > > The idea behind the genetic algorithms stuff is that it is just a > smarter way to execute a work flow diagram so that remote processes > will run simultaneously and the whole processing thing will be done > faster. a GA is like a cryscal ball. It's main purpose is to try to predict the future :-) > > Perhaps we should take a look at direct BL -> BL communication (keep > > execution > > in the RTS). From what Jarl has said, it seems the BL is very > capable of > > doing that. > > Sure, if Jarl thinks this is better, then maybe we should look at > this. If we want to have all of the remote authentication occur at the > level of the definition layer, then the definition layer can be > responsible for fetching object references for remote nodes, and then > the BL can do all of the calling directly. At any rate, I am for > leaving this thread for the time being and focus on local stuff in our > coding and discussions right now. At first BL->BL communication seems more natural to me, but remembering the pull\push systems I misjudged, BL->DL->DL->BL comm. might be better. This is something to think about in the (near) future. Nothing really important a.t.m. > > > what's the purpose of the BL??? > > I suggest that we cut it out? This is a very unproductive way to talk > about things. The BL and Jarl's contributions to Piper are extremely > important, and we should never have to question this. Please, let's > keep things positively focused. Positive energy. > Thnx Brad :) But serieusly, I see cristisism as a good thing because it will make me do a better job. Let me list the functionallity of the BL again the way I see it: 1. AAA (Authorisation, Authentication and Accounting), Authorisation = giving a user access to an system. Authentication = user+password system to get a network address space, cq an area where a user can run it's nodes. Accounting = Resources management (cpu\ram\HD space\etc) 2. Brokering, to spread and connect nodes (PL networks) across multiple systems 3. Optimalisation, a dynamic weighting system that predicts loads so the brokering can be done better. Note this system requieres a network of SINGLE type nodes, the +/- 120 diff. node types of the PL can never be 'compared' to each other. From bizzaro at geoserve.net Sat Jun 24 10:46:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <200006240845.EAA134058@archa11.cc.uga.edu> Message-ID: <3954C9CA.A466E7F0@geoserve.net> Brad Chapman wrote: > > Now we are going through the exact same thing > with the BL--suggesting Jarl code in a different language, trying to > micromanage what libraries he uses, saying that the BL isn't > important, blah, blah, blah. Since I think this sucks really hard, can > I suggest that we cut it out? This is a very unproductive way to talk > about things. The BL and Jarl's contributions to Piper are extremely > important, and we should never have to question this. Please, let's > keep things positively focused. Positive energy. The criticism was not aimed at the BL at all. Quite the opposite, in fact. I was criticising a model that would reduce the role of the BL to that of a simple messenger, doing nothing but relaying information between 2 systems, the DL and the PL. The BL is capable of much more than that (BL -> BL communication, for example). You should know by now that I'm not some monster that goes around trashing other people's code :-) Cheers. Negative Energy Man -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From 94329828 at hermes.usherb.ca Sat Jun 24 11:14:30 2000 From: 94329828 at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] icons In-Reply-To: <3953E327.62680A7@geoserve.net> References: <394F7A8F.F0344377@geoserve.net> <39521824.2FA350C5@geoserve.net> <3952318E.6D562C20@hermes.usherb.ca> <3953E327.62680A7@geoserve.net> Message-ID: <200006241514.LAA21612@hermes.usherb.ca> > The saga continues. Below are 17 icons we should probably have made for > Pied/Piper. We need to give some idea as to what each icon should look > like. > Feel free to provide a descriptions where needed. > > Jean-Marc, about categorization, do you think we could put some of the more > special-purpose nodes (like VQ and NNet) in a "Misc" category? No, but since you can simply remove (rm -f *nnet* *vq*) those toolboxes if you don`t want them (without recompiling), I don`t think it`s an issue. > There are also signal types, but do we really need separate icons for them > right now? No, since it`s going to change anyway. For now, the Signal category is a mess Jean-Marc From jarl at casema.net Sat Jun 24 20:43:38 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] hierarchy (was: icons) References: <200006240845.EAA134058@archa11.cc.uga.edu> <3954C9CA.A466E7F0@geoserve.net> Message-ID: <395555BA.2B12E9B4@casema.net> > You should know by now that I'm not some monster that goes around trashing > other people's code :-) > Looking at this picture on your home site people might suspect otherwise :-) Nah, like I said before, criticism is always welcome, as long as it is on it's place. not so suicidal man, jarl From o.t at altavista.net Sat Jun 24 13:59:08 2000 From: o.t at altavista.net (o.t) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] paradigm Message-ID: <3954F6EC.A40C5F18@altavista.net> There is little technical information on your web site. Are you creating a visual programming language (VPL)? If so then what paradigm will it use? Or are you creating a framework in which different VPLs can be plugged in? There is a huge number research papers about VPLs on the net: http://cui.unige.ch/eao/www/Visual/Visual.Programming.biblio.html http://www.cs.orst.edu/~burnett/vpl.html http://cui.unige.ch/eao/www/petri/list.html Maybe you can put pointers to papers that you use in your project on your web site. From bizzaro at geoserve.net Sat Jun 24 16:03:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] paradigm References: <3954F6EC.A40C5F18@altavista.net> Message-ID: <39551422.5D69E216@geoserve.net> "o.t" wrote: > > There is little technical information on your web site. We're working on it :-) > Are you creating a visual programming language (VPL)? If so then what > paradigm will it use? Or are you creating a framework in which different > VPLs can be plugged in? Piper started out (as Loci) as a framework to connect APPLICATIONS across the Internet. It just so happened that we found a VPL being developed that uses a very similar paradigm, only it is not Internet-distributed. That VPL (I guess you can call it that) is Overflow, by Jean-Marc Valin and Dominic Letourneau: http://freespeech.sourceforge.net/overflow.html We decided to work together since we had complementary systems and compatible licenses (GNU). > There is a huge number research papers about VPLs on the net: > > http://cui.unige.ch/eao/www/Visual/Visual.Programming.biblio.html > http://www.cs.orst.edu/~burnett/vpl.html > http://cui.unige.ch/eao/www/petri/list.html > > Maybe you can put pointers to papers that you use in your project on > your web site. Thanks for the links. Jean-Marc is probably the best person to answer your question. The Internet-distributed part of Piper was not developed with a documented VPL model in mind, but perhaps Overflow was. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jun 24 17:02:59 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] paradigm Message-ID: <200006242102.RAA54156@archa11.cc.uga.edu> > "o.t" wrote: >> There is little technical information on your web site. Just curious, what kind of information would you like to see? > o.t. wrote: >> Are you creating a visual programming language (VPL)? If so then what >> paradigm will it use? Or are you creating a framework in which different >> VPLs can be plugged in? Jeff wrote: > Piper started out (as Loci) as a framework to connect APPLICATIONS across the > Internet. It just so happened that we found a VPL being developed that uses > a very similar paradigm, only it is not Internet-distributed. That VPL (I > guess you can call it that) is Overflow, by Jean-Marc Valin and > Dominic Letourneau: >From my talking with Jean-Marc, the major goal of the visual part of Overflow was to make the programs he wrote using his libraries more readible and understandable (people on the list saw his screenshots and how crazy things can get). Although it has some elements of a programming language (since it is loosely modeled after it) I definately do not think a major goal was developing a full featured VPL. This is probably why you do not see links to specific design choices for this. o.t. wrote: >> Or are you creating a framework in which different >> VPLs can be plugged in? This is certainly possible, if someone is really interested in working on it. As Jeff mentioned Overflow already has some elements of a programming languages (with constructs like 'and', 'multiplexers', etc.), so it should be something feasible. o.t. wrote: >> Maybe you can put pointers to papers that you use in your project on >> your web site. At least from my side, I am more of a "self-taught" programmer, than an "academic" programmer, so I am not very likely to do much reading of papers (well, not computer science papers--but I do have huge piles of biologically related papers in a mass surrounding my desk :-). But I am also very interested in hearing about any ideas you could suggest about things we could read that would help us in our coding, and am very open to suggestions. Thanks for writing. Brad From 94329828 at hermes.usherb.ca Sat Jun 24 19:12:05 2000 From: 94329828 at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] paradigm In-Reply-To: <3954F6EC.A40C5F18@altavista.net> References: <3954F6EC.A40C5F18@altavista.net> Message-ID: <200006242312.TAA19866@hermes.usherb.ca> Quoting "o.t" : > There is little technical information on your web site. Try http://freespeech.sourceforge.net/overflow.html There is some (outdated) doc. > Are you creating a visual programming language (VPL)? If so then what > paradigm will it use? Or are you creating a framework in which different > VPLs can be plugged in? > There is a huge number research papers about VPLs on the net: As said before, Overflow is complementary to the rest of Piper. At first, the goal was not to design a VPL, it just evolved this way. The idea was to make it simple to do image and signal processing. Currently, most "features" you would expect from a language are there: conditions, loops, functions/arguments. The features it has now are features that are/were useful to us (the GUI was the last part being written). The main thing to know about it is that it works by "pulling" on data, and not the other way. We currently have "toolboxes" for the following things: speech/signal processing (both real-time and batch), image processing, neural networks and vector quantization. You can contact me if you need more info. Jean-Marc Valin From chapmanb at arches.uga.edu Sat Jun 24 22:14:50 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] A couple o' BL questions WAS hierarchy Message-ID: <200006250214.WAA57114@archa10.cc.uga.edu> Hey Jarl (and anyone else who is interested :-) Hope everything is going good with you. I just had some more time to read more carefully over your listing of what the brokering layer is planned to do, and just had a couple of comments/questions. 1. Is the planned order of implementing things like you have specified in the numbering of the things to do (ie. first AAA, then Brokering, then Optimization/GA stuff)? It seems like this makes sense, since the AAA stuff is kind of what we already have in the idl, combined with the internal authentication system you've been talking about. Then we need to figure out what is going on with remote applications, etc. I was just curious about the development plan. 2. How does KQML, which you mentioned really wanting to use before, fit into this framework? Is this planned to be used for communication within the BL, remote communications, etc. etc. Just curious how this fits in. 3. In the optimization section you wrote: "Note this system requieres a network of SINGLE type nodes, the +/- 120 diff. node types of the PL can never be 'compared' to each other." Can you explain more about what you are talking about here? I don't really understand your idea for a 'single' type node, and how this will fit in with the framework on how things working in the PL right now. That's it. Thanks for writing up this listing. I'll be very excited to have it all working! Brad From bizzaro at geoserve.net Sun Jun 25 00:00:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] Pied TODO Message-ID: <395583F3.AD704B0B@geoserve.net> Here is an updated TODO list for Pied. I need one for each part of Piper. They will of course be included in the code, but I also want to put them on the web (Brad's suggestion) so that potential volunteers will know what needs to be done. Please post them to this list! :-) Hurry, hurry! Then we can announce the project on Gnotices and Freshmeat, right Brad? Jeff ---------------------------------------------- SHORT TERM: * Link selection and indication via color change * Pop-up menu needs to reflect the item selected (node, link, workspace) [ALMOST DONE] * Link disconnection via pop-up menu over link * Node deletion; 2 types: (1) delete to move to another windowlet, and (2) delete to destroy * Connection of more than 2 links together; allowed is either N>0 outputs with 1 input, or N>0 inputs with 1 output * Add and remove links to/from nodes * Show and hide unconnected links; represents "map to parent" and "dead end", respectively * Automatic link mapping to parent node * Windowlets attached to links; will give informational view * Names attached to links; seen only when disconnected and/or selected * Windowlets resizable by dragging on frame (no windowsill) LONG TERM: * Node import to take place via DnD from Gnome desktop, file manager, or open dialog * Alternate view in windowlet: Gtk widgets * Occupy or unoccupy parent windowlet (menu option -- no windowsill) * Alternate view in windowlet: Informational view (name, icon, location) * Alternate view in windowlet: Global view of network * Alternate view in windowlet: Tree view showing hierarchy of supernets and subnets * Status minicons (surrounding node icon -- no windowsill) * Multiple node selection capabilities; SHIFT-button1 and CTRL-button1 will do this * Network navigation via keyboard * Clipboard node for doing copy/cut/paste of nodes; should be a subnet and able to be placed on the workspace. * Trash node; like clipboard node * Start up with a few nodes already on the workspace (trash, clipboard) * Node export to Gnome desktop or file manager * Option to add only MIME and link type-compatible nodes to other nodes ---------------------------------------------- -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Sun Jun 25 17:18:05 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] A couple o' BL questions References: <200006250214.WAA57114@archa10.cc.uga.edu> Message-ID: <3956770D.ACC4B26A@casema.net> > > 1. Is the planned order of implementing things like you have specified > in the numbering of the things to do (ie. first AAA, then Brokering, > then Optimization/GA stuff)? It seems like this makes sense, since the > AAA stuff is kind of what we already have in the idl, combined with > the internal authentication system you've been talking about. Then we > need to figure out what is going on with remote applications, etc. I > was just curious about the development plan. I planned my todo list in this order: 1. Remove all fixed stuff in GMS, which I've finished coding and is being debugged atm. (It had some consequences so it took a lot more work as I had fought) 2. Link to Overflow libraries (compiling GMS sources as C++, writing code that communicates with Overflow, etc.) 3. Debug \ extend the threading. 4. Implement the AAA according to the Piper DL-BL idl. 5. Write BL->BL communication code (plugins that are KQML compliant) After these points there's more work todo, but I am not sure about the order here: 6. Batch code 7. GAP engine > > 2. How does KQML, which you mentioned really wanting to use before, > fit into this framework? Is this planned to be used for communication > within the BL, remote communications, etc. etc. Just curious how this > fits in. See 5. of the TODO. > > 3. In the optimization section you wrote: "Note this system requieres > a network of SINGLE type nodes, the +/- 120 diff. node types of the PL > can never be 'compared' to each other." Can you explain more about > what you are talking about here? I don't really understand your idea > for a 'single' type node, and how this will fit in with the framework > on how things working in the PL right now. With the term 'single type object' I mean a system that is based on ONE object type, opposing a system that consists of many different type. GMS is based on the object (which OOP people would call a 'structure') messaging_object, and no other type is used for node representation. Why I do this? The BL will need to optimize resources like load \ space \ time \ bandwidth etc. and NOT the actual data processing. In other words: the BL wont take heed of what is going on, but how things run. The 'value' of a node depends on the resources it consumes, not on what it does to the data it contains. To compare these values they must represent the same node type. Nodes with high values (weights) require less resources and will be scheduled on systems that have high load, and nodes with low weights are redirected to systems with lot of idle resources. Each [time frame] the weights for all BL nodes are recalculated and rescheduled accordingly. So the BL will handle this situation: (1) Network definition (UI\DL) -> (2) BL nodes resources consumption || (3) net system resources <- (4) gross system resources ('->' = 'results into' or 'simplicity', and '||' is the contradicting border between two interests) Recalculation of the weight will be based upon (2) and (3), but will be influenced by (1) and (4) indirectly of course. Am I being clear? I probably forgot some critical element that's obvious to me, so feel free to ask more details if you're interested. I wont answer till wednesday, I'm gone now to catch my plane... and miss the Euro2000 match TheNetherlands-Jugoslavia :(( bye, jarl From bizzaro at geoserve.net Sun Jun 25 08:37:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] A couple o' BL questions References: <200006250214.WAA57114@archa10.cc.uga.edu> <3956770D.ACC4B26A@casema.net> Message-ID: <3955FD12.C51D4322@geoserve.net> jarl van katwijk wrote: > > To compare these values they must represent the same node type. Nodes with high > values (weights) require less resources and will be scheduled on systems that > have high load, and nodes with low weights are redirected to systems with lot > of idle resources. Each [time frame] the weights for all BL nodes are > recalculated and rescheduled accordingly. If I understand what you're saying, the user (network builder) won't choose the location of a node, the BL will. Is that true? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Sun Jun 25 17:43:18 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] A couple o' BL questions References: <200006250214.WAA57114@archa10.cc.uga.edu> <3956770D.ACC4B26A@casema.net> <3955FD12.C51D4322@geoserve.net> Message-ID: <39567CF6.F174A8C5@casema.net> > > To compare these values they must represent the same node type. Nodes with high > > values (weights) require less resources and will be scheduled on systems that > > have high load, and nodes with low weights are redirected to systems with lot > > of idle resources. Each [time frame] the weights for all BL nodes are > > recalculated and rescheduled accordingly. > > If I understand what you're saying, the user (network builder) won't choose > the location of a node, the BL will. Is that true? When the node is created the user will choose, and localhost will be default. But when the node is free to be located on an other system, the BL will do so if that is 'better'. We can introduce 'fixed' nodes of course if they are needed, so the BL wont touch them. bye, jarl From chapmanb at arches.uga.edu Sun Jun 25 09:25:18 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] Pied TODO Message-ID: <200006251325.JAA71208@archa10.cc.uga.edu> > Here is an updated TODO list for Pied. I need one for each part of Piper. Okay dokee, at the bottom of this is a TODO list off the top of my head for the definition layer. > They will of course be included in the code, but I also want to put them on > the web (Brad's suggestion) so that potential volunteers will know what needs > to be done. I also need to improve the documentation for how to setup and install Piper, and I'll work on this (and probably convert it to LaTeX or something). > Hurry, hurry! Then we can > announce the project on Gnotices and Freshmeat, right Brad? Sure :-). You can post without it too if you all want to. You just asked for opinions, so I gave one... Brad Definition layer project list ------------------------------ * Short term stuff to finish: -- Finish integration of Overflow into Piper -- Finish implementing MVC. Debug the code and make sure it works properly. -- Improve and finish implementing the connection with the BL. Modify the code in the DL to deal with the kind of information the BL will give us, and also the kind that it needs. -- Finish saving and loading of work flow diagrams as XML. * Update existing documentation to be consistent with what we've got in the code. Add more documentation about how to run Piper and deal with different things. * Improve the system for storing passwords safely. The current setup should be reasonably secure, but the only way to deal with it is through a hard to use command line program. which probably doesn't even work properly with the current setup. So the basic code exists for this, but it needs some serious work to fix up and make it easier to use. * Dealing with databases. The basic code to connect with three kinds of databases (MySQL, PostgreSQL and Gadfly) already exists, but doesn't work properly with the new CORBA framework since I haven't done this yet. So need to get this working, and also expand it to include support for making SQL queries on the databases. Then this needs to be integrated with some user interfaces to give a way to manipulate the databases through the user interface. * Dealing with the filesystem. Again, the basic code to do this already exists, but it needs to be fixed to work with the new setup of the definition layer, and fix the user interfaces to deal with it. * Remote Communication with other Piper instances. Since we aren't positive how remote communication will occur between nodes, this should probably mostly be focused on connecting with remote Piper programs, and then querying them for available nodes, and then work on a way to integrate these remote nodes with local nodes so they work together seemlessly. * Implementing stuff that make it easier to write XML files for programs that will work with Piper. Need to work on automating the system of plugins so it is easier to deal with. From bizzaro at geoserve.net Sun Jun 25 13:07:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:13 2006 Subject: [Pipet Devel] Charming Python: Tinkering with XML and Python Message-ID: <39563C56.5C93A748@geoserve.net> I'm sure you're beyond this, Brad, but I thought it'd be good to post anyway: http://www-4.ibm.com/software/developer/library/python1/ Jeff From bizzaro at geoserve.net Sun Jun 25 15:37:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:14 2006 Subject: [Pipet Devel] Pied TODO References: <395583F3.AD704B0B@geoserve.net> Message-ID: <39565F65.C395ABB4@geoserve.net> I added to CVS the TODO's from Brad (DL), Jarl (BL), and myself (Pied). Brad, I had to make a BL directory; I hope that's okay. We should also get TODO's from Jean-Marc (PL) and Deanne (Peep). I'm going to make a page for these on the web now. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jun 25 16:59:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:14 2006 Subject: [Pipet Devel] Pied TODO References: <395583F3.AD704B0B@geoserve.net> <39565F65.C395ABB4@geoserve.net> Message-ID: <395672C3.703DFFE3@geoserve.net> "J.W. Bizzaro" wrote: > > I'm going to make a page for these on the web now. Okay, I put under "FOCUS & GOALS" links to the TODO files at the CVSWeb interface to CVS. I have a few other links on the site that point directly to CVSWeb. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jun 27 15:20:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:14 2006 Subject: [Pipet Devel] [Fwd: Your ISMB 2000 poster - abstract needed in ASCii; reminder to] Message-ID: <3958FE68.BE3953C5@geoserve.net> We're ready to roll. Jeff -------------- next part -------------- An embedded message was scrubbed... From: Ann Redelfs Subject: Your ISMB 2000 poster - abstract needed in ASCii; reminder to register Date: Tue, 27 Jun 2000 10:23:02 -0800 Size: 4471 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000627/08d85128/attachment.mht From bizzaro at geoserve.net Tue Jun 27 15:52:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] BXXP Message-ID: <395905F7.86C023D5@geoserve.net> "Internet engineers say BXXP will significantly reduce the time it takes to prototype and build Internet applications protocols because it provides reusable code for basic data exchange between systems." http://www.nwfusion.com/news/2000/0626bxxp.html Jeff From chapmanb at arches.uga.edu Wed Jun 28 05:17:17 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] reminder to][Fwd: Your ISMB 2000 poster - abstract needed in ASCii; reminder to] reminder to] Message-ID: <200006280917.FAA93438@archa12.cc.uga.edu> > We're ready to roll. Jeff > > Dear ISMB Poster Presenter, > > Thank you for your poster submission for the 8th Annual Meeting of > Intelligent Systems for Molecular Biology (ISMB 2000, August 19-23, San > Diego, California, USA). We are pleased to inform you that your poster has > been accepted for presentation. Woo hoo! We didn't get rejected! Of course, now this means we have to have Piper ready to be doing the stuff we promised by August :-). > To insure that your poster appears in the conference Final Program, please > send a 50-word abstract as ASCii text to richmond@sdsc.edu no later than > July 6, 2000. If you miss this deadline, only the title of your poster and > the author(s)' name(s) will appear in the ISMB2000 Final Program. Jeff, do you want me to take care of this, or are you going to? Either way is fine with me. Brad From bizzaro at geoserve.net Wed Jun 28 07:30:03 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] Your ISMB 2000 poster References: <200006280917.FAA93438@archa12.cc.uga.edu> Message-ID: <3959E1BB.ECA3D9E4@geoserve.net> Brad Chapman wrote: > > > To insure that your poster appears in the conference Final Program, > > please send a 50-word abstract as ASCii text to richmond@sdsc.edu > > no later than July 6, 2000. If you miss this deadline, only the > > title of your poster and the author(s)' name(s) will appear in the > > ISMB2000 Final Program. > > Jeff, do you want me to take care of this, or are you going to? Either > way is fine with me. A 50-word abstract is preeeeetty darn short. In fact, the paragraph above is about 50 words. I think we can use the wording from the web page, which is short. I'll take of it. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Jun 28 19:07:01 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] Your ISMB 2000 poster Message-ID: <395A8515.CFF17C09@geoserve.net> Here is an abstract under 50 words: -------------- Piper is a system for creating and managing links between Internet-distributed components, such as networks, programs, files, and widgets. Components can reside remotely, on higher performance and capacity computers, while only representations reside locally. Links can represent protocol-independent data flow, procedural steps, and relationships. http://bioinformatics.org/piper -------------- Do you think we should keep the URL in there? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Jun 28 19:45:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] IBM WebSphere Message-ID: <395A8E37.46B47772@geoserve.net> This is also somewhat similar to Piper: http://www-4.ibm.com/cgi-bin/software/track3.cgi?file=/software/info/websphere/developers/index.html&S_TACT=100AWW11&S_CMP=campaign I can't help but get the impression, however, that WebSphere and Micro$oft.NET are a lot more convoluted and complex than Piper. Jeff From jean-marc.valin at hermes.usherb.ca Wed Jun 28 19:16:18 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] Your ISMB 2000 poster References: <395A8515.CFF17C09@geoserve.net> Message-ID: <395A8742.1FFF6E70@hermes.usherb.ca> > -------------- > Piper is a system for creating and managing links between Internet-distributed > components, such as networks, programs, files, and widgets. Components can > reside remotely, on higher performance and capacity computers, while only > representations reside locally. Links can represent protocol-independent data > flow, procedural steps, and relationships. http://bioinformatics.org/piper > -------------- I'd add something about the fact that everything is done "visually", and not in a "shell script" form. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Wed Jun 28 20:02:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] Your ISMB 2000 poster References: <395A8515.CFF17C09@geoserve.net> <395A8742.1FFF6E70@hermes.usherb.ca> Message-ID: <395A9228.E60685D9@geoserve.net> Jean-Marc Valin wrote: > > > -------------- > > Piper is a system for creating and managing links between Internet-distributed > > components, such as networks, programs, files, and widgets. Components can > > reside remotely, on higher performance and capacity computers, while only > > representations reside locally. Links can represent protocol-independent data > > flow, procedural steps, and relationships. http://bioinformatics.org/piper > > -------------- > > I'd add something about the fact that everything is done "visually", and not in > a "shell script" form. Perhaps I could start off the abstract this way: ----------------- Piper is a system for interactively creating and managing links between... ^^^^^^^ ----------------- What do you think? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From gvd at penguin.pharmacy.ualberta.ca Wed Jun 28 22:55:36 2000 From: gvd at penguin.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] Your ISMB 2000 poster In-Reply-To: <395A8515.CFF17C09@geoserve.net> Message-ID: On Wed, 28 Jun 2000, J.W. Bizzaro wrote: > Do you think we should keep the URL in there? Perhaps if you put it after the first instance of piper: > -------------- > Piper (http://bioinformatics.org/piper) is a system for creating and managing links between Internet-distributed > components, such as networks, programs, files, and widgets. Components can > reside remotely, on higher performance and capacity computers, while only > representations reside locally. Links can represent protocol-independent data > flow, procedural steps, and relationships. http://bioinformatics.org/piper > -------------- Otherwise sounds very nice. Since we are presenting at ISMB it might be nice to give it a biiological slant: Piper's design facilitates biological sequence analysis, which often involves coordinated data transfer in a network-distributed environment. Kinda wordy, I know. Jeff can gzip it though, I'm sure ;-) Regards, g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From chapmanb at arches.uga.edu Thu Jun 29 15:44:07 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] omniORB and cvs code breakage Message-ID: <200006291944.PAA153012@archa10.cc.uga.edu> Hello all; The omniORB folks have just announced the pre-releases for omniORB3 and omniORBpy 1.0, which will be the actual releases in a couple of days assuming there are no bug reports, etc. Right now I'm compiling these on my machine and am going to move to begin using them. Okay, so who cares what I do? Well, there was an argument on the distribution object python SIG about the mapping, and it ended up that the omniORB folks lost... so the stubs and skeletons that are generated by the omniORB idl compiler have changed (hopefully to what will now be the stable standard). As a result of this, I'll have to change the makefiles and imports to reflect this change, so if you are using an older version than the omniORBpy pre-release, the cvs code will not work for you :-<. However, moving to the releases makes a lot of sense, since then we can point users of Piper at stable releases (instead of old cvs tarballs) and also so we can stay compliant with the python mapping. For anyone following cvs, the only thing you should have to rebuild is omniORBpy, which you can get from: ftp://ftp.uk.research.att.com/pub/omniORB/omniORBpy/ I'd like to check in the changes tonight... so if you have any objections, speak up :-). Sorry about the pain. Brad From chapmanb at arches.uga.edu Fri Jun 30 03:37:37 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] omniORB and cvs code breakage Message-ID: <200006300737.DAA98024@archa12.cc.uga.edu> I wrote: [...snip... talking about changes to the python mapping in the new omniORB...] > I'd like to check in the changes tonight... so if you have any > objections, speak up :-). Okee dokee, no one spoke up to stop me, so I just cvsed the changes. Please let me know if you have any problems building and running with the new stuff. Thanks! Brad From bizzaro at geoserve.net Fri Jun 30 23:00:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:20:15 2006 Subject: [Pipet Devel] Your ISMB 2000 poster References: Message-ID: <395D5EEB.3DEC57C4@geoserve.net> Gary Van Domselaar wrote: > > Otherwise sounds very nice. Since we are presenting at ISMB it might be > nice to give it a biiological slant: > > Piper's design facilitates biological sequence analysis, which often > involves coordinated data transfer in a network-distributed > environment. Piper (http://bioinformatics.org/piper) is an interactive system for creating and managing links between Internet-distributed components such as those used for bioinformatics analyses. Components can reside remotely, on higher performance and capacity computers, while only representations reside locally. Links can depict protocol-independent data flow, procedural steps, and relationships. 48 words. How's that? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+