From bizzaro at geoserve.net Tue Nov 2 22:13:20 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] snapshot 19991102 Message-ID: <381FA850.DB57788F@geoserve.net> Locians, There is a snapshot of loci-core in the usual place: http://bioinformatics.org/loci/download/snapshots/ Some minor improvements have been made since last time. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at geoserve.net Wed Nov 3 14:28:09 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] slashdot post Message-ID: <38208CC9.A1FCEDFB@geoserve.net> Locians, I described Loci in a reply to someone's post at Slashdot. The article is about 3D window managers and how they are more efficient than the 2D kind. I call Loci an N-dimensional window manager: http://slashdot.org/comments.pl?sid=99/11/03/0917216&cid=172 Thought you might want to read it. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From bizzaro at geoserve.net Fri Nov 5 08:53:35 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:56 2006 Subject: [Pipet Devel] Re: loci tar file References: <001a01bf276e$26efd180$010a0a0a@0q6vm> Message-ID: <3822E15F.F0B0B909@geoserve.net> > Cayte wrote: > > When I opened the tar file with winzip, the Message > > "Error in reading header" appeared. Are you attempting to run Loci under Windows or just unpack it there? Loci will execute only in a UNIX environment; it's not made for Windows. I'm not sure if we made it that clear on the Web site. Either way, Loci is not a functional application yet. Let me know what you want to do with Loci. If you must use WinZip, I can put it in to a zip file for you. Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From mangalam at home.com Fri Nov 5 15:56:34 1999 From: mangalam at home.com (Harry Mangalam) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] New version of tacg: (mostly) free sequence analysis app References: <001a01bf276e$26efd180$010a0a0a@0q6vm> <3822E15F.F0B0B909@geoserve.net> Message-ID: <38234482.441A332E@home.com> Hi All, Version 3 of tacg is feature-complete and is ready for testing on as many platforms as you can run it on. It has been tested to various levels on Linux (Intel, alpha), Solaris, IRIX. It should compile on anything that supports gcc. Unfortunately, 'feature-complete' doesn't include a lot of things I was thinking about, including graphic restriction maps, XML output, more protein analyses, etc, etc, etc. That'll be next... I'm being overwhelmed with other obligations and consulting and so the final polishing, testing, and especially documenting is not going as fast as I thought it would (currently only tacg3.man.html and tacg.1 in the Docs subdirectory can give you any hint of what it does). BUT it is not GPL. Not to take anything away from RMS and it's not to say that someday it won't be, but for the forseeable future, it'll be 'mostly free', as defined in 'tacg.h'. But what that means for Loci is that as long as Loci is freely available, tacg can be bundled with it for no charge. I think that makes it advantageous to everyone (but I'm willing to be convinced otherwise)... I thought the loci group would be a good to release it to 1st as you're all pretty savvy about compilation and you might be able to give functional feedback instead of 'it doesn't work'. Here's the promo blurb - let me know what it dies on or how it can be made better. tacg is a command-line program that performs many of the common routines in pattern matching in biological strings. It was originally designed for restriction enzyme analysis and while that still forms a core of the program, it has been expanded to fill more roles, sort of a 'grep' for DNA. However, it is also more than that: a brief description of its abilities is at the bottom of this announcement. What it is not: - It is not a point and click graphical user program like Lasergene, MacVector, or even GCG's SeqLab. - It is not free, nor public domain, nor GPL, nor Open Source. It remains the intellectual property of tacg Informatics. However, that said, the distribution policy is meant to encourage widespread use. It is freely available to you in both binary AND SOURCE CODE for personal use and examination, with the only restriction being that you may not incorporate it into other software that is sold for profit without licensing it for that purpose. I will be happy to consider making specific exemptions for copies to be included with certain distributions of Linux and other collections of software. What it is: - It is a commandline tool, albeit one designed for humans. It has compiled-in brief help hints, a decent man page (and expanded version thereof in the HTML version) and a full length manual as well. - It was written congruent to the philosophy that most large-scale bioinfomatics will done in a pipeline and therefore the tools for those analyses should support pipelines as much as possible. It is also highly applicable to Web interfaces and an updated one will be made available shortly. - It was also written for the analysis of genomic DNA, so it uses dynamic memory for almost all internal storage and therefore it is not limited to a specific sequence length. - It is written in ANSI C, using standard libaries or supplied code, so that it compiles and runs on all unix variants that I've tried: Linux (PPC, Intel, Alpha (64-bit)), DEC Unix(64bit), IRIX(32/64bit), Solaris, ConvexOS, HP/UX, NeXTStep. - It also runs on Win95/NT (compiled with the amazing Cygwin tools), DOS (with the DJGPP extender), and has been compiled for the Mac as part of Don Gilbert's SeqPup application, although the DOS and Mac versions have not yet been compiled as I write this. - It is meant to be extended to include your own functions. An example skeleton function is included as a guide, so that even relative newcomers to the field should be able to plug in analytical code to extend it. This code is, of course, YOUR Intellectual Property. - perhaps you can think of it as the bioinformatics equivalalent of a Husqvarna chainsaw with all the guards and brakes removed :) Savage but effective. It supports: [* = new or improved] - searching arbitrarily large nucleic acid strings (dynamic memory allows searching whole bacterial genomes, or eukaryotic chromosomes (or genomes) in one sweep) - handles sequences as small as 5 bases for analysis of linkers, oligos - handles circular and linear DNA appropriately, correctly - allows subsequences to be extracted from larger sequences, generates both subsequence #ing and original sequence #ing * integrated with Jim Knight's Seqio to allow automatic sequence conversion on input, and scanning multiple sequence databases (or not - it still supports the ability to assume that ALL input is sequence - this is useful for analyzing file fragments or editor buffers). - FAST (5-35X equiv routines in GCG) pattern matching of nucleic acids up to about 30 bases - simultaneous searching of thousands of patterns read from a database or a few explicit patterns read from the command-line - searching with errors - searching for patterns containing IUPAC degeneracies in strings which also contain IUPAC degeneracies * searching for regular expressions (in nucleic acid), with autoconversion of IUPAC degeneracies to the appro regex. * searching for TRANSFAC matrices, with user-specified cutoffs - GCG-style ladder maps * gel simulations with low and high end cutoffs for expansion * selection of Restriction Enzymes explicitly, by overhang generated, magnitude of recognition site, price, minimum, maximum number of cuts (overall or on a per-pattern basis) * supports Combination Cuts of up to 15 REs at a time * supports limited AFLP fragment matching / simulation * simulates Dam and/or Dcm methylation of DNA - generates summaries of # of patterns found, Sites, Fragments (sorted/unsorted) * searches for silent sites, with reverse translation - Full Linear Maps with enzyme cuts marked AT THE POINT OF CUTTING, not beginning of pattern, with double/single strand selection - co-translation of DNA, based on a (user-expandable) number of Codon usage tables, in 1 2 or 6 frames * ORF finding in any combination of frames with FASTA output, with offsets in DNA, protein, Molecular Wt, pI, with optional additional info on AA frequency in #s or % - dump of internal data for analysis / plotting with external plotting programs in 3 formats, incl gnuplot. * conditional output based on matches, for scanning large numbers of sequences at a time * 2 types of Proximity matching: 1 - exact specification of the relationships of 2 patterns (upstream, downstream, by how much, within/outside of a range 2 - specify rules for arbitrarily complex relationships among many patterns (in a sliding window or in the whole sequence) with logical AND, OR conjunctions (if people want the FULL logical connectives (XOR, NAND, NOR, etc) it's trivial to add them) joining pattern specifications (unbiased editorial comment :) - this is cool!) * sequence extraction surrounding pattern matches, with variable upstream, downstream inclusion, optional reverse translation in FASTA format. * uses autoconf/configure to ease building on different platforms. * includes an explicit example function to show how to add your own funtionality - (mostly) free - source code included And you can get it from: http://24.1.175.29/tacg/Beta/tacg-latest-beta.tar.gz Instructions: tar -xzvf tacg-latest-beta.tar.gz cd tacg; ./configure; make the files in the Data subdir need to go in the current directory, your home directory, or in '/usr/local/lib/tacg' or wherever you define the environment var TACGLIB to be. (no make install just yet - put the bits where you want them) -- Cheers, Harry Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com From Alan at MolBio.org Mon Nov 8 19:56:29 1999 From: Alan at MolBio.org (Alan J. Williams) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Mentioned in The Chronicle In-Reply-To: <381FA850.DB57788F@geoserve.net> Message-ID: Hi All, I was just browsing through the most recent issue of The Chronicle of Higher Education (Nov 5, 1999). They have an article entitled, "The 'Open-Source Movement' Turns Its Eye to Science" in their IT section. Imagine my suprise when I read the following, ... and Loci, created by scholars at the Open Lab, and independent group in Hudson, Mass., to coordinate computer programs that work together on a network. Enjoy, 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 geoserve.net Mon Nov 8 19:17:55 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Mentioned in The Chronicle References: Message-ID: <38276833.9485BD3B@geoserve.net> "Alan J. Williams" wrote: > > I was just browsing through the most recent issue of The Chronicle of > Higher Education (Nov 5, 1999). They have an article entitled, "The > 'Open-Source Movement' Turns Its Eye to Science" in their IT section. > Imagine my suprise when I read the following, > > ... and Loci, created by scholars at the Open Lab, > and independent group in Hudson, Mass., to > coordinate computer programs that work together > on a network. So, we're being watched! Everyone, be on your best behavior: tuck your shirts in, and sit up straight. Don't make any spelling misstakes :-) Alan, did you see that in print or on the Web? Cheers. Jeff -- +----------------------------+ | J.W. Bizzaro | | jeff@bioinformatics.org | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------+ From Alan at MolBio.org Mon Nov 8 20:18:25 1999 From: Alan at MolBio.org (Alan J. Williams) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Mentioned in The Chronicle In-Reply-To: <38276833.9485BD3B@geoserve.net> Message-ID: In hard print. On Tue, 9 Nov 1999, J.W. Bizzaro wrote: > Alan, did you see that in print or on the Web? -------------------------------------------------------------------- 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 geoserve.net Wed Nov 10 20:02:46 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] E-Speak Message-ID: <382A15B6.4F254FD5@geoserve.net> Hewlett Packard just released the E-Speak object broker under the GNU GPL license: ------------------------------ E-speak breaks the tight linkage that constrains applications to specific hardware or operating system environments, dynamically virtualizing the entire e-services environment. The e-speak core software consists of two elements: universal e-services APIs and a run-time e-services engine. E-speak run-time software is installed on each computing device or information appliance that connects to the virtual services environment. The run-time software then provides basic infrastructure capabilities like messaging, mediation, security, naming, and monitoring for the e-speak e-services hosted on, or accessed by, these devices. Through the consistent e-speak services interface (APIs), developers can design and create any e-service using a set of elegant, simple e-services programming interfaces. http://www.e-speak.hp.com/ ------------------------------ We can add that to the list of brokers, which includes CORBA, XML-RPC, SOAP, and of course PAOS. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Nov 10 20:54:47 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Gnome port to Windows? Message-ID: <382A21E7.1F8D43E9@geoserve.net> >From Gnotices: "Another interesting Gnome tidbit from the [AbiSource] list is that there seems to be a government funded project in Indonesia that is looking seriously at attempting a port of Gnome to Windows." >From the list: ------------------- I have also been contacted by GNOME people, offering yet still another approach: use GTK only API, and port GNOME to Win32. As for GNOME, the story is quite similar to your founding with wxWin. We didn't consider GNOME because we thought it was too platform- specific. But since one of the GNOME developers assured me it would be 'quite easy' to port GNOME to Win32, this brings a different light into the picture. http://www.abisource.com/mailinglists/abiword-dev/99/October/0260.html -------------------- Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Nov 10 21:33:03 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Re: loci tar file References: <001a01bf276e$26efd180$010a0a0a@0q6vm> <3822E15F.F0B0B909@geoserve.net> <001301bf2845$f7604840$010a0a0a@0q6vm> Message-ID: <382A2ADF.E13D0557@geoserve.net> Cayte wrote: > > Do you plan to make it Windows compatible, in the future? Loci depends on programming libraries from the Gnome project: http://gnome.org/ Gnome currently works on most flavors of Unix but has not been ported to any other OS. If and when Gnome is ported to Windows, Loci should work there as well. Will this happen? Probably. When? When somebody actually starts working on the Gnome port, it would be easier to say. > I just like to help with the bio open source efforts. Loci (and other projects at The Open Lab) offers many opportunities to contribute, even without programming. There is always a need for help with documentation and graphics, if you are so inclined to do so. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From fdrake at acm.org Thu Nov 11 08:59:03 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Re: [pygtk] Gnome port to Windows? In-Reply-To: <382A21E7.1F8D43E9@geoserve.net> References: <382A21E7.1F8D43E9@geoserve.net> Message-ID: <14378.52135.394829.988647@weyr.cnri.reston.va.us> This is good news! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From bizzaro at geoserve.net Sat Nov 13 01:59:52 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] XML schemas Message-ID: <382D0C68.A5DC3AFA@geoserve.net> >From News.com: ------------------------ XML schemas, first introduced in May, are a new way of letting computers interpret languages and applications based on Extensible Markup Language (XML). XML is a technology that Web and application developers can use to craft their own markup languages with special tags and functions. Schemas tell a computer reading an XML document how to interpret tags that are not universally recognized. Schemas are meant to replace an existing technology called the Document Type Definition (DTD). Schemas are supposed to be a step up from DTDs because they are written in XML and support the use of XML namespaces, which let computers distinguish between similarly named tags from distinct XML-based languages that find their way into the same application. http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/ ------------------------ Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Nov 14 07:52:48 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] PSB 2000 Message-ID: <382EB0A0.EBB1724A@geoserve.net> Locians, Well, it seems PSB 2000 is less frequented than I thought. EVERYBODY, except Jennifer, has told me they aren't going. (Recall that I was thinking of holding 'LOCI 2000' there.) Even my brother, who was going to pay my way, can't make it. So, it looks like Jennifer will be holding the meeting by herself, on the beach :-) Sorry, Jennifer. Maybe we should start talking about some other conference next year. I think RECOMB 2000 is in Tokyo...which probably rules it out for everyone. I don't know where ISMB 2000 will be. There's also that Objects in Bioinformatics conference in California. And of course, we can go to some Linux conference. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Nov 16 09:04:59 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] EMBOSS, etc. Message-ID: <3831648B.D3FE668F@geoserve.net> (This is my reply to part of a message David sent to me directly.) David Lapointe wrote: > > I have had a productive couple of weeks at work, due I think to to the > OSOS conference. I have been making webized ( read CGI) interfaces to EMBOSS. Interfacing Loci with EMBOSS will a major first step for Loci. Perhaps you are the best candidate to head up that effort, if you are that familiar with EMBOSS. Of course, EMBOSS uses AJAX/ADL, which is the route to connectivity with Loci. If you have any information on how EMBOSS will connect to AppLab, that will be applicable to Loci--we (Gary and I) have nodded our heads in agreement that Loci's CORBA-based infrastructure should be modeled closely after AppLab's: http://industry.ebi.ac.uk/applab/ > Maybe it's time for me to start getting into LOCI a little more. I might wade > in with some Python frontends, then try to tackle LOCI connectivity. Loci's Python-based API to CORBA will be done via Justin's PyORBit: http://bioinformatics.org/pyorbit/ If you want a Python-based connectivity project, it might be to implement PyORBit. If you want to work in another language, you will need to know the CORBA API for that language. What did you use for the EMBOSS Web interface? > How would you connect some executable to a LOCI element? Maybe I should > take this up on the list. 10-4. Again, we'll take the AppLab approach, with some SEView mixed in where it would be helpful: http://www.bioinfo.de/isb/1998/01/0003/ Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Wed Nov 17 12:22:39 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Docbook online Message-ID: <3832E45F.841A06C4@redpoll.pharmacy.ualberta.ca> Locians, Loci's white pages will be written using docbook: the 'industry standard' for creating professional documentation. It is especially well-suited to writing books and documentation for computer software and hardware. Organizations including GNOME have adopted docbook as the authoring system for their documentation. O Reilly has recently released 'Docbook: The definitive guide'. I bought my copy yesterday and it is well worth the cdn $53.95 that i paid. Docbook is essentially an SGML DTD (although an unofficial XML based version is available). It is parsed by jade, Tex, etc to create rtf,html,LaTeX, postscript, pdf, and so on, all from the same source. The book itself was written using docbook, and you can get the SGML source from http://www.docbook.org and render it using docbook! Those of you who might not have the time or inclination to install docbook just so you can render the docbook book will be relieved to find that the kind folks at o reilly have also posted html-ized versions of the docbook book as well. It's my impression that David Lapointe and I will probably make the heaviest use of docbook to document Loci, but it is important to have Loci's 'subject expert' developers contribute Loci documentation as well. BTW, the XML version of Docbook probably won't be industry strength until version 5.0 (current version is 3.1), so Loci's documentation currently will be written in SGML. Fortunately, it is a relatively easy task to convert docbook SGML to XML, so this is not a big deal. Happy authoring! --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 hinsen at dirac.cnrs-orleans.fr Fri Nov 19 04:37:51 1999 From: hinsen at dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Docbook online In-Reply-To: <199911181700.MAA08008@bioinformatics.org> (pipet-devel-admin@bioinformatics.org) References: <199911181700.MAA08008@bioinformatics.org> Message-ID: <199911190937.KAA14799@chinon.cnrs-orleans.fr> > Loci's white pages will be written using docbook: the 'industry > standard' for creating professional documentation. It is especially > well-suited to writing books and documentation for computer software and > hardware. Organizations including GNOME have adopted docbook as the I decided to use DocBook for the ScientificPython and MMTK manuals, and my enthusiasm about DocBook gradually disappeared over the time. First of all, DocBook is extremely complicated, and deciding which markup to use for what use is not easy. And it doesn't help that the various existing documentations sometimes contradict each other. On the other hand, in spite of the enormous number of markup tags, some very basic things were forgotten; there is no straightforward markup for citing journal articles, and the markup for library and code documentation covers only C. Another problem is translating DocBook to something readable for normal people. Jade with the DSSSL stylesheets does a good job at HTML translation (but be prepared to have a fast machine with lots of memory if you plan to use Jade), but hardcopy output produced via Jade and JadeTeX looks terrible; it doesn't even respect basic typesetting rules such as not breaking a page after the first line of a paragraph. Since I had already started with DocBook and didn't want to start again from scratch with something else, I ended up using the XML version of DocBook with modifications (added in the internal DTD subset) for documenting Python code, and I wrote my own translators to HTML and LaTeX in Python using DOM. But if I had to do it again, I'd design my own specialized DTD. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From bizzaro at geoserve.net Fri Nov 19 05:06:51 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Docbook online References: <199911181700.MAA08008@bioinformatics.org> <199911190937.KAA14799@chinon.cnrs-orleans.fr> Message-ID: <3835213B.33F7CB82@geoserve.net> hinsen@dirac.cnrs-orleans.fr wrote: > > Since I had already started with DocBook and didn't want to start > again from scratch with something else, I ended up using the XML > version of DocBook with modifications (added in the internal DTD > subset) for documenting Python code, and I wrote my own translators to > HTML and LaTeX in Python using DOM. But if I had to do it again, I'd > design my own specialized DTD. Hmmm. Are you saying that if started from scratch, you would use DocBook + your own DTD. Or are you saying you would not use DocBook at all? What would be the _next_ "best" thing to DocBook? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From dlapointe at mediaone.net Fri Nov 19 07:54:04 1999 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Docbook online In-Reply-To: <199911190937.KAA14799@chinon.cnrs-orleans.fr> References: <199911181700.MAA08008@bioinformatics.org> <199911190937.KAA14799@chinon.cnrs-orleans.fr> Message-ID: <99111908105601.00536@celery> On Fri, 19 Nov 1999, hinsen@dirac.cnrs-orleans.fr wrote: > I decided to use DocBook for the ScientificPython and MMTK manuals, > and my enthusiasm about DocBook gradually disappeared over the time. > First of all, DocBook is extremely complicated, and deciding which > markup to use for what use is not easy. And it doesn't help that the > various existing documentations sometimes contradict each other. > On the other hand, in spite of the enormous number of markup tags, > some very basic things were forgotten; there is no straightforward > markup for citing journal articles, and the markup for library > and code documentation covers only C. > It is very complicated and definitely NOT WYSIWYG. The appearance of DocBook: TDG ( the book ) will help somewhat. O'Reilly publishes their books using Docbook and they have two books on Python full of Python code docs. > Another problem is translating DocBook to something readable for > normal people. Jade with the DSSSL stylesheets does a good job at HTML > translation (but be prepared to have a fast machine with lots of > memory if you plan to use Jade), but hardcopy output produced via Jade > and JadeTeX looks terrible; it doesn't even respect basic typesetting > rules such as not breaking a page after the first line of a paragraph. Well, this is always a problem. I think those rules have to be set up on a per case basis, that is , the basic rules are generic and you would build up from there to what you want. The lists about sgml ( I was reading the sgmltools list ) are full of these issues. I like the idea of one document-> many output formats. There is a lot of work involved, however. -- .david David Lapointe "First things first," mandates sci-fi icon Doctor Who, "but not necessarily in that order." From gvd at redpoll.pharmacy.ualberta.ca Fri Nov 19 10:46:00 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] Docbook online References: <199911181700.MAA08008@bioinformatics.org> <199911190937.KAA14799@chinon.cnrs-orleans.fr> Message-ID: <383570B8.E0D078A2@redpoll.pharmacy.ualberta.ca> hinsen@dirac.cnrs-orleans.fr wrote: > Since I had already started with DocBook and didn't want to start > again from scratch with something else, I ended up using the XML > version of DocBook with modifications (added in the internal DTD > subset) for documenting Python code, and I wrote my own translators to > HTML and LaTeX in Python using DOM. But if I had to do it again, I'd > design my own specialized DTD. Konrad, Thanks for your input on the limitations of DocBook. Being rather new to DocBook, I wasn't aware of these limitations that you pointed out. I understand that DocBook is customizable (although its not DocBook any more once you customize it). What do you recommend? Is there a better alternative to DocBook, or could we just customize it to meet our needs? --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 geoserve.net Sat Nov 20 11:42:55 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] [Fwd: A suggestion] Message-ID: <3836CF8F.BD49C03F@geoserve.net> This came from a gnome list. I thought you might find it timely. -------------- next part -------------- An embedded message was scrubbed... From: Hassan Aurag Subject: A suggestion Date: Sat, 20 Nov 1999 15:59:05 GMT Size: 2900 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991120/036821ea/attachment.mht From bizzaro at geoserve.net Sat Nov 20 12:47:02 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] [Fwd: A suggestion] Message-ID: <3836DE96.EF143C78@geoserve.net> -------------- next part -------------- An embedded message was scrubbed... From: Colin Fox Subject: Re: A suggestion Date: Sat, 20 Nov 1999 17:26:22 +0000 Size: 3653 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991120/c15ab9ba/attachment.mht From bizzaro at geoserve.net Sat Nov 20 12:49:36 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] [Fwd: A suggestion] Message-ID: <3836DF30.64614888@geoserve.net> -------------- next part -------------- An embedded message was scrubbed... From: Havoc Pennington Subject: Re: A suggestion Date: Sat, 20 Nov 1999 12:30:55 -0500 (EST) Size: 2111 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991120/c4a08051/attachment.mht From bizzaro at geoserve.net Sat Nov 20 14:22:46 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:57 2006 Subject: [Pipet Devel] [Fwd: A suggestion] Message-ID: <3836F506.E6D870B0@geoserve.net> -------------- next part -------------- An embedded message was scrubbed... From: lacage@email.enst.fr (Mathieu Lacage) Subject: Re: A suggestion Date: 20 Nov 1999 18:26:55 +0100 Size: 2588 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991120/1ca48776/attachment.mht From bizzaro at geoserve.net Sat Nov 20 14:48:41 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] [Fwd: A suggestion] Message-ID: <3836FB19.5F28194@geoserve.net> -------------- next part -------------- An embedded message was scrubbed... From: Miguel de Icaza Subject: Re: A suggestion Date: Sat, 20 Nov 1999 08:17:50 -0600 Size: 1888 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991120/6ba668e0/attachment.mht From bizzaro at geoserve.net Sat Nov 20 14:59:29 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] bunch of stuff added to loci-doc Message-ID: <3836FDA1.78C8919A@geoserve.net> Greetings fellow Lab Rats! I just added some 'documents' of mine, which have been collecting dust on my drive, to the loci-doc module on CVS: poster-osos99 (poster from BNL meeting - in Applix format) slides-bambct (slides from an Oct presentation - Applix + HTML-ized) overview-for-compaq.wp8 (in WordPerfect 8 format) The latter one is based on the osos99 poster and currently under development. It will be handed to Compaq in a short while. (Some on this list know why. If you want to know, contact me.) Anyway, please take a look at this one and make any (constructive) changes you'd like. (An account at TOL is required.) WARNING: Due to the additions to loci-doc, it is now over 600 kB. =-D Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Nov 21 11:12:47 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] important changes to docs Message-ID: <383819FF.B582180C@geoserve.net> Locians, ***ALL DOCUMENTATION (INCLUDING THE DOCUMENTATION WEB PAGES THAT GARY MADE) FOR LOCI WILL BE KEPT IN THE LOCI-DOC MODULE AND MODIFIED VIA THE CVS SYSTEM. AND THE CONTENTS OF LOCI-DOC WILL BE IN THE DOCUMENTATION DIRECTORY ON THE WEB: THEY ARE TO BE THE SAME. This way, Gary, David, myself and others can all work on parts of the documentation from one source, and keep it in one place. Major changes: (1) What was in the root directory of the module loci-doc is now in loci-doc/manual/ (2) What was in the Web directory loci/documentation/ is now in the root directory of the module loci-doc ***That Web directory is therefore the check(ed)out loci-doc from CVS. (3) What was in the Web directory loci/documentation/official/ which was simply the contents of loci-doc, is now loci/documentation/manual/ and as mentioned above in (1) is in the module directory loci-doc/manual/ (4) The name 'Loci Documentation Project' previously described the contents of the loci-doc module. Since the contents are now in loci-doc/manual, the name is 'Loci Users Manual'. (This needs to be changed still in the TOC, Gary.) (5) The screenshots directory is used mostly by the documentation, so the Web directory loci/screenshots/ is now loci/documentation/screenshots/ and is therefore in the module directory loci-doc/screenshots/ ***I REPEAT: ALL DOCUMENTATION FOR LOCI WILL BE KEPT IN THE LOCI-DOC MODULE AND MODIFIED VIA THE CVS SYSTEM. AND THE CONTENTS OF LOCI-DOC WILL BE IN THE DOCUMENTATION DIRECTORY ON THE WEB: THEY ARE THE SAME. So, checkout a copy of loci-core. If you make changes, then in the loci-core directory type cvs commit If you make changes directly on the server (Gary), type cvs commit If you want to get the updated version after someone else made changes, then from the directory, type cvs update (You probably know the routine.) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Nov 21 12:58:01 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] development roadmap (humor) Message-ID: <383832A9.D9635779@geoserve.net> Alpha Test Version: Too buggy to be released to the paying public. Beta Test Version: Still too buggy to be released. Release Version: Alternate pronunciation of "Beta Test Version". Version 1.0: Buggier than Maine in June; eats data. Version 1.1: Eats data only occasionally; upgrade is free, to avoid litigation by disgruntled users of Version 1.0. Version 2.0: The version originally planned as the first release, except for a couple of data-eating bugs that just won't seem to go away; no free upgrades or the company would go bankrupt. Version 3.0: The revision in the works when the company goes bankrupt. (from http://www.gnu.org/fun/jokes/software.terms.html) :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Sun Nov 21 18:26:52 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] important changes to docs References: <383819FF.B582180C@geoserve.net> Message-ID: <38387FBC.79927BFE@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Locians, > > ***ALL DOCUMENTATION (INCLUDING THE DOCUMENTATION WEB PAGES THAT GARY > MADE) FOR LOCI WILL BE KEPT IN THE LOCI-DOC MODULE AND MODIFIED VIA THE > CVS SYSTEM. AND THE CONTENTS OF LOCI-DOC WILL BE IN THE DOCUMENTATION > DIRECTORY ON THE WEB: THEY ARE TO BE THE SAME. > > This way, Gary, David, myself and others can all work on parts of the > documentation from one source, and keep it in one place. Absotively fantabulous idea! > > Major changes: > > (1) What was in the root directory of the module > > loci-doc > > is now in > > loci-doc/manual/ > > (2) What was in the Web directory > > loci/documentation/ > > is now in the root directory of the module > > loci-doc > > ***That Web directory is therefore the check(ed)out loci-doc from CVS. > > (3) What was in the Web directory > > loci/documentation/official/ > > which was simply the contents of loci-doc, is now > > loci/documentation/manual/ > > and as mentioned above in (1) is in the module directory > > loci-doc/manual/ got it. > > (4) The name 'Loci Documentation Project' previously described the > contents of the loci-doc module. Since the contents are now in > loci-doc/manual, the name is 'Loci Users Manual'. (This needs to be > changed still in the TOC, Gary.) done. > > (5) The screenshots directory is used mostly by the documentation, so the > Web directory > > loci/screenshots/ > > is now > > loci/documentation/screenshots/ Updated the ToC here, too. > > and is therefore in the module directory > > loci-doc/screenshots/  > > ***I REPEAT: ALL DOCUMENTATION FOR LOCI WILL BE KEPT IN THE LOCI-DOC > MODULE AND MODIFIED VIA THE CVS SYSTEM. AND THE CONTENTS OF LOCI-DOC WILL > BE IN THE DOCUMENTATION DIRECTORY ON THE WEB: THEY ARE THE SAME. > I just made a small change to the loci-doc module as a test. It seems to work nicely, but how about publishing the updated web documentation? Transplanting the cvs docs to the actual web docs is an administrative issue, so perhaps we should discuss the protocol on admin list? BTW, I'll mark-up your posting and add it to the Loci Development pages. On a related, nit-picking, semantics note, we currently describe the Loci Manual as a technical description of the various loci components. Do we plan to use that document as described (currently it is just a skeleton of the 'various loci components')? I suggest we make that document a users guide, and have an extra link on the documentation page (white pages) where we publish our technical essays on Loci. -- 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 hinsen at dirac.cnrs-orleans.fr Wed Nov 24 09:58:27 1999 From: hinsen at dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] Docbook online In-Reply-To: <199911191700.MAA10940@bioinformatics.org> (pipet-devel-admin@bioinformatics.org) References: <199911191700.MAA10940@bioinformatics.org> Message-ID: <199911241458.PAA32228@chinon.cnrs-orleans.fr> > > HTML and LaTeX in Python using DOM. But if I had to do it again, I'd > > design my own specialized DTD. > > Hmmm. Are you saying that if started from scratch, you would use DocBook > + your own DTD. Or are you saying you would not use DocBook at all? For my needs (lots of library documentation with little else) I'd not use DocBook at all. It's just terribly complicated in areas that I don't need. For applications where much of the DocBook tags could be used profitable, DocBook + extensions might be fine. However, it should be clear that once you modify DocBook (including additions), you lose many of its benefits. None of the standard tools will understand your private DTD, for example. Extending DSSSL stylesheets is possible in principle, but I suspect it's about as easy to write a whole new typesetting system. So the only reason to keep anything of DocBook if you need modifications anyway is to be able to use many of its tags. > What would be the _next_ "best" thing to DocBook? What does "best" mean? If you accept that no DTD can be used without modifications, then I'd go for the simplest DTD possible. Perhaps the old LinuxDoc DTD. Or the simplified subset of DocBook. But in any case, it could turn out to be as easy to design a DTD from scratch. In the long run, I expect that an approach based on many small standard DTDs will evolve, using XML namespaces. But we aren't there yet. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From bizzaro at geoserve.net Thu Nov 25 00:40:18 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] we're not innovative Message-ID: <383CCBC2.484E0478@geoserve.net> Dave McAllister, SGI's Director of Technical Strategy says, "The open-source community is a good imitator but not a good innovator. They don't build their own problems." And surprisingly, he's considered a Linux advocate. http://www.it.fairfax.com.au/software/19991123/A56903-1999Nov21.html I guess Loci has been an imitation all along. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From dlapointe at mediaone.net Thu Nov 25 11:25:48 1999 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] we're not innovative In-Reply-To: <383CCBC2.484E0478@geoserve.net> References: <383CCBC2.484E0478@geoserve.net> Message-ID: <99112511555100.01260@gnomen> On Thu, 25 Nov 1999, J.W. Bizzaro wrote: > Dave McAllister, SGI's Director of Technical Strategy says, "The open-source > community is a good imitator but not a good innovator. They don't build their > own problems." And surprisingly, he's considered a Linux advocate. > > http://www.it.fairfax.com.au/software/19991123/A56903-1999Nov21.html > > I guess Loci has been an imitation all along. > > > Cheers. > Jeff What about Sendmail, Apache, Perl, Python, Bind ? ( FORTH also but that was BOSS ). Just to name a few. What is Beowulf imitating? The Eric Raymond interview on Amazon is also critical of OSS. (http://www.amazon.com/exec/obidos/tg/feature/-/11693/002-6355772-7740249) But so what? IBM thought the world would have no need for more than 5 or 6 mainframes, Ken Olson of DIgital fame thought no one would need a personal computer. OSS is neither this nor that. It is a whole spectrum of apps and ideas. Some bad some great. -- .david David Lapointe "Hokey religions and ancient weapons are no match for a good blaster at your side, kid," From toneman at phil.uu.nl Thu Nov 25 12:14:46 1999 From: toneman at phil.uu.nl (Michiel Toneman) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] we're not innovative In-Reply-To: <99112511555100.01260@gnomen> Message-ID: On Thu, 25 Nov 1999, David Lapointe wrote: > On Thu, 25 Nov 1999, J.W. Bizzaro wrote: > > Dave McAllister, SGI's Director of Technical Strategy says, "The open-source > > community is a good imitator but not a good innovator. They don't build their > > own problems." And surprisingly, he's considered a Linux advocate. > > > > http://www.it.fairfax.com.au/software/19991123/A56903-1999Nov21.html > > > > I guess Loci has been an imitation all along. > > > > > > Cheers. > > Jeff > I think the Open Source community IS innovative, it's all a matter of suurvival of the fittest. Let me explain: Companies throw some halfwit idea onto the market, hype it up as the replacement for sliced bread. The idea fails to catch on, and the idea fades away. The company markets this as being "innovative". Have you ever heard of an idea being "ahead of its time" when it utterly fails to impress, my point exactly? In the Freeware community, if an idea sounds good but doesn't work, it is abandoned, without the hype about being "innovative". This means that the innovation is much less visible. As for the interview, I think that Mr. McAllister has a pretty big mouth saying IRIX to be so much more advanced than Linux. From my experience IRIX has it's own share of security and stability problems. The GNU file/text tools are much more stable and advanced than the IRIX's braindead tools, and CDE stopped being "cool" quite some years ago. Greetings, Michiel -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called "brightness", but it doesn't work. From bizzaro at geoserve.net Thu Nov 25 15:09:48 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] we're not innovative References: Message-ID: <383D978C.463111D9@geoserve.net> Michiel Toneman wrote: > > As for the interview, I think that Mr. McAllister has a pretty big mouth > saying IRIX to be so much more advanced than Linux. This guy also says that Linux hasn't shown it can run more than one application at a time. That's just too humorous for a response. I really had high hopes for SGI, being they're trying to embrace 'Open Source'. But then I a recall my experiences running IRIX, which doesn't come with gcc or even ping and whois. Oh, I guess you can 'buy' gcc from them for $1,500 or so. SGI's just jumping on the bandwagon. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Nov 26 18:39:02 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] KDE to use graphical pipline approach? Message-ID: <383F1A16.503C8734@geoserve.net> Locians, I came across this interview with KDE developers at Slashdot. One person asked about using a 'connect-the-dots' approach. The 'AVS' referred to is likely this product: http://www.avs.com/products/expdev/netedit.htm http://www.avs.com/products/expdev/example/outlines/devotl1a.htm ------------------------- 10) by Tom Christiansen What non-Windows systems have you evaluated in mining existing technology for ideas? How about XEROX Star or OS/2 or Amigas? Have you ever looked at AVS, the scientific visualization graphical shell? It has (or had, when I long ago looked at it) a very cool graphical representation in which datasets and filters get connected in by pipelines in a visual rather than a CLI way, which is sometimes easier to produce. IF you haven't seen it, think of what it might be to combine drag-and-drop with connect-the-dots... Kurt Granroth answers: [cut] As for the 'connect-the-dots' approach.. I believe that various KDE apps are doing something in that vein. aRts does (or did). I could have sworn that there were more. We currently have no plans of doing this in the core KDE stuff.. but who knows what will happen after KDE 2.0 Actually, it's interesting that you mention AVS because we *did* have a rather extensive discussion about treating everything as graphical pipes about a year ago (I think). If my memory holds true, we decided that it's a great idea but we probably couldn't pull it off by KDE 2.0 if we wanted it to be stable, usable, and intuitive. Like I said, we'll see what happens after 2.0 ------------------------ Full interview: http://slashdot.org/article.pl?sid=99/11/26/1126252&mode=nocomment Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Nov 28 15:53:37 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] [Fwd: The Loci Project] Message-ID: <38419651.C945E58B@geoserve.net> I sent a about Loci message to Tom Christiansen, who asked the KDE developers about a 'connect-the-dots' desktop for Unix (I sent his question to this list a few days ago). Here is his message back to me... -------------- next part -------------- An embedded message was scrubbed... From: Tom Christiansen Subject: Re: The Loci Project Date: Sun, 28 Nov 1999 07:34:27 -0700 Size: 2840 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991128/997a0ba2/attachment.mht From bizzaro at geoserve.net Sun Nov 28 15:55:20 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] [Fwd: The Loci Project] Message-ID: <384196B8.57DF30A4@geoserve.net> I also sent a message to Ed Hall, who made comments like Tom's at Slashdot. Here is his reply... -------------- next part -------------- An embedded message was scrubbed... From: Ed Hall Subject: Re: The Loci Project Date: Sat, 27 Nov 1999 02:30:41 -0800 Size: 1783 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991128/4ca606ce/attachment.mht From bizzaro at geoserve.net Mon Nov 29 16:12:43 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] Re: The Loci Project References: <199911281434.HAA17955@jhereg.perl.com> Message-ID: <3842EC4B.271C46EE@geoserve.net> Tom Christiansen wrote: > > I've looked at it, and found it quite interesting. It reminds me of AVS. > I'm not completely sure whether I'd be happy to work within a system such > as you described, but I'd certainly be more than willing to give it a try. > I confess to longing for Perl bindings, however. :-) Do you mean Perl bindings to Loci, or Loci using Perl instead of Python? > The easier of my two point is to make programs Unix-friendly and > touch-typist-friendly. I would like a program to "lay well under my > fingers", as musicians are known to say of a particular composition. > It should follow the principle of least surprise and not cause me > confusion. Would a mouse-friendly system address your point? I suppose this second point is to make intuitive programs, rather than just touch-typist friendly. > For example, the "xv" program does a good job at this. It doesn't require > strange keystroke combinations, but uses regular keys. It doesn't require > the mouse for non-mouse things, like selecting or executing commands. > It doesn't put things on menus whose name have no relationship to the > purpose of the command. I see. > KDE is very bad at all of this, and the only excuse provided me is > Microsoft compatibility. That is no excuse whatsover. It just ends up > producing something that feels completely foreign to me, like a poem > run through babelfish. As you know, Apple gave the world a very well thought out graphical shell or windowing system (which they 'stole' from Xerox, but probably did a better job at it) back in 1982? (Lisa). And this gave Microsoft a good case of the metoos. Up until 1995, Microsoft had been playing catchup, trying to make theirs as good as Apple's (IMHO, maybe Windows 95 = Mac System 7). Since then, however, it seems the two have been rushing to implement ALL of the features of the other, leaving both looking and working very much alike. So, with 90-something percent of all desktops working like the two do, who would DARE make something that works a completely different way? When it comes to making a new desktop (KDE, Gnome, etc.), it's not that 'Winintosh' is the ultimate, and there is no more room for innovation (or rethinking things); making something different would simply mean bucking the great trend and leaving your desktop potentially dead in the water. > If you read the three report cards I belately posted to that feature > article, you'll get a feel for what I do or do not enjoy. Mostly > do not. :-) But this isn't much to do with your project, I imagine, > because you are tackling the harder, more innovative, and far > more interesting aspects of all this. Well, I hope Loci can address BOTH of your points: be innovative AND be intuitive! Your very much welcome to test the work in progress and give us some feedback about its ease-of-use, since this is obviously something you care about in the programs you use. BTW, Loci is pronounced 'low-sigh', as I'm certain is the proper latin pronunciation :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Nov 29 23:44:21 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] [Fwd: desktop as a separate window (fwd)] Message-ID: <38435625.C8D3C94D@geoserve.net> posted to the gnome-devel-list -------------- next part -------------- An embedded message was scrubbed... From: "J.W. Bizzaro" Subject: Re: desktop as a separate window (fwd) Date: Tue, 30 Nov 1999 04:37:27 +0000 Size: 2330 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991130/89eac904/attachment.mht From bizzaro at geoserve.net Mon Nov 29 23:44:35 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] [Fwd: desktop as a separate window (fwd)] Message-ID: <38435633.CDEB3CDA@geoserve.net> -------------- next part -------------- An embedded message was scrubbed... From: "J.W. Bizzaro" Subject: Re: desktop as a separate window (fwd) Date: Tue, 30 Nov 1999 04:40:45 +0000 Size: 1108 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991130/1a0688f0/attachment.mht From bizzaro at geoserve.net Tue Nov 30 02:07:13 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:58 2006 Subject: [Pipet Devel] Re: desktop as a separate window (fwd) References: <199911300051.SAA08417@erandi.nuclecu.unam.mx> Message-ID: <384377A1.F5C1F1FF@geoserve.net> Miguel de Icaza wrote: > > What is loci? Loci is a graphical shell and scripting language for Gnome. Data pipelining is represented by connecting icons (data, programs, etc.) via lines (pipes). You may think of it as the more elaborate and general-purpose cousin to Gnogurt. http://bioinformatics.org/loci/documentation/overview.php3 Loci has been under slow development for nearly a year. It's written using gnome-python, will use ORBit and Bonobo, and is licensed under the LGPL. Jeff From bizzaro at geoserve.net Tue Nov 30 02:22:57 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] [Fwd: desktop as a separate window (fwd)] Message-ID: <38437B51.8C790090@geoserve.net> >From Havoc... -------------- next part -------------- An embedded message was scrubbed... From: Havoc Pennington Subject: Re: desktop as a separate window (fwd) Date: Tue, 30 Nov 1999 00:13:19 -0500 (EST) Size: 1758 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/19991130/faf425a8/attachment.mht From bizzaro at geoserve.net Tue Nov 30 02:38:15 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] new snapshot Message-ID: <38437EE7.C73154CD@geoserve.net> Locians, I finally got multiple I/O lines to connect properly and stay connected (next I have to work on _disconnecting_). You might be surprised by how much better it works. Here's the snapshot: http://bioinformatics.org/loci/download/snapshots/loci-core-19991129.tar.gz Please let me know what you think! BTW, it now needs gnome-python-1.0.50 which you can get at http://bioinformatics.org/resources/download/ Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bagfors at pdc.kth.se Tue Nov 30 04:31:43 1999 From: bagfors at pdc.kth.se (=?iso-8859-1?Q?Erik_B=E5gfors?=) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] Re: desktop as a separate window (fwd) In-Reply-To: <384377A1.F5C1F1FF@geoserve.net> References: <199911300051.SAA08417@erandi.nuclecu.unam.mx> <384377A1.F5C1F1FF@geoserve.net> Message-ID: <19991130103143.C1781@zyrgelkwyt.pdc.kth.se> On Tue, Nov 30, 1999 at 07:07:13AM +0000, J.W. Bizzaro wrote: > > Loci has been under slow development for nearly a year. It's written using > gnome-python, will use ORBit and Bonobo, and is licensed under the LGPL. Is there bonobo-bindings for python yet? Is someone working on it? That would be great! /Erik -- Erik B?gfors | http://www.acc.umu.se/~bagfors/ Email: bagfors@pdc.kth.se | Center for Parallel Computers GSM +46 70 398 54 43 | Supporter of free software From chapmanb at arches.uga.edu Tue Nov 30 05:29:51 1999 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] New guy speaks up Message-ID: Hello brave Locians! I know that no one has ever seen me here before, but Jeff has been kind enough to provide me a cvs account and I've been doing a bit o' learning from the code and docs there. In addition, I've been sorting through the old archives and reading up on all of the discussion I've missed and also trying to become more familiar with CORBA/GTK/bonobo/python. I meant to hang back silently a while longer and try and learn more, but I've been getting too excited about Loci and so I just felt the uncontrollable need to speak up with what I've been thinking about. I apologize if I am too out of touch still! First let me give you a little background on myself so you can have an idea where I'm coming from. I'm a just starting off grad student in botany at the U of Georgia and although my background is in molecular biology/botany stuff, I've been directing my graduate thesis work towards including computational work--both out of necessity and interest (well, mostly interest!) and have been trying to springboard off of my limited background in programming (C++) into the wide world of open source programming. Whew, so that's me in one sentence! My interest in loci comes from the fact that my work will include integrating a number of previously existing programs and hopefully some distributed computing (so I don't have to run all of my sequence alignments on my pieced together home computer and wait 12 days for them to finish!). In addition, I love the ideas behind Loci and want to see it succeed. So, because of all my interest I've been trying to get up to speed and so I have a few questions/discussion items from the depths of the mailing list archives: 1) First off, I really like the new core. I can connect dots together. Very nice--excellent work, Jeff! I do get some seriously weird behavior (Weird behavior 1) if I 1) add a document, 2) add a converter, 3) link them together (a 0 from the document to a 0 from the converter) I get some weird crazy stuff--a green 0/0 coming from the document which isn't connected to anything and a green 0/0 from the converter which moves together with a red 0 from the document. Weird Behavior 2) If I am really stupid and place dots from the same loci onto one point (ie. put a bunch of points from a processor onto one connection) I lose the connection and get a couple of huge green circles from the processor. Trippy!) These aren't complaints or anything (it's brand new--who could complain!?!), just what I've noticed! 2) Converters. This is based on Oct 15 discussions about how to convert data between formats. My random thought was--why have a specific internal format (ie. XML)? Instead, how about when a document comes in (in some particular format) it is parsed and pushed into a relational database (see point 3 for more on the storage component). This eliminates a need for an internal data format (because, man, we do not need anymore formats to put sequence data in!) and also allows direct querying of specific parts of a format (ie. you can search only sequence data, or search only bib data, or search only genbank id, or whatever). In this way, to read any particular file type into Loci, you would need to write a plug-in that would insert data into the database. To me, this seems analogous to the DBD/DBI mechansisms that perl uses for database connectivity. 3) Data storage. This goes back to discussions from Sept 22 (and a few other places). I've been thinking about this from a very molecular biology viewpoint (ie. DNA/protein data) and as I mentioned in point 2, I think that a good way to store the data would be in a relational database. This 1) eliminates the need to write a database 2) allows you to take advantage of functionality already implemented in exisiting databases (querying/sorting/dealing with the database (SQL)) 3)Would keep the database used "independent" of the rest of loci. SQL is "fairly standard" across databases (MySQL, PostgreSQL, Oracle, Sybase) so this would allow users of loci to run it on their personal favorite database. Here again I am thinking about how the DBI/DBD database connectivity works for perl. I think for a LGPLed project, there are two choices of databases: 1) MySQL (http://www.mysql.org) GPLs old versions (as Jeff mentioned earlier). The new version costs for Microsoft users. 2) PostgreSQL (http://www.postgresql.org) has a "do whatever you want with it" copywrite. Both are very good from what I hear and have decent documentation to make learning easier. I currently mess around with MySQL (I converted ArrayDB, an NIH microarray storage/query program, to run with MySQL instead of Sybase), but am by no means an expert, but from what I hear the basic difference between MySQL and PostgreSQL are that MySQL is lighter and faster, while PostgreSQL supports more functions and has better data integrity. But like I said, I'm no expert! 4) Other languages besides python. This isn't from the discussion, but from my own personal interest--how easy is it to intergrate other languages with python and the planned Loci implementation? Does everything have to run through CORBA before it can interoperate or is there a clean way to, say, use python and perl together? 5) Me. (Sorry, I'm definately not egocentric!) I would really like to see Loci succeed and would like to try to get involved in some coding. I will admit I'm not ready to code in Python yet since I know next to nothing (I am working through the documentation, though!) but I'm really interested/excited about the project and so I would like to try to jump in (and hopfully swim!) and try to do some helping. In regards to this, I would therefore like put the question forward to everyone about what I could/should work on to start. Like I've mentioned, I'm definately no expert on anything, but I can try to help as much as possible and do my best. So what do you think? What should I hack? 6) Congrats to Jeff on his expert networking. I just wanted to say how incredibly good Jeff is at getting the word out about Loci. I originally heard about it and the TOL through his post on biopython. However, now he is going for the big time--Loci and gnome! Good luck and excellent work! Well that is all my rambling for now. Hopefully I haven't been too far behind everyone's thinking and if I have, please flame me gently... Brad From dlapointe at mediaone.net Tue Nov 30 07:10:42 1999 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] new snapshot In-Reply-To: <38437EE7.C73154CD@geoserve.net> References: <38437EE7.C73154CD@geoserve.net> Message-ID: <99113007133200.00553@gnomen> I don't seem to have gnome-python-anyversion. Would this be a new name for the pygnome package? On Tue, 30 Nov 1999, J.W. Bizzaro wrote: > Locians, > Here's the snapshot: > > http://bioinformatics.org/loci/download/snapshots/loci-core-19991129.tar.gz > BTW, it now needs > > gnome-python-1.0.50 > > which you can get at > > http://bioinformatics.org/resources/download/ > > > Cheers. > Jeff -- .david David Lapointe "Hokey religions and ancient weapons are no match for a good blaster at your side, kid," From gvd at redpoll.pharmacy.ualberta.ca Tue Nov 30 13:09:39 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] New guy speaks up References: Message-ID: <384412E3.B5D155F4@redpoll.pharmacy.ualberta.ca> Brad Chapman wrote: > > Hello brave Locians! Welcome to the club, Brad. I'll add your info to the lab rats page (if you have a favorite email and webpage you can provide me with that as well). > 2) Converters. This is based on Oct 15 discussions about how to convert > data between formats. My random thought was--why have a specific internal > format (ie. XML)? Instead, how about when a document comes in (in some > particular format) it is parsed and pushed into a relational database (see > point 3 for more on the storage component). This eliminates a need for an > internal data format (because, man, we do not need anymore formats to put > sequence data in!) and also allows direct querying of specific parts of a > format (ie. you can search only sequence data, or search only bib data, or > search only genbank id, or whatever). In this way, to read any particular > file type into Loci, you would need to write a plug-in that would insert > data into the database. To put a sequence into a relational database, wouldn't you have to design a data model to place the sequence information into? at least tables like: Sequence Accesssion Features Bibliography Then you would have a sequence data format based on a relational data model, no? I'm no database exert either, so I'm asking out of sheer naievety here :-) Jeff and I talked at length about this issue more than once. We believe it would be better to have Loci as a Graphical Shell/ Graphical Scripting language with a database 'locus', but the actual database, and data model used to store the sequence data (and annotations) would be an 'option' depending on what the developers have provided for loci. so there may be a relational database, an object database etc., or a combination of databases for sequence data storage. Because of the GNU MySQL, the Loci developers will likely create a relational database to store and retrieve sequence data, but this would not be a 'requirement' so much as a 'plug-in'. Loci's own database requirements may not be so much for sequence storage as much as it is for things like the container locus, which is a queriable locus that contains other loci. But i'm on your side here, and I like your idea. >To me, this seems analogous to the DBD/DBI > mechansisms that perl uses for database connectivity. > Python has crazy-wicked bindings to MySQL (and mSQL): basic connectivity, dynamic connectivity, queries, statement handlers, even database meta-data (information about a database connection). No need to worry about Perl here. > I think for a LGPLed project, there are two choices of databases: > 1) MySQL (http://www.mysql.org) GPLs old versions (as Jeff mentioned > earlier). The new version costs for Microsoft users. 2) PostgreSQL > (http://www.postgresql.org) has a "do whatever you want with it" copywrite. > Both are very good from what I hear and have decent documentation to make > learning easier. I currently mess around with MySQL (I converted ArrayDB, > an NIH microarray storage/query program, to run with MySQL instead of > Sybase), but am by no means an expert, but from what I hear the basic > difference between MySQL and PostgreSQL are that MySQL is lighter and > faster, while PostgreSQL supports more functions and has better data > integrity. But like I said, I'm no expert! Check out O'reilly MySQL and mSQL for a good comparison between MySQL, mSQL, and PostgreSQL. > > 4) Other languages besides python. This isn't from the discussion, but from > my own personal interest--how easy is it to intergrate other languages with > python and the planned Loci implementation? Does everything have to run > through CORBA before it can interoperate or is there a clean way to, say, > use python and perl together? That would mean two interpreters running together. I'm not sure if Jeff would be smiling at that idea. Python can be extended with C libraries, and C can 'embed' Python. Python can do just about anything Perl can do, and it can access precompiled binaries, so, is there a need for Perl? > > 5) Me. (Sorry, I'm definately not egocentric!) I would really like to see > Loci succeed and would like to try to get involved in some coding. I will > admit I'm not ready to code in Python yet since I know next to nothing (I > am working through the documentation, though!) but I'm really > interested/excited about the project and so I would like to try to jump in > (and hopfully swim!) and try to do some helping. In regards to this, I > would therefore like put the question forward to everyone about what I > could/should work on to start. Like I've mentioned, I'm definately no > expert on anything, but I can try to help as much as possible and do my > best. So what do you think? What should I hack? I'll let the Ubermeister handle that one. Again, nice to have you aboard, Brad! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 gvd at redpoll.pharmacy.ualberta.ca Tue Nov 30 13:12:11 1999 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] new snapshot References: <38437EE7.C73154CD@geoserve.net> <99113007133200.00553@gnomen> Message-ID: <3844137B.FFABB2DA@redpoll.pharmacy.ualberta.ca> David Lapointe wrote: > > I don't seem to have gnome-python-anyversion. Would this be a new name for the pygnome package? David, Go install yourself the OctoberGnome release. Then all will be fine. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 geoserve.net Tue Nov 30 16:24:48 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] new snapshot References: <38437EE7.C73154CD@geoserve.net> <99113007133200.00553@gnomen> <3844137B.FFABB2DA@redpoll.pharmacy.ualberta.ca> Message-ID: <384440A0.BE21D61C@geoserve.net> > David Lapointe wrote: > > > > I don't seem to have gnome-python-anyversion. Would this be a new name for the pygnome package? It's not a new name. gnome-python contains both pygnome & pygtk pygtk is needed for pygnome anyway. Gary Van Domselaar wrote: > > David, > > Go install yourself the OctoberGnome release. Then all will be fine. I don't have OctoberGnome myself, and Loci works. It just so happens that gnome-python-1.0.50 works with some fairly old gnome-libs. Loci needs at least gnome-libs-1.0.10. So, an upgrade of Gnome is probably not needed by many. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Nov 30 17:06:46 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] New guy speaks up References: Message-ID: <38444A76.254FA147@geoserve.net> Brad Chapman wrote: > > Hello brave Locians! Hey new guy! > In addition, I've been sorting through the > old archives and reading up on all of the discussion I've missed That's a huge task :-) > and also > trying to become more familiar with CORBA/GTK/bonobo/python. I meant to > hang back silently a while longer and try and learn more, but I've been > getting too excited about Loci and so I just felt the uncontrollable need > to speak up with what I've been thinking about. I apologize if I am too out > of touch still! No problem. It's nice to see someone new get excited about the project. > First let me give you a little background on myself so you can have > an idea where I'm coming from. I'm a just starting off grad student in > botany at the U of Georgia and although my background is in molecular > biology/botany stuff, I've been directing my graduate thesis work towards > including computational work--both out of necessity and interest (well, > mostly interest!) It would be unusual, and unusually nice, if your advisor were to let you take on a computational project. Most established biologists, chemists and physicists, who _could_ get into bioinformatics, will not because (1) it is just too different (for them and from their respective fields) and (2) they've never used computers for anything beyond running shrink-wrapped applications. > and have been trying to springboard off of my limited > background in programming (C++) into the wide world of open source > programming. It isn't enough that we're on the bleeding edge being bioinformaticists, we've got to be in the (currently) blazing hot field of open-source software! > My interest in loci comes > from the fact that my work will include integrating a number of previously > existing programs and hopefully some distributed computing (so I don't have > to run all of my sequence alignments on my pieced together home computer > and wait 12 days for them to finish!). Ah, you just described the goal of Loci in one sentence. > In addition, I love the ideas behind > Loci and want to see it succeed. Oddly enough, so do I ;-) > So, because of all my interest I've been trying to get up to speed > and so I have a few questions/discussion items from the depths of the > mailing list archives: Fire away. > 1) First off, I really like the new core. I can connect dots together. Very > nice--excellent work, Jeff! I do get some seriously weird behavior (Weird > behavior 1) if I 1) add a document, 2) add a converter, 3) link them > together (a 0 from the document to a 0 from the converter) I get some weird > crazy stuff--a green 0/0 coming from the document which isn't connected to > anything and a green 0/0 from the converter which moves together with a red > 0 from the document. Okay, I just tried what I think you tried. And the problem is simply because I didn't put any code in to handle this situation yet. I think you tried connecting an output line to another output line (or input to input). Lines with arrows that point away from the locus are outputs, and lines with no arrows are inputs. It's just something a user shouldn't be able to do, and I'll make it so they simply won't connect. (If you want to know the dirty details, in the code, inputs can only connect to outputs and visa versa. If you drop an output 0 on an output 0, Loci thinks you're dropping output 0 on _input_ 0, and this leads to some crazy things in the code.) Really though, the fix is simpler than typing this paragraph :-) > Weird Behavior 2) If I am really stupid and place dots > from the same loci onto one point (ie. put a bunch of points from a > processor onto one connection) I lose the connection and get a couple of > huge green circles from the processor. Trippy!) These aren't complaints or > anything (it's brand new--who could complain!?!), just what I've noticed! Ooops. Another no-no I need to handle. Of course, the user shouldn't be able to connect a locus directly back to itself. In the workflow (when the script is run), this would create an infinite loop. (I'll answer the rest of your message in the next e-mail.) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Nov 30 17:56:06 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] New guy speaks up References: Message-ID: <38445606.18FA3717@geoserve.net> (continuation) Brad Chapman wrote: > > 2) Converters. This is based on Oct 15 discussions about how to convert > data between formats. My random thought was--why have a specific internal > format (ie. XML)? Instead, how about when a document comes in (in some > particular format) it is parsed and pushed into a relational database (see > point 3 for more on the storage component). This eliminates a need for an > internal data format (because, man, we do not need anymore formats to put > sequence data in!) and also allows direct querying of specific parts of a > format (ie. you can search only sequence data, or search only bib data, or > search only genbank id, or whatever). In this way, to read any particular > file type into Loci, you would need to write a plug-in that would insert > data into the database. To me, this seems analogous to the DBD/DBI > mechansisms that perl uses for database connectivity. If Loci worked with _one_ particular database to do this, it would be akin to having an internal format. We should have plug-in databases, which are what the 'Containers' are meant to be. I agree wholeheartedly with the idea of using databases as alternatives to data formats, but you have to consider (it's the same problem with an internal format) that some programmers won't agree on how good 'our preference' is, if we choose _one_ database. With every technology, you have both ardent supporters and staunch detractors; we just can't please everyone with only one option. > 3) Data storage. This goes back to discussions from Sept 22 (and a few > other places). I've been thinking about this from a very molecular biology > viewpoint (ie. DNA/protein data) and as I mentioned in point 2, I think > that a good way to store the data would be in a relational database. This > 1) eliminates the need to write a database 2) allows you to take advantage > of functionality already implemented in exisiting databases > (querying/sorting/dealing with the database (SQL)) 3)Would keep the > database used "independent" of the rest of loci. SQL is "fairly standard" > across databases (MySQL, PostgreSQL, Oracle, Sybase) so this would allow > users of loci to run it on their personal favorite database. Here again I > am thinking about how the DBI/DBD database connectivity works for perl. I agree. > I think for a LGPLed project, there are two choices of databases: > 1) MySQL (http://www.mysql.org) GPLs old versions (as Jeff mentioned > earlier). The new version costs for Microsoft users. 2) PostgreSQL > (http://www.postgresql.org) has a "do whatever you want with it" copywrite. > Both are very good from what I hear and have decent documentation to make > learning easier. I currently mess around with MySQL (I converted ArrayDB, > an NIH microarray storage/query program, to run with MySQL instead of > Sybase), but am by no means an expert, but from what I hear the basic > difference between MySQL and PostgreSQL are that MySQL is lighter and > faster, while PostgreSQL supports more functions and has better data > integrity. But like I said, I'm no expert! Loci is LGPL'd, so we can run proprietary databases too. There is some confusion in the license about what 'linking' means, and whether Loci would be considered the library or the program. I think we can interpret it pretty librally, providing the basic points of the (L)GPL are preserved: * Users can run Loci at no cost * Users can modify Loci's code * Users can redistribute Loci under the same license * Users can redistribute modified versions of Loci under the same license (an important distinction of the GPL) * The source code must remain accessible at no cost > 4) Other languages besides python. This isn't from the discussion, but from > my own personal interest--how easy is it to intergrate other languages with > python and the planned Loci implementation? Does everything have to run > through CORBA before it can interoperate or is there a clean way to, say, > use python and perl together? Since the Loci _core_ is a rather thin graphical shell with some networking capabilities, it probably isn't a sin to want the core in one language, even if it is Python (not a bad choice, I think). But for the extended Loci _system_, it is very important to have connectivity with other languages: particularly Perl and Java (favorites of bioinformaticists - for now). Most of the connectivity should be handled by CORBA. I really don't know of any other way to mix Python and Perl...unless we work through a C core, but why? What did you have in mind? > 5) Me. (Sorry, I'm definately not egocentric!) I would really like to see > Loci succeed and would like to try to get involved in some coding. I will > admit I'm not ready to code in Python yet since I know next to nothing (I > am working through the documentation, though!) but I'm really > interested/excited about the project and so I would like to try to jump in > (and hopfully swim!) and try to do some helping. In regards to this, I > would therefore like put the question forward to everyone about what I > could/should work on to start. Like I've mentioned, I'm definately no > expert on anything, but I can try to help as much as possible and do my > best. So what do you think? What should I hack? Hey, we've got tons of stuff to do. The only problem is I've been neglecting the compilation of a TODO or task list. I'm going to get right on it now, and I'll let people pick what they think is most interesting to them, and appropriate for their skills. > 6) Congrats to Jeff on his expert networking. I just wanted to say how > incredibly good Jeff is at getting the word out about Loci. I originally > heard about it and the TOL through his post on biopython. However, now he > is going for the big time--Loci and gnome! Good luck and excellent work! *blush* I gather everyone around for the big party but neglect to bring the food, drinks and music! > Well that is all my rambling for now. Hopefully I haven't been too far > behind everyone's thinking and if I have, please flame me gently... No open flames allowed in the Laboratory! Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Nov 30 19:03:15 1999 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] python-bonobo (was Re: desktop as...) References: <199911300051.SAA08417@erandi.nuclecu.unam.mx> <384377A1.F5C1F1FF@geoserve.net> <19991130103143.C1781@zyrgelkwyt.pdc.kth.se> Message-ID: <384465C3.358A117B@geoserve.net> Erik B?gfors wrote: > > On Tue, Nov 30, 1999 at 07:07:13AM +0000, J.W. Bizzaro wrote: > > > > Loci has been under slow development for nearly a year. It's written using > > gnome-python, will use ORBit and Bonobo, and is licensed under the LGPL. > > Is there bonobo-bindings for python yet? Is someone working on it? That > would be great! Not that I know of. The Open Lab is working on Python bindings to ORBit (partly for Loci's sake): http://bioinformatics.org/pyorbit/ We'll probably take on the Python-Bonobo bindings if no one else does. Want to help us get started? Jeff From justin at ukans.edu Tue Nov 30 22:12:24 1999 From: justin at ukans.edu (Justin Bradford) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] python-bonobo (was Re: desktop as...) In-Reply-To: <384465C3.358A117B@geoserve.net> Message-ID: > > Is there bonobo-bindings for python yet? Is someone working on it? That > > would be great! > > Not that I know of. The Open Lab is working on Python bindings to ORBit > (partly for Loci's sake): > > http://bioinformatics.org/pyorbit/ > > We'll probably take on the Python-Bonobo bindings if no one else does. Want > to help us get started? I haven't explored bonobo adequately yet, but I suspect we won't need the ORBit bindings before we can make bonobo bindings. It is my understanding that while bonobo uses ORBit, it is just a library. If I am correct, non-elegant bindings should be relatively easy. By "non-elegant", I mean it the Python interface would feel more C-ish than Python-ish. In fact, I saw this program, SWIG, on freshmeat, which seemed to imply that it would spit out the Python-C stubs automatically for a library. Justin From chapmanb at arches.uga.edu Tue Nov 30 22:39:10 1999 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:18:59 2006 Subject: [Pipet Devel] Databases/Languages (was New guy speaks up) In-Reply-To: <38445606.18FA3717@geoserve.net> References: Message-ID: Hello all! Thanks for the responses. Exciting to hear I'm not *completely* out in left field on all of this. My thoughts: J.W. Bizzaro wrote: Gary Van Domselaar wrote: 1) Databases/Converters. J.W. Bizzaro wrote: >If Loci worked with _one_ particular database to do this, it would be akin to >having an internal format. We should have plug-in databases, which are what >the 'Containers' are meant to be. I agree wholeheartedly with the idea of >using databases as alternatives to data formats, but you have to consider >(it's the same problem with an internal format) that some programmers won't >agree on how good 'our preference' is, if we choose _one_ database. With >every technology, you have both ardent supporters and staunch detractors; we >just can't please everyone with only one option. I agree completely. This is kind of what I was thinking of when I mentioned how the Perl DBI/DBD stuff works. I took some time to look a little at the Python drivers and it looks like the same type of thing is possible with python, as Gary pointed out (Gary Van Domselaar wrote: >Python has crazy-wicked bindings to MySQL (and mSQL)...). Based on the work I did migrating a Sybase/Oracle DB under perl to a MySQL DB under perl, the only real changes were to the driver and to fix SQL that was not supported under MySQL (which is a more lean DB and doesn't support things like VIEWS and UNION). So I think it would be quite possible to write some simple widely supported SQL and have a system which could plug into multiple databases. I could test PostgreSQL, MySQL, and mSQL on my system and the Linux users out there could provide testing for Oracle/Sybase to kind of ensure a database independent system. Since it would be independent, it wouldn't have to be distributed with Loci, and so we wouldn't even have to worry about LGPL stuff. Yay, No lawyers coming round! Gary Van Domselaar wrote: > Loci as a Graphical Shell/ Graphical >Scripting language with a database 'locus', but the actual database, and >data model used to store the sequence data (and annotations) would be an >'option' depending on what the developers have provided for loci. so >there may be a relational database, an object database etc., Based on this thinking and the 'plug-in' idea mentioned so often, why not implement a database as a loci? (maybe this could be some kind of derivative of the container?). This way, the user can use or not use a database depending on their work with Loci. For instance, if I am using Loci to pull single files from the PDB and pipe them into RasMol for viewing, it would be really stupid to have an intermediate step where I stick a single object into a database. By contrast, if I am parsing the current UniGene text file (100MB), it is crazy to not have some structured way to store this. I mean, I would be none too happy a user if I watched my computer spend an hour parsing a huge document and another several BLASTing the results and then had the computer crash losing all of my data. A 'plug-in' database loci could serve as the storage for huge data files--allowing data backup and easy access to the important parts of the data (sequences in this case). Is this the kind of plan everyone was thinking of? Gary Van Domselaar wrote: >To put a sequence into a relational database, wouldn't you have to >design a data model to place the sequence information into? at least >tables like: Sequence, Accesssion, Features, Bibliography > >Then you would have a sequence data format based on a relational data >model, no? I'm no database exert either, so I'm asking out of sheer >naievety here :-) I agree completely. A database is still a data intermediate, but I think it at least has the advantages of: 1) being readily storable 2) allowing specific parts of the data to be individually queried. 3) being flexible enough to allow a wide variety of data types to be stored without data loss. Gary Van Domselaar wrote: >Loci's own database requirements may not be so >much for sequence storage as much as it is for things like the container >locus, which is a queriable locus that contains other loci. One thing I'm not clear about--how does all this relate to the idea of the container and storing loci? I guess I'm not clear about exactly what it means to store a converter loci, for instance? Even more confusing to me, how do you query a container locus? How does this relate with storing actual data? Confusion, confusion over here! 2) Other Languages. Gary Van Domselaar wrote: >That would mean two interpreters running together. I'm not sure if Jeff >would be smiling at that idea. Python can be extended with C libraries, >and C can 'embed' Python. Python can do just about anything Perl can >do, and it can access precompiled binaries, so, is there a need for >Perl? I will agree that I would rather not mess around with two languages/two interpreters and all of that jazz. No fun! However there are a number of things that are implemented in perl currently that are not available in python. For instance, the bioperl modules. Although the biopython project is dealing with building the same functionalities in python they currently have no code (and the list has been relatively silent!). In addition, a number of excellent programmers are coding in perl and so there are a lot of good scripts/code available. Should all perl scripts either: a) be run through CORBA to be used with Loci? or b) have to be reimplemented in python to be used with Loci? For example, how are we planning on connecting to AceDB servers--rewriting AcePerl or running it through CORBA? I think our disadvantage if we try and rewrite everything is that we can't take full advantage of work done in other languages and have to work really hard to keep the python implementation "up to date" with the perl. In addition, there is an unhealthy competition between perl and python for programmer time, regardless of which is a "better" language. J.W. Bizzaro wrote: >Since the Loci _core_ is a rather thin graphical shell with some networking >capabilities, it probably isn't a sin to want the core in one language, even >if it is Python (not a bad choice, I think). But for the extended Loci >_system_, it is very important to have connectivity with other languages: >particularly Perl and Java (favorites of bioinformaticists - for now). Most >of the connectivity should be handled by CORBA. I really don't know of any >other way to mix Python and Perl...unless we work through a C core, but why? >What did you have in mind? I mention above the kind of things I had in mind. Specifically, where is the point where it takes more effort to connect things with CORBA then it does to rewrite them in python? What should be rewritten and what should be connected? From what I've read, gnome development (which you all seem to be wisely following closely!) seems to do a good job of making CORBA tie a lot together, but I'm not completely positive how this all can translate to Loci. Once again, confusion is overwhealming me! Okay, I think I've confused myself enough for this e-mail! Again, thanks for your responses and for making thing clearer for at least a little while. Sorry to have muddied everything up again! Brad