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