From nat at nat.org Fri Oct 1 03:08:28 1999 From: nat at nat.org (Nat Friedman) Date: Fri Feb 10 19:18:53 2006 Subject: [Pipet Devel] RE: ref counting in Bonobo In-Reply-To: <40DEF2EE1151D311BC520050047B4145018C44@195-66-34-2.itv.se> References: <40DEF2EE1151D311BC520050047B4145018C44@195-66-34-2.itv.se> Message-ID: <14324.24044.579154.699498@retrans.mit.edu> Svanberg Liss writes: > > I was wondering about the implications of the ref counting routines in the > > Unknown interface. If I have a remote client that's holding a reference > > to an object in a server, and the client crashes, what happens? > > > > I've heard that Microsoft is trying to implement distributed garbage > > collection in COM+ 2.0. And I mean full mark-and-sweep type garbage > > collection. It's hard to imagine making that work. > > > > Do Bonobo client programs explicitly call ref and unref on server objects, > > or is this all handled transparently by Gnome? > > There is nothing wrong with refcounting, as long as you can exiplictly kill > an object. We do have gnome_object_destroy(), but don't encourage its wide-spread use for the obvious reasons. Nat From David.Lapointe at umassmed.edu Fri Oct 1 12:45:05 1999 From: David.Lapointe at umassmed.edu (Lapointe, David) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] XMLHACK Site Message-ID: <93307F07DE63D211B2F30000F808E9E501644E4B@edunivexch02.umassmed.edu> Here's some XML info which came from the perl-XML list today. %%%%%%%% A number of XML-folk have gotten together to set up an XML news site. Named in honor of both the 'Desperate Perl Hacker' who was a key icon in the development of XML and the many journalists (hacks) out there typing away, xmlhack.com hopes to bring developers the latest news on XML happenings and discussions. http://xmlhack.com/ xmlhack: developer news from the XML community xmlhack.com is a web site covering essential news, issues, opinions and programming advice from the XML developer community. It aims to: * provide succinct and informative summaries of current issues and emerging technologies in the XML world * promote XML and its uses among developers: particularly with those who don't have the time to read five mailing lists every day! * recognize and reflect the distinct flavor of the XML community * cover discussions as well as projects * help new users find their way among the hundreds of different directions XML is going * give developers another way to find related projects and cross-pollinate ideas Feedback is welcome - I think we've only got one Perl/XML story up so far, but more will be coming! Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com %%%% David Lapointe, Ph.D. Research Computing Manager 6-5141 "What we obtain too cheap, we esteem too lightly." - T. Paine From obouriez at qben.quintiles.com Fri Oct 1 14:10:53 1999 From: obouriez at qben.quintiles.com (obouriez@qben.quintiles.com) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] Re: ref counting in Bonobo Message-ID: <802567FD.006438BC.00@qedilc01.qedi.quintiles.com> > The only real problem appears to be the interfaces ( GNOME::Storage / > GNOME::Stream ) that has no callbacks. On the other side, none of those > objects are supposed to stay alieve for a prolonged time, are they? They are refcounted as well. -- FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq To unsubscribe: mail gnome-components-list-request@gnome.org with "unsubscribe" as the Subject. From bizzaro at bc.edu Fri Oct 1 17:02:01 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] SLIDESHOW! Message-ID: <37F52149.DCBF4ED3@bc.edu> Greetings. I gave a talk about Loci at Harvard/Mass General Hospital yesterday. It went well, I think. Some 20 people attended. I just took the slides from the talk and put them on the Web site for viewing: http://bioinformatics.org/loci/slideshow/ You may find that this is the best explanation yet of how Loci works. I will be at the Brookhaven National Lab tomorrow to present a poster on Loci. We'll have a workstation next to the poster and can point a Web browser to the slideshow. David is going with me, and I expect to see Barry and Robert there too. I'll get some pictures. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From Alan at MolBio.org Mon Oct 4 14:29:18 1999 From: Alan at MolBio.org (Alan J. Williams) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] Bonobo Docs In-Reply-To: <37F52149.DCBF4ED3@bc.edu> Message-ID: Thanks for the tip on the Bonobo Docs. I checked out the latest version from CVS using (just hit return when asked for a password): $ export CVSROOT=:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome $ cvs login $ cvs checkout bonobo-doc Alternatively you can download a tarball at: ftp://batch2112.ucr.edu/pub/Linux -Alan -------------------------------------------------------------------- Alan Williams Where observation is concerned, Alan@MolBio.org chance favors the prepared mind. http://www.MolBio.org/cv/ -- Louis Pasteur -------------------------------------------------------------------- ** University of California, Botany Department, Riverside ** From bizzaro at bc.edu Mon Oct 4 14:52:49 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] snapshot-19991001 Message-ID: <37F8F780.8AE3AE74@bc.edu> Greetings Loci-type people. The version of the Workspace that was used to make the screenshots for the slideshow and poster, is available as a tarball in the usual place: http://bioinformatics.org/loci/download/snapshots/ Please provide comments and suggestions. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Mon Oct 4 21:20:12 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] gnome/gtk+ application development manual Message-ID: <199910050120.TAA10659@redpoll.pharmacy.ualberta.ca> Hey! I found this on the gnome developer site. I don't remember seeing it on the mailing list: http://developer.gnome.org/doc/GGAD/ Its the official gnome programming manual, and its free! Joy! --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From Alan at MolBio.org Tue Oct 5 00:03:04 1999 From: Alan at MolBio.org (Alan J. Williams) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] gnome/gtk+ application development manual In-Reply-To: <199910050120.TAA10659@redpoll.pharmacy.ualberta.ca> Message-ID: Gary Van Domselaar wrote: > I found this on the gnome developer site. I don't remember seeing it on > the mailing list: > > http://developer.gnome.org/doc/GGAD/ > > Its the official gnome programming manual, and its free! Joy! I got this book a week or so ago and just finished skimming the whole thing. My recommendation for any newbies out there is to go through the gtk tutorial (http://www.gtk.org/tutorial/) and then the gnome tutorial (http://www-4.ibm.com/software/developer/library/gnome-programming/index.html and http://developer.gnome.org/doc/tutorials/gnome-libs/). This should give you a pretty good foundation and even though it is all from a C perspectiv, it should help in getting started with other bindings (such as python :) >From there you may want to get Havoc Pennington's book (which Gary brought up) at http://developer.gnome.org/doc/GGAD/. There is another book (Developing Linux Applications with GTK+ and GDK - by Eric Harlow) but I found it to be disappointing. Your better off with the GTK+ tutorial and Havoc's book. And of course check out http://developer.gnome.org/doc/ for all sorts of other docs. http://developer.gnome.org/news/ is also good for keeping up with gnome development via the "Summaries". Happy Hacking, -Alan -------------------------------------------------------------------- Alan Williams Where observation is concerned, Alan@MolBio.org chance favors the prepared mind. http://www.MolBio.org/cv/ -- Louis Pasteur -------------------------------------------------------------------- ** University of California, Botany Department, Riverside ** From bizzaro at bc.edu Tue Oct 5 14:54:02 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] gnome/gtk+ application development manual References: Message-ID: <37FA494A.4AC4B74A@bc.edu> "Alan J. Williams" wrote: > > From there you may want to get Havoc Pennington's book (which Gary brought > up) at http://developer.gnome.org/doc/GGAD/. For those who haven't gone to see it, the whole book is online in HTML. > There is another book > (Developing Linux Applications with GTK+ and GDK - by Eric Harlow) but I > found it to be disappointing. Your better off with the GTK+ tutorial and > Havoc's book. I have both books in printed form, and they have been decent for reference on occation. Keep in mind, though, that they are about GUI development and don't get into any of the networking tools that Gnome is known for. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Tue Oct 5 15:03:56 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] screenshots directory Message-ID: <37FA4B9C.82930AC6@bc.edu> Locians, I put a bunch of screenshots of the Loci Workspace in a directory on the server, in case you are interested: http://bioinformatics.org/loci/screenshots/ Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Oct 7 12:53:05 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] Pharmatrix Message-ID: <37FCCFF1.7FE7CA15@bc.edu> Greetings. Here is another application to take a gander at: http://pharmatrix.com/ Pharmatrix is made by Base4. Thanks to Carol Gebert for the link. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Oct 7 19:07:57 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] Intro to XML Message-ID: <37FD27CD.7C85071D@bc.edu> Salutations. Linux World has a multipart introduction to XML: http://www.linuxworld.com/linuxworld/lw-1999-09/lw-09-xml2.html?10-07 Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Fri Oct 8 16:39:39 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] snapshot 19991008 Message-ID: <37FE568B.31F6A60A@bc.edu> Get it while it's hot: http://bioinformatics.org/loci/download/snapshots/ Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Sat Oct 9 14:23:55 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] Required Reading: CORBA at EBI Message-ID: <37FF883B.92ACA186@redpoll.pharmacy.ualberta.ca> Is anyone aware of the work being done with corba at the European Bioinformatics Institute? http://corba.ebi.ac.uk They have CORBA servers that give access to the EMBL nucleotide sequence database! Of particular interest to the Loci team, check out AppLab: A CORBA-Java based application wrapper. the main goal is to develop a distributed object system which provides an easy-to-use and well-defined access to a large set of existing command-line-driven applications of different types. In summary: AppLab defines the IDL interfaces for invoking and controlling the remote applications and for browsing their results, AppLab implements a mechanism making possible to plug-in new applications without any additional programming effort (source code generator), and Applab is easily extensible for the problem-specific application sets (such as special data structures needed in bioinformatics). Sound familiar? Here's a bit more about AppLab: AppLab is an automatically generated wrapper for command-line driven applications. It provides a uniform graphical user interface for the applications. AppLab is about CORBA. CORBA is the Common Object Request Broker Architecture, sometimes considered to be "...the most important (and ambitious) middleware project ever undertaken by our industry..." (Robert Orfali). The beauty of CORBA is its clean division between interface specification (IDL) and implementation code. There is plenty of Web pages about CORBA and OMG (CORBA's mother and father), here is one list of lists: http://industry.ebi.ac.uk/~corba. AppLab is about Java. Java is a programming language used by AppLab on both ends of the CORBA client/server architecture. AppLab generates Java source code containing all necessary CORBA callings. Using AppLab code generators and Java compiler you have immediately a CORBA based application ready to run. AppLab is not an ORB. The ORB (Object Request Broker) is the implementation of middleware based on CORBA standards. You must have an ORB to be able to let your clients and servers (presumably created by AppLab) communicate together. It can be any ORB supporting Java language mapping (AppLab was considerably tested with OrbixWeb and Visibroker for Java). AppLab is the application wrapper. A CORBA server offers the command-line driven applications. A CORBA client asks the server to execute an application with its set of parameter values. Both client and server can be completely generated by AppLab. AppLab is not a domain-specific application, it can wrap applications from different domains. And AppLab is not a viewer of resulting data. It provides links to appropriate data viewers, if needed, but it does not display graphical data itself. Sounds interesting, no? I'll dl a copy and read the documentation. Get back to ya! --gary From bizzaro at bc.edu Sat Oct 9 16:04:54 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] Required Reading: CORBA at EBI References: <37FF883B.92ACA186@redpoll.pharmacy.ualberta.ca> Message-ID: <37FF9FE6.86AEB8E7@bc.edu> Here are some messages I dug up from our archive about AppLab: ---from me, 11/21/98----------------- The following are some Java-based packages, tools, and links to tools. ... AppLab Homepage http://industry.ebi.ac.uk/applab/ ------------------------------------- ---from Peter Rice, 12/11/98 (Loci list)--- > (4) TULIP also uses XML. We could do. There are some XML fans over here. The AppLab project at the EBI for example. ------------------------------------------- ---from Peter Rice, 3/19/99 (EMBOSS list)---- It sounds like you have most of the functionality already. USA processing uses various other parts of the ACD interface: o database names form the emboss.defaults file o sequence formats from the emboss.defaults file and the command line o debugging calls which are redirected through the ACD options .. and of course applications look exactly like any other EMBOSS application to end users, and can be integrated with any other interface on top of EMBOSS (AppLab for example) --------------------------------------------- ---from Peter Rice, 6/2/99 (EMBOSS list)----- >1) Do you plan to make a "DNA Strider"-like application, with a GUI? EMBOSS is command line driven with the specific aim of running it under any GUI that can cope. Examples we are looking at, though implementations are some way off, include AppLab from the EBI.... --------------------------------------------- ---from Peter Rice, 7/20/99 (Loci list)------ EMBOSS appears to be command line based, but internally it uses a simple "AJAX command definition" file (the idea comes from VMS). These "ACD" files can be converted to other GUI definitions, so that we hope to automate implementing EMBOSS under most other GUIs in bioinformatics. There are many of these around the EMBnet community and beyond. Examples are BioNavigator (eBioinformatics and EMBnet Australia) AppLab (Martin Senger, EBI), W2H (Martin Senger and EMBnet Germany), www2gcg (EMBnet Belgium), SRS applications (EBI and Lion), ACEDB utilities (Sanger Centre and Montpelier), Staden (Rodger Staden, Cambridge), SeqPup (Don Gilbert, Indiana).... --------------------------------------------- I'd put AppLab in the list of programs most like Loci. Like a couple others, AppLab's description could be mistaken for Loci's. The major difference, however, is Loci's Workspace, which provides a unique (if not intuitive) approach to distributed data processing. Of course, AppLab is Java-based, while Loci is mostly Python/C-based. Loci is trying for a high degree of language independence, which AppLab gives too by wrapping command-line programs. But the GUI components of Loci can also be 'written' in any language. AppLab has a 'copyright-only' license, which makes it essentially freeware. The good news for Loci is that we can learn a lot from the CORBA implementation and command-line wrapping scheme they have used. I'd like to know if anyone on this list has actually used AppLab, besides Peter Rice :-) Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Sat Oct 9 17:28:31 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:54 2006 Subject: [Pipet Devel] MySQL GPL Message-ID: <37FFB37F.F3F2D06D@bc.edu> Greetings. An older version of the MySQL database was released under the GNU GPL license. Being GPL'd, I would say it is the best database under that license. I wonder if someone could make use of this for a free (as in free speech) bioinformatics database. I have a copy residing on The Open Lab server: http://bioinformatics.org/resources/download/MySQL_GPL-3.20.32a.tar.gz (4.4 MB) Here is snippet from the README-ABOUT-GPL-VERSION file. It appears they will continually release older versions under the GPL. ----------------- This is a GPL release of MySQL, a SQL database server. [...] The next stable version of MySQL (next is 3.21.34) will normally be released as a GPL version when the next major version of the commercial MySQL is declared stable. [...] All new clients for the commercial MySQL version should also work with this release. Tables from this release is usable with all 3.x MySQL servers. [...] It has been used in production for long periods of time, but even then it may have some bugs. The MySQL team will not update this version until the next GPL release. ----------------- Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Sat Oct 9 17:44:44 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] [Fwd: LOCI documentation] Message-ID: <37FFB74C.8C39DA4C@bc.edu> Sorry David, but I thought this should be posted on the list :-) -------------- next part -------------- An embedded message was scrubbed... From: David Lapointe Subject: LOCI documentation Date: Sat, 9 Oct 1999 16:54:20 -0400 Size: 10762 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991009/36666a56/attachment.mht From bizzaro at bc.edu Sat Oct 9 17:57:28 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: LOCI documentation Message-ID: <37FFBA48.E37F911F@bc.edu> David Lapointe wrote: > > I was just fooling around with this. Maybe I could accumulate > documentation as it becomes available into a > LOCI HowTo. This is the HTML output of a DocBook based > SGML document. KInd of industrial grade but fun > neverthe less. Excellent! What program did you use to generate this...DocBook? I'll make a new module, loci-doc, for this. > The new core looks good. Thanks. If you checkout the latest version on the CVS, you'll see I've been working on the icons. I'm going for a BeOS-style for them, since I think the BeOS icons are about the most attractive around. I'm also using color coding for the dots at the ends of lines: red for unconnected lines and green for connected. I still have to get the connections to work right though. Cheerios. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Sat Oct 9 19:29:11 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: LOCI documentation References: <37FFBA48.E37F911F@bc.edu> Message-ID: <37FFCFC7.F46E09C2@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > David Lapointe wrote: > > > > I was just fooling around with this. Maybe I could accumulate > > documentation as it becomes available into a > > LOCI HowTo. This is the HTML output of a DocBook based > > SGML document. KInd of industrial grade but fun > > neverthe less. > > Excellent! What program did you use to generate this...DocBook? I'll make a > new module, loci-doc, for this. Great news! I have just completed the new web pages for TOL/Loci and the DocBook documentation is a perfect fit-- I had planned on using docbook to document loci as well-- lets get the documentation source onto the cvs tree so we can work on it together! BTW I think I will begin putting up the new pages onto the bioinformatics.org today. Feel free to preview them at http://gvd.v-wave.com --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Sat Oct 9 20:44:19 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: LOCI documentation References: <37FFBA48.E37F911F@bc.edu> <37FFCFC7.F46E09C2@redpoll.pharmacy.ualberta.ca> Message-ID: <37FFE163.8F17AE25@bc.edu> Gary Van Domselaar wrote: > > Great news! I have just completed the new web pages for TOL/Loci and > the DocBook documentation is a perfect fit-- I had planned on using > docbook to document loci as well-- lets get the documentation source > onto the cvs tree so we can work on it together! The module is already on the CVS, and it's called 'loci-doc'. Below is a copy of the instructions for using CVS at TOL. Anyone with a shell account can access and modify it. > BTW I think I will > begin putting up the new pages onto the bioinformatics.org today. Feel > free to preview them at > http://gvd.v-wave.com Shaggedelic! And I see PyORBit got a new Web page out of this :-) Do you think we'll need a CVS module for the Web pages? I think Gnome uses CVS for their site. ------------- (1) Set the environment variable. is your shell account user name. For bash, use $ export CVSROOT=':pserver:@bioinformatics.org:/home/cvs' For csh, use $ setenv CVSROOT ':pserver:@bioinformatics.org:/home/cvs' (2) Login. $ cvs login CVS will ask for your password. This will be your shell account pw. (3) To "checkout" a module, use the command by the same name. $ cvs checkout This will create a directory called ./ (within the pwd) with everything in it. (4) You can cd to the new directory and make whatever changes you want. (5) When you add or remove a file, you need to notify CVS. Let's say you created a README file. $ cvs add README (6) Once you have finished working in the directory, commit the changes. $ cvs commit This will commit everything in the pwd, since no specific file was specified. You can also specify a file. (7) Newer versions of CVS support logouts. $ cvs logout (8) You can start all over again at a later time, but it is likely the module will have been changed by someone else. In the directory where you created the directory, rename to something else (say "-old") if you want to keep it. Otherwise typing "cvs checkout " may change some things. If you want to update the copies of the files you have, you can use the "update" command. $ cvs update Remember that the checkout command is used in the parent directory to the directory. The other commands are used within the directory itself. (9) You can also make a new module with the "import" command. $ cvs import -m "" Note that the -m option lets you put in a message without starting an editor. Otherwise CVS will start up $EDITOR. (10) If you would like to see a list of the cvs commands, you can use the "help" command. $ cvs help ------------- Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Sat Oct 9 20:50:37 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: LOCI documentation References: <37FFBA48.E37F911F@bc.edu> <37FFCFC7.F46E09C2@redpoll.pharmacy.ualberta.ca> <37FFE163.8F17AE25@bc.edu> Message-ID: <37FFE2DD.CBEDFAFC@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Gary Van Domselaar wrote: > > > > Great news! I have just completed the new web pages for TOL/Loci and > > the DocBook documentation is a perfect fit-- I had planned on using > > docbook to document loci as well-- lets get the documentation source > > onto the cvs tree so we can work on it together! > > The module is already on the CVS, and it's called 'loci-doc'. Below is a copy > of the instructions for using CVS at TOL. Anyone with a shell account can > access and modify it. Jeff, is this truly the docbook 'source' from David, or the html rendered from the source (I haven't looked yet). BTW the CVS instructions are on the new web pages ;-) -- gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Sat Oct 9 21:08:38 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: LOCI documentation References: <37FFBA48.E37F911F@bc.edu> <37FFCFC7.F46E09C2@redpoll.pharmacy.ualberta.ca> <37FFE163.8F17AE25@bc.edu> <37FFE2DD.CBEDFAFC@redpoll.pharmacy.ualberta.ca> Message-ID: <37FFE716.E244FF06@bc.edu> Gary Van Domselaar wrote: > > Jeff, is this truly the docbook 'source' from David, or the html > rendered from the source (I haven't looked yet). I don't know. There is a file called 'docbook.css' or something like that. I'm not familiar with DocBook, so David will have to answer that. > BTW the CVS > instructions are on the new web pages ;-) I saw them, thanks! Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From dlapointe at mediaone.net Sat Oct 9 22:30:35 1999 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] (no subject) Message-ID: <99100922345702.01108@celery> DocBook source, but what I sent was html rendered from it. Article ArtHeader Sect1 Sect2 SGML stuff. More info at http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro/docbook-intro.html -- .david David Lapointe If you are not confused you're not paying attention. -- Will Durst From dlapointe at mediaone.net Sun Oct 10 00:00:03 1999 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Loci-doc updated. Message-ID: <99101000193006.01108@celery> I have added the source document (loci.sgml) to the CVS repository. Subject:Wildly off-topic Those interested in technical documents might want to look at this discussion. http://www.ntlug.org/~kclark/roadmap/ and the (sadly) defunct sgmltools project http://www.sgmltools.org See also the official word http://www.oasis-open.org/docbook/ http://nwalsh.com/docbook/dsssl/doc/ -- .david David Lapointe "What we obtain too cheap, we esteem too lightly." - T.Paine From hortiz at neurobio.upr.clu.edu Mon Oct 11 16:29:17 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] MARC: msg 'the MICO/CORBA issue.' Message-ID: <3802489D.7FDFD3B3@neurobio.upr.clu.edu> I found this on the KDE developer's forum. Looks like KDE is dropping pure corba based components too (gnome did this a while back, ORBit already supports shared libs as components). http://lists.kde.org/?l=kde-core-devel&m=93734188322527&w=2 KDE 2x or 3 will have a KDE widget based component library (like bonobo?). From bizzaro at bc.edu Mon Oct 11 18:48:11 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] MARC: msg 'the MICO/CORBA issue.' References: <3802489D.7FDFD3B3@neurobio.upr.clu.edu> Message-ID: <3802692B.71AFBC69@bc.edu> Humberto Ortiz Zuazaga wrote: > > I found this on the KDE developer's forum. Looks like KDE is dropping > pure corba based components too (gnome did this a while back, ORBit > already supports shared libs as components). > > http://lists.kde.org/?l=kde-core-devel&m=93734188322527&w=2 > > KDE 2x or 3 will have a KDE widget based component library (like > bonobo?). They stated the same thing a little more formally in a Linux Today article: http://linuxtoday.com/stories/10975.html The comments posted by some readers are interesting as well. >From what I gathered, KDE is concerned that CORBA is overkill (and too slow) for user interface components and document embedding. They say that CORBA is best for distributing objects across a network but that nobody is really going to want to run a GUI across a network. So, KDE is planning on making a 'local library' to handle these things without CORBA. I _think_ Bonobo uses CORBA and is not quite what the KDE people had in mind. Preaching: It's pretty amazing how the Gnome and KDE developers seem to just want to reinvent the wheel for the sake of getting to invent _something_. They have collaborated on a few minor issues lately, but the KDE 2x plan shows that they are unwilling to touch (or help with) Gnome projects that may do just what they want and help consolidate the desktop effort. As for Loci, I think what KDE says about the shortcomings of CORBA for GUI components is valid. The approach we want to take is to get the GUI information transferred quickly and _once_, via an XML description. We wrote about this at length in the past. If the user needs a low-level component, Loci will point to where it can be downloaded from, and the sysadmin will have to install it. We won't be taking the high-bandwidth X-Windows approach of running low-level components interactively through the Internet. Any other thoughts? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Mon Oct 11 19:03:15 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] MARC: msg 'the MICO/CORBA issue.' References: <3802489D.7FDFD3B3@neurobio.upr.clu.edu> <3802692B.71AFBC69@bc.edu> Message-ID: <38026CB3.1B04A20B@bc.edu> "J.W. Bizzaro" wrote: > > We won't be taking the high-bandwidth X-Windows approach of running > low-level components interactively through the Internet. Additional thought: Internet bandwidth may increase 10-fold in the next 10 years, making the interactive approach viable. But on the other hand, the number of people on the Internet may increase 10-fold. In any case, the software development world will be different, and who knows if players like CORBA will still be used? :-) Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Tue Oct 12 00:17:56 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] [Fwd: A good read] Message-ID: <3802B674.F9FDB2B5@bc.edu> >From the gnome-devel list... -------------- next part -------------- An embedded message was scrubbed... From: "Sergey I. Panov" Subject: Re: A good read Date: Mon, 11 Oct 1999 23:25:29 -0400 (EDT) Size: 2412 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991012/6d215d2a/attachment.mht From lisss at ydab.se Tue Oct 12 10:47:51 1999 From: lisss at ydab.se (Svanberg Liss) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] RE: msg 'the MICO/CORBA issue.' Message-ID: <40DEF2EE1151D311BC520050047B4145018E52@195-66-34-2.itv.se> > From what I gathered, KDE is concerned that CORBA is overkill (and too slow) for > user interface components and document embedding. They say that CORBA is best > for distributing objects across a network but that nobody is really going to > want to run a GUI across a network. So, KDE is planning on making a 'local > library' to handle these things without CORBA. I think ORBit is quite fast. I recall that Elliot has said that it's allmost as fast as a plain shared library, when running it on a local machine... I'm not sure if this is correct, but I know that ORBit is *very* fast, compared to many other ORB's. ( including Micro$oft's DCOM, which isn't CORBA but often is compared to CORBA ) > I _think_ Bonobo uses CORBA and is not quite what the KDE people had in mind. Yes, bonobo uses CORBA. Bonobo allso has got a shared library. From what I've understood, the shared library is just a way to make it easier to write bonobo applications, and not to make them faster , because it is simply a big wrapper around the CORBA stuff. Gnome was using MICO in the beginning, but they stopped using it because they thought it was too slow (just after I had got it running ;), and created their own ORB with speed in mind. KDE on the other side, are [still] using MICO, so I think this think about "CORBA is to slow" is more of a KDE matter than a Gnome/Bonobo. > As for Loci, I think what KDE says about the shortcomings of CORBA for GUI > components is valid. The approach we want to take is to get the GUI information > transferred quickly and _once_, via an XML description. We wrote about this at > length in the past. If the user needs a low-level component, Loci will point to Ok, there is a good point here. Anyone can put their own GUI togeather in runtime, whit a little scripting ( or perhaps a lot of scripting :) No bandwidth is wasted just to make things run. But the same approach is possible using CORBA, you are just not bound to run everything locally. // Liss From bizzaro at bc.edu Tue Oct 12 18:18:07 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] RE: msg 'the MICO/CORBA issue.' References: <40DEF2EE1151D311BC520050047B4145018E52@195-66-34-2.itv.se> Message-ID: <3803B39F.3B057A81@bc.edu> Svanberg Liss wrote: > > Ok, there is a good point here. > Anyone can put their own GUI togeather in runtime, whit a little scripting ( > or perhaps a lot of scripting :) > No bandwidth is wasted just to make things run. > > But the same approach is possible using CORBA, you are just not bound to run > everything locally. I guess we agree. The way I see these object models working in Loci: CORBA - Allow non-Python components to communicate with the Workspace/Daemon - Allow remote components " " " " " Bonobo - Allow Loci 'viewers' to be embedded in Gnome applications XML/DOM - Allow low-bandwidth specification of user interface components, including the recombination of interfaces a la 'composite' loci. - Allow filesystem-based storage and databasing of loci. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From hortiz at neurobio.upr.clu.edu Thu Oct 14 10:12:28 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] We found our installer Message-ID: <199910141412.KAA11820@chimbo.neurobio.upr.clu.edu> I found this blurb in this weeks gnome news: Loki's new GPL Setup 1.0 installer uses libglade and libxml for its user interface. libglade loads an XML file generated by the Glade GUI builder at runtime, giving you the ability to tweak your widget layout in Glade without recompiling your application. Setup 1.0 uses XML to describe the application to be installed, as well as for the GUI. Have a look: http://www.lokigames.com/development/setup.php3 libglade and libxml are some of the most exciting features of the GNOME development environment, so it's sweet to see them in production use. -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From bizzaro at bc.edu Thu Oct 14 17:18:55 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] SYNERGY Message-ID: <380648BF.71D5ABFD@bc.edu> Locians, Gary sent me a link to this 'paper' from NetGenics titled "NetGenics White Papers - A CORBA-Java Framework for Drug Discovery": http://www.netgenics.com/white_paper.html If you haven't heard of this product, I suggest you read this paper. Actually, if you are at all interested in the CORBA-based framework for Loci, you REALLY need to read this thoroughly! Why? Because this is almost exactly what we had in mind for Loci's infrastructure, with the exception of some different wording. Here's a SYNERGY <-> Loci translation of terms: Client == GUI interface, such as a Viewer Locus Server == Processor Locus Project Manager == Loci Daemon Analysis Manager == Loci Hub This goes to show that the use of CORBA in bioinformatics is not new, and that it doesn't take much to derive a 'framework' for data-type and language-independent analyses. I didn't find any information on pricing for SYNERGY or even screenshots. Informax's VectorNTI is another commercial application that uses a similar (although I think not CORBA-based) framework: http://www.informaxinc.com/products/vntisuite/index.html The framework may not be unique, but Loci's Workflow Diagram, project management and graphical programming language in this environment could be. How else can we improve upon this now 'common' framework? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Oct 14 17:35:17 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: SYNERGY References: <3805610E.1279A89C@bc.edu> <38058368.8F782037@redpoll.pharmacy.ualberta.ca> Message-ID: <38064C95.FC7CCA2F@bc.edu> Humberto Ortiz Zuazaga wrote: > > Jeff, post it to the list, I don't see any point in keeping it a secret. Since their design is so close to ours, I am a bit concerned that NetGenics may _claim_ that we stole it. On the other hand, we've been discussing Loci in an open forum for a year now, so maybe they stole _our_ design :-) Seriously, we are dealing with a commercial entity, and they get pretty nasty when it comes to intellectual property, as I have had first hand experience with such matters. Nevertheless, I'll post it. If NetGenics complains, I'll tell them to go bite me. Gary Van Domselaar wrote: > > I'm not discouraged by this white paper, on the contrary, I'm happy that > other people are validating the conclusions that we have drawn. Yeah. > Here > are my (initial) thoughts on the advantages of loci of the the netgenics > model: > > 0. Loci is data independent, netgenetics in bioinformatics-centric Right. Speaking a data independence. It looks as though SYNERGY uses an internal format for their biodata, which we have decided against. An internal format requires 2 conversions between incompatible components: GENBANK 1 Internal 2 Analysis document ---> format ---> that doesn't read GENBANK The 'converter locus' scheme that Loci uses, would do only 1 conversion via the converter. > 1. Loci is free under LGPL, netget is definitely Not. Yep. > 2. We are free to use the concepts provided by netgen to evaluate and > refine our model. How free? Did you see any statement to that effect? > 3. NetGenics is vary vague about the actual client/server apps that > will plug in to their architecture Will they provide them? Will others? Hmmm. Unless they are trying to develop an open standard. > 3. Loci provides a graphical scripting language for the construction of > complex data processing systems in a 'batch' or 'pipeline' mode, the > netgenics white pages are very vague on this subject, as are they on the > status of their project. There are several innovations we have made beyond the basic framework. > maybe we'll wait and see? Maybe we will beat > them to the punch. This raises the issue of completing our design and > implementing our code. with Justin et al's work on the pyortit project, > and H. Mangalam's command line, pipeline-ready bioinformatics apps (for > designing, developing, and testing our network object model), we may be > further along with the loci network object model framework & testing > plug-in architecture than we might think. Time is of the essence. > (Jeff: it may be time to get a > global status report on loci soon anyways). Ahem. Yeah, I was planning on do something a la Gnome status report pretty soon. > 4. Netgenics will be charging big dollars for their framework, we will > be charging 0 dollars for our framework. I suppose. > 5. They will be running through Java, which IMHO sucks pretty bad. its > more example of pushing the web to places where it was not really > intended. Why is it there are so many Java apps for bioinformatics, yet no one seems to use them? > P.S. Paul Stothard (my roomate found and ad for Netgenics in Nature in > the last journal-- they may be recruiting for developers. I'mnot sure > how far beyond vaporware they are at the moment. Maybe we'll all go work for them :-) > In summary, I say we look at their proposal, also at APpLab, and we > adopt the idl protocols outlined in applap, which are largely consistent > with the OMG RFP for biomolecular proposed IDL in the OMG adoption > process (RFP for Biomolecular Sequences analysis) and when it is > adopted: We are certainly free to borrow ideas from AppLab. > from lifesciences home page: > http://www.omg.org/homepages/lsr/agendas/cambridge.html > > The Cambridge Meeting will be even more action-packed with the following > plannedactions: > Vote on recommendation to adopt Biomolecular Sequence > Analysis RFP Joint Revised Submission > Vote on recommendation to adopt Genomic Maps Joint Revised > Submission (following vote-to-vote) > Issue Clinical Trials Laboratory Data Interchange RFP > Finalize Entity Identification RFP (to be issued at the > January meeting) > Draft Cheminformatics RFP (to be issued at the January > meeting) > Draft Gene Expression RFP (to be issued at the January > meeting) > > (there is a vote in Cambridge MA on 15-19 November 1999 > Who's able to attend? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Oct 14 17:46:07 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] We found our installer References: <199910141412.KAA11820@chimbo.neurobio.upr.clu.edu> Message-ID: <38064F1F.1448990@bc.edu> Setup was mentioned on Slashdot the other day. I downloaded it and took a gander at it. It is nice that it is GPL and uses GTK (which we use), libglade (which is like what I am trying to implement on the Workspace for dynamic GUI generation) and libxml (which we will be using). It is 2 MB (!) however, compared to Loci's 39 kB right now, and Setup seems to be aimed at creating a bootable image on CDs...Maybe good for a CD distribution of Loci? Cheers. Jeff Humberto Ortiz Zuazaga wrote: > > I found this blurb in this weeks gnome news: > > Loki's new GPL Setup 1.0 installer uses libglade and libxml for its > user interface. libglade loads an XML file generated by the Glade GUI > builder at runtime, giving you the ability to tweak your widget layout > in Glade without recompiling your application. > > Setup 1.0 uses XML to describe the application to be installed, > as well as for the GUI. Have a look: > > http://www.lokigames.com/development/setup.php3 > > libglade and libxml are some of the most exciting features of the > GNOME development environment, so it's sweet to see them in production > use. > -- > Humberto Ortiz Zuazaga > Bioinformatics Specialist > Institute of Neurobiology > hortiz@neurobio.upr.clu.edu > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at bc.edu Thu Oct 14 18:33:29 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] what we're dealing with Message-ID: <38065A39.300AF1C5@bc.edu> Companies usually have little to lose and much to gain by legal action, even if it all seems pretty silly: http://www.wired.com/news/print/1,1294,31884,00.html Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From stein at fmppr.fmnh.org Thu Oct 14 18:43:37 1999 From: stein at fmppr.fmnh.org (J. Steinbachs) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: SYNERGY References: <3805610E.1279A89C@bc.edu> <38058368.8F782037@redpoll.pharmacy.ualberta.ca> <38064C95.FC7CCA2F@bc.edu> Message-ID: <38065C99.8881D32B@fmnh.org> > > > 5. They will be running through Java, which IMHO sucks pretty bad. its > > more example of pushing the web to places where it was not really > > intended. > > Why is it there are so many Java apps for bioinformatics, yet no one seems to > use them? > Because Java is slow? :) I have yet to see a good speedy java app that actually does something.... Thinking of apps... Check out this recent issue of Bioinformatics: Milanesi et al. GeneBuilder: interactive in silico prediction of gene structure. 15(7/8):612-621 web version of genebuilder can be found at http://www.itba.mi.cnr.it/webgene Kolchanov et al. Integrated databases and computer systems for studying eukaryotic gene expression. 15(7/8):669-686 http://wwwmgs.bionet.nsc.ru/systems/GeneExpress -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 -------------------------- From pmr at sanger.ac.uk Fri Oct 15 04:47:33 1999 From: pmr at sanger.ac.uk (pmr@sanger.ac.uk) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: SYNERGY In-Reply-To: <38064C95.FC7CCA2F@bc.edu> (bizzaro@bc.edu) References: <3805610E.1279A89C@bc.edu> <38058368.8F782037@redpoll.pharmacy.ualberta.ca> <38064C95.FC7CCA2F@bc.edu> Message-ID: <199910150847.JAA517013@unst.sanger.ac.uk> Jeff, >Since their design is so close to ours, I am a bit concerned that >NetGenics may _claim_ that we stole it. On the other hand, we've been >discussing Loci in an open forum for a year now, so maybe they stole >_our_ design :-) Seriously, we are dealing with a commercial entity, >and they get pretty nasty when it comes to intellectual property, as I >have had first hand experience with such matters. I have met the NetGenics folk at a couple of conferences, and they seemd very happy to discuss Synergy and public domain software. They have shown interest in EMBOSS and they could be interested in working with Loci. One of the nice things about CORBA is the way it encourages developers to work together. It becomes very hard to do that if you also want to be aggressive about intellectual property. I would recommend contacting them and see what they have to say. Wonder whether they are aware of Loci yet? >I didn't find any information on pricing for SYNERGY or even screenshots. Screenshots and more information are available at: http://www.netgenics.com/SYNERGY.html >From the nature of Synergy I would guess pricing is customised for each customer, but I have no idea what level they pitch it at. Peter -- ---------------------------------------------------------------------- Peter Rice | Informatics Division, The Sanger Centre, E-mail: pmr@sanger.ac.uk | Wellcome Trust Genome Campus, Tel: (44) 1223 494967 | Hinxton, Cambridge, CB10 1SA, England Fax: (44) 1223 494919 | URL: http://www.sanger.ac.uk/Users/pmr/ From hortiz at neurobio.upr.clu.edu Fri Oct 15 15:55:31 1999 From: hortiz at neurobio.upr.clu.edu (Humberto Ortiz Zuazaga) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] Re: SYNERGY In-Reply-To: Your message of "Thu, 14 Oct 1999 21:35:17 GMT." <38064C95.FC7CCA2F@bc.edu> Message-ID: <199910151955.PAA25352@chimbo.neurobio.upr.clu.edu> > > 0. Loci is data independent, netgenetics in bioinformatics-centric > > Right. Speaking a data independence. It looks as though SYNERGY uses an > internal format for their biodata, which we have decided against. An internal > format requires 2 conversions between incompatible components: > > GENBANK 1 Internal 2 Analysis > document ---> format ---> that doesn't > read GENBANK > > The 'converter locus' scheme that Loci uses, would do only 1 conversion via the > converter. Jeff, you've got this exactly backwards. We need an internal format, we decided it would be xml based, perhaps extended BSML. Converters should be written to any format to ours and from any format to ours, otherwise we get to write a converter for every pair of formats we support. Example, image we want to support 4 file formats: genbank - internal pdb - internal fasta - internal bsml - internal vs converters between the same 4 formats: genbank - pdb genbank - fasta genbank - bsml pdb - fasta pdb - bsml fasta - bsml this comparison gets worse as you add more file formats. This is why the netpbm tools all convert to pnm files. What we had decided is that we can defer defining our file formats until we actually have any loci that use them, and that we can have many small languages instead of a big language that tries to capture all possible data types. So we'll have an internal format for nucleotide sequences, one for amino acid sequences, one for multi sequence objects, one for sequence annotations, one for bibliographic references, ... -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz@neurobio.upr.clu.edu From bizzaro at bc.edu Sun Oct 17 00:24:37 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] converters (was Re: SYNERGY) References: <199910151955.PAA25352@chimbo.neurobio.upr.clu.edu> Message-ID: <38094F85.939A8EC@bc.edu> Humberto Ortiz Zuazaga wrote: > > Jeff, you've got this exactly backwards. We need an internal format, we > decided it would be xml based, perhaps extended BSML. Converters should be > written to any format to ours and from any format to ours, otherwise we get to > write a converter for every pair of formats we support. > > Example, image we want to support 4 file formats: > > genbank - internal > pdb - internal > fasta - internal > bsml - internal On the other hand, the requirement of an internal format would force Loci to do 2 conversions: genbank - internal - genbank pdb - internal - pdb fasta - internal - fasta bsml - internal - bsml where NONE would be needed without an internal format: genbank - genbank (not needed) pdb - pdb (not needed) fasta - fasta (not needed) bsml - bsml (not needed) > vs converters between the same 4 formats: > > genbank - pdb > genbank - fasta > genbank - bsml > pdb - fasta > pdb - bsml > fasta - bsml Maybe if we use a temporary, intermediate format used only during conversion, it would be much simpler plugging 2 formats together. From my experience writing converters, some intermediate format is usually needed anyway. So, each converter is built by connecting 2 parts together: genbank - internal <---> internal - pdb pdb - internal <---> internal - bsml fasta - internal <---> internal - genbank bsml - internal <---> internal - fasta The problem is, yeah, we're still doing 2 conversions. But if the 'internal' format is not a file format (such as XML), it should be quicker and require less disk space. > What we had decided is that we can defer defining our file formats until we > actually have any loci that use them, and that we can have many small > languages instead of a big language that tries to capture all possible data > types. All I am against is just that: a big language that tries to capture all possible types, therefore needing to be redefined each time we add a new file format to Loci, and requiring file system reads/writes each time a conversion is done. We have to ask ourselves this when thinking about the conversion process: How is Loci going to handle data from the Genome Projects, where an annotated file may be gigabytes to terabytes in size??? > So we'll have an internal format for nucleotide sequences, one for amino acid > sequences, one for multi sequence objects, one for sequence annotations, one > for bibliographic references, ... I'd agree to having an internal format that is really many smaller specialized formats, if you'd agree that they are used to BUILD converters, for QUICK conversions, only AS NEEDED, like I wrote above. Again... A big language that tries to capture all possible types, therefore needing to be redefined each time we add a new file format to Loci, and requiring file system reads/writes each time a conversion is done Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Mon Oct 18 00:41:25 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:55 2006 Subject: [Pipet Devel] converters (was Re: SYNERGY) References: <199910151955.PAA25352@chimbo.neurobio.upr.clu.edu> <38094F85.939A8EC@bc.edu> Message-ID: <380AA4F5.66294350@redpoll.pharmacy.ualberta.ca> > > Example, image we want to support 4 file formats: > > > > genbank - internal > > pdb - internal > > fasta - internal > > bsml - internal > > On the other hand, the requirement of an internal format would force Loci to do > 2 conversions: > > genbank - internal - genbank > pdb - internal - pdb > fasta - internal - fasta > bsml - internal - bsml Like Humberto mentioned recently, pbmtools automatically converts everything to an internal format, then reparses it out to the desired format. NCBI does the same with their all-encompassing ASN.1 format. So, in the data-independent Loci model, how would Loci's internal format be implemented as a plug-in? Would the plug-in developer be responsible to create a locus that converts all incoming data to an internal format, like so: ______ |Data|<----idl/api<----Request document |Base| | | ______----->idl/api---->document--->conversion--------->processing-->result---storage(database, to "loci" internal (file, etc). format-then parse to required format If this is the model, its seems to me that a great deal of work would befall on the plug-in developers, and the Loci framework itself would be quite minimal (which is not a bad thing). This begs the question, how will the loci plug-in to the Loci architecture? What would Loci be, at this data-independent core? I'm not an expert on network-object models, or data object models, or databases for that matter, so these issues frighten and confuse me. I'm beginning to write up the Loci white-pages, so some enlightenment on these issues would go a long way to help me write intellible stuff! I have read a bit about AppLab (a Java-based command-line application wrapper that runs throught CORBA). AppLab is very similar to our design, although it is bioinfo-centric, as is NetGenics SYNERGY. How do we decouple the nature of the data from the data-framework itself? > genbank - genbank (not needed) > pdb - pdb (not needed) > fasta - fasta (not needed) > bsml - bsml (not needed) Ineresting. What scenario do you envision for this data 'passthru' scheme? A genbank doc could be connected to a genbank-readable processor/widget/whatever without the need of passing thru a convertor, therefore, no wasted conversion time or resources. Similarly, a convertor could be constructed to realize that internal format conversion is not necessary and simply relay the data (ie in dynamic situations where the format of the incoming data, or the requirements of the receiving locus are not known in advance). Comments anyone? > > > vs converters between the same 4 formats: > > > > genbank - pdb > > genbank - fasta > > genbank - bsml > > pdb - fasta > > pdb - bsml > > fasta - bsml > > Maybe if we use a temporary, intermediate format used only during conversion, it > would be much simpler plugging 2 formats together. From my experience writing > converters, some intermediate format is usually needed anyway. > > So, each converter is built by connecting 2 parts together: > > genbank - internal <---> internal - pdb > pdb - internal <---> internal - bsml > fasta - internal <---> internal - genbank > bsml - internal <---> internal - fasta > > The problem is, yeah, we're still doing 2 conversions. But if the 'internal' > format is not a file format (such as XML), it should be quicker and require less > disk space. What are you thinking? I recall from the bioobjects project (from the bioinformatics journal .pdf that gotcirculated a while back) that the biosequence data is abstracted into its basic types: raw sequence data, internal id, Locus or Accession number, references (including bibliographic, organism, etc), x-refs to other databases, and feature information. these data structures are then assembled into an object and stored in and object database for access via CORBA.... > > > What we had decided is that we can defer defining our file formats until we > > actually have any loci that use them, and that we can have many small > > languages instead of a big language that tries to capture all possible data > > types. > > All I am against is just that: a big language that tries to capture all possible > types, therefore needing to be redefined each time we add a new file format to > Loci, and requiring file system reads/writes each time a conversion is done. > > We have to ask ourselves this when thinking about the conversion process: > > How is Loci going to handle data from the Genome Projects, where an > annotated file may be gigabytes to terabytes in size??? I'm stymied on this one... ;-) > > > So we'll have an internal format for nucleotide sequences, one for amino acid > > sequences, one for multi sequence objects, one for sequence annotations, one > > for bibliographic references, ... > > I'd agree to having an internal format that is really many smaller specialized > formats, if you'd agree that they are used to BUILD converters, for QUICK > conversions, only AS NEEDED, like I wrote above. --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd From bizzaro at bc.edu Tue Oct 19 11:13:14 1999 From: bizzaro at bc.edu (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] PyGTK ported to Windows Message-ID: <380C8A8A.693431B7@bc.edu> >From Kevin Butler: ------------- Well, after countless hours of thinking, "I ought to port it", and even more hours wishing someone else would port it, I went ahead and did it. I ported PyGTK to Win32. Read all about it at: http://www.geocities.com/kevin_j_butler/pygtk/ Comments, suggestions, code fixes, etc. welcome. kb PS For those who may have received a previous announcement, note that I've updated the port to pygtk-0.6.3... ------------- Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at geoserve.net Thu Oct 21 08:01:47 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] CORBA and The GNOME Message-ID: <380F00AB.FA49D449@geoserve.net> >From http://developer.gnome.org/doc/guides/corba/ CORBA is used everywhere in The GNOME. The aim of this paper is to give the reader enough knowledge of CORBA to understand how it is dispatched in The GNOME. This Paper is also an detailed introduction to Bonobo's CORBA interfaces. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at geoserve.net Thu Oct 21 09:52:46 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] SOAP Message-ID: <380F1AAE.F5551734@geoserve.net> >From http://news.cnet.com/news/0-1003-200-853508.html The new technology, called the Simple Object Access Protocol (SOAP), based on the increasingly popular Web standard for data exchange called the Extensible Markup Language (XML), will let business software programs communicate over the Internet, regardless of the programming model on which they're based. Jeff From bizzaro at geoserve.net Fri Oct 22 15:25:51 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] another app to look at Message-ID: <3810BA3F.48DF9511@geoserve.net> >From http://www.cerebellumsoft.com/products/index.shtml "Cerebellum is a robust data integration platform that provides features for easily accessing, integrating, and updating information from multiple data sources for use in new Web-based and enterprise applications. Cerebellum fits right in to a company's existing IT infrastructure to decrease the time and costs associated with e-business application development. It generates the code necessary to communicate with the data sources already in place and its API supports the customer's current development environment, whether it's C++, Java, Visual Basic, or a GUI tool." Here are a couple interesting screenshots: http://www.cerebellumsoft.com/slides/Slide9.html http://www.cerebellumsoft.com/slides/Slide10.html Cerebellum bears some resemblance to Clementine, mentioned before: http://www.isldsi.com/clementine.htm Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Tue Oct 26 16:09:18 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] yet another app: BioKRIS Message-ID: <199910262009.OAA06662@redpoll.pharmacy.ualberta.ca> Space Monkeys, Found this from a tibtech paper: http://www.kris-inc.com/KRIS/index.html Here's an excerpt: BioKRIS software provides computational workflow and data warehousing solutions for bioinformatics. BioKRIS solves challenging data integration tasks with a revolutionary mathematical query engine that speeds development time and dramatically improves query performance. BioKRIS can be used both as a stand-alone application or as a platform for integrating in-house tools into packaged applications. ------------ They also have links to a bunch of publications (~200 pages!) related to their core architecture, Kleisli and the collection programming language (CPL). --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at geoserve.net Wed Oct 27 13:48:44 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] The Open Lab (was Re: Tkinter) Message-ID: <38173AFB.10953FAD@geoserve.net> Jeffrey Chang wrote: > > We could use Tkinter to create a GUI for biopython. Is this worth > > exploring? > Also, I should mention that there are some open source projects working on > GUI's for bioinformatics. The Open Lab (http://bioinformatics.org/) has > some work going on developing GUI's with Python. We (The Open Lab) have a strong preference for Python, but we are not excluding any projects based on language. Our criterion for bioinformatics development projects is that the _license_ be compatible with the GNU GPL. As for software, we hope to be the Free Software Foundation (GNU) of bioinformatics. We also have research and information projects. > Another intriguing possibility would be to work through the CORBA > interface that Ewan's been working out. That way, bioperl and biopython > could share a GUI. But I'm getting ahead of myself... Along this line, The Open Lab is developing The Loci Project, which is a CORBA-based, Python-implemented graphical programming language for distributed data processing (bioinformatics in particular): http://bioinformatics.org/loci/ We (Justin Bradford et al.) are developing Python bindings to ORBit (GNU's CORBA system): http://bioinformatics.org/pyorbit/ This is the only free and open-source CORBA implementation for Python. I am curious about what Ewan is up to regarding Python and CORBA. Regarding the cross-platform capabilities of GTK (versus Tkinter), The Open Lab is hosting the only port of the PyGTK (GTK/Python bindings) widget set to the Windows OS: http://bioinformatics.org/pygtkwin/ We have mailing lists for all of our projects and we hope that more Python developers for bioinformatics will join in on the fun, as your own Jeff Chang has already contributed to the Python Phylogenetics project: http://bioinformatics.org/pyphy/ It's true that we have great interests in GUI development, and the BioPython project addresses infrastructure programming, which we have not so far. I think The Open Lab and BioPython as well as BioPerl all complement each other in that respect. Congratulations on starting this project, and I hope that we can work closely on some projects. Cheers. The other Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at geoserve.net Wed Oct 27 19:59:19 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] converters (was Re: SYNERGY) References: <199910151955.PAA25352@chimbo.neurobio.upr.clu.edu> <38094F85.939A8EC@bc.edu> <380AA4F5.66294350@redpoll.pharmacy.ualberta.ca> Message-ID: <381791D7.7C31BC21@geoserve.net> It's about time I got back to this :-) Gary Van Domselaar wrote: > > Like Humberto mentioned recently, pbmtools automatically converts > everything to an internal format, then reparses it out to the desired > format. NCBI does the same with their all-encompassing ASN.1 format. > So, in the data-independent Loci model, how would Loci's internal format > be implemented as a plug-in? Yes. Although an 'internal plug-in' is an oxymoron :-) I want (and I think everyone else here wants) as many aspects of Loci as possible to be plugged-in or modular. So instead of an 'internal format', I would call it a 'neutral conversion format'. And like any other data format, it is only present in Loci as long as the locuses are there to work with it. > Would the plug-in developer be responsible > to create a locus that converts all incoming data to an internal format, > like so: > > ______ > |Data|<----idl/api<----Request document > |Base| > | | > ______----->idl/api---->document--->conversion--------->processing-->result---storage(database, > to "loci" internal (file, etc). > format-then parse > to required format If the plug-in/locus developer is dealing with a data format new to Loci, they should provide SOME sort of converter. A converter that ouputs data in the neutral conversion format would be minimal. > If this is the model, its seems to me that a great deal of work would > befall on the plug-in developers, and the Loci framework itself would be > quite minimal (which is not a bad thing). I think the less that Loci comes standard with, the more malleable it will be, which is a Good Thing. > This begs the question, how will the loci plug-in to the Loci > architecture? What would Loci be, at this data-independent core? Locuses/loci should be able to (1) Communicate with the Workspace to send/receive GUI information (2) Communicate with a directory service or 'hub' establish the CORBA connections > I'm not an expert on network-object models, or data object models, or > databases for that matter, so these issues frighten and confuse me. I too am frightened and confused. > I'm > beginning to write up the Loci white-pages, so some enlightenment on > these issues would go a long way to help me write intellible stuff! I > have read a bit about AppLab (a Java-based command-line application > wrapper that runs throught CORBA). AppLab is very similar to our design, > although it is bioinfo-centric, as is NetGenics SYNERGY. How do we > decouple the nature of the data from the data-framework itself? As an example of how separate the data is from the data-framework, the data is kept as XML, and the data-frameowrk communicates via CORBA. These are very different models for data management and do not mix very well. All the CORBA system needs to know is that there is some text (XML) that needs to go somewhere. At least that's the way I see it. > > genbank - genbank (not needed) > > pdb - pdb (not needed) > > fasta - fasta (not needed) > > bsml - bsml (not needed) > > Ineresting. What scenario do you envision for this data 'passthru' > scheme? It's simple. We're just connecting output to input in every case. Data conversion means making 2 extra connections (adding a converter). If data conversion is not needed, which is true in the case I mentioned above, you just leave the converter out. If everything must be converted to an 'internal format', which is something I'm arguing against, then data conversion can never be left out. > A genbank doc could be connected to a genbank-readable > processor/widget/whatever without the need of passing thru a convertor, > therefore, no wasted conversion time or resources. Right. > Similarly, a > convertor could be constructed to realize that internal format > conversion is not necessary and simply relay the data (ie in dynamic > situations where the format of the incoming data, or the requirements of > the receiving locus are not known in advance). Comments anyone? IMO, you do not want to relay data when the format is unknown. I don't know, maybe it should just be saved. > What are you thinking? I recall from the bioobjects project (from the > bioinformatics journal .pdf that gotcirculated a while back) Shhh! > that the > biosequence data is abstracted into its basic types: raw sequence data, > internal id, Locus or Accession number, references (including > bibliographic, organism, etc), x-refs to other databases, and feature > information. these data structures are then assembled into an object and > stored in and object database for access via CORBA.... It's good to see someone reads the references I send them :-) The BioObjects project is certainly not data format independent. We could come up with a nice XML-based, cross-referenced data format for our neutral conversions. > > We have to ask ourselves this when thinking about the conversion process: > > > > How is Loci going to handle data from the Genome Projects, where an > > annotated file may be gigabytes to terabytes in size??? > > I'm stymied on this one... ;-) Well, we have to consider this. The trend in bioinformatics has been toward a great increase in the size of documents. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at geoserve.net Wed Oct 27 20:19:51 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] Re: SYNERGY References: <199910151955.PAA25352@chimbo.neurobio.upr.clu.edu> Message-ID: <381796A7.31D8A51D@geoserve.net> Humberto Ortiz Zuazaga wrote: > > Example, image we want to support 4 file formats: > > genbank - internal > pdb - internal > fasta - internal > bsml - internal > > vs converters between the same 4 formats: > > genbank - pdb > genbank - fasta > genbank - bsml > pdb - fasta > pdb - bsml > fasta - bsml Ah, but you really only need 3 (vs. 4 for an internal format)! genbank - pdb genbank - fasta genbank - bsml Because you can do this: pdb - genbank - fasta pdb - genbank - bsml fasta - genbank - bsml To get the other 3! Tee hee hee :-) Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Thu Oct 28 01:29:09 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] Re: SYNERGY References: <199910151955.PAA25352@chimbo.neurobio.upr.clu.edu> <381796A7.31D8A51D@geoserve.net> Message-ID: <3817DF25.F78C518F@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Humberto Ortiz Zuazaga wrote: > > > > Example, image we want to support 4 file formats: > > > > genbank - internal > > pdb - internal > > fasta - internal > > bsml - internal > > > > vs converters between the same 4 formats: > > > > genbank - pdb > > genbank - fasta > > genbank - bsml > > pdb - fasta > > pdb - bsml > > fasta - bsml > > Ah, but you really only need 3 (vs. 4 for an internal format)! > > genbank - pdb > genbank - fasta > genbank - bsml > > Because you can do this: > > pdb - genbank - fasta > pdb - genbank - bsml > fasta - genbank - bsml > > To get the other 3! or you could adopt the all-powerful asn.1 nested-data format which according to the ncbi crew can parse out just about any document ;-) -- gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada http://redpoll.pharmacy.ualberta.ca/~gvd