From bizzaro at geoserve.net Sun Jan 2 11:56:52 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:03 2006 Subject: [Pipet Devel] Loci collaboratories Message-ID: <386F8354.52D7AC8E@geoserve.net> Happy New Millennium, oh great Locians. I just wanted to bring up the 'collaboratory' feature of Loci once more. We haven't talked much about it (it's not even on the TODO list), but it will surely require some sort of chat mechanism. Here are a couple free chat systems to chew on: http://www2.linuxjournal.com/lj-issues/issue69/3465.html http://www.interloper.net/~dan/software/software.html#mchat Ideas are sought about how conferencing/chat and locus exchange can work within the Loci paradigm. For example, can/should a 'chatter' be represented as a locus? Hmmmm. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jan 3 13:03:55 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] Re: Panic over References: <99123119283701.08821@gnomen> <38709862.A5C6D100@geoserve.net> <00010307564900.00967@gnomen> Message-ID: <3870E48B.99D810C@geoserve.net> David Lapointe wrote: > > Yes, there are a lot of enhancements to the new core. > I am puzzled by the way it works, but that's due > my expectations. > > Connecting in/out I started up a document ( input? ) connected > a converter to it, got a nice green connection. Then added a > processor to the output of the converter. That broke the > connection between document and converter. I went back and redid this > and I can only imagine that I connected the wrong links. I can't reproduce this. Did you get a green connection between converter and processor too? What do you mean the connection between document and converter broke? Did the color change? Did moving the locus cause the lines to move out of sync with the locus (as if it was still connected) or in sync (unconnected)? (Note that the disconnecting of loci is a feature that doesn't work yet.) > Outputs have an arrow, but what do the numbers mean? Outputs have an arrow and can only be connected to inputs, which have no arrow. Green means connected, and red means unconnected. The numbers are simply the connection numbers. For example, a locus with 3 outputs would have outputs labeled 0, 1 and 2. New versions of loci-core will show numbers only for composite loci, which will be used to match unconnected connectors on the composite's workspace with the icon's connectors. When numbered connectors are connected the string in the dot becomes #/# and the numbers are displayed in the order of the workflow. So, if you connect an output #1 to an input #0, the string would be 1/0 This is so you can see both numbers in the same dot. > Could I select an output and add a locus to it? Not yet, but this feature will be added soon. The only problem with this is, while you have identified the output # of the locus, you have not identified the input # of the locus you want to add (the 'mate'). The user will probably be presented with a dialog asking which input # to use, unless Loci can take a very good guess at it. > Is there an order in which to do things? Not really. I haven't found the nature of the bug you spotted, and it seems that it is this bug that makes things confusing. Everything works in a very intuitive manner, at least to me. But let me ask you, what were your expectations? How do you think it should work? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jan 3 13:40:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] Re: Panic over References: <99123119283701.08821@gnomen> <38709862.A5C6D100@geoserve.net> <00010307564900.00967@gnomen> <3870E48B.99D810C@geoserve.net> Message-ID: <3870ED06.F654BDE6@geoserve.net> "J.W. Bizzaro" wrote: > > The numbers are simply the connection numbers. In the grand scheme of things, numbered dots can't be used. It just won't work when you have loci inside of loci inside of loci ad infinitum. I think a better approach is to use a combination of MIME and ID numbers, to ensure the connection type is know and that it is completely unique (all connectors can be identified without confusion). A recent idea I had was to use 'windowlets' with the dots so that more detailed information about the connection can be found by double-clicking on the dot (exactly like windowlets under icons). How does that sound? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jan 4 06:59:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] loci-core changes in cvs Message-ID: <3871E09B.467573FD@geoserve.net> 20000104 J.W. Bizzaro * a dot is the default locus representation (when there is no symbol or icon for locus) * text can appear on locus dot - space (' ') is default text * connector dots have space as default text too * NOTE: dot/line combination should be called 'connector' * selection boxes are now used instead of changing text_box color Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jan 4 09:29:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] loci-core changes in cvs References: <3871E09B.467573FD@geoserve.net> Message-ID: <387203BF.E91B30CF@geoserve.net> "J.W. Bizzaro" wrote: > * selection boxes are now used instead of changing text_box color Three reasons for this: (1) Works better with themes. For example, locus text may be optionally placed over a symbol, or the text_box may simply not be used. (2) I'm using a PI/200, and dragging connected loci is just a leeeetle bit slow. As an option for slower systems (especially if the antialiased canvas is used), the selection box can be the only thing dragged. And when it is dropped, loci and lines just snap to the new positions. (3) Connector dots will have selection boxes too. Without selection boxes, it would be awkward trying to show that a dot is selected. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Jan 4 10:09:20 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] GNOME Developer's Interview Follow-up Message-ID: <38720D20.BEE931E7@geoserve.net> Locians, If you read the interview with the Gnome developers a couple months ago, you may want to check out the follow-up, which has some additional responses: http://news.gnome.org/gnome-news/946276088/index_html About 1/4 the down, there are some interesting responses about the upcoming Gtk+ 1.4 release. Cheers. Jeff From chapmanb at arches.uga.edu Wed Jan 5 11:43:05 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] more cvs changes Message-ID: Heidi-Ho Locians! Sorry for my delay in posting--I'm now back with my computer (yay!) and can code once again (double yay!). Man, I have a lot to catch up with--but I just wanted to start with letting everyone know about the big changes in loci-file. First, my little directory representation thing is now "complete." You can scope it out the same way as before, by running './filegui.py &'. It can now display filesystem representations as lists and trees, and both have nifty little pixmaps which distinguish files from directories. Second, I'm starting to do more with XML stuff. I guess I'm thinking about getting into the overall XML scripting stuff (part II. o' the TODO list). In preparation for this I went through loci-core quite extensively and made almost an exact copy of it in loci-file. To see this (which hopefully looks and behaves exactly like the most recent loci-core), run './testgui.py' (which is located in the base directory of loci-file). Why did I bother to do this? A couple of reasons: 1. To start messing around I am going to need to start changing some parts of workspace.py in loci-core, so to not interfere with Jeff's work, I decided to just make my own copy. The changes I'm making are small, so it should be easy to integrate them into loci-core, if so desired. 2. Related to number 1, I am kind of using this as a testing platform. So we can try out ideas, see how people like them, and then if they are accepted, integrate them into loci-core. 3. I needed to go through the code anyways to see how it works. I'd be interested to know your thoughts on this type of arrangement. Also, I have already made a change to how loci-core works. I modified workspace.py so instead of loading individual python files like 'container.py' to get initial info about a container, it now calls an XML parser which parses a 'container.xml' file to get the initial info. From Jeff's comments, it looked like this was a change that needed to be made, so I thought I would start with this to get myself going on XML stuff in the workspace. The loci-file directory structure is still quite very unstable but should hopefully get a little more stable within the next couple of days, so if you haven't been making any changes in it, it might be best to just checkout a fresh copy. I'm really interested to hear everyone's comments, so if you have a chance, please check it out. Thanks much! Hope everyone had a wonderful Christmas/Kwanzaa/Ramadan and a snazzy New Year. Brad From chapmanb at arches.uga.edu Wed Jan 5 12:50:40 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] WidgetMain() and more... In-Reply-To: <38604A5D.67872C5B@geoserve.net> Message-ID: J.W. Bizzaro wrote: > class WidgetMain() > >The name may change, but it should be the same for all widgets. > Gotcha! Makes sense now that I've been looking in-depth at the code. We can change the name when we try to fit the widgets into loci-core. J.W. Bizzaro wrote: >> Note that since this now does XML parsing, loci-file requires something >> new. I used the SAX (simple API for XML) complient parser from the python >> xml toolkit. > >The licenses are acceptable. I'd like to keep the number of extra packages >that the user needs to install to a minimum though. Does SAX provide what >straight xmllib cannot? Well, I did some looking at the xmllib documentation (in the general python library docs) and now I have a better idea of what XML tools are in the python distribution and what extra stuff is in the xml toolkit. While it seems like basically whatever parser you use is a matter of personal preference, I see a couple of advantages for the SAX parser: 1. SAX is based on a generalized API, which gives it some extra modularity over any other parser application. In addition, it might be likely that programmers have had exprience with SAX in other languages, which might make the Loci code easier to follow and maintain by others. 2. From a bioinformatics standpoint, the proposed biopython BLAST parser has a SAX-like interface, so it makes learning SAX twice as worthwhile for anyone who will be used the BLAST parser and coding on Loci (namely, me!) In general, I think we really do need the extra stuff from the xml toolkit. It provides a DOM implementation, which we will really need, and architectural forms processors, in addition to SAX and some other parsers. In addition, if we want to stick with xmllib, the xml toolkit has some kind of C extension that supposedly makes it 5 times as fast. With all the XML work that we will need to do, my vote is definately for keeping the xml toolkit. Any thoughts? >How long would it take to do this for a large filesystem? at a remote >location? > >These are the reasons why I wanted to use a list. If trees are (1) made fast >enough and (2) aren't used for every container, they would be good to use. >Can you give us some feedback about these issues? Sure. Since the tree implementation works in the new filegui.py thingy, everyone can check it out on different size directories to their heart's content. While I think it is plenty fast for medium sized directories (with 5 or so levels) if we want to stick with a tree representation we definately need some limitations. I accidentally started parsing my /usr directory (with 5 MB worth of stuff) and needless to say, I had to go in and kill that process! I think a good way to limit the parsing and also keep a tree representation would be to have the tree created only a certain number of levels deep. Then, the user could have an idea of the contents of subdirectories, and if they need to go into one subdirectory whose contents weren't listed, they could drag the subdirectory as a new loci and see it that way. I think I could implement this without too many problems. How does this sound to everyone? Any thoughts on the number of levels to go? Other ideas? BTW, I don't think that the tree representation will be good for databases. My thought is that a listing of the different databases available in a particular locus will be good enough for that. I think that there will probably be too much info in a database to represent in a simple GUI. Thanks for your comments on this! Brad From chapmanb at arches.uga.edu Wed Jan 5 13:05:38 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] Loci collaboratories In-Reply-To: <386F8354.52D7AC8E@geoserve.net> Message-ID: J.W. Bizzaro wrote: > >Ideas are sought about how conferencing/chat and locus exchange can work >within the Loci paradigm. For example, can/should a 'chatter' be represented >as a locus? Hmmmm. > I really like this idea! I hadn't even thought about this before, but, wow, there is some nice conferencing stuff available! Maybe we should have a 'chat' locus specifically for this. Its associated gui could be the chat program, which would pop up in separate windows (Based on the screenshots, this would be waaaay to busy to have pop up inside a workspace, IHMO). However cool this is, it would probably be a lot of work, especially if we are going to try and get a huge chat system like 'The Collaborative Virtual Workspace (CVW)' working with a gtk interface. Would it be better for now just to have the CVW as a "suggested" program to use with Loci, and then get it worked into Loci as time (and programmers) permit? Brad From chapmanb at arches.uga.edu Wed Jan 5 13:17:55 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] Re: Panic over In-Reply-To: <3870E48B.99D810C@geoserve.net> References: <99123119283701.08821@gnomen> <38709862.A5C6D100@geoserve.net> <00010307564900.00967@gnomen> Message-ID: J.W. Bizzaro wrote: >> Connecting in/out I started up a document ( input? ) connected >> a converter to it, got a nice green connection. Then added a >> processor to the output of the converter. That broke the >> connection between document and converter. I went back and redid this >> and I can only imagine that I connected the wrong links. > >I can't reproduce this. Did you get a green connection between converter and >processor too? What do you mean the connection between document and converter >broke? Did the color change? Did moving the locus cause the lines to move >out of sync with the locus (as if it was still connected) or in sync >(unconnected)? Jeff, I can get two loci to break by following the following series of actions: 1. Add a document. 2. Add a converter and connect with the document. Get a good connection. 3. Add a processor. Connect an output (arrow) of the processor with the previously made connection. This causes the connection to break with the document and converter and form with the document and processor. This would be fine, except that the document output end still moves with the newly created link. I also noticed another thing when I was messing around. If you move a dot directly onto a locus (ie. on top of the two people) you lose this input or output. Just something that will have to be worked around eventually so dumb people like me don't keep accidentally losing their connecting dots. BTW, I really like the "windowlet" idea for the dots. This way you wouldn't have to worry about trying to write a whole bunch of info inside a dot and ending up with dots that are as big as the loci! I guess this will have to work by getting the info from an XML document. Hmmmm... Brad From chapmanb at arches.uga.edu Wed Jan 5 13:33:51 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes Message-ID: Okay, last message! I just wanted to update everyone on the current status of dbXML, the in-development XML database I was hoping to use to do some XML storage. I went back to check on things (www.dbxml.org) after the break and found out that the project is no longer open source with a BSD license, but is apparently going to be bought out and go commericial...[censored: a whole lot of not so nice words]... Anyways, I won't rant on about my feelings on this, but I was just wondering if anyone knows what happens to the code which was being previously released under a open source license. I have the most recently released snapshot (which is not complete) and documentation--can I use this to finish development or pass it out to people who would want to continue the open source development of it? Or is this code protected by the new commerical license? Along the same lines, has anyone heard about other open source XML databases? (gotta keep me fingers crossed...:) Okay, last message from me. Sorry to clog up everyone's in boxes. Brad From tim at nbci.com Wed Jan 5 06:13:02 2000 From: tim at nbci.com (Tim (not representing his employer's opinions)) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes References: Message-ID: <3873273E.5EDF8ACF@nbci.com> Brad Chapman wrote: > > Okay, last message! I just wanted to update everyone on the current > status of dbXML, the in-development XML database I was hoping to use to do > some XML storage. > I went back to check on things (www.dbxml.org) after the break and > found out that the project is no longer open source with a BSD license, but > is apparently going to be bought out and go commericial...[censored: a > whole lot of not so nice words]... Anyways, I won't rant on about my > feelings on this, but I was just wondering if anyone knows what happens to > the code which was being previously released under a open source license. I > have the most recently released snapshot (which is not complete) and > documentation--can I use this to finish development or pass it out to > people who would want to continue the open source development of it? Or is > this code protected by the new commerical license? > Along the same lines, has anyone heard about other open source XML > databases? (gotta keep me fingers crossed...:) > Okay, last message from me. Sorry to clog up everyone's in boxes. Try xDBM. http://www.bowerbird.com.au/XDBM/ Doesn't handle concurrency or any of the other stuff I like in a DBMS, but it's open. -- "Once you pull the pin, Mr. Grenade is no longer your friend." --effugas From gvd at redpoll.pharmacy.ualberta.ca Wed Jan 5 17:32:22 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] DB2XML Message-ID: <200001052232.PAA09905@redpoll.pharmacy.ualberta.ca> Locians, Jeff and I have been searching (mostly in vain) for a GPL XML DBMS. We have found the following link, which we may resort to instead: http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/ It is a java program, but it it worth checking for to see if the concept of transforming relational data into XML is feasable for Loci. Comments welcome! -Gary and Jeff From tim at nbci.com Wed Jan 5 10:32:52 2000 From: tim at nbci.com (Tim (not representing his employer's opinions)) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] DB2XML References: <200001052232.PAA09905@redpoll.pharmacy.ualberta.ca> Message-ID: <38736424.A90730A0@nbci.com> Gary Van Domselaar wrote: > http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xmldbms/xmldbms.htm This is in full release with good documentation and may be more useful for object -> XML -> relational type mapping. I can't seem to find any C-based packages that do the same, but some of the stuff on http://xml.apache.org/ looks like maybe it would be useful. Or maybe a hack based on James Clark's really fast and light parsers. Who knows, it's not my arena, really. -- "A computer system without Microsoft products is like a dog without bricks chained to its head." --David Wagle From gvd at redpoll.pharmacy.ualberta.ca Wed Jan 5 19:12:11 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes In-Reply-To: <3873273E.5EDF8ACF@nbci.com> from "Tim" at Jan 5, 0 03:13:02 am Message-ID: <200001060012.RAA10534@redpoll.pharmacy.ualberta.ca> > > Brad Chapman wrote: > > some XML storage. > > I went back to check on things (www.dbxml.org) after the break and > > found out that the project is no longer open source with a BSD license, but > > is apparently going to be bought out and go commericial...[censored: a > > whole lot of not so nice words]... Anyways, I won't rant on about my > > feelings on this, but I was just wondering if anyone knows what happens to > > the code which was being previously released under a open source license. I > > have the most recently released snapshot (which is not complete) and > > documentation--can I use this to finish development or pass it out to > > people who would want to continue the open source development of it? Or is > > this code protected by the new commerical license? Nice work, Brad! Jeff and I were hoping someone might have the latest version of dbXML. Unfortunately, we are not sure about the licensing issue concerning dbXML--certainly there website is obfuscating this issue as much as possible. Hold on to that code until we can get a handle on the licensinge or other alternatives (see my posting on db2xml). > > Along the same lines, has anyone heard about other open source XML > > databases? (gotta keep me fingers crossed...:) > > Okay, last message from me. Sorry to clog up everyone's in boxes. > > Try xDBM. > > http://www.bowerbird.com.au/XDBM/ > > Doesn't handle concurrency or any of the other stuff I like in a DBMS, > but it's open. This is a QPL licensed DBMS. Jeff and I looked at the license today and were not sure if it would fit with Loci's LGPL licensing scheme. Our interpretation is that if we were to use xDBM in Loci we would have to pay a per-developer licensing fee (this may not apply specifically to us because we are not developing a commercial application, but again, this is not made clear in their licensing terms. Perhaps someone else may have some insight on this issue? .g =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at geoserve.net Wed Jan 5 20:46:42 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] Re: Panic over References: <99123119283701.08821@gnomen> <38709862.A5C6D100@geoserve.net> <00010307564900.00967@gnomen> Message-ID: <3873F402.B5E5EA48@geoserve.net> Brad, I'll get to all of your messages ASAP. Brad Chapman wrote: > > Jeff, I can get two loci to break by following the following series of actions: > > 1. Add a document. > 2. Add a converter and connect with the document. Get a good connection. > 3. Add a processor. Connect an output (arrow) of the processor with the > previously made connection. > > This causes the connection to break with the document and converter and > form with the document and processor. This would be fine, except that the > document output end still moves with the newly created link. Ah, now I get it! You're making a 3-way connection. It's something I wasn't planning on allowing in Loci, since the number of inputs and outputs permitted for each locus must be well defined. Plus the workflow at a junction of 3+ connectors becomes a bit confounded. So, only 2-way connections are allowed. A 'splitter locus' may be developed instead to allow the workflow to be split or duplicated to run along more than one path. I'll fix it. Thanks for the bug report. > I also noticed another thing when I was messing around. If you move > a dot directly onto a locus (ie. on top of the two people) you lose this > input or output. Just something that will have to be worked around > eventually so dumb people like me don't keep accidentally losing their > connecting dots. Oh yeah, I noticed that a while back. Basically, the connector can be dragged under the symbol of its own icon, and when it's dropped, there's no way to get it out. The solution I was planning on was to define a radius that clears all locus ornaments. And when an unconnected connector is dropped within that radius, the connector is automatically extended to fall beyond it. > BTW, I really like the "windowlet" idea for the dots. This way you > wouldn't have to worry about trying to write a whole bunch of info inside a > dot and ending up with dots that are as big as the loci! I guess this will > have to work by getting the info from an XML document. Hmmmm... Yep. Connector information is kept as XML along with some other stuff about the locus. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Jan 5 21:01:55 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes References: Message-ID: <3873F793.B0ADFC2D@geoserve.net> Brad Chapman wrote: > > I went back to check on things (www.dbxml.org) after the break and > found out that the project is no longer open source with a BSD license, but > is apparently going to be bought out and go commericial...[censored: a > whole lot of not so nice words]... Oddly enough, Gary and I just noticed that today (Gary is in Boston, and I've been meeting with him to sort out some Loci design issues). > Anyways, I won't rant on about my > feelings on this, but I was just wondering if anyone knows what happens to > the code which was being previously released under a open source license. That's a good question. Ultimately, the code is the property of the authors, and they can do what they want with it. But, a license was granted to you to use the code under certain conditions. And that license is valid because (1) you obtained the license from the authors before the code was pulled, and (2) there is no condition saying that your license can be revoked at any time. I think this is why they were so thorough at removing the code from the Internet. > Along the same lines, has anyone heard about other open source XML > databases? (gotta keep me fingers crossed...:) XDBM is another. It was mentioned here a few months back and then again by Tim. Unfortunately, it has the wacky QPL license: End users can run it for free, but developers have to pay $300-500 per developer, per year. The license is incompatible with the GPL, so it would have to be distributed separately. Justin mentioned he would like to make his own GPL'd XML database. I'd love to see it. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From tim at nbci.com Wed Jan 5 13:00:21 2000 From: tim at nbci.com (Tim (not representing his employer's opinions)) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes References: <3873F793.B0ADFC2D@geoserve.net> Message-ID: <387386B5.DB1F01A1@nbci.com> > XDBM is another. It was mentioned here a few months back and then again by > Tim. Unfortunately, it has the wacky QPL license: End users can run it for > free, but developers have to pay $300-500 per developer, per year. This is not true. Look carefully at the license; if you are writing Free software compliant with their definition, then you only need pay these fees in the event you want paid support. > The > license is incompatible with the GPL, so it would have to be distributed > separately. This is (AFAIK) true. Incidentally, I have been dead to the world for some time now (having switched jobs, etc.) but might have something to contribute in the near future (eg. this spring). The original Codon was a hack of tacg and I stumbled trying to make it worthwhile in any other capacity; however it seems that the smart people at JPL (whom my father is now working with) may provide me with some ideas for how to implement the features that working biologists said were important to them (eg. "smart" handling of ambiguity in chromatograms, etc.). We'll see. I realized while reading today's discussions that I might as well suck it up and admit that I haven't had much to contribute over the last year, and get on with participating. -- "The difference between the right word and the almost-right word is the difference between lightning and the lightning-bug." --Mark Twain From bizzaro at geoserve.net Wed Jan 5 21:36:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes References: <3873F793.B0ADFC2D@geoserve.net> <387386B5.DB1F01A1@nbci.com> Message-ID: <3873FFA5.3E3489B7@geoserve.net> Tim Triche! I was wondering if it was you. Boy, long time no read :-) "Tim (not representing his employer's opinions)" wrote: > > > XDBM is another. It was mentioned here a few months back and then again by > > Tim. Unfortunately, it has the wacky QPL license: End users can run it for > > free, but developers have to pay $300-500 per developer, per year. > > This is not true. Look carefully at the license; if you are writing > Free software compliant with their definition, then you only need pay > these fees in the event you want paid support. Okay, here's the part in question: --------------------------------------------------- The fee charged for such uses of the work is: Number of Programmers Fee per programmer per annum 1 US$500 2-3 US$450 4-6 US$400 7-9 US$350 10+ US$300 (Australians add ten percent pro rata GST) This fee also entitles the licensee to free email support and customised enhancements to this work from Bowerbird Computing for the duration of the license. --------------------------------------------------- The phrase 'This fee also entitles the licensee to...' implies that the fee is not strictly _for_ the purpose of support. The word 'also' makes the sentence read as if the fee is initially for something else...'THEN you can ALSO get free e-mail support...' Here is the link: http://www.bowerbird.com.au/licensing.shtml > Incidentally, I have been dead to the world for some time now (having > switched jobs, etc.) but might have something to contribute in the near > future (eg. this spring). The original Codon was a hack of tacg and I > stumbled trying to make it worthwhile in any other capacity; however it > seems that the smart people at JPL (whom my father is now working with) Jet Propulsion Lab? > may provide me with some ideas for how to implement the features that > working biologists said were important to them (eg. "smart" handling of > ambiguity in chromatograms, etc.). We'll see. I realized while reading > today's discussions that I might as well suck it up and admit that I > haven't had much to contribute over the last year, and get on with > participating. Eh, don't worry about it. We're happy to have you help in any capacity and at any time. Have you seen the TODO list? Anything there appeal to you? BTW, I'll be updating it shortly to include 'figure building loci', security and chat, stuff that I forgot to add last time. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From dlapointe at mediaone.net Wed Jan 5 21:07:24 2000 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] DB2XML In-Reply-To: <200001052232.PAA09905@redpoll.pharmacy.ualberta.ca> References: <200001052232.PAA09905@redpoll.pharmacy.ualberta.ca> Message-ID: <00010521254101.00533@gnomen> Locians, The perl-XML group has been working on this problem, too. Try http://www.activestate.com/lyris/. Once there visit the perl-xml and search on database. DBIx::XML is one module that dovetails into some standardardized perl database code. Another thread is about mysql->exportxml.. On another note, DB2XML "relies on the functionality of the JDBC (or ODBC) driver in use" which may or may not be one of those roads to go down.
On Wed, 05 Jan 2000, Gary Van Domselaar wrote: > Locians, > > Jeff and I have been searching (mostly in vain) for a GPL XML DBMS. We > have found the following link, which we may resort to instead: > > http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/ > > > It is a java program, but it it worth checking for to see if the concept > of transforming relational data into XML is feasable for Loci. Comments > welcome! > > > -Gary and Jeff -- .david David Lapointe Do Not Attribute To Malice That Which Can Be Attributed To Stupidity From chapmanb at arches.uga.edu Thu Jan 6 04:30:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] XML database woes In-Reply-To: <3873FFA5.3E3489B7@geoserve.net> References: <3873F793.B0ADFC2D@geoserve.net> <387386B5.DB1F01A1@nbci.com> Message-ID: >"Tim (not representing his employer's opinions)" wrote: >> >> > XDBM is another. It was mentioned here a few months back and then >>again by >> > Tim. Unfortunately, it has the wacky QPL license: End users can run >>it for >> > free, but developers have to pay $300-500 per developer, per year. >> >> This is not true. Look carefully at the license; if you are writing >> Free software compliant with their definition, then you only need pay >> these fees in the event you want paid support. > >Okay, here's the part in question: > > >The phrase 'This fee also entitles the licensee to...' implies that the fee is >not strictly _for_ the purpose of support. The word 'also' makes the sentence >read as if the fee is initially for something else...'THEN you can ALSO get >free e-mail support...' > Reading the licensing info on this makes my head hurt, but if you look at the main Bowerbird page (http://www.bowerbird.com.au/) I think they spell out the licensing issues pretty clearly: Bowerbird Computing specialises in producing high quality XML tools. All of our products are free software. That is, with our products you have the freedom to modify the programs and can share your modifications freely with others. As a result of this you can also download, use and redistribute our software for no cost. The one restriction with this is that if you wish to release non-free versions of our software or link our software with your non-free program then you must pay us a fee for doing so. See our licensing page for more information. Purchasing a proprietary license also entitles you to free email support from the programmers who wrote the software you are using. To me, this reads that since Loci is freely available, we would not have to pay any licensing fees. It seems like you only have to pay if you use XDBM to build a commercial program, but not to build an open source program. Brad From bizzaro at geoserve.net Thu Jan 6 10:13:40 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] Python Style Guide Message-ID: <3874B124.68A2F8A2@geoserve.net> Anyone working in Python may find this useful: http://python.org/doc/essays/styleguide.html Cheers. Jeff From bizzaro at geoserve.net Thu Jan 6 11:13:11 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:04 2006 Subject: [Pipet Devel] more cvs changes References: Message-ID: <3874BF17.58C8557E@geoserve.net> Brad Chapman wrote: > > First, my little directory representation thing is now "complete." > You can scope it out the same way as before, by running './filegui.py &'. > It can now display filesystem representations as lists and trees, and both > have nifty little pixmaps which distinguish files from directories. It looks very nice, Brad! I'm thinking that for filesystem containers, the user should be able to switch between views. Both views would appear in the _same_ _windowlet_, and they can be switched via...pull-down menu button, as one solution. The menu button would appear above the list/tree view like so: +---------------------+ | [] | +---------------------+ | | | | | | | | | | | | | | +---------------------+ Clicking on the button pulls down a menu with the options: +---------------------+ | [] | +------------+---------+ | | List | | | Tree | | | Bla | | | | | +---------+ | | | | +---------------------+ The pull-down menu button (I don't know if that is the actual name) is the button with the 'down arrow' on it. For many GUI's, this is something to be used instead of menu bars. Why not menu bars? Composite loci will have composite GUI's. Imagine how ugly multiple menu bars would look, and how confusing it would be if they all had the same labels (for example, if they all had File, Edit and Help - note that loci won't use 'File' in the traditional sense). But I think pull-down menu buttons are best for 5+ options. What's another solution? Little buttons on a toolbar can be used if there are only 2-4 options to display. So the GUI could look like this: +---------------------+ | [] [] [] | +---------------------+ | | | | | | | | | | | | | | +---------------------+ Look at the 'views' buttons on the MS Windows file manager for an example. Little icons are used to indicate the options. > Second, I'm starting to do more with XML stuff. I guess I'm > thinking about getting into the overall XML scripting stuff (part II. o' > the TODO list). In preparation for this I went through loci-core quite > extensively and made almost an exact copy of it in loci-file. To see this > (which hopefully looks and behaves exactly like the most recent loci-core), > run './testgui.py' (which is located in the base directory of loci-file). > Why did I bother to do this? A couple of reasons: > > 1. To start messing around I am going to need to start changing some parts > of workspace.py in loci-core, so to not interfere with Jeff's work, I > decided to just make my own copy. The changes I'm making are small, so it > should be easy to integrate them into loci-core, if so desired. > 2. Related to number 1, I am kind of using this as a testing platform. So > we can try out ideas, see how people like them, and then if they are > accepted, integrate them into loci-core. I'd really rather we both work from one module, Brad. It doesn't bother me that someone else is coding the Workspace. It's just too confusing having two versions being developed separately. Plus imagine we get a few more developers who want to make separate modules too ;-) CVS is indeed very good at showing what changes have been made and managing multiple developers for one project. Otherwise, why use CVS? I think your changes to the Workspace are an improvement, and I should probably just work from what you have. But, after talking to Gary about the design of Loci, we will end up restructuring what we have. I'll get back to you about that. > Also, I have already made a change to how loci-core works. I > modified workspace.py so instead of loading individual python files like > 'container.py' to get initial info about a container, it now calls an XML > parser which parses a 'container.xml' file to get the initial info. From > Jeff's comments, it looked like this was a change that needed to be made, > so I thought I would start with this to get myself going on XML stuff in > the workspace. That's just what I was planning on doing. Thanks for your help :-) > The loci-file directory structure is still quite very unstable but > should hopefully get a little more stable within the next couple of days, > so if you haven't been making any changes in it, it might be best to just > checkout a fresh copy. I looked at the structure, and again, we'll be changing it quite a bit in the near future to go along with some major design improvements. > I'm really interested to hear everyone's comments, so if you have a > chance, please check it out. I suppose you're planning on doing this, but the filesystem views should appear together, in one windowlet, rather than in their own X-windows. Otherwise, it looks great. 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 Thu Jan 6 21:44:04 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] workflow diagram data model and databases Message-ID: <200001070244.TAA13669@redpoll.pharmacy.ualberta.ca> Locians, today Jeff and I agonized over different methods of storing descriptions of the workspace in a database. This led us to try and develop a data model for the workflow diagram, which is no easy task. the workspace has elements of tree-based model, in that there exist loci that can contain a workspace (the composite locus), but also there is a 'relational' web-like aspect where individual loci are related to other loci via the connections made between them. The description of the workspace is in XML. Finally Loci paradigm treats every locus as an object (with the exception of inheritance). So ultimately we have an XML description of a kind of 'web model' with a semi-heirachical structure as well. Because of the hardship that we've had in finding a database that servers our very specific needs, and is GPL's we decided to put the issue out on the floor for discussion. As we see it, these are some of the issues regarding the storage of the Workspace: 0. The XML description of the WFD should be modular, but easily portable. 1. The WFD should be constructed from a number of smaller XML documents, essentially one per locus in the WFD. If the WFD contains a composite Locus, then that locus is itself a pointer to the xml documents contained within it. A WFD then should be represented a single database (collection of files). The DBMS should be able to manage multiple independent databases. Connectivity between Loci must be preserved: If you want to extract a subset of loci from a WFD you must first disconnect thost loci from any 'external' loci, or you must extract the entire superset of connected loci along with the selected subset. I hope that makes sense. The DBMS should operate as client/server processes in order to accommodate distributed processing requirements. The DBMS should be able to quickly provide an XML description of information stored inside the database. Others considerations? Essentially our options, as far as we can see are: 1. Make our own custom database to store our workflow diagram. This may be easier than it sounds because the nature of our data storage needs are so unique and specific that trying to write an interface to an existing DBMS might be just as hard or harder that writing our own custom loci-db. 2. Use the MySQL database with an XML->SQL->XML interface. This would require some thinking in order to derive a relational data model that can accommodate the possibly quite complex Loci WFD. 3. Use the PostgreSQL Object-Relational database with an XML-SQL-XML interface. I'm not 'up' on how postgres differs from MySQL, but if it can more naturally handle objects (loci) and the relationships between them (connections) than this may be a better choice that MySQL. The same considerations exist for creating an intelligent data model for the WFD as in option 2. 4. Use an XML database. We would appreciate any and all comments on this important aspect of Loci's design architecture, so fire away! --gary =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From chapmanb at arches.uga.edu Fri Jan 7 12:27:53 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes In-Reply-To: <3874BF17.58C8557E@geoserve.net> References: Message-ID: > >I'm thinking that for filesystem containers, the user should be able to switch >between views. Both views would appear in the _same_ _windowlet_, and they >can be switched via...pull-down menu button, as one solution. > >The menu button would appear above the list/tree view like so: [...snip...lots of nice pictures] I think I get the idea that you are talking about here. So when I right (button 3) click on a loci, I get a "MS file manager type thing" with the loci contents in the window and options for the loci at the top (as menu-buttons)? Should the window that appears be imbedded in the loci window, or in its own X window? Just want to make sure I am completely with you on your ideas. > >I'd really rather we both work from one module, Brad. It doesn't bother me >that someone else is coding the Workspace. It's just too confusing having two >versions being developed separately. Plus imagine we get a few more >developers who want to make separate modules too ;-) > That sounds great to me. I just didn't know what you plans were for changing the main loci-core and didn't want to interfere with them. I just committed some more cvs changes today (see my next message) and modified the directory structure a little, but I think I have a "firm" structure for now. I'm definately open to changes, and will be very interested to hear your ideas on how to structure things. They'll probably be lots better than my structure since I just ended up building the structure through trial and error. >I think your changes to the Workspace are an improvement, and I should >probably just work from what you have. Keep me updated on your thoughts and plans. I'll be continuing to code heavily for the next few days (until I have to, ack, get back to classes) and then things will lighten up. Thanks much for your comments! Brad From chapmanb at arches.uga.edu Fri Jan 7 13:23:48 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] workflow diagram data model and databases In-Reply-To: <200001070244.TAA13669@redpoll.pharmacy.ualberta.ca> Message-ID: I'm quite glad you wrote about this! Very timely--I have just committed to cvs my attempts to start coding the workspace as XML. I was very happy to see that my attempt to do this is very much in line with your thinking. Let me just describe really quick what I've coded, and then I'll try and figure out how that relates to your message. The new loci-file has a few directory changes (sorry again!), so it is probably best to just check out a clean version if you want to look at it. By typing ./testgui.py & within the main directory, you get the familiar loci workspace. You can add and link loci as before, but now the workspace is being represented as xml in the created directory loci-file/workxml. This directory will be removed if you exit via the menu buttons (Session->Quit) to prevent the build-up of a lot of crap in the directory, but you can keep after you quit, if you want to look at it, by clicking on the close button on the X window (I disconnected this button from the quit dialog in loci-test for this purpose). Anyways, the xml is created according to the following plan: 1. When workspace.py starts up (ie. when a new workspace is created): a. make a directory: loci-file/workxml/workspace#. The number will refer to the number of the workstation being opened. Everytime a composite locus is opened, a new directory should be created. b. copy the file baselocus.xml to the new directory. This will be the overall script for the whole container. 2. When a locus is added to the workspace: a. copy the file locustype.xml to loci-file/workxml/workspace# modify the name as locustype#.xml b. make a xml:link to the locus in baselocus.xml 3. When loci are connected: a. modify the two loci to indicate the connection. change the input xml:link of the input to point to the output xml file change the output xml:link of the output to point to the input xml file 4. When info is added about a locus: (Note: this has only been sort of implemented for containers) a. load the DOM tree of the locus from its xml file b. make the modifications c. save the resulting xml file So basically, the overall plan is that every workspace gets a unique directory created containing baselocus.xml, an xml file with links to each of the loci in the workspace, and xml files for each loci in the workspace. So far, everything seems to work okay from my 4 points, except that point 4 has only been semi-implemented for containers. You can right (button 3) click on a container, and you will get an x window with options for the container. So far, the "set container" and "show contents" buttons work. When you click on "set container" you get a file-chooser dialog where you can select a directory for the container to hold. Then the program will load the xml file for this container, convert it into a DOM tree, add the container contents to it, and then save the xml file. The "show contents" button can then be used to retrieve these contents and display them as a tree. This is much like the ugly loci-file window did before, except that now things are done in DOM trees. Unfortunately, dealing with DOM trees also has led to a big slow-down in the time it takes to walk through a directory tree and write it as xml. To sort-of counteract this, the directory structure will only be parsed to a certain depth (currently it is set to something like 3). I'll try to think up speed-ups, but dealing with DOM trees slows things down. Sorry! Okay, whew, I think that's it. Let me get into the message! >today Jeff and I agonized over different methods of storing descriptions >of the workspace in a database. This led us to try and develop a data >model for the workflow diagram, which is no easy task. the workspace has >elements of tree-based model, Right, excellent point! When a workspace/composite loci is created within another workspace, the newly created workspace directory should be inside the previous workspace directory. I'll try to make my xml model do this. >0. The XML description of the WFD should be modular, but easily portable. I think making it xml makes it intrinsically portable. Once you create an xml workspace, you can zip it up (or use an xml compression tool) and send it around to your hearts content. >1. The WFD should be constructed from a number of smaller XML documents, >essentially one per locus in the WFD. If the WFD contains a composite >Locus, then that locus is itself a pointer to the xml documents contained >within it. Right-o. I think I've done this with my baselocus.xml thing. Let me know your thoughts on whether this satisfies this condition. >A WFD then should be represented a single database (collection of files). >The DBMS should be able to manage multiple independent databases. I think the directory structure that I currently have could be shoved into a database in the following way: directories -> main databases xml files -> sub-databases within the main database info in xml files -> the column/row info within the sub-database >Connectivity between Loci must be preserved: If you want to extract a >subset of loci from a WFD you must first disconnect thost loci from any >'external' loci, or you must extract the entire superset of connected >loci along with the selected subset. I hope that makes sense. Okay. I've connected loci using the xml:link linking language. How does this sound? Once we get the ability to disconnect links working, I think it shouldn't be too hard to disconnect the xml:links. >The DBMS should operate as client/server processes in order to >accommodate distributed processing requirements. Do we want to have a DBMS as a client/server process separate from the Loci client/server stuff, or as a part of it? >The DBMS should be able to quickly provide an XML description of >information stored inside the database. Okay, so we need xml to database and database to xml converters, right? >Essentially our options, as far as we can see are: > >1. Make our own custom database to store our workflow diagram. This may >be easier than it sounds because the nature of our data storage needs are >so unique and specific that trying to write an interface to an existing >DBMS might be just as hard or harder that writing our own custom loci-db. > >2. Use the MySQL database with an XML->SQL->XML interface. This would >require some thinking in order to derive a relational data model that can >accommodate the possibly quite complex Loci WFD. > >3. Use the PostgreSQL Object-Relational database with an XML-SQL-XML >interface. I'm not 'up' on how postgres differs from MySQL, but if it >can more naturally handle objects (loci) and the relationships between >them (connections) than this may be a better choice that MySQL. The >same considerations exist for creating an intelligent data model for the >WFD as in option 2. > >4. Use an XML database. Okay, I'll take an early stand on this issue and go straight for point number 4, specifically using XDBM as our XML database (side note: did we come to any conclusions about whether we can safely use this?). My arguments for this: 1. I think it will be *a lot* of work to write a database, or map xml into a relational database like MySQL/PostgreSQL. 2. I have been looking at XDBM and I really think it does a lot of what we need (these points are taken from the xdbm documentation) a. Provides xdbm2xml and xml2xdbm converters. b. Stores the XML in a pre-parsed format so we don't need to go through entire XML files to find stuff. c. You can load only parts of the XML file at a time. d. Allows you to stored linked lists (the xml:links, I assume) e. Will support DOM complient interfaces. The disadvantages are that XDBM is brand new and probably still has a lot of bugs to work out. In addition, the "FreeDOM" interfaces which will supply the DOM complient interface is still under design/development, and will require a set of python bindings once they are available. Okay, no more writing. Thanks much if you read all of the way here. I'm looking forward to hearing everyone's thoughts on the new loci-file and the xml stuff. Thanks again to Jeff and Gary for bringing this up! Brad From chapmanb at arches.uga.edu Fri Jan 7 13:29:33 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] XML database woes In-Reply-To: <3873FFA5.3E3489B7@geoserve.net> References: <3873F793.B0ADFC2D@geoserve.net> <387386B5.DB1F01A1@nbci.com> Message-ID: Just read this in the (very small) archive for XDBM: Fri, 24 Dec 1999 Hi everyone, I've had a request from the SDS group to dual license XDBM under the GPL as well so that there is no license confusion with those writing GPL'd programmes. Does anyone object? ...snip... Matthew Parry There are no responses to this message in the archives, but I think this might be a good sign that XDBM will be licensing friendly with Loci. Brad From bizzaro at geoserve.net Fri Jan 7 15:02:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes References: Message-ID: <38764673.C2F69E89@geoserve.net> Brad Chapman wrote: > > I think I get the idea that you are talking about here. So when I right > (button 3) click on a loci, Actually a double-click from the left (button 1) button. > I get a "MS file manager type thing" with the > loci contents in the window and options for the loci at the top (as > menu-buttons)? Should the window that appears be imbedded in the loci > window, or in its own X window? Just want to make sure I am completely with > you on your ideas. The 'loci window' is what I call a 'windowlet'. You already have one that shows up under the container, but it doesn't have any filesystem info. You have the filesystem info showing up in its own X-window. I'd like to have everything in windowlets if possible (not possible with non-GTK GUI's). > That sounds great to me. I just didn't know what you plans were for > changing the main loci-core and didn't want to interfere with them. I understand. But I'm not such an Uberhacker that you have to worry about stepping on my toes. > I just > committed some more cvs changes today (see my next message) and modified > the directory structure a little, but I think I have a "firm" structure for > now. I'm definately open to changes, and will be very interested to hear > your ideas on > how to structure things. They'll probably be lots better than my structure > since I just ended up building the structure through trial and error. We've got some major changes to make. We might as well start a new CVS module called 'loci'. Here is the preliminary structure: loci/ loci* (currently loci.py) (plus some other python scripts) frontends/ desktop/ (this is currently loci-core - see below) nli/ (this will be explained later) elements/ (elemental components) web/ (this will be the web interface) elements/ (elemental components) middleware/ (this is where loci XML will be kept) bindings/ (bindings to various loci) backends/ (this is where shared backends will be kept) Here is the structure of 'desktop': desktop/ desktop.py (currently workspace.py) (plus other python scripts for desktop) elements/ (elemental GUI widgets in PyGTK) pixmaps/ (misc. graphics) themes/ (some XML preferences here) gtkstyles/ (currently styles) symbols/ (currently under pixmaps) icons/ (currently under pixmaps) Note that the XML will be managed by the 'middleware' and should not be kept with the workspace/desktop. Additions/plugins to Loci will primarily use the elements and bindings directories. For example, a plugin for EMBOSS will put things in... loci/frontends/desktop/elements/emboss/ loci/frontends/nli/elements/emboss/ loci/frontends/web/elements/emboss/ loci/middleware/bindings/emboss/ And if you want EMBOSS to run publicly via Loci, you'd put it in the 'sandbox': loci/backends/emboss/ (if EMBOSS allows this) > Keep me updated on your thoughts and plans. I'll be continuing to code > heavily for the next few days (until I have to, ack, get back to classes) > and then things will lighten up. Thanks much for your comments! Okay. Thanks for everything :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 7 15:04:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] XML database woes References: <3873F793.B0ADFC2D@geoserve.net> <387386B5.DB1F01A1@nbci.com> Message-ID: <387646D5.BB3FD361@geoserve.net> Brad Chapman wrote: > > Just read this in the (very small) archive for XDBM: > > Fri, 24 Dec 1999 > Hi everyone, > I've had a request from the SDS group to dual license XDBM under > the GPL as well so that there is no license confusion with those > writing GPL'd programmes. Does anyone object? > > ...snip... > > Matthew Parry > > > There are no responses to this message in the archives, but I think this > might be a good sign that XDBM will be licensing friendly with Loci. Especially if they go ahead and GPL it. That'd be super cool. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 7 16:22:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] BioNavigator Message-ID: <3876590A.C878AE14@geoserve.net> This is pretty interesting: http://www.bionavigator.com/ Cheers. Jeff From bizzaro at geoserve.net Fri Jan 7 17:57:42 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes References: <38764673.C2F69E89@geoserve.net> Message-ID: <38766F66.B1415F96@geoserve.net> "J.W. Bizzaro" wrote: > > frontends/ > middleware/ > backends/ or maybe frontendware/ middleware/ backendware/ A little long but what the hey. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 7 19:39:50 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] GnomeIconView References: <3.0.32.20000104105411.0086cab0@postoffice.att.net> <200001061800.MAA10957@guanabana.nuclecu.unam.mx> Message-ID: <38768756.AF71F042@geoserve.net> Brad, a 3rd view for containers? Federico Mena Quintero wrote: > > GnomeIconList is being dropped in favor of something > better. That something may be the GnomeIconView that I am writing in > the eog module on CVS; it is not finished yet because I am working on > the Evolution calendaring stuff right now. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 7 19:42:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes References: <38764673.C2F69E89@geoserve.net> <38766F66.B1415F96@geoserve.net> Message-ID: <38768805.137E7D62@geoserve.net> "J.W. Bizzaro" wrote: > > frontendware/ > middleware/ > backendware/ or maybe still frontend/ middle/ backend/ Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat Jan 8 09:57:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes References: <3874BF17.58C8557E@geoserve.net> Message-ID: <3877504F.B766D939@geoserve.net> "J.W. Bizzaro" wrote: > > I'm thinking that for filesystem containers, the user should be able to switch > between views. Both views would appear in the _same_ _windowlet_, and they > can be switched via...pull-down menu button, as one solution. [...] > But I think pull-down menu buttons are best for 5+ options. What's another > solution? Little buttons on a toolbar can be used if there are only 2-4 > options to display. A third solution would be to use a notebook widget. Each tab would give a different view. What do you guys think is best? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat Jan 8 10:35:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes References: <38764673.C2F69E89@geoserve.net> Message-ID: <3877595C.F2626C3D@geoserve.net> Another change to the proposed structure: I'd move loci/ desktop/ themes/ icons/ (currently under pixmaps) to loci/ backends/ (this is where shared backends will be kept) icons/ (currently under pixmaps) Why, and why not symbols? Because icons are specific to backend applications; symbols are not. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat Jan 8 20:44:44 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] Python 101 Message-ID: <3877E80C.623F6ECE@geoserve.net> IBM DeveloperWorks has a little intro to Python: http://www-4.ibm.com/software/developer/library/python101.html Jeff From chapmanb at arches.uga.edu Sun Jan 9 12:41:12 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] Resend: workflow diagram data model and databases In-Reply-To: <200001070244.TAA13669@redpoll.pharmacy.ualberta.ca> Message-ID: Hello all! I actually sent this a couple of days ago but I just realized that I don't think it ever made it to the list (at least, it never made it back to me), although it somehow managed to get in the archives. Weirdo! Anyways, my apologies for the re-send if I'm the only one who failed to get it. I'm quite glad you wrote about this! Very timely--I have just committed to cvs my attempts to start coding the workspace as XML. I was very happy to see that my attempt to do this is very much in line with your thinking. Let me just describe really quick what I've coded, and then I'll try and figure out how that relates to your message. The new loci-file has a few directory changes (sorry again!), so it is probably best to just check out a clean version if you want to look at it. By typing ./testgui.py & within the main directory, you get the familiar loci workspace. You can add and link loci as before, but now the workspace is being represented as xml in the created directory loci-file/workxml. This directory will be removed if you exit via the menu buttons (Session->Quit) to prevent the build-up of a lot of crap in the directory, but you can keep after you quit, if you want to look at it, by clicking on the close button on the X window (I disconnected this button from the quit dialog in loci-test for this purpose). Anyways, the xml is created according to the following plan: 1. When workspace.py starts up (ie. when a new workspace is created): a. make a directory: loci-file/workxml/workspace#. The number will refer to the number of the workstation being opened. Everytime a composite locus is opened, a new directory should be created. b. copy the file baselocus.xml to the new directory. This will be the overall script for the whole container. 2. When a locus is added to the workspace: a. copy the file locustype.xml to loci-file/workxml/workspace# modify the name as locustype#.xml b. make a xml:link to the locus in baselocus.xml 3. When loci are connected: a. modify the two loci to indicate the connection. change the input xml:link of the input to point to the output xml file change the output xml:link of the output to point to the input xml file 4. When info is added about a locus: (Note: this has only been sort of implemented for containers) a. load the DOM tree of the locus from its xml file b. make the modifications c. save the resulting xml file So basically, the overall plan is that every workspace gets a unique directory created containing baselocus.xml, an xml file with links to each of the loci in the workspace, and xml files for each loci in the workspace. So far, everything seems to work okay from my 4 points, except that point 4 has only been semi-implemented for containers. You can right (button 3) click on a container, and you will get an x window with options for the container. So far, the "set container" and "show contents" buttons work. When you click on "set container" you get a file-chooser dialog where you can select a directory for the container to hold. Then the program will load the xml file for this container, convert it into a DOM tree, add the container contents to it, and then save the xml file. The "show contents" button can then be used to retrieve these contents and display them as a tree. This is much like the ugly loci-file window did before, except that now things are done in DOM trees. Unfortunately, dealing with DOM trees also has led to a big slow-down in the time it takes to walk through a directory tree and write it as xml. To sort-of counteract this, the directory structure will only be parsed to a certain depth (currently it is set to something like 3). I'll try to think up speed-ups, but dealing with DOM trees slows things down. Sorry! Okay, whew, I think that's it. Let me get into the message! >today Jeff and I agonized over different methods of storing descriptions >of the workspace in a database. This led us to try and develop a data >model for the workflow diagram, which is no easy task. the workspace has >elements of tree-based model, Right, excellent point! When a workspace/composite loci is created within another workspace, the newly created workspace directory should be inside the previous workspace directory. I'll try to make my xml model do this. >0. The XML description of the WFD should be modular, but easily portable. I think making it xml makes it intrinsically portable. Once you create an xml workspace, you can zip it up (or use an xml compression tool) and send it around to your hearts content. >1. The WFD should be constructed from a number of smaller XML documents, >essentially one per locus in the WFD. If the WFD contains a composite >Locus, then that locus is itself a pointer to the xml documents contained >within it. Right-o. I think I've done this with my baselocus.xml thing. Let me know your thoughts on whether this satisfies this condition. >A WFD then should be represented a single database (collection of files). >The DBMS should be able to manage multiple independent databases. I think the directory structure that I currently have could be shoved into a database in the following way: directories -> main databases xml files -> sub-databases within the main database info in xml files -> the column/row info within the sub-database >Connectivity between Loci must be preserved: If you want to extract a >subset of loci from a WFD you must first disconnect thost loci from any >'external' loci, or you must extract the entire superset of connected >loci along with the selected subset. I hope that makes sense. Okay. I've connected loci using the xml:link linking language. How does this sound? Once we get the ability to disconnect links working, I think it shouldn't be too hard to disconnect the xml:links. >The DBMS should operate as client/server processes in order to >accommodate distributed processing requirements. Do we want to have a DBMS as a client/server process separate from the Loci client/server stuff, or as a part of it? >The DBMS should be able to quickly provide an XML description of >information stored inside the database. Okay, so we need xml to database and database to xml converters, right? >Essentially our options, as far as we can see are: > >1. Make our own custom database to store our workflow diagram. This may >be easier than it sounds because the nature of our data storage needs are >so unique and specific that trying to write an interface to an existing >DBMS might be just as hard or harder that writing our own custom loci-db. > >2. Use the MySQL database with an XML->SQL->XML interface. This would >require some thinking in order to derive a relational data model that can >accommodate the possibly quite complex Loci WFD. > >3. Use the PostgreSQL Object-Relational database with an XML-SQL-XML >interface. I'm not 'up' on how postgres differs from MySQL, but if it >can more naturally handle objects (loci) and the relationships between >them (connections) than this may be a better choice that MySQL. The >same considerations exist for creating an intelligent data model for the >WFD as in option 2. > >4. Use an XML database. Okay, I'll take an early stand on this issue and go straight for point number 4, specifically using XDBM as our XML database (side note: did we come to any conclusions about whether we can safely use this?). My arguments for this: 1. I think it will be *a lot* of work to write a database, or map xml into a relational database like MySQL/PostgreSQL. 2. I have been looking at XDBM and I really think it does a lot of what we need (these points are taken from the xdbm documentation) a. Provides xdbm2xml and xml2xdbm converters. b. Stores the XML in a pre-parsed format so we don't need to go through entire XML files to find stuff. c. You can load only parts of the XML file at a time. d. Allows you to stored linked lists (the xml:links, I assume) e. Will support DOM complient interfaces. The disadvantages are that XDBM is brand new and probably still has a lot of bugs to work out. In addition, the "FreeDOM" interfaces which will supply the DOM complient interface is still under design/development, and will require a set of python bindings once they are available. Okay, no more writing. Thanks much if you read all of the way here. I'm looking forward to hearing everyone's thoughts on the new loci-file and the xml stuff. Thanks again to Jeff and Gary for bringing this up! Brad From chapmanb at arches.uga.edu Sun Jan 9 13:03:08 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes In-Reply-To: <38764673.C2F69E89@geoserve.net> References: Message-ID: J.W. Bizzaro wrote: >Actually a double-click from the left (button 1) button. > >The 'loci window' is what I call a 'windowlet'. You already have one that >shows up under the container, but it doesn't have any filesystem info. You >have the filesystem info showing up in its own X-window. I'd like to have >everything in windowlets if possible (not possible with non-GTK GUI's). > Okee-dokee. I just cvsed a new container representation that (I think) does what you are looking for. As usual, you can fire up the loci-file program with './testgui.py &'. If you add a container and then give it a double click, you'll see an imbedded window which I tried to design according to Jeff's specifications. Along the top are the toolbar buttons and pull down menu buttons (will little arrows) to do everything, in the middle is the current representation of the filesystem, and at the bottom are some labels indicating info about the container. If you click the set button, you get a dialog allowing you to chose a directory to be represented by the container. Pressing 'OK' will create the xml representation of this (this is pretty slow for large/complex directories). Currently, you need to click the 'Renew' button to show the new filesystem after you add it. I tried very hard to get an "automatic" update after resetting the container contents but I ran into the problem that all of the code to be run in the main window (ie. the refresh command) executes before opening the chooser dialog (a new window). Does anyone with more experience with Gtk/python have any ideas about how to make the main window wait until the new window finishes processing stuff? Anyways, besides selecting and renewing, you can also use the two pull down style buttons to change between a tree and list view, and between setting the container as a database or filesystem (although this doesn't currently do anything except for update the label). Well, that's it on that. I look forward to hearing comments/suggestions. > >We've got some major changes to make. We might as well start a new CVS module >called 'loci'. Here is the preliminary structure: > Looks great to me. I'll leave this up to Jeff, since he has the master directory plan. Let me know when you want loci-file stuff to move. Brad From bizzaro at geoserve.net Sun Jan 9 14:31:41 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] Resend: workflow diagram data model and databases References: Message-ID: <3878E21D.29E61DD2@geoserve.net> Brad Chapman wrote: > > Hello all! I actually sent this a couple of days ago but I just realized > that I don't think it ever made it to the list (at least, it never made it > back to me), although it somehow managed to get in the archives. Weirdo! > Anyways, my apologies for the re-send if I'm the only one who failed to get > it. Sendmail went down a while ago. That might have been the problem. > So basically, the overall plan is that every workspace gets a unique > directory created containing baselocus.xml, an xml file with links to each > of the loci in the workspace, and xml files for each loci in the workspace. As Gary mentioned, we will want to use a real database for all this. What you've done is a step in the right direction though. > This is much like the ugly loci-file window did before, except that > now things are done in DOM trees. Unfortunately, dealing with DOM trees > also has led to a big slow-down in the time it takes to walk through a > directory tree and write it as xml. To sort-of counteract this, the > directory structure will only be parsed to a certain depth (currently it is > set to something like 3). I'll try to think up speed-ups, but dealing with > DOM trees slows things down. Sorry! I would favor parsing only the highest level (depth = 1) directory. Would that speed things up? It seems to me that parsing depth = 3 or more would give you much more to parse, and it would be done everytime a new directory is opened. > Right, excellent point! When a workspace/composite loci is created within > another workspace, the newly created workspace directory should be inside > the previous workspace directory. I'll try to make my xml model do this. A WFD represents any contiguously connected group of loci. It can be as small as a single, disconnected locus, and it has no upper size limit. The boundaries of a WFD are the unconnected connectors. A WFD wholey enclosed by its boundaries (the WFD is unconnected) should be represented by its own portable data structure (a database). A WFD may represented on a higher level as a composite locus. The result is nested structures: WFD's inside of WFD's and Workspaces (the windowlet view) inside of Workspaces. But by connecting a composite locus to other loci, its WFD becomes connected. A WFD not wholey enclosed by its boundaries (connected via higher-level composite locus) may still be its own portable data structure, but this would require connectivity between these structures (is this possible?). Otherwise, the connection of WFD via composites will require integration of data structures. > I think making it xml makes it intrinsically portable. Once you create an > xml workspace, you can zip it up (or use an xml compression tool) and send > it around to your hearts content. Gary and I figured that if we wanted portibility, a single XML file would be best. But if we had one giant XML file, it would be difficult to hash/search. This is why we settled on an XML-capable database. > I think the directory structure that I currently have could be shoved into > a database in the following way: > > directories -> main databases > xml files -> sub-databases within the main database > info in xml files -> the column/row info within the sub-database Looks good. But we wouldn't use the fuilesystem as an intermediate, right? > Okay. I've connected loci using the xml:link linking language. How does > this sound? Once we get the ability to disconnect links working, I think it > shouldn't be too hard to disconnect the xml:links. That might work. > >The DBMS should operate as client/server processes in order to > >accommodate distributed processing requirements. > > Do we want to have a DBMS as a client/server process separate from the Loci > client/server stuff, or as a part of it? Heh. Actually, Gary and I spent a lot of time discussing how we can split Loci up into functional layers, running as separate processes. It turns out that nearly all of the use of XML will belong to the 'middleware' process. The Workspace/Desktop will be a 'thin-client, frontend' process that communicates with the middleware via a high-level API. (So, about half of your work will eventually run from separate processes, Brad.) For the sake of allowing other frontends to be used with Loci (for example, a Web interface), the API will be a 'dialog' between the processes, where the frontend requests that the middleware do something, and the middleware responds to that request. For example: frontend: connect middleware: connect frontend: composite middleware: composite middleware: xml description of the composite gui follows ... And the workspace (frontend) won't actually make connections, etc. until it gets the command echoed back, indicating it is okay to proceed. I'm thinking that the frontend will be pretty dumb, doing only what the user and middleware say to do. So, you can see how various frontends can be made for Loci, including the mysterious 'NLI'. Maybe Gary will explain this some more ;-) > >The DBMS should be able to quickly provide an XML description of > >information stored inside the database. > > Okay, so we need xml to database and database to xml converters, right? Yes. (continued) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 9 14:38:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] Resend: workflow diagram data model and databases References: Message-ID: <3878E3D2.A004562C@geoserve.net> (continuation) Brad Chapman wrote: > > Okay, I'll take an early stand on this issue and go straight for point > number 4, specifically using XDBM as our XML database (side note: did we > come to any conclusions about whether we can safely use this?). We can use it, but we can't package it with Loci. I think we should keep in mind that we may swap it for something more suitable (GPL'd) later on. > My arguments for this: > > 1. I think it will be *a lot* of work to write a database, or map xml into > a relational database like MySQL/PostgreSQL. But I'm not so sure that we even need most of the functionality of a general-purpose database. > 2. I have been looking at XDBM and I really think it does a lot of what we > need (these points are taken from the xdbm documentation) > a. Provides xdbm2xml and xml2xdbm converters. > b. Stores the XML in a pre-parsed format so we don't need to go > through entire XML files to find stuff. > c. You can load only parts of the XML file at a time. > d. Allows you to stored linked lists (the xml:links, I assume) > e. Will support DOM complient interfaces. That all looks very good. > The disadvantages are that XDBM is brand new and probably still has a lot > of bugs to work out. In addition, the "FreeDOM" interfaces which will > supply the DOM complient interface is still under design/development, and > will require a set of python bindings once they are available. The advantages still outweigh the disadvantages. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 9 14:42:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] more cvs changes References: Message-ID: <3878E4BE.7FFD2F56@geoserve.net> Brad Chapman wrote: > > Okee-dokee. I just cvsed a new container representation that (I think) does > what you are looking for. I'll go take a look at it and get back to you. > >We've got some major changes to make. We might as well start a new CVS module > >called 'loci'. Here is the preliminary structure: > > Looks great to me. I'll leave this up to Jeff, since he has the master > directory plan. Let me know when you want loci-file stuff to move. Brad, I'll set up the new module when you're done with loci-file. Give me a window of time for when you won't be working on it. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 9 16:03:52 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:05 2006 Subject: [Pipet Devel] resent Message-ID: <3878F7B8.8FE070@geoserve.net> This message appears to have gotten lost too, so I rebooted. Brad Chapman wrote: > > Hello all! I actually sent this a couple of days ago but I just realized > that I don't think it ever made it to the list (at least, it never made it > back to me), although it somehow managed to get in the archives. Weirdo! > Anyways, my apologies for the re-send if I'm the only one who failed to get > it. Sendmail went down a while ago. That might have been the problem. > So basically, the overall plan is that every workspace gets a unique > directory created containing baselocus.xml, an xml file with links to each > of the loci in the workspace, and xml files for each loci in the workspace. As Gary mentioned, we will want to use a real database for all this. What you've done is a step in the right direction though. > This is much like the ugly loci-file window did before, except that > now things are done in DOM trees. Unfortunately, dealing with DOM trees > also has led to a big slow-down in the time it takes to walk through a > directory tree and write it as xml. To sort-of counteract this, the > directory structure will only be parsed to a certain depth (currently it is > set to something like 3). I'll try to think up speed-ups, but dealing with > DOM trees slows things down. Sorry! I would favor parsing only the highest level (depth = 1) directory. Would that speed things up? It seems to me that parsing depth = 3 or more would give you much more to parse, and it would be done everytime a new directory is opened. > Right, excellent point! When a workspace/composite loci is created within > another workspace, the newly created workspace directory should be inside > the previous workspace directory. I'll try to make my xml model do this. A WFD represents any contiguously connected group of loci. It can be as small as a single, disconnected locus, and it has no upper size limit. The boundaries of a WFD are the unconnected connectors. A WFD wholey enclosed by its boundaries (the WFD is unconnected) should be represented by its own portable data structure (a database). A WFD may represented on a higher level as a composite locus. The result is nested structures: WFD's inside of WFD's and Workspaces (the windowlet view) inside of Workspaces. But by connecting a composite locus to other loci, its WFD becomes connected. A WFD not wholey enclosed by its boundaries (connected via higher-level composite locus) may still be its own portable data structure, but this would require connectivity between these structures (is this possible?). Otherwise, the connection of WFD via composites will require integration of data structures. > I think making it xml makes it intrinsically portable. Once you create an > xml workspace, you can zip it up (or use an xml compression tool) and send > it around to your hearts content. Gary and I figured that if we wanted portibility, a single XML file would be best. But if we had one giant XML file, it would be difficult to hash/search. This is why we settled on an XML-capable database. > I think the directory structure that I currently have could be shoved into > a database in the following way: > > directories -> main databases > xml files -> sub-databases within the main database > info in xml files -> the column/row info within the sub-database Looks good. But we wouldn't use the fuilesystem as an intermediate, right? > Okay. I've connected loci using the xml:link linking language. How does > this sound? Once we get the ability to disconnect links working, I think it > shouldn't be too hard to disconnect the xml:links. That might work. > >The DBMS should operate as client/server processes in order to > >accommodate distributed processing requirements. > > Do we want to have a DBMS as a client/server process separate from the Loci > client/server stuff, or as a part of it? Heh. Actually, Gary and I spent a lot of time discussing how we can split Loci up into functional layers, running as separate processes. It turns out that nearly all of the use of XML will belong to the 'middleware' process. The Workspace/Desktop will be a 'thin-client, frontend' process that communicates with the middleware via a high-level API. (So, about half of your work will eventually run from separate processes, Brad.) For the sake of allowing other frontends to be used with Loci (for example, a Web interface), the API will be a 'dialog' between the processes, where the frontend requests that the middleware do something, and the middleware responds to that request. For example: frontend: connect middleware: connect frontend: composite middleware: composite middleware: xml description of the composite gui follows ... And the workspace (frontend) won't actually make connections, etc. until it gets the command echoed back, indicating it is okay to proceed. I'm thinking that the frontend will be pretty dumb, doing only what the user and middleware say to do. So, you can see how various frontends can be made for Loci, including the mysterious 'NLI'. Maybe Gary will explain this some more ;-) > >The DBMS should be able to quickly provide an XML description of > >information stored inside the database. > > Okay, so we need xml to database and database to xml converters, right? Yes. (continued) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 9 19:06:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] libxml intro Message-ID: <3879227D.37EF28E9@geoserve.net> IBM DeveloperWorks has an intro to Gnome's libxml: http://www-4.ibm.com/software/developer/library/gnome3/ BTW, are there Python bindings to this? Jeff From bizzaro at geoserve.net Sun Jan 9 19:33:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Secure Programming for Linux HOWTO Message-ID: <387928EB.7B8CE209@geoserve.net> This should be required reading for Loci developers: http://dwheeler.com/secure-programs/Secure-Programs-HOWTO.html Jeff From gvd at redpoll.pharmacy.ualberta.ca Sun Jan 9 19:25:37 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] workflow diagram data model and databases In-Reply-To: from "Brad Chapman" at Jan 7, 0 01:23:48 pm Message-ID: <200001100025.RAA21396@redpoll.pharmacy.ualberta.ca> > 1. When workspace.py starts up (ie. when a new workspace is created): > a. make a directory: loci-file/workxml/workspace#. > The number will refer to the number of the workstation being opened. > Everytime a composite locus is opened, a new directory should be > created. > b. copy the file baselocus.xml to the new directory. This will be the > overall script for the whole container. > 2. When a locus is added to the workspace: > a. copy the file locustype.xml to loci-file/workxml/workspace# > modify the name as locustype#.xml > b. make a xml:link to the locus in baselocus.xml > 3. When loci are connected: > a. modify the two loci to indicate the connection. > change the input xml:link of the input to point to the output xml file > change the output xml:link of the output to point to the input xml file this sounds about right wrt to what Jeff and I were discussing. > 4. When info is added about a locus: > (Note: this has only been sort of implemented for containers) > a. load the DOM tree of the locus from its xml file > b. make the modifications > c. save the resulting xml file I think this is the best 'open standard' way of doing it. > > So basically, the overall plan is that every workspace gets a unique > directory created containing baselocus.xml, an xml file with links to each > of the loci in the workspace, and xml files for each loci in the workspace. Or I would say that each workspace geta a unique database created conting a baselocux.xml, and xml files for each locus in the workspace. Whether we plan to have an xml file containing the linking iformation as opposed to containing the linking information in each locus is a matter of debate. I have no personal preference, In fact a separate xml file the locus _references_ and the connections (including connection type) between them (genereated dynamically during the construction of a WFD) may be an interesting approach. > So far, everything seems to work okay from my 4 points, except that > point 4 has only been semi-implemented for containers. You can right > (button 3) click on a container, and you will get an x window with options > for the container. So far, the "set container" and "show contents" buttons > work. When you click on "set container" you get a file-chooser dialog where > you can select a directory for the container to hold. Then the program will > load the xml file for this container, convert it into a DOM tree, add the > container contents to it, and then save the xml file. The "show contents" > button can then be used to retrieve these contents and display them as a > tree. > This is much like the ugly loci-file window did before, except that > now things are done in DOM trees. Unfortunately, dealing with DOM trees > also has led to a big slow-down in the time it takes to walk through a > directory tree and write it as xml. To sort-of counteract this, the > directory structure will only be parsed to a certain depth (currently it is > set to something like 3). I'll try to think up speed-ups, but dealing with > DOM trees slows things down. Sorry! what if parsing depth was set to one, and subdirectories were retrieved dynamaically, (by user action folder.open) to reveal the contents of that subdirectory. The 'filesystem' get parsed together piecemeal as the user manually traverses it. This aspect may becomem more important when the 'filesystem' resides over a network with a slow pipe. I submint that only what is necessay be undertaken. Just my 2 cents (Cdn) ;-) > Okay, whew, I think that's it. Let me get into the message! > > >today Jeff and I agonized over different methods of storing descriptions > >of the workspace in a database. This led us to try and develop a data > >model for the workflow diagram, which is no easy task. the workspace has > >elements of tree-based model, > > Right, excellent point! When a workspace/composite loci is created within > another workspace, the newly created workspace directory should be inside > the previous workspace directory. I'll try to make my xml model do this. jeff and I are thinking about data models as well. This is a critical part of the Loci's design, so it is in everyone's best interests to participate on this subject. Thanks for your your input, Brad. It it much appreciated > > >0. The XML description of the WFD should be modular, but easily portable. > > I think making it xml makes it intrinsically portable. Once you create an > xml workspace, you can zip it up (or use an xml compression tool) and send > it around to your hearts content. > > >1. The WFD should be constructed from a number of smaller XML documents, > >essentially one per locus in the WFD. If the WFD contains a composite > >Locus, then that locus is itself a pointer to the xml documents contained > >within it. > > Right-o. I think I've done this with my baselocus.xml thing. Let me know > your thoughts on whether this satisfies this condition. > sounds good to me. > >A WFD then should be represented a single database (collection of files). > >The DBMS should be able to manage multiple independent databases. > > I think the directory structure that I currently have could be shoved into > a database in the following way: > > directories -> main databases > xml files -> sub-databases within the main database > info in xml files -> the column/row info within the sub-database > > >Connectivity between Loci must be preserved: If you want to extract a > >subset of loci from a WFD you must first disconnect thost loci from any > >'external' loci, or you must extract the entire superset of connected > >loci along with the selected subset. I hope that makes sense. > > Okay. I've connected loci using the xml:link linking language. How does > this sound? Once we get the ability to disconnect links working, I think it > shouldn't be too hard to disconnect the xml:links. that could be taken care of easily enough with a Loci database interface exception handling message, so again sound good to me. > > >The DBMS should operate as client/server processes in order to > >accommodate distributed processing requirements. > > Do we want to have a DBMS as a client/server process separate from the Loci > client/server stuff, or as a part of it? For modularity, I would propose a separate client/server. I'm sure the XDBM database is a client/server system, no? > > >The DBMS should be able to quickly provide an XML description of > >information stored inside the database. > > Okay, so we need xml to database and database to xml converters, right? > Only if we decide on MySQL or postgreSQL (which is better for storing our data model than MySQL I have learned). > > >Essentially our options, as far as we can see are: > > > >1. Make our own custom database to store our workflow diagram. This may > >be easier than it sounds because the nature of our data storage needs are > >so unique and specific that trying to write an interface to an existing > >DBMS might be just as hard or harder that writing our own custom loci-db. > > > >2. Use the MySQL database with an XML->SQL->XML interface. This would > >require some thinking in order to derive a relational data model that can > >accommodate the possibly quite complex Loci WFD. > > > >3. Use the PostgreSQL Object-Relational database with an XML-SQL-XML > >interface. I'm not 'up' on how postgres differs from MySQL, but if it > >can more naturally handle objects (loci) and the relationships between > >them (connections) than this may be a better choice that MySQL. The > >same considerations exist for creating an intelligent data model for the > >WFD as in option 2. > > > >4. Use an XML database. > > Okay, I'll take an early stand on this issue and go straight for point > number 4, specifically using XDBM as our XML database (side note: did we > come to any conclusions about whether we can safely use this?). My > arguments for this: > > 1. I think it will be *a lot* of work to write a database, or map xml into > a relational database like MySQL/PostgreSQL. I agree. > 2. I have been looking at XDBM and I really think it does a lot of what we > need (these points are taken from the xdbm documentation) > a. Provides xdbm2xml and xml2xdbm converters. > b. Stores the XML in a pre-parsed format so we don't need to go > through entire XML files to find stuff. Big Plus. > c. You can load only parts of the XML file at a time. > d. Allows you to stored linked lists (the xml:links, I assume) > e. Will support DOM complient interfaces. Good! > > The disadvantages are that XDBM is brand new and probably still has a lot > of bugs to work out. In addition, the "FreeDOM" interfaces which will > supply the DOM complient interface is still under design/development, and > will require a set of python bindings once they are available. Well, we're no strangers to writing python bindings ;-) i'm also leaning towards Brad's idea of using the XML database. I'd like to see an 'all XML solution' for communication between our front-end and middleware, and possibly even backend-ware stuff. BTW brad. Jeff and I looked at you latst work on representing filesystems as containers in Loci. Very nice Work. We looked at the code and it looks like you are using they python xmllib. You may want to see if you get get the GNOME xml-parser to work for you instead. it has a SAX interface http://www.megginson.com/SAX/index.html). To accomodate the retrieval of XML from a distributed environment, the XML parser needs to be CORBA compliant (It can then pss the DOM over CORBA). The GNOME xml-parser can do this: Check out (http://xmlsoft.org/xml.html). Regards g. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at geoserve.net Sun Jan 9 19:56:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] more Python 101 Message-ID: <38792E4D.9F38EC4E@geoserve.net> The saga continues: http://www-4.ibm.com/software/developer/library/pythonunit/ We may see several installments of this feature. Jeff From chapmanb at arches.uga.edu Sun Jan 9 23:14:37 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] libxml questions Message-ID: J.W. Bizzaro wrote: >IBM DeveloperWorks has an intro to Gnome's libxml: Gary Van Domselaar wrote: >You may want to see if you get get the GNOME xml-parser to work >for you instead. Quick question--what are the specific advantages to libxml/gnome-xml that make us want to use it over the PyXML modules? I took a look at the library reference for the module (http://xmlsoft.org/libxml.html) and it seems to offer the same things as the PyXML package: regular parser, SAX interface, DOM stuff, etc. I'm probably just missing the advantages of it--could someone detail them for me? Gary Van Domselaar wrote: >To accomodate the retrieval of XML from a >distributed environment, the XML parser needs to be CORBA compliant (It >can >then pss the DOM over CORBA). The GNOME >xml-parser can do this: Check out (http://xmlsoft.org/xml.html). This definately seems like an advantage, but I guess I don't really understand what it means for an XML parser to be CORBA compliant. Does it have to implement some sort of interface? Sorry, this is just my ignorance, but how do the gnome xml parsers accomplish this? Thanks much for any help anyone could provide on enlightening me! Brad From bizzaro at geoserve.net Mon Jan 10 15:27:54 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Sodipodi Message-ID: <387A40CA.E8171D9@geoserve.net> Locians, I came across Sodipodi: http://www.ariman.ee/linux/sodipodi/ (impressive screensots) which is a GnomeCanvas-based vector drawing application. It also uses SVG (Scalable Vector Graphics), which is an XML description of drawings. Just what the doctor ordered. This is probably in the lead with respect to vector drawing applications that can be used as, and with, Loci viewers. Another option mentioned before is Sketch. But Sketch does not use SVG. Cheers. Jeff From stein at fmnh.org Mon Jan 10 15:25:05 2000 From: stein at fmnh.org (JES) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Bioinformatics Workshop Announcement Message-ID: <200001102023.OAA17253@mail.fmnh.org> For those who have not seen this announcement... Info below can also be found at: http://www4.nationalacademies.org/cls/bbhome.nsf The National Research Council invites you to attend: BIOINFORMATICS: Converting Data to Knowledge Date: February 16, 2000 Location: National Academies 2101 Constitution Ave. N.W. Washington, DC Opening Remarks: (0830) (to be determined) Opening Presentation: The Signal Transduction Knowledge Environment (0840) Brian Ray, American Association for the Advancement of Science Session I: Generating and Integrating Biological Data (0900-1030) a. Methods for data collection Dong-Guk Shin, University of Connecticut b. Data characteristics Stephen Koslow, Office on Neuroinformatics, National Institute of Mental Health c. Data integration Jim Garrels, Proteome, Inc. Moderated Discussion: By Susan Davidson, University of Pennsylvania Break (1030-1045) Session II: Interoperability of Databases (1045-1230) a. Design features of interoperable databases Daniel Gardner, Cornell University b. Information retrieval and complex queries Peter Karp, SRI International c. Definition of data elements and database structure William Gelbart, Harvard University d. Novel approaches to achieving interoperability Jaron Lanier, National Tele-Immersion Initiative Moderated Discussion: By Perry Miller, Yale University Lunch (1230-1330) Session III: Database Integrity (1330-1500) a. Curation and quality control Michael Cherry, Stanford University b. Error detection protocols Chris Overton, University of Pennsylvania c. Methods for correcting errors (to be determined) Moderated Discussion (1415-1500) (to be determined) Break (1500-1515) Session IV: Converting Data to Knowledge--Analytical Approaches (1515-1645) a. Modeling and simulation James Bower, California Institute of Technology b. Data Mining Douglas Brutlag, Stanford University c. Visualization of model fit to data John Mazziotta, University of California Los Angeles Moderated Discussion (1600-1645) By Ray White, University of Utah Wrap Up (1645-1700) Adjourn (1700) -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org -------------------------- From gvd at redpoll.pharmacy.ualberta.ca Mon Jan 10 15:34:28 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] libxml questions In-Reply-To: from "Brad Chapman" at Jan 9, 0 11:14:37 pm Message-ID: <200001102034.NAA24834@redpoll.pharmacy.ualberta.ca> > Gary Van Domselaar wrote: > >You may want to see if you get get the GNOME xml-parser to work > >for you instead. > > Gary Van Domselaar wrote: > >To accomodate the retrieval of XML from a > >distributed environment, the XML parser needs to be CORBA compliant (It > >can >then pss the DOM over CORBA). The GNOME > >xml-parser can do this: Check out (http://xmlsoft.org/xml.html). > > This definately seems like an advantage, but I guess I don't really > understand what it means for an XML parser to be CORBA compliant. Does it > have to implement some sort of interface? Sorry, this is just my ignorance, > but how do the gnome xml parsers accomplish this? > Thanks much for any help anyone could provide on enlightening me! > Brad, Its not so much the xml parser that is CORBA compliant, so much as the gnome xmllib modules that work together to provide CORBA capability (sorry for not being clear) There is a module (the gnome-dom library) that contains the DOM IDL necessary to manipulated a DOMIFIED XML document via CORBA. To my knowledge, the python modules do not have the DOM IDL. Of course, I dont imagine it would be too huge a task to make a python DOM IDL library, using the gnome-dom library as a template. Other considerations for GNOME's xml parser are speed (compiled vs interpreted) and ability to produce a DOM tree in memory or to file (python's XML parser creates DOM trees only in RAM). Regards, g. From bizzaro at geoserve.net Mon Jan 10 16:20:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Bioinformatics Workshop Announcement References: <200001102023.OAA17253@mail.fmnh.org> Message-ID: <387A4D09.E28782F0@geoserve.net> JES wrote: > > BIOINFORMATICS: > Converting Data to Knowledge > > Date: February 16, 2000 > Location: National Academies 2101 Constitution Ave. N.W. Washington, DC Hey, I might just try to make that. That's a Wednesday, BTW :-( Anyone else going? It's very heavy on the computation and light on the biology, aint it? BTW Jennifer, did you go to PSB 2000? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From stein at fmnh.org Mon Jan 10 16:07:17 2000 From: stein at fmnh.org (JES) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] PSB 2000 summary Message-ID: <200001102105.PAA19584@mail.fmnh.org> Aloha! I'm sold... I'm going back to PSB next year. Hawaii in January is super -er, well, PSB is a great conference. They managed to get good rates for hotels - early January is not peak tourist season in Hawaii. The scheduling of sessions also allowed one lots of time to check out the local attractions. You can download (free!) copies of papers from the PSB website at http://www.cgl.ucsf.edu/psb/ I went to the Python tutorial (run by Jeffrey Chang at Stanford) where Loci was mentioned in the handout, along with Biopython, as Open Source projects using python. Jeffrey did such a good job, I walked out of there thinking "Gee, I could learn that..." For those doing phylogenetic analysis, check out http://wh.uwaterloo.ca/ Paul Kearney's undergrad presented their interactive tree-building program (InVEST). While it's not yet on their web page, this application is something to watch closely. There are calls for both Session Proposals and Tutorial Proposals for next year (also to be held on the island of Oahu). Session Proposals are due Feb 14, 2000. Short tutorial proposals are due March 13, 2000, with full proposals due June 5, 2000. I don't see the info for this on the website, but if anyone has ideas for sessions/tutorials and wants more info on requirements and responsibilities, let me know and I'll pass it along. Compaq underwrote much of the conference - Compaq and SGI provided computers for internet access (although, you can also get vacation accounts from local ISPs when one does not have access through conference machines). They had a spiffy brochure detailing the Sanger Centre's hardware (*drool*). There was a panel discussion on data mining... the general consensus is that the genetic data is only dripping through the pipeline right now... and until genetic databases become as large as United Airline's database, we cannot really complain about the complexity of our databases. On a related note, ISMB2000 (Aug 20-23, 2000, UCSD, LaJolla CA) has a couple of impending deadlines: Call for Papers - deadline is Jan 13 (changed from Jan 6, although not changed on the website); Call for tutorials - deadline for short version is Jan 15; Posters and Software demonstrations - abstracts due May 31,2000 More info at http://ismb2000.sdsc.edu Cheers, -j -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org -------------------------- From stein at fmnh.org Mon Jan 10 16:10:07 2000 From: stein at fmnh.org (JES) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Bioinformatics 2000 - Denmark Message-ID: <200001102108.PAA19752@mail.fmnh.org> So many meetings... BIOINFORMATICS 2000 Elsinore, Denmark, April 27 - 30, 2000 Bioinformatics 2000 is the second major international bioinformatics meeting in Scandinavia. It is organized jointly by Swedish, Norwegian and Danish bioinformatics groups. The aim is to provide up-to-date accounts of new developments in bioinformatics, both from a basic science, technology development, and industrial point of view. The meeting (www.cbs.dtu.dk/bioinformatics2000/) will include sessions on (all speakers confirmed): ** BIOINFORMATICS AND THE HUMANE GENOME Gene Myers - Celera Ken Fasman - AstraZeneca Pharma Perspectives Claire O'Donovan - Human Proteomic Initiative Mathias Uhlen - Royal Insitute of Technology, Stockholm ** WHOLE CELL BIOINFORMATICS Bernhard Palsson - University of San Diego Aviv Regev - Tel Aviv University Christopher Ahlberg - Spotfire Beverly J. Paigen - The Jackson Laboratory ** ALGORITHMS Willie Taylor - MRC, NIMR Sean Eddy - Washington University Pavel Pevzner - University of Southern California David Hausler - Universit? du Quebec Martin Vingron - DKFZ, Heidelberg ** STRUCTURE FUNCTION PREDICTION David Eisenberg - UCLA David Baker - University of Washington Andrej Sali - Rockefeller University, New York Tim Bailey - San Diego Super Computer Center Mark Gerstein - Yale University ** DATABASES Amos Bairoch - Swissprot Rolf Apweiler - EMBL Outstation, EBI, Cambridge Michael Ashburner - Flybase, University of Cambridge Kenneth Paigen - Mouse Genome Database, The Jackson Laboratory Eric Neuman - Netgenetics, University of Wisconsin Tim Clark - Millenium Steve Gardner - Synomics The meeting will be held at Hotel Marienlyst in Elsinore in the north-east of Denmark, a location easily accessible from Copenhagen airport. The hotel is situated next to Kronborg Castle, the home of the "virtual" Danish Prince in Shakespeare's play Hamlet (see fp.image.dk/fpeifa/kronborg.htm). For more information and registration see: www.cbs.dtu.dk/bioinformatics2000/ or contact the conference secretary Johanne Keiding: e-mail: johanne@cbs.dtu.dk, phone: +45 45 25 24 77, fax: +45 45 93 15 85 We warmly welcome you to Elsinore! Soren Brunak & Anders Krogh Center for Biological Sequence Analysis, Technical University of Denmark Gunnar von Heijne & Arne Elofsson Department of Biochemistry, Stockholm University Erik Sonnhammer & Bengt Persson Karolinska Institute, Stockholm Bo Servenius AstraZeneca R&D, Lund Inge Jonassen Department of Informatics, University of Bergen The groups colaborate in SocBiN - Society for Bioinformatics in the Nordic countries (see: www.socbin.org/) -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org -------------------------- From stein at fmnh.org Mon Jan 10 16:12:25 2000 From: stein at fmnh.org (JES) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] STOCKHOLM BIOINFORMATICS CENTER LINUX ADMIN JOB Message-ID: <200001102110.PAA19870@mail.fmnh.org> >From the ISCB mailing list... Stockholm Bioinformatics Center at KTH-SU-KI Stockholm Bioinformatics Center is the newly created Swedish center for bioinformatics and it is run by Stockholm University, the Royal Institute of technology and Karolinska Institute. It is funded by the Foundation for Strategic Research. We expect to be at least 20 scientists within a year. We are looking for a person who can be responsible for the creation of our Linux based computer administration. The position includes: Responsibility and development of our www environment. Responsibility for programs and databases Responsibility for the security Implementation of bioinformatical algorithms System administration We are looking for you who: Is familiar with Unix (Linux) administrations Enjoy programmig Would enjoy a dynamic research environment Wants to learn more about high performance computing The position is as a part of a time-limited project. We want your application at the latest: Dec 31 1999 For more information please contact: Doc Arne Elofsson (email: arne@biokemi.su.se Tel: +46-8-161553) or Prof. Gunnar von Heijne (email: gunnar@biokemi.su.se Tel: +46-8-162590) Union representatives are Bo Ekengren, SACO, Lillemor Moberg, ST/ATF, and Birgitta Carl?n, SEKO, tfn +46-8-16 20 00 (switchboard) A written application marked 55/99 should be sent to: Stockholms universitet Registrator/P? 106 91 STOCKHOLM -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org -------------------------- From stein at fmnh.org Mon Jan 10 16:14:21 2000 From: stein at fmnh.org (JES) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Faculty position - Columbia University Message-ID: <200001102112.PAA19944@mail.fmnh.org> Also from the ISCB mailing list... The Columbia Genome Center (CGC) and the Department of Medical Informatics (MI) are jointly recruiting an expert in computational genomics/bioinformatics to apply for a tenured or tenure-track faculty position (depending upon qualifications). Applicants should have a PhD, or MD/PhD, in medical informatics, computer science, or a closely related field, and minimum of 5 years further experience in the area of computational molecular biology, with significant achievements in computational biology, medical informatics, or computer science. Candidate should have outstanding academic credentials and demonstrated ability to teach effectively at the graduate level. The successful candidate will serve as Head of both the informatics section of the CGC and the bioinformatics section in MI. The candidate will be expected to build and lead a research program and faculty in computational biology that spans molecular biology, medical informatics, and computer science. The appointee will also be responsible for academic duties associated with graduate level programs. Interested applicants should send CV, a short statement of research plans, and the names of three references to: Conrad Gilliam, Columbia Genome Center, 1150 St. Nicholas Ave, College of Physicians and Surgeons at Columbia University: Email TCG1@columbia.edu; Fax: 212-404-5515. Columbia University is an Equal Opportunity/Affirmative Action Employer. -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org -------------------------- From chapmanb at arches.uga.edu Mon Jan 10 17:52:25 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] libxml questions In-Reply-To: <200001102034.NAA24834@redpoll.pharmacy.ualberta.ca> References: from "Brad Chapman" at Jan 9, 0 11:14:37 pm Message-ID: >Its not so much the xml parser that is CORBA compliant, so much as the >gnome xmllib modules that work together to provide CORBA capability (sorry >for not being clear) There is a module (the gnome-dom library) that >contains the DOM IDL necessary to manipulated a DOMIFIED XML document via >CORBA. To my knowledge, the python modules do not have the DOM IDL. >Of course, I dont imagine it would be too huge a task to make a python >DOM IDL library, using the gnome-dom library as a template. Thanks Gary--that makes a little more sense to me. I had been looking at the libxml library reference and didn't see much on anything in terms of idls. I'll take a look for the DOM idl in the gnome-dom library and see if I can find anything equivalent in the pyXML stuff. > >Other considerations for GNOME's xml parser are speed (compiled vs >interpreted) and ability to produce a DOM tree in memory or to file >(python's XML parser creates DOM trees only in RAM). > I think, however, that parsing speed will be less of a concern once we get a xml database in place, since we won't need to parse the document using the pyXML libraries unless we are loading it, saving it, or passing it. Most of the querying, etc. will, I hope, be done through the database. The question of producing DOM trees not in RAM has at least been mentioned in the pyXML documentation, so this may be something that is being worked on. However, since I am only using SAX and DOM interfaces for the parsing, etc, we shouldn't even need to change the internal code if we change from pyXML SAX/DOM parsers to gnome xmllib parsers. Hopefully, a python wrapping for gnome xmllib will have the same interfaces (otherwise, why bother with SAX and DOM!). Thanks for clearing stuff up for me! Brad From chapmanb at arches.uga.edu Mon Jan 10 18:04:10 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Resend: workflow diagram data model and databases In-Reply-To: <3878E21D.29E61DD2@geoserve.net> References: Message-ID: >I would favor parsing only the highest level (depth = 1) directory. Would >that speed things up? It seems to me that parsing depth = 3 or more would >give you much more to parse, and it would be done everytime a new directory is >opened. I changed it to only parse to directory level 1 and it does speed things up "a bit." Part of the slowdown is also due to the fact that I'm taking the effort to print things out nice, so that requires two extra walks through the dom tree, one to strip the whitespace at the beginning, and one to add the beautifying whitespace at the end. Also, I really don't think my code is very optimal for making the DOM tree from the filesystem info is very optimal. I'm still trying to think up a quicker solution. >> >> directories -> main databases >> xml files -> sub-databases within the main database >> info in xml files -> the column/row info within the sub-database > >Looks good. But we wouldn't use the fuilesystem as an intermediate, right? Right! I'm just thinking of the filesystem as a model of the database, until a database becomes available. >The Workspace/Desktop will be a 'thin-client, frontend' process that >communicates with the middleware via a high-level API. (So, about half of >your work will eventually run from separate processes, Brad.) This is something I *tried* to do in my current code. All of my xml processing code is separate from the workspace and the actual changes I made to workspace.py are very small (only a few lines of code calling the xml functions). Some of it is dependent on the Gtk interface, but I don't think that would be too difficult to change. > >For the sake of allowing other frontends to be used with Loci (for example, a >Web interface), the API will be a 'dialog' between the processes, where the >frontend requests that the middleware do something, and the middleware >responds to that request. For example: > Makes sense. So then when the user is ready to execute a workspace script, the middleware (xml) will be parsed and used to generate code for interfacing with the backendware (the programs)? Am I thinking along the right lines? Brad From chapmanb at arches.uga.edu Mon Jan 10 18:57:03 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] libxml questions In-Reply-To: <200001102034.NAA24834@redpoll.pharmacy.ualberta.ca> References: from "Brad Chapman" at Jan 9, 0 11:14:37 pm Message-ID: One more thing I just found out. The 4Thought DOM module (4DOM: http://fourthought.com/4Suite/4DOM/) implements an idl interface that appears on a quick glance to be ver similar to the gdome one, and apparently works with Fnorb and ILU. It is LGPLed, so we could use that if need be, and I assume that the PyXML DOM module may eventually implement the same sort of interface. Thanks again, Gary, for pointing out the importance of having the CORBA interface! I hadn't even thought about it previously. Brad From bizzaro at geoserve.net Mon Jan 10 23:05:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Resend: workflow diagram data model and databases References: Message-ID: <387AAC1D.8DA4668C@geoserve.net> Brad Chapman wrote: > > I changed it to only parse to directory level 1 and it does speed things up > "a bit." Part of the slowdown is also due to the fact that I'm taking the > effort to print things out nice, so that requires two extra walks through > the dom tree, one to strip the whitespace at the beginning, and one to add > the beautifying whitespace at the end. Also, I really don't think my code > is very optimal for making the DOM tree from the filesystem info is very > optimal. I'm still trying to think up a quicker solution. Right, you do print to stdout. That really does slooooooow things down. > This is something I *tried* to do in my current code. All of my xml > processing code is separate from the workspace and the actual changes I > made to workspace.py are very small (only a few lines of code calling the > xml functions). Some of it is dependent on the Gtk interface, but I don't > think that would be too difficult to change. I've got a pretty clear picture of how this dialog will work, so I'd like to take on that part of the Desktop/Workspace. You'll see what kind of 'requests' I generate, and that should help a lot with designing the middleware. > Makes sense. So then when the user is ready to execute a workspace script, > the middleware (xml) will be parsed and used to generate code for > interfacing with the backendware (the programs)? Am I thinking along the > right lines? Ummm. The data structure of the linked XML in the database is a pseudo-code that will be followed by interpreters. These interpreters will 'call up' loci according to how they are connected, execute them one-by-one, and manage the data transfer. And forks in the workpath will cause multiple interpreters to be launched. Basically, the interpreters will walk the workpath ringing bells, blowing whistles and tooting horns as they are found. (What is the name used to describe those 'mouse trap' devices, where you take the most round-about path to do the simplest thing? It's named after a person. This is how you may picture a running WFD.) This is the DYNAMIC/ACTION/VERB part of Loci. Otherwise, all you see is the STATIC/ACTIONLESS/NOUN part. 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 Mon Jan 10 23:30:34 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] Resend: workflow diagram data model and databases In-Reply-To: <387AAC1D.8DA4668C@geoserve.net> from "J.W. Bizzaro" at Jan 11, 0 04:05:49 am Message-ID: <200001110430.VAA26753@redpoll.pharmacy.ualberta.ca> > > Basically, the interpreters will walk the workpath ringing bells, blowing > whistles and tooting horns as they are found. (What is the name used to > describe those 'mouse trap' devices, where you take the most round-about path > to do the simplest thing? It's named after a person. Rube Goldberg. Maybe if we get sued for the name Loci we can change it to Rube :P .g =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at geoserve.net Tue Jan 11 19:37:53 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:06 2006 Subject: [Pipet Devel] [Fwd: Sodipodi and Loci] Message-ID: <387BCCE1.FBDC1F66@geoserve.net> This is a reply message from the Sodipodi author. My original message is at the end. Jeff -------------- next part -------------- An embedded message was scrubbed... From: Lauris Kaplinski Subject: Re: Sodipodi and Loci Date: Wed, 12 Jan 2000 00:06:47 +0200 (EET) Size: 5822 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000112/d68e5078/attachment.mht From bizzaro at geoserve.net Wed Jan 12 02:03:37 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] [Fwd: Sodipodi and Loci] Message-ID: <387C2749.EB52DE1C@geoserve.net> I'm re-forwarding this message. It's from the Sodipodi author. My original message is at the end. Jeff -------------- next part -------------- An embedded message was scrubbed... From: Lauris Kaplinski Subject: Re: Sodipodi and Loci Date: Wed, 12 Jan 2000 00:06:47 +0200 (EET) Size: 5822 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000112/3e55f854/attachment.mht From bizzaro at geoserve.net Thu Jan 13 16:00:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] workflow diagram data model and databases References: Message-ID: <387E3CE2.45B645F1@geoserve.net> Brad Chapman wrote: > > I'm quite glad you wrote about this! Very timely--I have just committed to [...] This message didn't get lost afterall :-) Some of our system problems must have held it up for a while. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Jan 13 18:43:21 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] [Fwd: Sodipodi and Loci] In-Reply-To: <387BCCE1.FBDC1F66@geoserve.net> Message-ID: Hey all! The following part of Jeff's message made me do some thinking: >> You see, Loci will use XML quite extensively. The Desktop of Loci (one >>of the >> frontends) will parse and manipulate XML descriptions of GUI widgets, >> something like what libglade does. But along with standard GUI widgets, the >> Desktop will have 'vector-graphic widgets', describe via XML and also >>able to >> be manipulated. (Loci is actually quite complex and difficult to >>explain in What is the current gameplan for attempting to implement this XML -> GUI parsing? a. Use Glade for Gtk widget generation and then use some kind of converter or something to get GUIs in other languages/graphic toolkits. b. Use Entity (http://entity.netidea.com/), which was mentioned on the list earlier (and does have python bindings) and has a more general XML format then Glade XML. We would then probably have to do some helping to get support for other GUI interfaces. c. Define our own XML and write our own parsers to generate user interfaces. Since I am starting to mess around with developing widgets and everything, this is a pretty interesting subject to me, as I rather be making them in XML. I would be really interested to hear everyone's ideas/suggestions about this subject! I also have another random idea that might be possible _instead_ of using an XML-> gui converter. We could only have two GUI interfaces--the current Gtk/Gnome one, and a Java one. If we used JPython to script the java interfaces, we could make use of these GUI interfaces. I can think of some advantages to this approach: 1. We could re-use a lot of the python/Gtk code, and would only have to re-implement the interfaces. 2. We could gain Java's portability, which would allow Loci to run just about everywhere (including web browsers). Of course, there are a number of disadvantages as well: 1. The method of Loci-sharing via interchange of XML would probably have to re-thought (although I think it would still be possible--the XML descriptions would probably be smaller/different). 2. Things we use would have to be written in either Java or python, so we'd lose a lot of useful c libraries. I was just thinking about this, so I thought I would throw it up for everyone's consideration. Thanks for listening! Brad From bizzaro at geoserve.net Thu Jan 13 22:02:25 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Source code as XML versus editing source code in structured form Message-ID: <387E91C1.12F1B730@geoserve.net> I thought this was relevant: http://www.advogato.org/article/21.html We mentioned Conglomerate before. Jeff From bizzaro at geoserve.net Thu Jan 13 23:20:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] database interfaces Message-ID: <387EA405.AFADD143@geoserve.net> Oh omniscient and omnipotent Locians, gASQL is a Gnome interface to PostgreSQL: http://malerba.linuxbox.com/ Look at the screenshots to see how 'relations' are respresented graphically. CerebellumSoft was mentioned before on this list: http://www.cerebellumsoft.com/products/index.shtml Note in particular the use of Workflow Diagrams: http://www.cerebellumsoft.com/slides/Slide9.html http://www.cerebellumsoft.com/slides/Slide10.html And Clementine, which does data-mining, was mentioned before: http://www.spss.com/clementine/ Clementine slideshow: http://www.spss.com/clementine/newshow/sld001.htm Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 14 00:02:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] [Fwd: Sodipodi and Loci] References: Message-ID: <387EADE7.E3D5EDB0@geoserve.net> Brad Chapman wrote: > > What is the current gameplan for attempting to implement this XML -> GUI > parsing? [...] > c. Define our own XML and write our own parsers to generate user interfaces. Something like this one. To start, the middleware will tell the frontend that some parameter needs to be set or that some elemental component from the library is needed. So, if a locus needs a certain parameter set, say a flag, the middleware would pass an XML object like this: The frontend would then choose the most appropriate element from its library. For example, the Workspace might choose a pulldown menu that has already been made as a composite widget. Brad, your filesystem widget (that goes in the container locus) is an example of what the Workspace can choose from its library. In this case, the middleware might send a request to select a locus/file: The Workspace would then just plop your widget into the windowlet. REMEMBER: We're talking about high level representations of GUI components here. The main reason for this: so that we can use different frontends (e.g., Web interface) with the middleware. Another reason: so that when loci are composited, the middleware doesn't have to mess around with the subtleties of Gtk+ design. On the other hand, the way for us to have non-Python GUI widgets would be to use an XML description. We could go with Glade or something else in this case, but make the _Workspace_ handle this, not the middleware. IOW, I'm proposing that we have at least one XML definition: * A very very high level request by the _middleware_ for a parameter or library component And the other is possible: * A description of the Gtk+ GUI to be read only by the _Workspace_ > Since I am starting to mess around with developing widgets and everything, > this is a pretty interesting subject to me, as I rather be making them in > XML. I would be really interested to hear everyone's ideas/suggestions > about this subject! What is now coded in Python: document.py processor.py container.py ... could be done in XML, as I wrote above. But remember, this would only be handled by the Workspace and not by the middleware. Please take a look at libglade, which comes with gnome-python and will become a big part of Gnome. This page should be helpful: http://www.baypiggies.org/10mintig.html > I also have another random idea that might be possible _instead_ of > using an XML-> gui converter. We could only have two GUI interfaces--the > current Gtk/Gnome one, and a Java one. If we used JPython to script the > java interfaces, we could make use of these GUI interfaces. I can think of > some advantages to this approach: Gasp! Are you suggesting we rewrite the Workspace in Java? :-O I think most of the great and mighty Locians would disapprove ;-) Of course, we should keep multiple development languages in mind here: Perl and Java are favs of bioinformaticists. C/C++, Tcl/Tk, FORTRAN and Pascal are considerations too. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 14 21:25:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] new directory structure Message-ID: <387FDAA9.99D6EF73@geoserve.net> Locians, Attached is an updated proposal for a new Loci directory structure. Gary and I spoke about using the UNIX standard for installing an application: everything goes in /usr/lib, /usr/bin, /etc, and /usr/doc (or replace /usr with /usr/local for some systems). But considering how Python works (a dispersed installation would mean adding a bit to the Python path) and that we won't have one big binary executable to put in /usr/bin, like traditional C/UNIX programs, I propose we use one Loci directory for all but documentation. What do you think? Brad, the module is not up yet, but I'll put it there shortly. Cheers. Jeff -------------- next part -------------- STRUCT - Filesystem structure of Loci - 20000114 loci/ AUTHORS (names of developers) CHANGES (ALL changes made to Loci) COPYING (GNU LGPL license) INSTALL (installation instructions) README (introduction) STRUCT (this file) loci* (primary Loci executable) (other python scripts) front/ (front-endware) gi/ (Gtk+ Interface) locigi.py (GI executable) (other python scripts) conf/ (GI configuration) lib/ (GI components) gtkstyles/ (Gtk+ styles) icons/ (standard icons) pixmaps/ (misc. graphics) symbols/ (symbols) widgets/ (high-level GUI widgets) nli/ (Natural Language Interface) locinli.py (NLI executable) (other python scripts) conf/ (NLI configuration) lib/ (NLI components) wi/ (Web Interface) lociwi.py (WI executable) (other python scripts) conf/ (WI configuration) lib/ (WI components) middle/ (middleware) back/ (back-endware) public/ (publicly accessible directory) lib/ (public components) icons/ (public icons) bindings/ (public bindings to files) container/ (public files and symlinks) private/ (privately accessible directory) lib/ (private components) icons/ (private icons) bindings/ (private bindings to files) container/ (private files and symlinks) conf/ (general Loci configuration) From bizzaro at geoserve.net Sat Jan 15 12:44:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Re: about db interfaces References: Message-ID: <3880B1E7.BFBEDE59@geoserve.net> (thread moved to list) Hi Brad! Brad Chapman wrote: > > One question--what is your ultimate goal for the > database interface? Are you thinking of it as just being a viewer to see > database contents, a viewer with selection options (ie. SQL quieries), or a > complete viewer, selector, data-mining system? Just curious about your > thoughts on this. Well, I was thinking that a database in its simplest form (no query interface, selector, useful viewer or data-mining system) would be represented as a container locus. The query interface, etc., would be added later via locus composition. That way, a person can choose to build his/her own database interface. So, a database container is the smallest possible wrapper for any particular database, with the ability to accept various interfaces upon locus composition. > Also, can you not destroy loci-file quite yet? I have been doing some > coding this week and *may* have a "constructing the command line" thing > working before the weekend is over. Wow, that'd be great. > I would like to be able to take a look > at it and see if it is the kind of thing you were thinking about, before I > go ahead and integrate that stuff with the new loci module. Okay, I'll hold off on the new module until you give me the go-ahead. I'm still making modifications anyway. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat Jan 15 12:57:49 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] another draft of struct Message-ID: <3880B51D.E364F026@geoserve.net> Enjoy. Comments welcome. Jeff -------------- next part -------------- STRUCT - Filesystem structure of Loci - 20000115 loci/ AUTHORS (names of developers) CHANGES (ALL changes made to Loci) COPYING (GNU LGPL license) INSTALL (installation instructions) README (introduction) STRUCT (this file) TODO (things to do) loci* (primary Loci executable) (other python scripts) front/ (front-endware) gi/ (Gtk+ Interface) locigi.py (GI executable) conf/ (GI configuration) gtkstyles/ (Gtk+ styles) lib/ (GI components) modules/ (python modules) widgets/ (high-level GUI widgets) pixmaps/ (graphics) dialogs/ (dialog icons) icons/ (generic icons) symbols/ (symbol icons) nli/ (Natural Language Interface) locinli.py (NLI executable) (other python scripts) conf/ (NLI configuration) lib/ (NLI components) modules/ (python modules) wi/ (Web Interface) lociwi.py (WI executable) (other python scripts) conf/ (WI configuration) lib/ (WI components) modules/ (python modules) middle/ (middleware) locimid.py (middleware executable) conf/ (middleware configuration) lib/ (middleware components) modules/ (python modules) back/ (back-endware) public/ (publicly accessible directory) lib/ (public components) modules/ (public python bindings to files) pixmaps/ (public graphics) icons/ (icons) container/ (public files and symlinks) private/ (privately accessible directory) lib/ (private components) modules/ (private python bindings to files) pixmaps/ (private graphics) icons/ (icons) container/ (private files and symlinks) conf/ (general Loci configuration) lib/ (general Loci library) modules/ (python modules) From bizzaro at geoserve.net Sat Jan 15 13:10:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] another draft of struct References: <3880B51D.E364F026@geoserve.net> Message-ID: <3880B814.E6742FFB@geoserve.net> "J.W. Bizzaro" wrote: > > Enjoy. Comments welcome. Jeff One question may be, "Why are we using so many different conf and lib directories? Why not just one set?" The answer is that we can have _5_ or more separate processes running under the Loci system. The primary executable is 1, and this can start any of 3 frontends plus 1 (or more) middleware process. And since these are all fairly independent processes, they need different configurations and libraries. Make sense? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Jan 15 13:27:42 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] another draft of struct In-Reply-To: <3880B51D.E364F026@geoserve.net> Message-ID: > back/ (back-endware) > public/ (publicly accessible directory) > lib/ (public components) > modules/ (public python bindings to files) > pixmaps/ (public graphics) > icons/ (icons) > container/ (public files and symlinks) > private/ (privately accessible directory) > lib/ (private components) > modules/ (private python bindings to files) > pixmaps/ (private graphics) > icons/ (icons) > container/ (private files and symlinks) Hey all. I just had a random thought on the private versus public program loci issue (sorry that it is so late into the design of the directory structure). What I was thinking is that maybe public versus private isn't specific enough for setting loci/program availability. For a bioinformatics example, you might have a database of information that hasn't been published, but that you would like to share with your collaborators. Or similary, you might have a program you are developing that isn't bug free, but you would like some of your friends who use Loci to help try out for you. Then you wouldn't want it to be publicly accessable, for fear that some evil crackers would try to crash your system using an undiscovered bug, but would like to let it be used by a restricted number of people. Okay, so I thought up a way to try and make this possible: 1. When a program is being ported to Loci, it will need to have some kind of Loci specific file describing it, like the meta-data files of Applab or the *.acd (I think--don't really know much about EMBOSS, sorry if I'm wrong!) files for EMBOSS. This file will likely be in XML like everything else and have info about the program including the widgets it wants, command line options, etc. Well, why not have an additional line that specifies something like: public In this way the loci users could set a locus to have specific availability, such as a group of collaborators on a project, ie. top_secret_HIV_project 2. When a remote user connects to another computer, they will need to authenticate themselves (through CORBA authentication stuff, I assume) with a name and password (if they are not registering as a public guest). 3. Then when a remote user asks the Loci program for a list of available programs/databases/etc. they will be passed all available loci. So if I logged in as guest, I would only see the publically available loci, while if I logged in under a user name and was put into the top_secret_HIV_project group, I would see publically available loci and the top_secret_HIV_project specific loci. So what does everyone think? Stupid idea? Good idea? Have-you-been-up-for-six-days-straight-doing-nothing-but-smoking-crack idea? Brad From chapmanb at arches.uga.edu Sun Jan 16 14:41:59 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line Message-ID: Hello, wild and wonderful Locians; I have just uploaded to the ever-expanding loci-file my first attempt at "constructing the command line." (To use Jeff's words) Basically, this is just an attempt to make UNIX style command lines within the Loci workspace. I have managed to get my idea of Jeff's vision of this working for everyone's favorite UNIX command, ls. Here is how to take a look at it: 1. Check out the just uploaded loci-file from cvs. There are some new directories added 2. Change into the top level directory and type "./testgui.py" to fire up the Loci workspace. You probably want to resize the workspace to be larger for everything that follows. 3. Right click and add a "composite" widget to the workspace 4. Double click with the left mouse button on the composite locus to open up the workspace belonging to this composite locus (the beautiful workspace within a workspace is courtesy of Jeff). 5. Right click within this new "inner" workspace and add a processor loci to it. This is kind of tricky--you have to look at the composite locus and be sure it is currently selected (has a blue box around it). Otherwise you can accidentally add the processor to the main workspace. If this happens, no big deal, just keep trying until you add a processor to the "inner" workspace. 6. Double click on the processor locus. This will open up a chooser type widget allowing you to pick a program. The programs are grouped within a tree, with the programs inside "modules" that describe the program. In this case you will see a "unixutils" folder. Click on the plus to open it up and you'll see the programs. 7. Clicking on the programs shows a little description at the bottom of the window. So far, only ls really works, so select it and press choose. 8. A new locus will pop up somewhere random within the "inner" workspace. This loci is a chooser for selecting flags to go along with ls. To check it out, double click on the "processor" locus to close its window, and center the "converter"/flag selector locus. 9. The flag selector locus has a pull down box with the flags available for the ls program. In this case, I only have a few flags set up, although it would be really easy to add more. As you scroll through the list of options, you will just barely be able to see, at the bottom of the "inner" window, a label which gives you information about each flag. Hopefully this will be more visible when I resize the windows some (I forgot to do this before I uploaded, but you can do this yourself by changing workspace_width and workspace_height in the loci-file/coregui/const.py file). Anyways, you can select through the flags and click on Add to add them. If you accidentally add one you don't want, click on it in the list below and press the remove button. 10. Once you have selected the flags, now comes the time to make things work. Close the flag selector window by double clicking on the "converter" locus. 11. Add a viewer locus by right clicking on the "inner" workspace, as you did before for the "processor" locus. 12. Connect everything up: Arrow/out from processor to input of converter, arrow/out of converter to input of viewer. Now you have your workpath: processor -> converter -> viewer 13. Right click on the composite locus holding this whole mess to pull up a little menu. Select "Construct Command Line." Yay! You just ran the ls program! 14. The viewer will pop up a text box displaying the results your list command. Very beautiful. 15. That's it! Well, if you managed to get through all of that, I hope that it managed to work out! I would really like to hear everyone's thoughts on it! I will work to add some more programs and make it possible to generate more complex command lines (with pipes and everything!), and also to make things a little prettier (ie. not so many random windows popping up all over the place!). As I said, suggestions are very welcome! I have a couple of questions about things before I go any further however: 1. What loci does everyone think should go with different widgets? Right now I have: processor = default program selector widget converter = default flag selection widget viewer = default viewer widget (okay, this one makes sense) Any ideas on whether these should be changed? Should we add differnt loci so it would make more sense? 2. (This is probably mostly to Jeff) I would like to make some changes to the Locus class and the workspace (the main WidgetMain class) to make them more object oriented so that I can make changes to them easier. Right now to manipulate things within a locus, you directly access the locus and change them (ie. locus.gui = "text_box" widget). This works okay for simple things like manipulating a locus.gui widget, but I can't use it to remove an old widget and replace it with a new one (for instance, I would like to get rid of the "program chooser" widget once a program is selected and replace it with a description of the program, but I can't do this with the current set up.) So I would like to set up the Locus class like the following class Locus: def __init__(self, etc): define all of the setup variables etc def setLocusGUI(self, widget): set the widget as GUI def getLocusGUI(self): return CurrentWidget etc.... This will make the classes fall more in lines with the OO nature of python, and will help me out with manipulating the workspace and loci. This shouldn't change the overall structure of anything, but will just change how you access stuff. How does this sound? Jeff, I don't know if this jives with your vision of where the Locus and workspace classes were going, so I wanted to get your opinion on this. I think that's it. I really look forward to hearing people's comments/suggestions. Brad From bizzaro at geoserve.net Sun Jan 16 17:48:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <38824AC6.C196C3CA@geoserve.net> Brad Chapman wrote: > > 2. Change into the top level directory and type "./testgui.py" to fire up > the Loci workspace. You probably want to resize the workspace to be larger > for everything that follows. ----------- File "./locixml/setupXML.py", line 47, in makeDir os.makedirs(os.path.join(self.makedir, self.name)) AttributeError: makedirs ----------- What version of Python are you using, Brad? Or is your os module different? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 16 18:03:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <38824E2A.4FC8E674@geoserve.net> Brad Chapman wrote: > > 5. Right click within this new "inner" workspace and add a processor loci > to it. [...] > Hopefully this > will be more visible when I resize the windows some (I forgot to do this > before I uploaded, but you can do this yourself by changing workspace_width > and workspace_height in the loci-file/coregui/const.py file). I didn't get past that attribute error, but just a note about windowlet sizes: They will be adjustable like ordinary X windows. I plan on making a routine for resizing when the windowlet borders are dragged. BTW Brad, we're gonna have to call you "The Beaver" because of how much work you've been doing. You're making me look even lazier than usual ;-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun Jan 16 23:29:25 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line In-Reply-To: <38824AC6.C196C3CA@geoserve.net> References: Message-ID: >Brad Chapman wrote: >> >> 2. Change into the top level directory and type "./testgui.py" to fire up >> the Loci workspace. You probably want to resize the workspace to be larger >> for everything that follows. > >----------- > File "./locixml/setupXML.py", line 47, in makeDir > os.makedirs(os.path.join(self.makedir, self.name)) >AttributeError: makedirs >----------- > >What version of Python are you using, Brad? Or is your os module different? I'm using the latest version (1.5.2). I took a look at the lib documentation for os.makedirs and found the following: makedirs(path[, mode ]) Recursive directory creation function. Like mkdir(), but makes all intermediate-level directories needed to contain the leaf directory. Throws an error exception if the leaf directory already exists or cannot be created. The default mode is 0777 (octal). New in version 1.5.2. So it appears as if this will require 1.5.2 to run. My setup for python is the default so hopefully the problem should only be a 1.5.2 versus older versions problem. I know there was mention of a RedHat issue with 1.5.2 versus 1.5 on the omniORBpy mailing list. I think some versions of RedHat ship with 1.5 by default, so sometimes even if people had 1.5.2 installed, 1.5 would still be in their path. If it is a problem to use 1.5.2 only stuff, let me know and I'll think of a workaround here. I like os.makedirs() over os.mkdir() because the former will put in all intermediate directories when making directories, but I can do something different. Let me know if you can't get it working, or if you get more errors. Sorry about that! >I didn't get past that attribute error, but just a note about windowlet sizes: >They will be adjustable like ordinary X windows. I plan on making a routine >for resizing when the windowlet borders are dragged. I figured this would feature would be coming around sometime, so I haven't been worrying about it too much. >BTW Brad, we're gonna have to call you "The Beaver" because of how much work >you've been doing. You're making me look even lazier than usual ;-) Hey, it's easy to be a programming monkey, but much more difficult to be thinking up the ideas/keeping things together. You should give yourself more credit, Jeff! Brad From bizzaro at geoserve.net Mon Jan 17 00:19:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <3882A657.4E139D94@geoserve.net> Brad Chapman wrote: > > I'm using the latest version (1.5.2). I took a look at the lib > documentation for os.makedirs and found the following: [...] > The default mode is 0777 (octal). New in version 1.5.2. That's the problem. I'm using 1.5.1, which is standard with RH6.0. > So it appears as if this will require 1.5.2 to run. My setup for python is > the default so hopefully the problem should only be a 1.5.2 versus older > versions problem. I know there was mention of a RedHat issue with 1.5.2 > versus 1.5 on the omniORBpy mailing list. I think some versions of RedHat > ship with 1.5 by default, so sometimes even if people had 1.5.2 installed, > 1.5 would still be in their path. Does RedHat 6.1 also come with 1.5.1? > If it is a problem to use 1.5.2 only stuff, let me know and I'll > think of a workaround here. I like os.makedirs() over os.mkdir() because > the former will put in all intermediate directories when making > directories, but I can do something different. 1.5.2 is still pretty new, so I don't know how many users will have it. Do we want to make some 95% of our users upgrade their Python installation? What's the concensus here? Who on this list wants to stick with Python 1.5.1? (I may have to send this as a separate message to get some people's attention.) I think we could have Loci check the version of Python being used and select a method accordingly. Or maybe we could hold off on os.makedirs() until 1.5.2 becomes more common. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From tim at nbci.com Mon Jan 17 01:02:24 2000 From: tim at nbci.com (Tim (not representing his employer's opinions)) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: <3882A657.4E139D94@geoserve.net> Message-ID: <3882B070.A14F74D4@nbci.com> redhat 6.1 comes with 1.5.2 and pygtk I might note From bizzaro at geoserve.net Mon Jan 17 01:29:35 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] VERY TIMELY: Ask Slashdot: XML and Transcoding Message-ID: <3882B6CF.A73A7605@geoserve.net> Gee, I'd swear someone here sent in this 'Ask Slashdot' question: http://slashdot.org/article.pl?sid=00/01/13/2330201&mode=flat Jeff From bizzaro at geoserve.net Mon Jan 17 02:52:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Re: Sodipodi and Loci References: Message-ID: <3882CA4E.8D13A122@geoserve.net> Hi Lauris! I'm sorry about the very late reply. I got a bit distracted by a script kiddie who broke into our system. It's all taken care of now. Lauris Kaplinski wrote: > > I'm very glad to hear about interest in sodipodi. Loci really seems an > interesting project and I would be glad, if I can help you in any means. > Still I have to say, that svg support in sodipodi is currently quite > limited (paths, rects, ellipses, images, texts + corresponding css > properties), but I hope it could be extended step by step using existing > framework. Well, we noticed that Sodipodi is new, since we've been looking for a GPL vector drawing program for Gnome for almost a year now. We were considering Sketch, but it doesn't do SVG. And Loci is new too, so we understand that all may not be as functional as desired. > 1. Widgets > > Currently I'm doing GUI exclusively with glade, but this should change in > future. Do you mean that you're using libglade? > The plan is to switch to GnomeMDI - and it does not do well with > glade generated application windows. Then the display object will be > separate widget (GnomeMDIView) anyway. > The sodipodi view object (desktop) actually only needs accessible > GnomeCanvas, so it should be possible to make very thin views, if needed. That's pretty much what we're looking to run in Loci: a thin, non-editing viewer of SVG-defined graphics (of course, using Gnome/Gtk+ and licensed under the GPL). Drag-and-drop from the viewer to Sodipodi would also be nice. What I didn't mention last time is that Loci is coded in Python and uses gnome-python. If we go the 'Sodipodi as a widget' route, we'll have to make Python bindings to it. > 2. Corba > > As of bonobo support, is is (of course) planned in both ways (as component > and container), but at moment I've not touched it yet. This will take some > time, as I've to familiarize myself with bonobo beforehand. If you use Bonobo, it would be desirable if we could have a thin view of Sodipodi and not the whole GUI. Loci uses little windows called 'windowlets', and this is where we would put a thin Sodipodi view. So, the simpler the better. > In addition to your two ideas, I can imagine using DOM and DOM Corba > bindings for manipulating vector objects. Sodipodi does not use DOM at > moment, as this (gdome) seemed a bit too complicated and incomplete at the > time I started. But it is designed such way that my own xml wrapper > (repr) can be replaced with DOM with minimal hazzle. If done, this should > make possible quite nice document model: > > xml + DOM <-> sodipodi core <-> Sodipodi component > in server in client Embedded in client canvas > bacbone | > | + - Low latency plugins (affine transforms) > | > +- Big latency plugins (setting color, fill etc.) > > The one reason the middle object layer (items) are designed, is to speed > up interactive modifications when DOM backbone resides across network > (during dragging only display is updated, if button is released, the xml > tree is also changed) We have been looking into similar models for Loci. XML and DOM will certainly be used. We'll likely have some uses for CORBA too. But much of how we will generate SVG graphics hasn't been worked out (some of it has been worked out - see below). > I downloaded loci-core & tried to look at it, but it hanged after > displaying big blue window and small one with progressbar. I still hope, I > can make it work if I tinker with it a bit. The snapshot you got is fairly old now, but it'll give you the right idea. Also, Loci is in the 'embryonic' stage of development, so...there's so little there that it may _look_ like it's frozen. The frozen progressbar was just a test, and the blue workspace is just empty, not frozen. Everything is popup-menu-driven in the workspace, so try clicking on the right mouse button :-) > Meanwhile I'm curious, how complex the vector 'widgets' are supposed to > be Well, it'd be nice if we could take full advantage of what SVG is capable of. > and how much interaction takes place between user and 'widgets'. Within the 'thin view' that will appear in Loci's workspace, almost no interaction should take place. A possible exception would be scaling. The idea is that the SVG graphic will be computer-generated. For example, one program (running under the Loci shell) may need to display a table of some sort. Loci would then pull an SVG description of a table out of the library and add whatever the program specified. This is why we're calling them 'graphical widgets': They're like GUI widgets in that most of the drawing has been done; all that's left is filling in some parameters. > Does > any graphical editing take place, or is the main function simply > displaying svg? In latter case it should be useful to make most editing > part of sodipodi facultative to reduce code bloat. Exactly. > As Loci uses xml, what is the internal representation of existing objects > (DOM?) Yes, we're using DOM internally. But these are things we've just started to implement (within the last few weeks). > is it exported & so on. If you're asking about object transfer in Loci, well, we've been arguing over how that could be done. XML-RPC, CORBA, Python active objects, and even HTTP have been considered. > Also, sodipodi object structure probably still changes a lot. So if you > have good idea, what component structure/level/interaction would be > usable for you, chances are that these would be usable to others too. Yeah, Loci's object structure is changing a lot too. If I could have my choice, I'd probably want a thin viewer widget that will do DnD with Sodipodi. The other developers involved in Loci (about 30 on the list, with 6 actively involved) might want something else. I'll ask. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Jan 17 07:44:07 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line In-Reply-To: <3882A657.4E139D94@geoserve.net> References: Message-ID: >That's the problem. I'm using 1.5.1, which is standard with RH6.0. Okee dokee. I just cvsed a new loci-file which doesn't use os.makedirs(), but instead 2 separate calls to os.mkdir(), which should be a pretty old lib function and available on lots of older pythons. Let me know if there is more that is 1.5.2 specific. >1.5.2 is still pretty new, so I don't know how many users will have it. Do we >want to make some 95% of our users upgrade their Python installation? What's >the concensus here? Who on this list wants to stick with Python 1.5.1? (I >may have to send this as a separate message to get some people's attention.) It is up to everyone. 1.5.2 has been around since April 99, and has been ported just about everywhere (even the Mac!) so I don't think it would be that hard for people to upgrade. But we should make it compatible with older versions of python where possible, and this is definately somewhere where is was easily possible. Hopefully it works for you now :) Brad From chapmanb at arches.uga.edu Mon Jan 17 09:04:02 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Documentation Question Message-ID: Hey all! I was just doing some thinking about the code base of Loci and how it would be pretty hard to access right now if you wanted to start programming on Loci, since you'd pretty much have to go through it all by hand and figure out what was going on. This made me start thinking about some solutions, and the one I thought of was trying to find a javadoc type tool for python; that is, a tool that would automatically extra comments from code and create HTML, etc. files from it. Well, what I came up with is, appropriately enough, pythondoc (http://starship.python.net/crew/danilo/pythondoc/). Of course, it has almost no documentation, but I looked through the examples and made up a little tester class, and got it working. Basically, it extracts the doc strings. For those who don't know (I didn't as of yesterday!), doc strings are comments under the definition of a function or class enclosed in """s, as in: def myfunction(self): """ Here is my doc string """ ...whatever the function does Anyways, it will take the doc strings and function and class names and generates either HTML4 or XML output (I have examples of this output for my little test if anyone would like to see) It can also take special stuff within the doc strings to make the output nicer. On the python DOC-SIG page (http://www.python.org/sigs/doc-sig/status.html) they give a description of the special symbols you can use. Of course, I can't test it on my current code because, like an idiot/new python programmer, I didn't use doc strings (but instead made my comments in the C++ way I learned, before the function). However, I imagine that it could be used relatively painlessly to create some HTML pages so at least people coming into Loci and wanting to program would have an easy way to get an idea of what all of the code does. Does anyone else think this would be a good idea to explore further? I know that Gary probably has ideas, and I also remember reading docbook markup mentioned on the list earlier on. It would probably be not too impossible to convert the XML generated by python doc into docbook XML, which might make it easy to put this stuff on the web pages. Anyways, I'd like to try and get this hashed out so I can do the right thing WRT documentation as I continue to code. Any comments, thoughts are very welcome! Brad From chapmanb at arches.uga.edu Mon Jan 17 09:14:03 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Documentation idea 2 Message-ID: Hello again! I also had a second documentation idea. I found in the python contrib modules (http://www.vex.net/parnassus/apyllo.py?find=interscript) a literate programming system written in python, which is something else that it might be possible to use. Literate programming involves incorporating the documentation into the code and then using an untangler to remove separate the python from the documentation. The homepage and developers list for the project seemed to have died, so I e-mailed the developer, and apparently it is still being actively worked on, although he does not have a suitable web page for hosting it. I thought that this is something else we could use to help make Gary's job easier and help to keep the documentation updated along with the code. Brad From gvd at redpoll.pharmacy.ualberta.ca Mon Jan 17 11:13:38 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Documentation Question References: Message-ID: <38833FB2.ABA2C2F1@redpoll.pharmacy.ualberta.ca> Brad Chapman wrote: > Does anyone else think this would be a good idea to explore > further? I know that Gary probably has ideas, and I also remember reading > docbook markup mentioned on the list earlier on. It would probably be not > too impossible to convert the XML generated by python doc into docbook XML, > which might make it easy to put this stuff on the web pages. Good idea, brad. I encourage everyone to use doc strings to document their code, and I dont forsee any problems with a python doc XML --> DocBook XML conversion. Who knows, someone out there may already be making an XSL for just such a purpose :-) 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 Mon Jan 17 19:57:20 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:07 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <3883BA70.F4B932DD@geoserve.net> Brad Chapman wrote: > > Okee dokee. I just cvsed a new loci-file which doesn't use os.makedirs(), > but instead 2 separate calls to os.mkdir(), which should be a pretty old > lib function and available on lots of older pythons. Let me know if there > is more that is 1.5.2 specific. Ooops: ------------------------- File "./program/programFactory.py", line 10, in ? from os.path import * ImportError: No module named path ------------------------- Okay, why don't I just upgrade to Python 1.5.2, and we'll list that as a requirement. You can go back to using os.makedirs() if you want, Brad. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From dlapointe at mediaone.net Mon Jan 17 20:45:55 2000 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line In-Reply-To: <3883BA70.F4B932DD@geoserve.net> References: <3883BA70.F4B932DD@geoserve.net> Message-ID: <00011720545301.01100@gnomen> Really! I already had Python 1.52 but had to upgrade very carefully to get PyGnome installed. Also, I was doing some python stuff this week on Linux/Mandrake/Intel and moved the program to IRIX/SGI. It broke even though both were Python 1.5.2. The linux version seemed to treat a try/finalize block differently that the IRIX version which according to the description in the book was correct (SGI). On Mon, 17 Jan 2000, J.W. Bizzaro wrote: > Brad Chapman wrote: > Okay, why don't I just upgrade to Python 1.5.2, and we'll list that as a > requirement. > > You can go back to using os.makedirs() if you want, Brad. > > Cheers. > Jeff -- .david David Lapointe Warning Dates in the calendar are closer than they appear From bizzaro at geoserve.net Mon Jan 17 21:42:40 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <3883D320.4594BBD2@geoserve.net> Okay, I got it working. Brad, YOU THE MAN! Very nice! Brad Chapman wrote: > > 3. Right click and add a "composite" widget to the workspace I was wondering why the composite locus was needed, but then I realized that you were planning on executing the composite as a whole. Of course, scripts/WFD's should be executable without first being composited. Is that what the 'execute script' option is for? Scripts/WFD's should be compositable at any point: The first step need not be to make a composite. But I know this is just the beginning and it was only a test :-) > to it. This is kind of tricky--you have to look at the composite locus and > be sure it is currently selected (has a blue box around it). Otherwise you > can accidentally add the processor to the main workspace. If this happens, > no big deal, just keep trying until you add a processor to the "inner" > workspace. I need to fix this: Clicking in a windowlet should select the locus it belongs to. > 6. Double click on the processor locus. This will open up a chooser type 'Processor', 'converter', 'viewer', etc. are only locus _class_ names. I was thinking that one processor would be the 'ls' command, another kind would be 'grep', and so on. Also, many of these can be saved _preset_ and then be pulled out of a container for use. So, you would get a list from a container of loci like so: +-------+ | | | | +-------+ [ /usr/bin ] +---------------------+ | ls | | grep | +---------------------+ In each case, the class would be 'processor', so the symbol and default icon that appears for the command would be for a processor. But the name that appears below the symbol would be the command name: 'ls', 'grep', etc. Of course, there should be a way to make new processors (or wrap programs to run under Loci), which is what you've demonstrated. But can unwrapped/non-Loci programs be wrapped automatically? How about using the container locus to select unwrapped programs: +-------+ | | | | +-------+ [ /usr/bin ] +---------------------+ | rpm | | ps | +---------------------+ which would eliminate the need for the selection tree widget you have under 'processor': The container would do the selection for you. A user could DnD a program onto the workspace, and Loci would automagically try to make a wrapper for it. But what does Loci need to know to make a wrapper? What did you have to do to make one for 'ls'? > widget allowing you to pick a program. The programs are grouped within a > tree, with the programs inside "modules" that describe the program. In this > case you will see a "unixutils" folder. Click on the plus to open it up and > you'll see the programs. Again, this works just like a container (tree widget and all), so wrapped and unwrapped processors should be selectable via container. > 7. Clicking on the programs shows a little description at the bottom of the > window. So far, only ls really works, so select it and press choose. I like this: It's like a statusbar with more room! Brad, should this be coded into the windowlet or the widget? > 8. A new locus will pop up somewhere random within the "inner" workspace. > This loci is a chooser for selecting flags to go along with ls. To check it > out, double click on the "processor" locus to close its window, and center > the "converter"/flag selector locus. Well, the locus class 'converter' was meant for data format conversion, but I get the point. Should there be an 'option' class of loci? So, there should be container listings for wrapped and unwrapped processors, plus 'options', and so on. > 9. The flag selector locus has a pull down box with the flags available for > the ls program. In this case, I only have a few flags set up, although it I was thinking that we would have one 'option locus' per flag. You have it so that you could set multiple flags, which may be more convenient but sort of bypasses the simple building block plan I had. I was thinking that _multiple_ flags (and other options) meant connecting _multiple_ option loci togther. > Anyways, you > can select through the flags and click on Add to add them. If you > accidentally add one you don't want, click on it in the list below and > press the remove button. You see, 'add' and 'remove' are exactly what the _Workspace_ lets you do. So, why not use the Workspace? We want to be sure we're reinventing the wheel: Make _everything_ work "The Loci Way" (take elemental loci, set parameters, and then plug them together to make composite loci). We can add and remove flags if they are separate loci on the Workspace. > 12. Connect everything up: Arrow/out from processor to input of converter, I wasn't sure which out arrow to use from the processor. If we have multiple arrows with different mime types, it should matter. I need to work on this: make connector windowlets and all. > 13. Right click on the composite locus holding this whole mess to pull up a > little menu. Select "Construct Command Line." Yay! You just ran the ls > program! Or maybe 'Run Command Line' :-) 'Construction' was already done by the user ;-) > 14. The viewer will pop up a text box displaying the results your list > command. Very beautiful. The viewer is very nice indeed, exactly what I was thinking of. > Well, if you managed to get through all of that, I hope that it managed to > work out! I would really like to hear everyone's thoughts on it! I will > work to add some more programs and make it possible to generate more > complex command lines (with pipes and everything!), and also to make things > a little prettier (ie. not so many random windows popping up all over the > place!). As I said, suggestions are very welcome! You asked for suggestions, well you got them :-) One other thing: About random windows popping up: It should be up to the user to select what goes next. I know ls has certain options, and it is obvious to you that the user needs to select one. But I think we should allow more flexibility for the user, and give ourselves less work. The ls processor does not need to know there are options to be set: It only handles outputting the string 'ls' to the command line. And the flag option locus does not need to know what flags are legal for ls. All flags should be choosable since this flag option locus is a _generic_ locus (it can be used with commands other than ls). Maybe to narrow the list of flags down, we could have a filter attached that can catch illegal flags. (continued) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jan 17 21:58:11 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <3883D6C3.826C8F01@geoserve.net> (continuation) Brad Chapman wrote: > > I have a couple of questions about things before I go any further > however: > > 1. What loci does everyone think should go with different widgets? Right > now I have: > > processor = default program selector widget > converter = default flag selection widget > viewer = default viewer widget (okay, this one makes sense) > > Any ideas on whether these should be changed? Should we add differnt loci > so it would make more sense? Again, these are meant to be classes, not names. The names that appear under symbols should those of the commands. And an 'option' locus should be made, instead of using 'converter'. I should have a variable for setting the locus name, which can be different from the class. > 2. (This is probably mostly to Jeff) I would like to make some changes to > the Locus class and the workspace (the main WidgetMain class) to make them > more object oriented so that I can make changes to them easier. > Right now to manipulate things within a locus, you directly access > the locus and change them (ie. locus.gui = "text_box" widget). This works > okay for simple things like manipulating a locus.gui widget, but I can't > use it to remove an old widget and replace it with a new one (for instance, > I would like to get rid of the "program chooser" widget once a program is > selected and replace it with a description of the program, but I can't do > this with the current set up.) So I would like to set up the Locus class > like the following > > class Locus: > > def __init__(self, etc): > define all of the setup variables etc > def setLocusGUI(self, widget): > set the widget as GUI > def getLocusGUI(self): > return CurrentWidget > > etc.... > > This will make the classes fall more in lines with the OO nature of python, > and will help me out with manipulating the workspace and loci. This > shouldn't change the overall structure of anything, but will just change > how you access stuff. > How does this sound? Jeff, I don't know if this jives with your > vision of where the Locus and workspace classes were going, so I wanted to > get your opinion on this. You're right, that is more OO than my code, which was kind of hack to begin with. It certainly would be the next step in windowlet development to make those the changes. Be my guest :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jan 17 21:59:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: <3883BA70.F4B932DD@geoserve.net> <00011720545301.01100@gnomen> Message-ID: <3883D71B.76B2A5F6@geoserve.net> David Lapointe wrote: > > Really! I already had Python 1.52 but had to upgrade very > carefully to get PyGnome installed. > > Also, I was doing some python stuff this week on Linux/Mandrake/Intel > and moved the program to IRIX/SGI. It broke even though both were > Python 1.5.2. The linux version seemed to treat a try/finalize block > differently that the IRIX version which according to the description > in the book was correct (SGI). Are you saying we shouldn't use Python 1.5.2? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Tue Jan 18 00:35:46 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <3883FBB2.12762E06@redpoll.pharmacy.ualberta.ca> Brad Chapman wrote: After installing the python XML package, I had no problems running the demo. Absolutively fantabulous, Brad, you're a superstar! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: loci_ls.gif Type: image/gif Size: 35449 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000117/ee677e8f/loci_ls.gif From bizzaro at geoserve.net Tue Jan 18 01:14:30 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: <3883D320.4594BBD2@geoserve.net> Message-ID: <388404C6.C21D690F@geoserve.net> "J.W. Bizzaro" wrote: > > Make _everything_ work "The Loci Way" (take elemental loci, set parameters, > and then plug them together to make composite loci). I can't stress this enough: Whenever anyone comes up with an interface to run in a windowlet, or the wrapper for a locus, BREAK IT UP INTO THE SMALLEST PIECES POSSIBLE: These pieces are the elemental loci; these will be combined by connecting connectors and forming a composite locus. And if the elemental loci do not exist, we need to make them and add them to the library. I was thinking about the statusbar description Brad made for "ls". How can you make this "The Loci Way"? Well, lets have a locus for setting statusbar descriptions. I imagine the Workspace GUI would be a simple text entry box: +---------------------------+ | | | Description: | | +-------------------+ | | | | | | | | | | | | | | +-------------------+ | | | +---------------------------+ Typing in some text, connecting the connector to another locus, and making a composite, causes this description to be added to the other locus, which would appear in the statusbar. The XML could be something like this: ls is a program for listing the contents of a directory. I imagine descriptions could be added to any number of widgets, and they'd appear in the statusbar whenever the widget is in focus. REMEMBER THE LOCI WAY: (1) Break a new feature up into the smallest possible elements. (2) Any new elements that need to be made are added to the library. (3) Connect the elements using the appropriate heirarchy. (4) Set any parameters that you need or want to. (5) Transform the connected elements into a composite. 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 Tue Jan 18 02:28:48 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] GNOME programming guidelines Message-ID: <38841630.DA56223@redpoll.pharmacy.ualberta.ca> Locians, I stumbled upon this when cruising through the GNOME developer documentation: http://developer.gnome.org/doc/guides/programming-guidelines/ Although it is written with GNOME programming in mind, it contains a lot of useful advice for any free-software programmer, and is probably worth a look. Regards, g. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 dlapointe at mediaone.net Tue Jan 18 06:41:29 2000 From: dlapointe at mediaone.net (David Lapointe) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line In-Reply-To: <3883D71B.76B2A5F6@geoserve.net> References: <00011720545301.01100@gnomen> <3883D71B.76B2A5F6@geoserve.net> Message-ID: <00011806445800.00534@gnomen> On Mon, 17 Jan 2000, J.W. Bizzaro wrote: > David Lapointe wrote: > > > > Really! I already had Python 1.52 but had to upgrade very > > carefully to get PyGnome installed. > > > > Also, I was doing some python stuff this week on Linux/Mandrake/Intel > > and moved the program to IRIX/SGI. It broke even though both were > > Python 1.5.2. The linux version seemed to treat a try/finalize block > > differently that the IRIX version which according to the description > > in the book was correct (SGI). > > Are you saying we shouldn't use Python 1.5.2? No, I am just talking about assumptions. Also cross platform testing ( probably premature at this point, but...). > > Jeff -- .david David Lapointe "First things first," mandates sci-fi icon Doctor Who, "but not necessarily in that order." From chapmanb at arches.uga.edu Tue Jan 18 07:23:05 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line In-Reply-To: <3883D320.4594BBD2@geoserve.net> References: Message-ID: >Ooops: > >------------------------- > File "./program/programFactory.py", line 10, in ? > from os.path import * >ImportError: No module named path >------------------------- > >Okay, why don't I just upgrade to Python 1.5.2, and we'll list that as a >requirement. Egads! I can't believe I used so many 1.5.2 specific commands. This is really weird, though, because according to the lib docs os.path has supposedly been around for a while, and shouldn't be 1.5.2 specific. I don't understand this error at all! But I guess it got fixed by upgrading to 1.5.2... Maybe we should think about "tester" machines for Loci, especially in light of what David was mentioning about differences between how things run on Linux vs. IRIX. It would be nice to have at least "simple to fix" bugs ironed out before random people start downloading Loci and getting cheesed about a million bugs, especially since we have so many testers available on the mailing list! I think once we get the new loci module set up it will make it easier for people to stay updated and test new features on their machines. But I think the quicker we can catch problems, the easier the will be to fix. This is especially true for inexperienced programmers like me, since I don't really know what kind of errors to expect and avoid. >I was wondering why the composite locus was needed, but then I realized that >you were planning on executing the composite as a whole. > >Of course, scripts/WFD's should be executable without first being composited. >Is that what the 'execute script' option is for? > >Scripts/WFD's should be compositable at any point: The first step need not be >to make a composite. > >But I know this is just the beginning and it was only a test :-) Righto! I really don't think it should be necessary to have to do everything inside a separate composite, especially since you might want to execute/construct the command line for the main workspace! I think, ideally, that there should be an option inside the pop-up menu bar (labelled something like "Action") and then sub-menus within this labelled "Execute" and "Construct" or whatever. What do you think about this? >Or maybe 'Run Command Line' :-) 'Construction' was already done by the user Well, what I was thinking is to have two options. A "Construction" type option and an "execute" type option. Actually, what I had working in loci-file was more of the "execute" option (oops! I guess I used the wrong selection!). Basically, my idea was this: 1. Construction: This will take the workspace and clean it up by condensing all of the loci on a command line (ie. the program ls loci and the flag option loci in this case) into a single loci showing the command to be executed. I couldn't do this yet because I don't have enough access to loci and their windows to change GUIs and delete loci. So in the little "ls" example, after construction you would be left with two loci, one labelled "ls" showing the entire command line selected, and the viewer loci 2. Execute: This will be the actual execution of the workspace. This is more of what I was demonstrating in the example--actually running the program and seeing the output in the viewer locus. >I need to fix this: Clicking in a windowlet should select the locus it belongs >to. Yeah, I don't really understand why the widgets don't hold the focus very well. Even with a container locus, if you click a bit with the right mouse button you can get the pop-up menu to show up, resulting in a loss of focus on the container widget. I was trying to think of a solution for this. Maybe if when a windowlet is open, all clicks within the region of the windowlet are ignored by the main window holding the windowlet. This might get rid of the competition between the main window and the windowlet for clicks. >'Processor', 'converter', 'viewer', etc. are only locus _class_ names. I was >thinking that one processor would be the 'ls' command, another kind would be >'grep', and so on. >One other thing: About random windows popping up: It should be up to the user >to select what goes next. I know ls has certain options, and it is obvious to >you that the user needs to select one. But I think we should allow more >flexibility for the user, and give ourselves less work. Right! Again, renaming seemed like something that was pretty difficult to do under the current Locus/Workspace class structure. My ultimate vision for how things would work is this: When a user chooses a program from the processor list of choices, say ls, the processor loci will "morph" into an 'ls' loci. My idea for how this would look is that it will be labelled 'ls' under the name, and the GUI/widget for the locus will consist of a description of the program and how it is used, along with buttons to press to set flags, etc. So then if the user would like to set ls flags, the would hit a "set flags" button or something and the new loci would pop up for them with all of the possible flags for ls (much as it pops up automagically in the little test thing). That is the first thing I'll work on to improve. >Also, many of these can be saved _preset_ and then be pulled out of a >container for use. So, you would get a list from a container of loci like so: [...snip of pretty picture...] This is a really good idea! It would be quite nice to save either frequently used programs, or frequently used "command lines" in a container locus that you could call up. This could kind of be like a history you could set yourself. I like it very much! >Of course, there should be a way to make new processors (or wrap programs to >run under Loci), which is what you've demonstrated. But can >unwrapped/non-Loci programs be wrapped automatically? How about using the >container locus to select unwrapped programs:> >which would eliminate the need for the selection tree widget you have under >'processor': The container would do the selection for you. A user could DnD a >program onto the workspace, and Loci would automagically try to make a wrapper >for it. But what does Loci need to know to make a wrapper? What did you have >to do to make one for 'ls'? That would be *very* nice, but I think it will take a lot of thinking to get this working. Okay, here is what I did to get ls working: 1. I grabbed the man page for ls and XMLified part of it for the example (You can take a look at the ls.xml file in 'loci-file/infofiles/unixutils/ls.xml'). 2. I added to the xml file some things, like a request for a "flag_select" widget, to display the possible flags for ls. That's it. This should work for any program which runs from the command line *and* all the info you want to get back from it is what it would normally spit out to standard out. So, to wrap things automatically we would need: 1. A way to get the man page for a particular command (we could probably just "man command" to get this). 2. Find/write a program which will convert man pages to xml. 3. Write a program to add the correct "loci specific" markup to the xml page. Of course, this won't work if you want to do something more complicated. For instance, lets say you were on a mission to get rid of all .rpm'ed files in the whole world. Then you might want a workpath that un-rpm's files and then sends the directories to tar/gzip to zip up. This wouldn't be easy to do with the simple wrapping that I used for ls. >> 7. Clicking on the programs shows a little description at the bottom of the >> window. So far, only ls really works, so select it and press choose. >I like this: It's like a statusbar with more room! Brad, should this be coded >into the windowlet or the widget? I think it should stick with the widget because not all widgets will want an "info" bar (like a viewer for instance). Then if widgets don't need them, they will have to go through the extra step of removing the "info" bar from the windowlet. >I was thinking that we would have one 'option locus' per flag. You have it so >that you could set multiple flags, which may be more convenient but sort of >bypasses the simple building block plan I had. I was thinking that _multiple_ >flags (and other options) meant connecting _multiple_ option loci togther. > >The ls processor does not need to know there are options to be set: It only >handles outputting the string 'ls' to the command line. > >And the flag option locus does not need to know what flags are legal for ls. >All flags should be choosable since this flag option locus is a _generic_ >locus (it can be used with commands other than ls). Maybe to narrow the list >of flags down, we could have a filter attached that can catch illegal flags. Okay, these were two things I started off doing, but then changed my mind during coding. Let me give my thoughts: 1. On the one loci per flag idea. I started off with just this, but think about how messy the workspace would get if you wanted to run a command like: 'pythondoc -i -f XML -d ./doc ./mypythonfile.py' This would require 3 loci for option flags plus the one for the program, plus the one of the file to choose. Now, right now I have my computer set up with an old Matrox 100 series graphics card and a crappy Compaq monitor I got for free from my friend who was throwing it away. With my screen resolution, 5 loci would barely fit in the screen, much less leave room for selecting options/connecting them to other loci. In addition, I was thinking that getting a command out should be as fast as possible so that it is a viable alternative to actually just typing things in on the command line. I think that the multiple flags in one locus makes it much quicker then opening up multiple loci. 2. For the "program specific" flags versus "generic/all flags" issue. My thought here was that Loci is supposed to be a way to hide the UNIX command line from the user, or at the very least make the command line easier to use. If you already know what all of the flags for ls are, and what they do, why not just type in your ls -l command on the command line. However, I thought that the info boxes, and the choices of possible flags, makes it a bit easier to learn what flags do what, and to avoid making mistakes. I think this is also a way to make the information that is already available for a program (ie, the man pages) more easily read and explored, even for experienced programmers/UNIX users. How many times have you read questions on newsgroups where the reply is "look at the man page?" I doubt if very many people have all of the millions of options for all of the UNIX programs memorized. In addition, I think it is pretty impossible to generate a list of all possible flags for all programs. For instance, omniORB had command line options like the following: '-BOAiiop name port' Should a user have to look through all kinds of crazy options like this just to find their -l option for a list. >Well, the locus class 'converter' was meant for data format conversion, but I >get the point. Should there be an 'option' class of loci? That's a great name! (I hadn't been able to come up with one--I must have some kind of mental issue or something!). I know 'converter' was inappropriate, but I couldn't really pick a good option. >I wasn't sure which out arrow to use from the processor. If we have multiple >arrows with different mime types, it should matter. I need to work on this: >make connector windowlets and all. Okay, two really stupid questions: 1. How does a mime type relate to the arrows? (I said the questions were really stupid!) 2. Why should the different connections matter, especially for constructing a UNIX command line? I thought we were just Rube Goldberging it and stepping through the workpath, running programs and passing the data on to the next program (if applicable). Does it really matter then which arrow the data goes down? (Cleary, I need some hand holding in explaining your ideas here!) >You're right, that is more OO than my code, which was kind of hack to begin >with. It certainly would be the next step in windowlet development to make >those the changes. Be my guest :-) Thanks much. That will be a big help and will likely get things running a lot prettier. I certainly wouldn't call the current code a hack though, I've been very impressed with how thought out the code is, especially in regards to the windowlets/internal widgets. This is in contrast to my coding, when I often have difficulty forseeing the very next class! >REMEMBER THE LOCI WAY: > > (1) Break a new feature up into the smallest possible elements. > (2) Any new elements that need to be made are added to the library. > (3) Connect the elements using the appropriate heirarchy. > (4) Set any parameters that you need or want to. > (5) Transform the connected elements into a composite. Okay, I haven't been sleeping much, but this whole thing just blew my mind. It will take a bit of time for this "student of the Loci" to digest this new teaching... Thanks much for everyone's comments, etc! Brad From chapmanb at arches.uga.edu Tue Jan 18 07:46:56 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:08 2006 Subject: [Pipet Devel] Good news on the XDBM front Message-ID: Hey all; I've been listening in on the FreeDOM/XDBM lists (our potential XML database/interface) and just wanted to keep you up to date with what is going on there: 1. There are 3 people (including myself, humbly representing Loci) interested in python bindings to XDBM. 2. Talk is just starting up for developing these, so hopefully, they should be on the way before any other language bindings. Yay! 3. The next version of XDBM will be dual-liscened under the GPL, so it looks like it will be no problem to use it with Loci. Double yay! There is also talk of making the FreeDOM bindings themselves LGPL, so I think in general we should have no liscensing problems with FreeDOM/XDBM. That is all the FreeDOM/XDBM news that's fit to print. Brad From gvd at redpoll.pharmacy.ualberta.ca Tue Jan 18 10:50:13 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Good news on the XDBM front References: Message-ID: <38848BB5.218057B2@redpoll.pharmacy.ualberta.ca> Brad Chapman wrote: > > Hey all; > I've been listening in on the FreeDOM/XDBM lists (our potential XML > database/interface) and just wanted to keep you up to date with what is > going on there: > > 1. There are 3 people (including myself, humbly representing Loci) > interested in python bindings to XDBM. > > 2. Talk is just starting up for developing these, so hopefully, they should > be on the way before any other language bindings. Yay! > > 3. The next version of XDBM will be dual-liscened under the GPL, so it > looks like it will be no problem to use it with Loci. Double yay! There is > also talk of making the FreeDOM bindings themselves LGPL, so I think in > general we should have no liscensing problems with FreeDOM/XDBM. Yaaay!!! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Jan 18 10:58:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Attempt at Constructing the Command Line References: Message-ID: <38848D8F.D7A7163F@geoserve.net> Brad Chapman wrote: > > Maybe we should think about "tester" machines for Loci, especially > in light of what David was mentioning about differences between how things > run on Linux vs. IRIX. It would be nice to have at least "simple to fix" > bugs ironed out before random people start downloading Loci and getting > cheesed about a million bugs, especially since we have so many testers > available on the mailing list! Maybe we can just keep track of who uses what. Let's see... IRIX 6.? David Lapointe FreeBSD x86 ?.? Brad Chapman RedHat x86 6.0 Jeff Bizzaro ... That way, we can say 'Loci has been tested to run on the following systems.' > Righto! I really don't think it should be necessary to have to do > everything inside a separate composite, especially since you might want to > execute/construct the command line for the main workspace! I think, > ideally, that there should be an option inside the pop-up menu bar > (labelled something like "Action") and then sub-menus within this labelled > "Execute" and "Construct" or whatever. What do you think about this? Right, and the Action will depend on what is selected: partial or whole workpath. (I'm going to continue this conversation in another e-mail, because I want to hammer on one point.) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Jan 19 00:29:57 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] composited GUI's revisted, part 1 References: Message-ID: <38854BD5.6860B323@geoserve.net> (continuation) Brad Chapman wrote: > > 1. Construction: This will take the workspace and clean it up by condensing > all of the loci on a command line (ie. the program ls loci and the flag > option loci in this case) into a single loci showing the command to be > executed. I couldn't do this yet because I don't have enough access to loci > and their windows to change GUIs and delete loci. So in the little "ls" > example, after construction you would be left with two loci, one labelled > "ls" showing the entire command line selected, and the viewer loci But why 2 loci? Composition should give you _one_ locus: the composite locus, which can switch its GUI between a workspace view and a composited Gtk+ GUI view. In the example you made, a composited Gtk+ GUI should appear in the composite's windowlet. Switching (via pull-down menu?) views shows the workspace. > 1. On the one loci per flag idea. I started off with just this, but think > about how messy the workspace would get if you wanted to run a command like: > > 'pythondoc -i -f XML -d ./doc ./mypythonfile.py' > > This would require 3 loci for option flags plus the one for the program, > plus the one of the file to choose. Now, right now I have my computer set > up with an old Matrox 100 series graphics card and a crappy Compaq monitor > I got for free from my friend who was throwing it away. With my screen > resolution, 5 loci would barely fit in the screen, much less leave room for > selecting options/connecting them to other loci. > In addition, I was thinking that getting a command out should be as > fast as possible so that it is a viable alternative to actually just typing > things in on the command line. I think that the multiple flags in one locus > makes it much quicker then opening up multiple loci. Okay, but there are 2 features you're not considering here: (1) LOCUSES/LOCI CAN BE COMPOSITED, LEAVING _ONE_ LOCUS THAT REPRESENTS MANY LOCI. (2) A COMPOSITE LOCUS CAN BE STORED AS A COMPOSITE LOCUS, MEANING THE USER WILL NEVER HAVE TO DEAL WITH THE LOCI THAT MAKE UP THE COMPOSITE LOCUS. So, yes... 'pythondoc -i -f XML -d ./doc ./mypythonfile.py' would be 7 loci, but once they are composited and stored, this line will ALWAYS be _one_ locus. And (recall 'constructing the command-line), if you leave one option unset... 'pythondoc -i XML -d ./doc ./mypythonfile.py' You have _one_ composite (made up of 6 set loci and 1 unset locus) with _one_ option to set: . ONLY THE USER WHO MADE THE COMPOSITE HAD TO WORRY ABOUT HOW MANY LOCI IT WOULD TAKE. FROM THEN ON, IT IS _ONE_ LOCUS. > 2. For the "program specific" flags versus "generic/all flags" issue. My > thought here was that Loci is supposed to be a way to hide the UNIX command > line from the user, or at the very least make the command line easier to > use. If you already know what all of the flags for ls are, and what they > do, why not just type in your ls -l command on the command line. Yes, IF YOU COULD NOT STORE COMPOSITES, you would have to rebuild ls -l each time, which would be more work than it is worth. BUT WE CAN STORE COMPOSITES!!! :-D SO, THEN ls -l IS ONE BUTTON CLICK!!! :-D > However, I > thought that the info boxes, and the choices of possible flags, makes it a > bit easier to learn what flags do what, and to avoid making mistakes. I really like the idea of info boxes. Loci may be incredibly flexible and powerful, but we want it to be intuitive and simple to learn. There should be a very simple motif to all of this: Take small components, connect the dots, and make bigger components (sort of like UNIX). > I think this is also a way to make the information that is already > available for a program (ie, the man pages) more easily read and explored, > even for experienced programmers/UNIX users. How many times have you read > questions on newsgroups where the reply is "look at the man page?" I doubt > if very many people have all of the millions of options for all of the UNIX > programs memorized. I'm very impressed by how you could get that information from a man page. "The Loci Way" still does not prevent us from using this innovation. > In addition, I think it is pretty impossible to generate a list of > all possible flags for all programs. For instance, omniORB had command line > options like the following: '-BOAiiop name port' Should a user have to look > through all kinds of crazy options like this just to find their -l option > for a list. I think if we have a 'flag locus' that has one flag per locus, the user/developer can set the flag names and the number of flags to choose from. Sure, you might end up with 10-20 loci, BUT THEY CAN BE COMPOSITED AND STORED!!! FUTURE USERS WILL ONLY SEE _ONE_ SIMPLE INTERFACE!!! :-D > >REMEMBER THE LOCI WAY: > > > > (1) Break a new feature up into the smallest possible elements. > > (2) Any new elements that need to be made are added to the library. > > (3) Connect the elements using the appropriate heirarchy. > > (4) Set any parameters that you need or want to. > > (5) Transform the connected elements into a composite. > > Okay, I haven't been sleeping much, but this whole thing just blew my mind. > It will take a bit of time for this "student of the Loci" to digest this > new teaching... Ahh, Young Grasshopper, you will soon know the ways of The Loci. You must keep in mind the 2 points I mentioned before: (1) LOCUSES/LOCI CAN BE COMPOSITED, LEAVING _ONE_ LOCUS THAT REPRESENTS MANY LOCI. (2) A COMPOSITE LOCUS CAN BE STORED AS A COMPOSITE LOCUS, MEANING THE USER WILL NEVER HAVE TO DEAL WITH THE LOCI THAT MAKE UP THE COMPOSITE LOCUS. (Part 2: How to make a composited GUI) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Jan 19 00:39:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Good news on the XDBM front References: <38848BB5.218057B2@redpoll.pharmacy.ualberta.ca> Message-ID: <38854E27.50BF0D3@geoserve.net> Gary Van Domselaar wrote: > > > 2. Talk is just starting up for developing these, so hopefully, they should > > be on the way before any other language bindings. Yay! > > > > 3. The next version of XDBM will be dual-liscened under the GPL, so it > > looks like it will be no problem to use it with Loci. Double yay! There is > > also talk of making the FreeDOM bindings themselves LGPL, so I think in > > general we should have no liscensing problems with FreeDOM/XDBM. > > Yaaay!!! Yaaaaaaaaaaaaaaaaaaaaaaaay!!!!!! Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Jan 21 01:45:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] It's the User, Stupid Message-ID: <38880082.89B6EB64@geoserve.net> Here's another "you're not innovative" article: http://sendmail.net/?feed=interviewkuniavsky The funny thing is that it appears at the Sendmail Web site. Jeff From bizzaro at geoserve.net Sun Jan 23 07:07:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] new loci module is on cvs Message-ID: <388AEEFA.6F4FA7FB@geoserve.net> Greetings Locians, I put the code from loci-file into a new module called 'loci'. The organization of the loci module is drastically different from that of loci-file, using the directory structure I posted earlier. Please give it a gander. And note that the modules loci-file and loci-core are officially DEAD: All future work will take place in the module loci. (This does not apply to loci-doc.) BTW, I fixed _everything_ that broke from the reorganization. It should work just like loci-file. To find out where things have moved to, look at the file STRUCT in the root directory. To make finding things easier, I put the old loci-file directory structure below the new one. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun Jan 23 12:36:38 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] new loci module is on cvs In-Reply-To: <388AEEFA.6F4FA7FB@geoserve.net> Message-ID: >I put the code from loci-file into a new module called 'loci'. The >organization of the loci module is drastically different from that of >loci-file, using the directory structure I posted earlier. Please give it a >gander. And note that the modules loci-file and loci-core are officially >DEAD: All future work will take place in the module loci. (This does not >apply to loci-doc.) Cool beans! Thanks Jeff! >BTW, I fixed _everything_ that broke from the reorganization. Wow! A *lot* of work! >It should work >just like loci-file. To find out where things have moved to, look at the file >STRUCT in the root directory. To make finding things easier, I put the old >loci-file directory structure below the new one. Looks great from a first glance. I've been working on my local copy a bit and making some changes so I'll integrate the changes into the new loci module and hopefully have that committed sometime tonight. Hey, can I ask a personal favor? Can we not cvs *.pyc files? I just hate them for no good reason, and we might as well not store them in cvs since they don't really have any new information over the actual code files. Thanks again for taking care of that, Jeff. I'm looking forward to working in the brand new module! Brad From webmaster at bioinformatics.org Sun Jan 23 15:20:46 2000 From: webmaster at bioinformatics.org (webmaster@bioinformatics.org) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] new loci module is on cvs Message-ID: <200001232020.PAA04270@bioinformatics.org> (For some reason my geoserve mail has been acting up.) Brad Chapman wrote: > > Hey, can I ask a personal favor? Can we not cvs *.pyc files? I just > hate them for no good reason, and we might as well not store them in cvs > since they don't really have any new information over the actual code files. I had forgotten to delete them before importing the code. I later thought about removing them but then recalled that you kept .pyc files in loci-file at one time. I'll take them out. > Thanks again for taking care of that, Jeff. I'm looking forward to > working in the brand new module! Let me know if you have trouble finding anything. Again, STRUCT should show you where everything moved to. (Let's try to keep STRUCT up-to-date too.) Also, we will all (whoever works on this module) be sharing the CHANGES (Changelog) file (organized by date and developer) and TODO (I put 'DEVELOPERS NOTES' on the bottom; yours is there now). Take a look at what I did. And one more thing: INSTALL (installation instructions, including dependencies) needs to be updated :-) Cheers. Jeff From bizzaro at geoserve.net Sun Jan 23 21:37:57 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] [Fwd: [pygtk] Python Gnome Skeleton program] Message-ID: <388BBB05.252F9714@geoserve.net> This is worth a look since we're considering using libglade in the _workspace_ (again, not for middle-to-front communication but for the workspace's own use): -------------- next part -------------- An embedded message was scrubbed... From: Baruch Even Subject: [pygtk] Python Gnome Skeleton program Date: Mon, 24 Jan 2000 07:25:28 +0800 (WST) Size: 1685 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000124/8536a396/attachment.mht From chapmanb at arches.uga.edu Mon Jan 24 08:23:53 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] new loci module is on cvs In-Reply-To: <200001232020.PAA04270@bioinformatics.org> Message-ID: >I had forgotten to delete them before importing the code. I later thought >about removing them but then recalled that you kept .pyc files in >loci-file at one time. I'll take them out. Cool! Thanks. Yeah, I had them in loci-file beacause I had some crazy idea that they were useful, but then I started getting annoyed with them and ended up taking them out. >Let me know if you have trouble finding anything. Again, STRUCT should >show you where everything moved to. (Let's try to keep STRUCT up-to-date >too.) I like STRUCT--very useful, and I'll definately keep it up to date. I was playing around with stuff last night and I'm getting used to the structure--no problemo. >Also, we will all (whoever works on this module) be sharing the CHANGES >(Changelog) file (organized by date and developer) and TODO (I put >'DEVELOPERS NOTES' on the bottom; yours is there now). Take a look at >what I did. Gotcha--everything looks good. Also, we all (whoever is working on this module :) will need to start keeping each other informed of changes we plan to make so that we don't overlap. This is what I've tried to do with my TODO list. >And one more thing: INSTALL (installation instructions, including >dependencies) needs to be updated :-) I updated it to at least reflect what we currently need. As people test it out more we can update it with more information to help solve installation problems/quirks. I just committed a whole ton of changes (it's all detailed in the change log). Everything has now been commented with doc strings, and I'm working on getting a method to have pythondoc generate some nice HTML pages for it, so then we will have documentation on the code. Yay! Currently to use pythondoc we'd have to individually run it on each module, and then re-do this everytime we update stuff. I've talked to the pythondoc author, and he said he would work on a way to have a listing of all the modules that could be fed into pythondoc for processing, so hopefully this little roadblock will be overcome. I made a lot of structural changes, so please let me know if something is broken or anything. Brad From stein at fmnh.org Mon Jan 24 15:11:19 2000 From: stein at fmnh.org (JES) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] MUST: Management Utilities for Sequences and Trees Message-ID: <200001242010.OAA30077@mail.fmnh.org> I just stumbled across this program: MUST, Management Utilities for Sequences and Trees. Information can be found in the article: H. Phillippe. 1993. Must, a computer package of Management Utilities for Sequences and Trees. Nucleic Acids Research. 21(22): 5264-5272. Sadly, no URL/ftp info is given. Distribution is either by acquiring a copy of the s/w from somebody who already has it, or by sending $100 to the author for a set of diskettes. Given the date, this does not surprise me, but I cannot find information on new versions. It was written in MS C 5.1, for Dos 3.x and higher (*shudder*). A unix version was in the design process at the time of publication. Regardless, the flowchart portraying data management in the document might provide some food for thought. Briefly, this is a phylogenetically oriented set of programs for data management and display, intended to be complementary to Phylip, Paup, hennig86 and clustalw. It allows uploading of new sequences, storing of aligned sequences (including multiple files), with correct formatting for input into phylogenetic analysis programs. Another description can be found at http://www.no.embnet.org/phylogeny.html 1993 contact info for the author is as follows: Herve Phillippe Laboratoire de Biologie Cellulaire, URA CNRS 1134 D, Batiment 444 Universite Paris-Sud 91405, Orsay Cedex, France -------------------------- J. Steinbachs, PhD Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org -------------------------- From bizzaro at geoserve.net Tue Jan 25 09:59:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] article about XDBM developer Message-ID: <388DBA4A.5C966CD@geoserve.net> http://www.it.fairfax.com.au/software/20000125/A42596-2000Jan24.html Jeff From bizzaro at geoserve.net Tue Jan 25 10:28:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] another application using a WFD Message-ID: <388DC105.8A8D6B4C@geoserve.net> Locians, Cye robots use a work flow diagram for function programming: http://www.personalrobots.com/cyetour/zaptour/ This is like the graphical language(s) used to program Lego Mindstorms, another robot kit, which were mentioned several times on this list. But this Cye example is interesting because of its use of _simple_ windowlets for functions. Cheers. Jeff From chapmanb at arches.uga.edu Wed Jan 26 08:24:40 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Big request from everyone Message-ID: Hey everyone! I have a favor to request from everyone on the list! As you may know, we are hoping to use XDBM as our XML database manager. Well, I have been working to get XDBM compiling on my FreeBSD machine, and have been having a lot of issues that I'm still trying to work out. This got me to thinking that likely XDBM may have issues on other machines as well, and that it might be good to get these kinks worked out before XDBM will start being an essential part of Loci itself. So, my request is, could everyone who has a little time on their hands try compiling XDBM on there respective machines? It should work fine on Linux machines (which is where is was developed) but I worry about how well it will compile on other machines. There is no INSTALL file, so below I'll give you everyone I know about trying to compile it (keep in mind that I haven't actually been successful yet--close, but not successful!). Thanks in advance for anyone who tries to do this. You can either direct questions at me (chapmanb@arches.uga.edu) or at the XDBM mailing list (xdbm-dev@bowerbird.com.au). Please let me know how it works out. Thanks again! Brad My mediocre XDBM installation knowledge ---------------------------------------- To get XDBM working, you will need the following stuff: 1. cweb: XDBM is written using literate programming, and currently the makefiles require cweb. The actual c source code is also distributed, so you can probably change the makefile to use this, and not get cweb, if you want. ftp://tug2.cs.umb.edu/tex-archive/web/c_cpp/cweb/ 2. PCRE (Perl C Regular Expression Library): ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/ 3. libunicode-0.5: http://www.bowerbird.com.au/download.shtml 4. Finally (whew!), XDBM: http://www.bowerbird.com.au/download.shtml Compilers etc to have: Currently, XDBM and linunicode work with gnu make (gmake) and the gnu c (gcc) compiler. I tried to compile with my FreeBSD native make, and had no luck whatsoever, so I had to switch over to gmake, and could then get a lot farther. There is no configure script for XDBM so far. What to do: Okay, once you get everything, you need to first install cweb and pcre. I can't offer any advice for these, because there are FreeBSD ports for them and so my install was easy. But please let me know if you have problems! Once you get these installed, then it is time to compile the XDBM specific programs. On FreeBSD the installed programs are located in /usr/local, so I unpacked everything in this directory (using tar -xzvpf on the two tar.gz files) and got a libunicode-0.5 directory and a libxdbm-1.0.5 directory. Okay, now first, libunicode: The libunicode install worked out decently for me. I changed into the libunicode-0.5 directory, and I had to change the Makefile to use gmake instead of my native FreeBSD make (but some systems may have gmake as their native make, I'm not positive) and then typed gmake, and then gmake install in the main directory, and had no big problems. Now XDBM itself. This is where I had the most problems, so I can tell you how far I got. I changed into the libxdbm-1.0.5 directory and I first modified the Makefile in the main directory to use gmake instead of make. Then I made two other modifications to Makefiles. In the lib directory, I modified the Makefile INCLUDES variable as follows: was: INCLUDES=-I../include now: INCLUDES=-I../include ../../include This allows my to include my /usr/local/include directory (which contains the header files for pcre). Then in the utils directory, I modified the Makefile LIBDIR variable as follows: was: LIBDIR=-L../lib now: LIBDIR=-L../lib -L../../lib -L../Xpat This allowed me to link libraries in my main /usr/local/lib directory and in the libxdbm-1.0.5/Xpat directory. (BTW, Xpat is a modified version of the expat xml parser, I believe.). Well, this is as far as I got, since I now have issues with different header files between Linux and FreeBSD. I hope all of this hasn't scared people off from trying it! I would be very interested in hearing people's luck, and also hearing advice from people who are more experienced at porting programs/writing in C then I am. Thanks much for listening! Brad From bizzaro at geoserve.net Wed Jan 26 11:02:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Big request from everyone References: Message-ID: <388F1A8E.45F89D4A@geoserve.net> Hi Brad! Brad Chapman wrote: > > machines? It should work fine on Linux machines (which is where is was > developed) but I worry about how well it will compile on other machines. I only have Linux boxes, so I can't help with this. > 2. PCRE (Perl C Regular Expression Library): > ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/ > 3. libunicode-0.5: > http://www.bowerbird.com.au/download.shtml Why are these used? > I hope all of this hasn't scared people off from trying it! Well, Jeez Brad, we got our very first 'unsubscribe' from the list right after you posted this :-) Seriously. > I would > be very interested in hearing people's luck, and also hearing advice from > people who are more experienced at porting programs/writing in C then I am. So, XDBM is written in C (an early question I had). Why then are the Python bindings being done in C++? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From Thomas.Sicheritz at ebc.uu.se Wed Jan 26 15:00:03 2000 From: Thomas.Sicheritz at ebc.uu.se (Thomas.Sicheritz@ebc.uu.se) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Big request from everyone In-Reply-To: References: Message-ID: <14479.21059.642173.710454@evolution.ebc.uu.se> Brad Chapman writes: > Hey everyone! > I have a favor to request from everyone on the list! As you may > know, we are hoping to use XDBM as our XML database manager. Well, I have > been working to get XDBM compiling on my FreeBSD machine, and have been > having a lot of issues that I'm still trying to work out. This got me to > thinking that likely XDBM may have issues on other machines as well, and > that it might be good to get these kinks worked out before XDBM will start > being an essential part of Loci itself. So, my request is, could everyone > who has a little time on their hands try compiling XDBM on there respective > machines? It should work fine on Linux machines (which is where is was > developed) but I worry about how well it will compile on other machines. > There is no INSTALL file, so below I'll give you everyone I know about > trying to compile it (keep in mind that I haven't actually been successful > yet--close, but not successful!). Thanks in advance for anyone who tries to > do this. You can either direct questions at me (chapmanb@arches.uga.edu) or > at the XDBM mailing list (xdbm-dev@bowerbird.com.au). Please let me know > how it works out. Thanks again! > > Brad > Ok - great advantage to take a rest from my writing :-) SUN Ultra1, Solaris 2.7 with gcc and GNU make, reports no problem ... I have compiled libxdbm-1.0.6.tar.gz libunicode-0.5.tar.gz and pcre-2.08.tar.gz ( I skipped the doc part of libxdbm-1.0.6.tar.gz which needed cweb) Except for minor changes in Makefiles (-L's and -I's) there were no problems. However, I don't know how to test if everything is really ok ... in fact I have not been listening to this list since month's - so I don't even know what I tried to compile. ;-) Does anyone (Brad !!!) has a test script or something similar ? Brad, what problems did you encounter ? I am actually surprised that there were no problems at all on the SUN. Usually I am prepared for a lot of hacking when I try to port anything to our machines - maybe I can help ? c ya and may the --force be with you -thomas -- Sicheritz Ponten Thomas E. Linnaeus Centre for Bioinformatics blippblopp@linux.nu BMC, Uppsala University BMC: +46 18 4714214 BOX 590 S-751 24 UPPSALA Sweden Fax +46 18 557723 http://evolution.bmc.uu.se/~thomas Molecular Python: http://evolution.bmc.uu.se/~thomas/python Molecular Linux: http://evolution.bmc.uu.se/~thomas/mol_linux De Chelonian Mobile ... The Turtle Moves ... From chapmanb at arches.uga.edu Wed Jan 26 14:45:39 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Big request from everyone In-Reply-To: <388F1A8E.45F89D4A@geoserve.net> References: Message-ID: >> 2. PCRE (Perl C Regular Expression Library): >> ftp://ftp.cus.cam.ac.uk/pub/software/programs/pcre/ >> 3. libunicode-0.5: >> http://www.bowerbird.com.au/download.shtml > >Why are these used? PCRE: I'm definately not an expert on the code, but I believe its used for doing the matching when searching the XDBM files for particular values. There isn't anything about this in the documentation (I just found out when I tried to compile it and got errors about not having pcre.h.) libunicode: XDBM handles text in the uchar format, which is what libunicode provides utilities for. Not being a C programmer or knowing much at all about string handling intricacies, I'm not positive what the advantage of using this type over another string handling type is. >> I hope all of this hasn't scared people off from trying it! > >Well, Jeez Brad, we got our very first 'unsubscribe' from the list right after >you posted this :-) Seriously. Sorry! I'm driving everyone away! :< >> I would >> be very interested in hearing people's luck, and also hearing advice from >> people who are more experienced at porting programs/writing in C then I am. > >So, XDBM is written in C (an early question I had). Why then are the Python >bindings being done in C++? Well, this hasn't actually been decided yet, its still kind of being argued over. SCXX is just a really thin wrapper around the C API for extending python, but the basic idea behind using C++ is that if we write the bindings for python, the tcl or perl crowd could come in and extend those to make their bindings. Plus, writing in C++ will be closer to writing in python, and apparently may make things a bit easier. As I said, there is still discussion over whether to use C or C++ and also how much of the binding should be written in C (and thus be reusable by other bindings to XDBM) and how much should be written in python. When all of the smoke clears on that, then, hopefully we'll get cracking on the bindings--I'm hoping we can get going soon! The other two people that will help with this are *much* more experienced then I, so I'm pretty much leaving the decision up to them. We'll see. Sorry again for my extensively boring posts about C that drive people away :) Brad From chapmanb at arches.uga.edu Thu Jan 27 08:03:30 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Big request from everyone In-Reply-To: <14479.21059.642173.710454@evolution.ebc.uu.se> References: Message-ID: >Ok - great advantage to take a rest from my writing :-) Happy to be of service! >SUN Ultra1, Solaris 2.7 with gcc and GNU make, reports no problem ... >I have compiled libxdbm-1.0.6.tar.gz libunicode-0.5.tar.gz and >pcre-2.08.tar.gz ( I skipped the doc part of libxdbm-1.0.6.tar.gz which >needed cweb) >Except for minor changes in Makefiles (-L's and -I's) there were no >problems. Great! Thanks much for trying this out! >However, I don't know how to test if everything is really ok >... in fact I have not been listening to this list since month's - so I >don't even know what I tried to compile. ;-) XDBM is a library that provides an XML database functionality. It can take XML files and then convert them into 'XDBM format' which is a preparsed format. It then provides functions for searching this format which will be (hopefully) much faster than the standard python DOM stuff. XDBM will hopefully soon have a python binding which will allow a DOM and SAX interface to the library. The plan is that XDBM will do all of the xml storage manipulation for Loci. >Does anyone (Brad !!!) has a test script or something similar ? Right, I checked into this and got the following. At the end of this mail are three C programs that will test different functions of XDBM. According to the docs, you need to link against libxdbm, libunicode, libpcre, and libXpat when compiling the tests. Of course, since I haven't got it working yet, I can't offer any other advice, but it seems like you are waaaay ahead of me... >Brad, what problems did you encounter ? I am actually surprised that there >were no problems at all on the SUN. Usually I am prepared for a lot of >hacking when I try to port anything to our machines - maybe I can help ? I hope so! I'm really stuck for something to try next. After the changes I made that I detailed in my last e-mail, I can compile up until the utils directory, when I get the following: gmake[1]: Entering directory `/usr/local/libxdbm-1.0.5/utils' #gcc295 -g -pg -static -L../../lib -L../lib xml2xdbm.o -o xml2xdbm -lxdbm -lunicode -lXpat -lm gcc295 -L../../lib -L../lib xml2xdbm.o -o xml2xdbm -lxdbm -lunicode -lXpat -lpcre -lm ../../lib/libXpat.so: undefined reference to `stderr' ../../lib/libunicode.so: undefined reference to `towlower' ../../lib/libXpat.so: undefined reference to `__fxstat' collect2: ld returned 1 exit status I'm not positive why I'm not finding these functions. Not being experienced at all with C programming/porting, I'm not positive where to turn next. Any advice you could offer would be *greatly* appreciated! Thanks again for testing this out for me. Below is the C code and the xml file they work on. Brad //test 1: test all of the functions Node *node, *nodeb, *nodec; NodeList nlist; Uchar *foo = u_utf8_to_uc( "foo"); Uchar *wop = u_utf8_to_uc( "wop"); Uchar *goo = u_utf8_to_uc( "goo"); Uchar *flop = u_utf8_to_uc( "flop"); puts("/* test xdbm_fetch, xdbm_name */"); nlist = xdbm_fetch(doc, goo, wop, foo, NULL); do{ printf("%s\n",u_uc_to_utf8(xdbm_name(nlist[0]))); printf("%s\n",u_uc_to_utf8(xdbm_value(nlist[0]))); node = nlist[0]; }while((++nlist)[0]); printf("%s\n","/* test xdbm_all_attributes */"); nlist = xdbm_all_attributes(node); do{ printf("%s\n",u_uc_to_utf8(xdbm_name(nlist[0]))); printf("%s\n", u_uc_to_utf8(xdbm_value(nlist[0]))); }while((++nlist)[0]); printf("%s\n","/* test xdbm_attribute */"); printf("%s\n",u_uc_to_utf8(xdbm_attribute(node, flop))); printf("%s\n","/* test xdbm_fetch_first */"); node = xdbm_fetch_first(doc); printf("%s\n",u_uc_to_utf8(xdbm_name(node))); printf("%s\n","/* test xdbm_fetch_child_name */"); nlist = xdbm_fetch_child_name(node, wop); do{ printf("%s\n",u_uc_to_utf8(xdbm_name(nlist[0]))); printf("%s\n",u_uc_to_utf8(xdbm_value(nlist[0]))); }while((++nlist)[0]); printf("%s\n","/* test xdbm_fetch_child_value */"); nlist = xdbm_fetch_child_value(node, "dollop.+wollop"); do{ printf("%s\n",u_uc_to_utf8(xdbm_name(nlist[0]))); printf("%s\n",u_uc_to_utf8(xdbm_value(nlist[0]))); }while((++nlist)[0]); printf("%s\n","/* test xdbm_fetch_child_nodetype */"); nlist = xdbm_fetch_child_nodetype(node, XDBM_NODE_TEXT); do{ printf("%s\n",u_uc_to_utf8(xdbm_name(nlist[0]))); printf("%s\n",u_uc_to_utf8(xdbm_value(nlist[0]))); }while((++nlist)[0]); printf("%s\n","/* test xdbm_first_child */"); nodeb = xdbm_first_child(node); printf("%s\n",u_uc_to_utf8(xdbm_value(nodeb))); printf("%s\n","/* test xdbm_next_sibling */"); nodec = xdbm_next_sibling(nodeb); printf("%s\n",u_uc_to_utf8(xdbm_value(nodec))); printf("%s\n","/* test xdbm_next_sibling */"); nodeb = xdbm_next_sibling(nodec); printf("%s\n",u_uc_to_utf8(xdbm_value(nodeb))); printf("%s\n","/* test xdbm_next_sibling */"); nodec = xdbm_next_sibling(nodeb); printf("%s\n",u_uc_to_utf8(xdbm_value(nodec))); printf("%s\n","/* test xdbm_last_child */"); nodeb = xdbm_last_child(node); printf("%s\n",u_uc_to_utf8(xdbm_value(nodeb))); printf("%s\n","/* test xdbm_previous_sibling */"); nodec = xdbm_previous_sibling(nodeb); printf("%s\n",u_uc_to_utf8(xdbm_value(nodec))); printf("%s\n","/* test xdbm_previous_sibling */"); nodeb = xdbm_previous_sibling(nodec); printf("%s\n",u_uc_to_utf8(xdbm_name(nodeb))); printf("%s\n","/* test xdbm_previous_sibling */"); nodec = xdbm_previous_sibling(nodeb); printf("%s\n",u_uc_to_utf8(xdbm_value(nodec))); //test 2: test manipulation function Node *node, *nodeb, *nodec; NodeList nlist; Uchar *foo = u_utf8_to_uc( "foo"); Uchar *wop = u_utf8_to_uc( "wop"); Uchar *goo = u_utf8_to_uc( "goo"); Uchar *flop = u_utf8_to_uc( "flop"); puts("/* test xdbm_fetch, xdbm_name */"); nlist = xdbm_fetch(doc, goo, wop, foo, NULL); do{ xdbm_delete_node(nlist[0]); xdbm_free_node(nlist[0]); }while((++nlist)[0]); node = nlist[0]; nodeb = xdbm_fetch_first(doc); nlist = xdbm_fetch(doc, wop, foo, NULL); nodec = nlist[0]; xdbm_insert(doc, nodeb, nodec, node); //test 3: test memory usage int i; for( i = 0; i < doc->numberDatum; i++){ (void) __xdbm_load_node(doc->searchDatumList[i]->nodePos, doc->fp, doc); # the XML file--I didn't make this up, so please don't ask me to explain it! dollop of wollop danny boy dollops of wollops one .. two three four bunkum From chapmanb at arches.uga.edu Fri Jan 28 13:34:39 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Change in xml DOM implementations In-Reply-To: <388F1A8E.45F89D4A@geoserve.net> References: Message-ID: Hey all! I just got the following from the XML-SIG (special interest group): * The current PyDOM code will be dropped and replaced with 4DOM. The precise details of how this will work are still to be resolved; will the 4DOM code move into xml.dom, or will xml.dom import from xml.Ft.dom and provide some wrappers? This came, crazily enough, just as I was looking at the latest 4DOM release. 4DOM is a python Document Object Model implementation for messing around with XML files and is distributed by 4Thought. The code and install instructions are located at http://fourthought.com/4Suite/4DOM/. I think I'm just going to go ahead and switch the DOM code in loci over to use the 4DOM stuff so I can learn how to use it, unless anyone seriously objects to this. I doubt if it will be a big deal to make the necessary changes necessary to fix things once 4DOM moves into the PyXML package--it sounds like there will just be a few import changes. BTW, although I know nothing about licensing, I don't think there should be any problems with the 4DOM license. The whole thing is pasted in below for anyone who cares to look. That's all the news that's fit to print on the xml front... Brad 4DOM License/Copyright (this makes it look like my e-mail is copyrighted by FourThought!) Copyright (c) 1999 FourThought LLC, USA All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of FourThought LLC not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. FOURTHOUGHT LLC DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL FOURTHOUGHT BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. From bizzaro at geoserve.net Sat Jan 29 11:51:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] Change in xml DOM implementations References: Message-ID: <38931AA3.EE7F8D2F@geoserve.net> Brad Chapman wrote: > > I think I'm just going to go ahead and switch the DOM code in loci > over to use the 4DOM stuff so I can learn how to use it, unless anyone > seriously objects to this. I doubt if it will be a big deal to make the > necessary changes necessary to fix things once 4DOM moves into the PyXML > package--it sounds like there will just be a few import changes. Okey-dokey. Thanks for the news. > Permission to use, copy, modify, and distribute this software and its > documentation for any purpose and without fee is hereby granted, > provided that the above copyright notice appear in all copies and that > both that copyright notice and this permission notice appear in > supporting documentation, and that the name of FourThought LLC not be > used in advertising or publicity pertaining to distribution of the > software without specific, written prior permission. This is a 'copyright only' license, the same as the Python license, which are almost always worded like this. It's the most liberal of licenses, next to being 'public domain', and it's compatible with the LGPL. So, we can use it. 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 Sat Jan 29 21:30:55 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] GStreamer Message-ID: <200001300230.TAA00684@redpoll.pharmacy.ualberta.ca> Hey Gang, I found this app on SourceForge: http://gstreamer.sourceforge.net/ >From the Summary: GStreamer is a streaming-media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Sound a little like Loci? Check out the GStreamer 'Editor' screenshot! g. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca Faculty of Pharmacy Phone: (780) 492-4493 University of Alberta FAX: (780) 492-5305 Edmonton, Alberta, Canada From bizzaro at geoserve.net Sat Jan 29 22:50:42 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] GStreamer References: <200001300230.TAA00684@redpoll.pharmacy.ualberta.ca> Message-ID: <3893B511.F798BC29@geoserve.net> Gary Van Domselaar wrote: > > Sound a little like Loci? Check out the GStreamer 'Editor' screenshot! I'm a step ahead of you, Gary, since I mentioned GStreamer a couple months ago :-) But it wasn't hosted at SourceForge at that time. (BTW, it's shocking how many projects have moved to SourceForge over the last month or so.) The Editor does look like our Workspace (Gtk+ interface), although I think we did a much better job at designing an intuitive (what is CRDPP?) and flexible (icons and windowlets) system. GStreamer is an important example of how programs can be piped for 'streaming' vs. 'step-wise' data flow. Our original plan for Loci was to make a system for step-wise data flow, meaning the data would be passed from the first application to the second, _only_ when the first application has stopped. This would work well for most bioinformatics applications (e.g., you run BLAST and _then_ get the results). But for media applications you need streaming (e.g., audio gets filtered _while_ it is being played). This is why lately I've been think of Loci as a 'connectivity broker': not dictating what protocol (CORBA, HTTP, etc.) should be used, but allowing the user to make the best or most appropriate connection. As Gary pointed out to me, it would be overkill to force the output of 'ls' as input into 'grep' using CORBA, when a simple UNIX pipe would work. The same would go for getting an HTML page from a Web server: Would we require that the Web server first be wrapped in CORBA before it can work with Loci? 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 Sun Jan 30 04:52:37 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:09 2006 Subject: [Pipet Devel] GStreamer References: <200001300230.TAA00684@redpoll.pharmacy.ualberta.ca> <3893B511.F798BC29@geoserve.net> Message-ID: <389409E5.9A498048@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > Gary Van Domselaar wrote: > > > > Sound a little like Loci? Check out the GStreamer 'Editor' screenshot! > > I'm a step ahead of you, Gary, since I mentioned GStreamer a couple months ago > :-) Ack! I've gotta get off of the heroin! But it wasn't hosted at SourceForge at that time. (BTW, it's shocking how many projects have moved to SourceForge over the last month or so.) Yeah... I think open-source software developers are starting to use SourceForge to advertise their projects, and to attract other developers. Kinda makes ya think... > > The Editor does look like our Workspace (Gtk+ interface), although I think we > did a much better job at designing an intuitive (what is CRDPP?) and flexible > (icons and windowlets) system. Natch ;-) BTW, CRDPP refers to 'Element States' (what we would call 'Locus states'): C Complete Element has all the required data R Running Element has acquired resources D Discovery Used during auto-connect P Preroll Sending ramp-up data P Playing Actively trading data P Pause Temporarily paused Food for thought, actually. Regards, g. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Sun Jan 30 05:02:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] GStreamer References: <200001300230.TAA00684@redpoll.pharmacy.ualberta.ca> <3893B511.F798BC29@geoserve.net> <389409E5.9A498048@redpoll.pharmacy.ualberta.ca> Message-ID: <38940C37.C0458BF9@geoserve.net> Gary Van Domselaar wrote: > > > I'm a step ahead of you, Gary, since I mentioned GStreamer a couple months ago > > Ack! I've gotta get off of the heroin! No, you can stay on heroin, Gary. I have to get off of crack. I could have sworn I sent that link to the list, but I can't find my original message. Maybe I just imagined the whole thing. Anyway, here is a screenshot of a WFD (bottom right corner) a _lot_ like GStreamer's (but a little prettier): http://beast.gtk.org/beast-shot1.png BEAST is another streaming audio application. Maybe I mentioned BEAST before, but I can't find that message either :-P > Yeah... I think open-source software developers are starting to use > SourceForge to advertise their projects, and to attract other > developers. Kinda makes ya think... Yeah, if only I knew someone with PHP and mySQL experience. Hmmmm ;-) > > The Editor does look like our Workspace (Gtk+ interface), although I think we > > did a much better job at designing an intuitive (what is CRDPP?) and flexible > > (icons and windowlets) system. > > Natch ;-) > BTW, CRDPP refers to 'Element States' (what we would call 'Locus > states'): > > C Complete Element has all the required data > R Running Element has acquired resources > D Discovery Used during auto-connect > P Preroll Sending ramp-up data > P Playing Actively trading data > P Pause Temporarily paused > > Food for thought, actually. Ohhhhhhh. I was thinking about little animated glyphs to show state, but there are no animated canvas items yet. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 30 06:07:30 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] WFD examples Message-ID: <38941B72.5A135E05@geoserve.net> Locians, For your viewing pleasure, I put a whole bunch of Work Flow Diagram examples on the Web (also in loci-doc module): http://bioinformatics.org/loci/documentation/screenshots/wfd-examples/ Most of these were mentioned earlier. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 30 09:17:17 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES Message-ID: <389447ED.38B9290D@geoserve.net> 20000130 J.W. Bizzaro * Added a new module for printing out comments as XML comments. comment(object1, object2, [...]) replaces use of print function. The idea is that this function can be turned on and off from the command-line (not implemented yet). 1/28/00 Brad * Changed the dom stuff to use the 4DOM implementation instead of the XML-SIG dom implementation, so that we'll be compatible later when the XML-SIG adopts 4dom as their "official" implementation. * Tried a bunch of things to try and get the container/directory stuff to speed up. I don't think I can optimize it any more. We'll have to do something about that--for now I just set it to only give the info about the top level directory, so it is quick. Maybe I can learn how to run the other process in the background. 1/27/00 Brad * Continued working on the command line. The added processor now has a window with a model of the command line. This model will be different depending on the program chosen, and the info about the program will be found from the the xml file. More on this to come. Big problem here: the internal widgets of a workspace don't always redraw, which can leave things looking ugly--need to find a way to fix this. * Tried to fix the problems with scrolling, so that you no longer lose the loci off the screen. Now the scrollbars and workspace size automatically increase when a loci is moved toward the bottom or the right. The loci is stopped from moving when it attempts to go to the top or left of the screen. Problem here: As a loci moves around there seems to begin to be a discrepency between the world_x and world_y and its actual coordinates on the screen. I think this is due to the fact that canvas coordinates are integers, and world coordinates are doubles. Need to think of a way to remedy this problem. Also, need to find a way to make the screen scroll automagically when the widget is moved. 1/26/00 Brad * Started working on a better way to build the command line. Now, when a program is selected from a processor, its GUI changes to a new workspace, and a processor is added to the workspace. This processor will soon contain a widget that will help them construct the command line within the new workspace window. 1/24/00 Brad Whole bunch o' changes: * Got everything documented with doc strings. I will be using doc strings for everything from now on. I'm still working to get pythondoc working to read all of our modules (I'm talking with the pythondoc author about this). * Changed the Locus class to be a lot larger and more OO. It is now a separate file from gi.py. Fixed all of the problems that changing this caused. * Tweaked a lot of the code in the xml, widget and wrap folders. Tried to make the interfaces a little more sensible. Fixed all of the problems that changing these interfaces caused. * Fixed the container loading system so that the contents of the container refresh when new contents for the container are chosen. However, this now makes it look like Loci is freezing up--need to think of a way to not make this so ugly, or to make things faster. * Fixed the addition of new workspaces so now the workspaces are added in a tree type fashion as Gary suggested (ie. when a container is added inside a workspace, the new workspace directory is inside the directory of the workspace that contains the container.) * Got sick of having two testwidget.py's that were exactly the same, so now there is just one testwidget.py in the widget directory. * I'm using os.makedirs in addLocusXML again since 1.5.2 is now a requirement for Loci. -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 30 09:50:29 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES References: <389447ED.38B9290D@geoserve.net> Message-ID: <38944FB5.708C1532@geoserve.net> Brad, > Big problem here: the internal widgets of a workspace don't always redraw, > which can leave things looking ugly--need to find a way to fix this. There is a Gtk or Gdk function to force a widget to redraw. I can't recall it off-hand. BTW, we've always had this problem with the windowlet not catching _windowlet_ events but workspace events. It seems the event box and windowlet positions are not always the same. Any ideas? > * Tried to fix the problems with scrolling, so that you no longer lose > the loci off the screen. Now the scrollbars and workspace size > automatically increase when a loci is moved toward the bottom or the > right. The loci is stopped from moving when it attempts to go to the top > or left of the screen. Great! That was one of the things I've been wanting to do. > Problem here: As a loci moves around there seems to begin to be a > discrepency between the world_x and world_y and its actual coordinates on > the screen. I think this is due to the fact that canvas coordinates are > integers, and world coordinates are doubles. Need to think of a way to > remedy this problem. I noticed the mouse cursor 'slips away' from the locus too. > Also, need to find a way to make the screen scroll automagically when the > widget is moved. It looks like the workspace starts to scroll but then stops. > 1/26/00 Brad > * Started working on a better way to build the command line. Now, when a > program is selected from a processor, its GUI changes to a new workspace, > and a processor is added to the workspace. This processor will soon contain > a widget that will help them construct the command line within the new > workspace window. Hmmm. Is the windowlet that looks like a control-panel meant to _help_ the user select loci used in command-line construction, or is it used to actually construct the command-line? Also, you have it work this way: (1) Select processor (2) Open processor and find command (3) Choose command and processor becomes composite (4) Command is inside of composite _Please_ make a these changes <:-) (1) Select processor ---> (1) Select container (2) Open processor and ---> (2) Open container find command and find command (3) Choose command and ---> (3) Choose command by dragging processor becomes it onto the workspace composite (4) Command is inside ---> (4) Command is on workspace of composite This is pretty much what we've been discussing. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sun Jan 30 13:30:05 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES Message-ID: <200001301833.NAA196658@archa10.cc.uga.edu> Hey Jeff; Good to hear from you. Thanks much for looking at my changes! I was trying to get them in better order before I wrote about them. I just cvsed a bunch of changes which will hopefully make things clearer about what I am trying to do. I'll comment on those below. >Thanks for taking out the .pyc files. I didn't get around to it. Oh yeah, no problem. I've just been pulling them out a little at a time when I cvs. That makes more sense anyways than having to cvs just to remove them. >* Added a new module for printing out comments as XML comments. > > comment(object1, object2, [...]) > > replaces use of print function. The idea is that this function > can be turned on and off from the command-line (not implemented yet). Cool, I'll start using this for all my prints. >> Big problem here: the internal widgets of a workspace don't always redraw, >> which can leave things looking ugly--need to find a way to fix this. > > There is a Gtk or Gdk function to force a widget to redraw. I can't recall > it off-hand. I remember trying to force a redraw using *.queue_draw_area() (a function in GtkWidget) but didn't have any luck. Even if I could manage to force a redraw when a locus is created in an internal windowlet (which would be so nice) there is still a problem of redrawing under normal circumstances (ie. when a composite GUI is being moved around). The loci in the internal windowlet seem to redraw fine, but not the GUI windowlets of the loci in the windowlet (man, that's confusing!) do not. It seems like there must be a way to connect the GUI to the internal windowlet GnomeCanvas so it will redraw with them, but I'm not sure how... >BTW, we've always had this problem with the windowlet not catching > _windowlet_ events but workspace events. It seems the event box and > windowlet positions are not always the same. Any ideas? Well, I was trying to fix this, and it seems like there are two problems. The first is the discrepency between the world_x, world_y and the actual positions on the screen. I was looking into this and it seems like the problem might be the difference between canvas coordinates and world coordinates. World coordinates are specified as a double, so they are very precise, while canvas coordinates (which are used when the loci moves) are integers. So it seems like every time a loci moves, its canvas position and world coordinates get further and further apart. I tried to use the GnomeCanvas function c2w to convert canvas to world coordinates, but I kept getting a seg fault whenever I used the function. I'm not sure if it's my problem or a pyGnome problem. So I'm not sure what to do about the position difference problem. The second problem is that there appears to be "competition" between the gui windowlet and the main workspace for clicks. I *tried* to force the gui to be selected whenever the mouse was over it or there was a click on it by connecting gui events to a handler that set the loci as selected (if you notice, the way I connected gui windowlets to mouse movement causes a huge amount of s to be printed to the screen. Sorry about that!). But, if you left click on a gui there will be two selection events. The gui windowlet is initially selected by its own event handlers, but then the main workspace is selected by its handlers. When this second selection of the main workspace occurs, that selection event wins out. What I'll try later today is to have the workspace ignore all clicks within the region defined by the locus.group.window_widget, when a gui windowlet is shown. I'll write the results in the CHANGE log tommorrow. Maybe this might work... >> * Tried to fix the problems with scrolling, so that you no longer lose >> the loci off the screen. Now the scrollbars and workspace size >> automatically increase when a loci is moved toward the bottom or the >> right. The loci is stopped from moving when it attempts to go to the top >> or left of the screen. > > Great! That was one of the things I've been wanting to do. I was just getting really annoyed because I was stupidly losing my loci all the time, so I decided to add this. > I noticed the mouse cursor 'slips away' from the locus too. Yeah, I don't know how much this affects the "actual position" versus world position problem. I'm not experienced enough in writing GUIs to know this. >> Also, need to find a way to make the screen scroll automagically when the >> widget is moved. > > It looks like the workspace starts to scroll but then stops. Yeah, I think this might just be a jerking motion caused by the resizing of the scrollbars and workspace. If you look at the scroll bars, you'll notice they never move when the canvas and scroll area is being resized. I'd like to have them move along with the position of the loci, so that it is always in view in the window. I can't seem to find a way to programmatically make the scroll bars move. Any ideas? > Hmmm. Is the windowlet that looks like a control-panel meant to _help_ the > user select loci used in command-line construction, or is it used to actually > construct the command-line? Okay, I think things will be a lot clearer about what I was trying to do if you look at the recently updated loci that I just cvsed today. The idea I had is that the control-panel thingy is like a "model" of the command line. If you want to take a look, try it out with gbparse (in the seqManip module)--this is the only program that works right. Basically, every button in the control-panel is a portion of the command line. This command line is specified in the xml file for a program via "request" tags. If you look at the xml file for gbparse (in back.private.library.xml.seqManip) you can probably get an idea about what I'm thinking of. Basically, my idea to port a program is to have a description, the flags available, and then a set of tags called in which you spell out the command line via request tags. This mechanism allows information about each item in the command line to be specified via tags. Right now I'm using these tags as the information to put in a tooltip for the buttons in the control-panel. So if you hold the mouse over a button in the control-panel, you can see a description of why you would want to click that button. So, I was hoping the control-panel would give the natural idea to start clicking the buttons in order. If you click the first button, you will be an info window with a description of the program. Right now this is a really ugly window with the information in the tags spit into a text_box. My ultimate thought for this is that the information could be tagged up like an html file, so this window could have links to web sites, bolded items, bullets, etc. Anyways, once your done reading this, click on okay, and then proceed to the next item in the control-panel list. When you click on this it will open up an option loci (Note: I just added this loci--feel free to change it to make it fit in with your vision of how the loci should look) with the flags for the program to be set. When you're done with this, click on the next button, and you'll get a file selection widget (which I just made--I hope it's what you were thinking of as a simple widget) where you can select the input file for the program. Well, I hope this gives the general idea of what I was thinking. What do people think? Like it, hate it? Changes? If anyone wants to try it out, please notice that I changed the DOM stuff to use 4DOM, so you'll need to install that (the web site for 4DOM is in the INSTALL file). Thanks much for listening! Brad From chapmanb at arches.uga.edu Sun Jan 30 13:30:11 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES Message-ID: <200001301833.NAA64424@archa11.cc.uga.edu> Hello again! I just wanted to go over this stuff in a separate e-mail because I'm not totally positive how you envision things working. I was just trying to get stuff working in the "easiest" way that I could to demonstrate my idea of constructing the command line using the control panel thingy. Below are tons o' questions to show my complete and utter confusion! > _Please_ make a these changes <:-) > > (1) Select processor ---> (1) Select container Lots o' questions on this: So a container holds 1. filesystems 2. databases and 3. all of the programs? When you create a new container, what kind of gui widget should appear? So, if you don't select "processing" programs from a processor loci, and "converting" programs from a converter loci, when are these loci used? > (2) Open processor and ---> (2) Open container > find command and find command Do you like the way things are divided up in modules now? Is this how you want things, or should there just be a big list of all the programs? > (3) Choose command and ---> (3) Choose command by dragging > processor becomes it onto the workspace > composite Right, drag and drop. This will take a bit of learning, but I'll start thinking about this. > (4) Command is inside ---> (4) Command is on workspace > of composite So how do you envision the "constructing the command line" happening? Will this occur on the main workspace, or inside a separate workspace, like I've been doing? My thought was that you could construct the command line inside of the composite, and then click on the main locus holding the composite workspace, and choose an option like "construct command line." This would change the GUI of the locus to display the chosen command line only. Then this could be reversed if the user decides to change the current command line. How would constructing the command line work if everything was done on the main workspace? > This is pretty much what we've been discussing. Sorry I'm off on your vision. I'm working on it... Brad From gvd at redpoll.pharmacy.ualberta.ca Sun Jan 30 22:11:00 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] GStreamer References: <200001300230.TAA00684@redpoll.pharmacy.ualberta.ca> <3893B511.F798BC29@geoserve.net> <389409E5.9A498048@redpoll.pharmacy.ualberta.ca> <38940C37.C0458BF9@geoserve.net> Message-ID: <3894FD44.2139C669@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > > Yeah... I think open-source software developers are starting to use > > SourceForge to advertise their projects, and to attract other > > developers. Kinda makes ya think... > > Yeah, if only I knew someone with PHP and mySQL experience. Hmmmm ;-) Not that this is Loci related, but you can point your browser to http://gvd.v-wave.com/ anytime and check on the progress of 'TOLForge' ;-) Regards, g. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Sun Jan 30 22:45:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES References: <200001301833.NAA64424@archa11.cc.uga.edu> Message-ID: <38950543.4230855B@geoserve.net> Brad Chapman wrote: > > > (1) Select processor ---> (1) Select container > > Lots o' questions on this: > > So a container holds 1. filesystems 2. databases and 3. all of the > programs? Okay, ignoring databases for a while, think of a container as representing any one directory/folder in the filesystem. It's that simple. Then, 1 and 3 are the same, IF a container represents the directory / IF a container is set to represent /usr/bin, then it holds the programs in /usr/bin and nothing else. > When you create a new container, what kind of gui widget should > appear? Ignoring databases, the workspace should have 2 default containers: * one for loci/back/private/container/ * and one for loci/back/public/container/ So, the GUI should be a directory listing. Remember, container = directory (ignoring databases). Does a user then actually 'create a new container'? Well, he/she can only _open_ directories (equals containers) that already exist in the filesystem. Creating a brand new container would mean creating a new directory on the filesystem, which is something we can do. > So, if you don't select "processing" programs from a processor loci, > and "converting" programs from a converter loci, when are these loci > used? Now I see where you're getting confused. You're considering locus types (processor, document, etc.) to be 'containers' of a sort, containing programs of that type. But only loci of type 'container' are containers. The program 'ls', for example, is a 'processor' type locus, but it doesn't _contain_ anything. It _represents_ ls, and that's all. Loci types _identify_ _file_ types. Any directory can then be interpreted as being a container locus full of other loci. For example: private/ babel* blast* pol3.pdb rasmol* stuff/ seqManip* yeast.genbank Is seen by Loci as private/ (container) babel* (processor) blast* (processor) pol3.pdb (document) rasmol* (viewer^) stuff/ (container) seqManip* (processor) yeast.genbank (document) (^ note that identifying rasmol as a viewer requires a wrapper for rasmol) So, how do I select seqManip? (1) Open 'private' container (2) DnD 'stuff' container onto workspace (if using non-tree view) (3) Open 'stuff' container (4) DnD 'seqManip' processor onto workspace Again, processor is a locus _type_, just like a file type. It is NOT a container. Okay, just think of it as pulling files and folders out of a Mac hard drive, onto the Mac desktop. It's _exactly_ the same. EXACTLY. So, now you're probably asking, 'What about the wrappers for seqManip? Where do they go?' Well, my thoughts are that Loci will (1) identify the location of the file, and (2) then check the 'wrappers' directory (back.private.wrappers?) for a wrapper. (3) If no wrapper is found, then (4) Loci uses a default wrapper based on file type (executables are processors, etc.) or (5) tries to make its own (as you were doing with man file parsing in middle.library.modules.wrap). > > (2) Open processor and ---> (2) Open container > > find command and find command > > Do you like the way things are divided up in modules now? Is this how > you want things, or should there just be a big list of all the > programs? Well, if containers are directories, then the user can sort loci however they want. They just DnD a locus into a different container. EXACTLY like files and folders in a Mac hard drive. > > (3) Choose command and ---> (3) Choose command by dragging > > processor becomes it onto the workspace > > composite > > Right, drag and drop. This will take a bit of learning, but I'll start > thinking about this. We're using classic 1984 Macintosh paradigms all over the place. I want to _start_ off that way anyhow. We can get fancier with trees, etc. later on. > > (4) Command is inside ---> (4) Command is on workspace > > of composite > > So how do you envision the "constructing the command line" happening? > Will this occur on the main workspace, or inside a separate workspace, > like I've been doing? On the main workspace, simply by DnD-ing the needed loci onto the workspace, and then connecting the dots/lines. > My thought was that you could construct the > command line inside of the composite, and then click on the main locus > holding the composite workspace, and choose an option like "construct > command line." This would change the GUI of the locus to display the > chosen command line only. Then this could be reversed if the user > decides to change the current command line. How would constructing the > command line work if everything was done on the main workspace? First, a command-line would be represented on the workspace as a workflow diagram (WFD). This means, of course, multiple loci connected via lines. Now, this can be executed as it is (by running the main executable/processor perhaps). This is just like what you have done _inside_ of a composite locus windowlet, only it's on the _workspace_. But making a composite locus (single locus out of a WFD) is _not_ the same as constructing the WFD. Making a composite means, for the workspace, making a single locus out of a WFD, and that's all. Of course this also means the GUI's become merged. Somehow, we'll just have the workspace 'zap' a whole WFD and leave a single locus in its place. How does all this sound? You know, I think it's a little less complex than what you had in mind. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sun Jan 30 22:51:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] GStreamer References: <200001300230.TAA00684@redpoll.pharmacy.ualberta.ca> <3893B511.F798BC29@geoserve.net> <389409E5.9A498048@redpoll.pharmacy.ualberta.ca> <38940C37.C0458BF9@geoserve.net> <3894FD44.2139C669@redpoll.pharmacy.ualberta.ca> Message-ID: <389506C0.4292C4E0@geoserve.net> Gary Van Domselaar wrote: > > Not that this is Loci related, but you can point your browser to > > http://gvd.v-wave.com/ > > anytime and check on the progress of 'TOLForge' ;-) You're such a tease! BTW, for you guys wondering if you've missed something here, The Open Lab has a new server that will host an implementation of SourceForge. More info on this will appear on the main TOL mailing list. 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 Mon Jan 31 03:16:46 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES References: <200001301833.NAA64424@archa11.cc.uga.edu> <38950543.4230855B@geoserve.net> Message-ID: <389544EE.FE7048BD@redpoll.pharmacy.ualberta.ca> Jeff and Brad wrote: > First, a command-line would be represented on the workspace as a workflow > diagram (WFD). This means, of course, multiple loci connected via lines. > Now, this can be executed as it is (by running the main executable/processor > perhaps). This is just like what you have done _inside_ of a composite locus > windowlet, only it's on the _workspace_. > > But making a composite locus (single locus out of a WFD) is _not_ the same as > constructing the WFD. Making a composite means, for the workspace, making a > single locus out of a WFD, and that's all. Of course this also means the > GUI's become merged. Somehow, we'll just have the workspace 'zap' a whole WFD > and leave a single locus in its place. I have 2 questions about the 'zapping' part: 1) Creating a new gui from a composited WFD. Say you are constructing a command line with a switch that requires a filename, regex, or some other field. How would you construct the WFD such that the switch and the text-field become associated during the WFD composition? Say, like, take for example a standard POVRAY command-line: loci>x-povray -Idef.ini my_povray_file.pov For the unitiated: -I requires the name of the povray config file def.ini my_povray_file.pov is the input filename. Using Jeff's method, would you create a WFD like this? Header Locus Connector Option Connector Field Connector Field ------------------------------------------------------------------------------------------------------------- URI path/to/povray + FLAG=-I -> ENTRY=def.ini + my_povray_file.pov LOCUS_ID DESCRIPTION="Config File" DESCRIPTION="Input File" LOCUS_NAME LOCUS DESCRIPTION Etc. Using the concatenator symbol '+' to represent the concatenation of 'unassociated' flags and the 'association' symbol (->) to associate the Flags with their required fields (note: these symbols are are mine and in no way reflect the symbols of my employer ;-), or would you instead use a 'concatenation connector (+)' for all the connections, and use composite loci to associate the flags with their required field? 2) What would one expect to see from the compostite locus when the command line had been constructed? ----------------------------------------- - POVRAY 3.0 - ----------------------------------------- - o Config File _def.ini________________- - o Input File _my_povray_file.pov_____- - - ----------------------------------------- - Helpful message here - ----------------------------------------- ? 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 chapmanb at arches.uga.edu Mon Jan 31 09:27:37 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES Message-ID: <200001311430.JAA245752@archa11.cc.uga.edu> Thanks for writing, Jeff and Gary--I got lots o' questions/comments on this: Jeff wrote: >> >> > (1) Select processor ---> (1) Select container >> >> Lots o' questions on this: >> >> So a container holds 1. filesystems 2. databases and 3. all of the >> programs? > > Okay, ignoring databases for a while, think of a container as representing > any > one directory/folder in the filesystem. It's that simple. > > Then, 1 and 3 are the same, IF a container represents the directory / > > IF a container is set to represent /usr/bin, then it holds the programs in > /usr/bin and nothing else. I don't know about you, but if I look at my /usr/local/bin directory there are hundreds of programs there, all ordered in a non-useful alphabetical fashion. Jumbled in with the useful programs are a whole crapload of randomprogram-config programs which I never need to run, etc. I personally do not want to look through a list of all these programs just to run a program. Jeff wrote: >> Do you like the way things are divided up in modules now? Is this how >> you want things, or should there just be a big list of all the >> programs? > > Well, if containers are directories, then the user can sort loci however they > want. They just DnD a locus into a different container. EXACTLY like files > and folders in a Mac hard drive. I agree with this for files, but I don't see how this would work for programs, if we arejust finding them all in the /usr/bin directory. I would not expect users to add sub-directories to their /usr/bin, sort the programs by hand, and then adjust their PATH to move into all these directories. Or, would moving a program loci to a different container only create a link to that program in the filesystem, and it would look to loci like the program is actually in the new folder? Jeff wrote: > Now I see where you're getting confused. You're considering locus types > (processor, document, etc.) to be 'containers' of a sort, containing programs > of that type. But only loci of type 'container' are containers. The program > 'ls', for example, is a 'processor' type locus, but it doesn't _contain_ > anything. It _represents_ ls, and that's all. Okay, gotcha, only containers contain other loci! But then, why would you ever want to add a processor directly to the workspace, as opposed to dragging it out of a container? Should the default gui for a processor by a selection widget to choose the program it represents? Jeff wrote: > Okay, just think of it as pulling files and folders out of a Mac hard drive, > onto the Mac desktop. It's _exactly_ the same. EXACTLY. Yay, Mac! Jeff wrote: > So, now you're probably asking, 'What about the wrappers for seqManip? Where > do they go?' Well, my thoughts are that Loci will (1) identify the location > of the file, and (2) then check the 'wrappers' directory > (back.private.wrappers?) for a wrapper. (3) If no wrapper is found, then (4) > Loci uses a default wrapper based on file type (executables are processors, > etc.) or (5) tries to make its own (as you were doing with man file parsing > in middle.library.modules.wrap). Okay, so for 4, what would a default wrapper look like? Would it have flag options? Would it specify input and output files? I really think that the chances of being able to develop a "standard" wrapper that will work for many programs is very slim. For 5, please notice that I'm not automatically parsing man files, I made the one for ls by hand. I just don't want you to expect too much. Also, man files seem to be getting outdated, as more and more info on programs move to the web--it seems like this strategy will miss a lot of programs. What I am proposing is not to try and have a "catch all" mechanism to try and get every program, but instead to require an xml file for every program you want to run. If we are using Loci as an analogy to a web browser, I think of this xml files as analagous to an html page for the info you want to display. I don't really think that a gui interface to a program will work well at all without some information about a program. Otherwise, the gui interface is just as unintuitive as using the command line, and then, why use the gui interface? This is the way things work for appLab with their meta-data files. However, I think a big problem with AppLab is that there is no way to get one of these meta-data files for programs that have already been wrapped. To remedy this situtation, I think it would be relatively easy to have a repository of xml files written for programs available along with Loci, and some script that automatically installs them for the user. Then the user can download all of the xml files they want and automatically install them. Am I making any sense? Jeff wrote: >> > (4) Command is inside ---> (4) Command is on workspace >> > of composite >> >> So how do you envision the "constructing the command line" happening? >> Will this occur on the main workspace, or inside a separate workspace, >> like I've been doing? > > On the main workspace, simply by DnD-ing the needed loci onto the workspace, > and then connecting the dots/lines. Right, so instead of buttons, you would want the "control-panel" to have loci that can be drug onto the workspace? Or do you dislike the control panel idea? Also, I really think that when a new loci is added the lines should be automatically connected (the way it works in the current loci that I'm messing with). Most of the time the user will want them connected anyways, and it is a serious pain to connect them by hand because all of the lines are hidden under the gui. So you have to close the gui for both loci, connect the lines, and then re-open the gui. I'm really for automatic connecting. Jeff wrote: > First, a command-line would be represented on the workspace as a workflow > diagram (WFD). This means, of course, multiple loci connected via lines. > Now, this can be executed as it is (by running the main executable/processor > perhaps). This is just like what you have done _inside_ of a composite locus > windowlet, only it's on the _workspace_. Gary wrote: >1) Creating a new gui from a composited WFD. >Say you are constructing a command line with a switch that requires a >filename, regex, or some other field. How would you construct the WFD >such that the switch and the text-field become associated during the WFD >composition? Right on Gary, this was my first followup question--you must have read my mind. I spent a lot of time trying to figure out a way to try and do this if we construct the command line on the main workspace, and couldn't think of one. For instance, lets take Gary's example and make it even harder by adding an output file: loci>x-povray -I def.ini my_povray_file.pov the_output_file.txt And say that you wanted the two input files to come in from the previous loci, and the output file to be transferred to the next loci. I can't figure out a way to do this if everything is on the main workspace. That is why I was working inside an internal windowlet. If you look at the newest loci, I started to work on this by having a button in a file selection widget that is a link. The idea I was thinking about here is that the inputs and outputs into the main locus that holds the "internal" command line would be available in a selection type window when the user clicked on the "add locus link" button. When a particular input or output was associated with a segment of the command line, this information would be available in the little windowlet that will eventually be in each dot. This idea is one of the reasons why I went to an internal windowlet to build a command line. Jeff wrote: > But making a composite locus (single locus out of a WFD) is _not_ the same as > constructing the WFD. Making a composite means, for the workspace, making a > single locus out of a WFD, and that's all. Of course this also means the > GUI's become merged. Somehow, we'll just have the workspace 'zap' a whole > WFD and leave a single locus in its place. But what about 'zapping' just the command line for one program, instead of for the whole WFD. Or what if you want to "undo" a zapped program to make changes? It seems like this would be very programmatically difficult to do if everything is on the main workspace. Gary wrote: >2) What would one expect to see from the compostite locus when the >command line had been constructed? ----------------------------------------- - POVRAY 3.0 - ----------------------------------------- - o Config File _def.ini________________- - o Input File _my_povray_file.pov_____- - - ----------------------------------------- - Helpful message here - ----------------------------------------- What I was thinking about was just about what you showed, with the addition of a button/option to undo the construction. Thanks for writing--I am at the point where I can probably start implementing a lot of this stuff, so I'd like to make things in line with what you are thinking. Brad From bizzaro at geoserve.net Mon Jan 31 09:47:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] composited GUI's revisted, part 2 (was: excerpt from CHANGES) References: <200001301833.NAA64424@archa11.cc.uga.edu> <38950543.4230855B@geoserve.net> <389544EE.FE7048BD@redpoll.pharmacy.ualberta.ca> Message-ID: <3895A06A.A386281@geoserve.net> Thanks for reminding me that I didn't get to part 2. Gary Van Domselaar wrote: > > > Of course this also means the > > GUI's become merged. Somehow, we'll just have the workspace 'zap' a whole WFD > > and leave a single locus in its place. > > I have 2 questions about the 'zapping' part: > 1) Creating a new gui from a composited WFD. > Say you are constructing a command line with a switch that requires a > filename, regex, or some other field. How would you construct the WFD > such that the switch and the text-field become associated during the WFD > composition? Say, like, take for example a standard POVRAY command-line: > > loci>x-povray -Idef.ini my_povray_file.pov > > For the unitiated: -I requires the name of the povray config file > def.ini Should there be a space in there? -Idef.ini or -I def.ini > my_povray_file.pov is the input filename. Are you asking, 'How would -I be associated with def.ini?' > Using Jeff's method, would you create a WFD like this? (I'm shortening your table a little cuz it wraps after 80 cols.) Header Conn Option Conn Field Conn Field ----------------------------------------------------------- URI path + FLAG=-I -> ENTRY=def.ini + my_pov...pov LOCUS_ID DESC="Config File" DESC="Input File" LOCUS_NAME LOCUS DESCRIPTION Etc. > Using the concatenator symbol '+' to represent the concatenation of > 'unassociated' flags ...because it doesn't matter the order in which unassociated items are written? Okay. > and the 'association' > symbol (->) to associate the Flags with their required fields (note: > these symbols are are mine and in no way reflect the symbols of my > employer ;-) Hmmm. > or would you instead use a 'concatenation connector (+)' > for all the connections, and use composite loci to associate the flags > with their required field? It is THE ORDER IN WHICH THINGS ARE CONNECTED that determines the order of the command-line fields. Simple as that. I'm expecting the user/developer would put things in the right order. So, your povray command line... x-povray -I def.ini my_povray_file.pov Would be 4 loci connected like so: +-----------+ +------+ +----------+ +----------+ | processor | ---> | flag | ---> | filename | ---> | filename | +-----------+ +------+ +----------+ +--+----------+------+ | povray | | -I | | def.ini | | my_povray_file.pov | +-----------+ +------+ +----------+ +--------------------+ Notice the loci types used here: (1) processor (2) flag (3) filename and that I haven't put types flag and filename in Loci yet. We'll have to make them. THERE ARE MANY MORE TYPES TO BE DEFINED THAN WHAT I HAVE ALREADY DEFINED. So, Brad, maybe type 'option' can be split up into flag, filename, and...what else can go on the command-line? Regex? > 2) What would one expect to see from the compostite locus when the > command line had been constructed? > > ----------------------------------------- > - POVRAY 3.0 - > ----------------------------------------- > - o Config File _def.ini________________- > - o Input File _my_povray_file.pov_____- > - - > ----------------------------------------- > - Helpful message here - > ----------------------------------------- Okay, note that the underscore ____ used to surround option names means that there is an edit box there, or a way to make a selection. Now, *IF* all options were changeable, you'd have something like this: (COMPOSITE GUI!!!) +---------------------------------------+ | PROCESSOR | (processor name supercedes others) +---------------------------------------+ | | | o Executable _x-povray______________ | | o Flag _-I____________________ | | o Filename _def.ini_______________ | | o Filename _my_povray_file.pov____ | | o Message _Povray is cool________ | | | | [Execute] | +---------------------------------------+ But, *IF* none of the options were changeable, you'd have something like this (COMPOSITE GUI!!!) +---------------------------------------+ | x-povray | (name is now set) +---------------------------------------+ | | | o Executable x-povray | | o Flag -I | | o Filename def.ini | | o Filename my_povray_file.pov | | | | [Execute] | +---------------------------------------+ | Povray is cool | (message is now set) +---------------------------------------+ Notice the edit boxes are gone. The names of options are now simply text labels. But I think we should also be able to hide the labels, for simplicity: (COMPOSITE GUI!!!) +-------------------+ | x-povray | +-------------------+ | [Execute] | +-------------------+ | Povray is cool | +-------------------+ Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jan 31 10:54:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:10 2006 Subject: [Pipet Devel] excerpt from CHANGES References: <200001311430.JAA245752@archa11.cc.uga.edu> Message-ID: <3895B052.5877A983@geoserve.net> Brad Chapman wrote: > > Thanks for writing, Jeff and Gary--I got lots o' questions/comments on > this: I just sent a reply to Gary's message. Maybe that will answer some of your questions here. But I'll continue... > I don't know about you, but if I look at my /usr/local/bin directory > there are hundreds of programs there, all ordered in a non-useful > alphabetical fashion. Jumbled in with the useful programs are a whole > crapload of randomprogram-config programs which I never need to run, > etc. I personally do not want to look through a list of all these > programs just to run a program. Well, I was using /usr/bin as an example. As I mentioned in that message, the default (root level) directories (and thus containers) are... * loci/back/public/container/ * loci/back/private/container/ Of course, for security we can't have a container for /usr/bin. Using our restricted sandbox directories is a lot like what some other apps are using. Sendmail, for example, now has its own bin directory AND its own shell. > > Well, if containers are directories, then the user can sort loci > > however they want. They just DnD a locus into a different > > container. EXACTLY like files and folders in a Mac hard drive. > > I agree with this for files, but I don't see how this would work for > programs, if we arejust finding them all in the /usr/bin directory. I > would not expect users to add sub-directories to their /usr/bin, sort > the programs by hand, and then adjust their PATH to move into all > these directories. Or, would moving a program loci to a different > container only create a link to that program in the filesystem, and it > would look to loci like the program is actually in the new folder? Again, we're not going to use /usr/bin. Sorry about that confusion. But how a user will 'import' a program from /usr/bin (or wherever) into our sandbox directories, is a good question. I think it would be best for the sysadmin to _manually_ create symlinks from /usr/bin/progname to the sandboxes. Maybe later we can work on a more automatic 'import' method. > > 'ls', for example, is a 'processor' type locus, but it doesn't > > _contain_ anything. It _represents_ ls, and that's all. > > Okay, gotcha, only containers contain other loci! But then, why would > you ever want to add a processor directly to the workspace, as opposed > to dragging it out of a container? Just to 'work with it' more easily. Hence the name 'workspace' :-) But, yeah, in the Loci model, the loci (wrapper and all) stay put...in their original 'location'. Only the _representation_ (XML!) is dragged to the workspace. Get it? :-) > Should the default gui for a > processor by a selection widget to choose the program it represents? Should the default gui for a processor _have_ a selection widget to choose the program it represents? We're talking about a 'blank processor' (program name never selected), right? Ummm. I was thinking about just having a edit box where the user/developer can type in the program name. Remember, for command-line construction, we're just adding strings: command_name = 'ls' flag_name = '-l' file_name = '*' command = executable_name + flag_name + file_name print command >>> ls -l * :-) > > So, now you're probably asking, 'What about the wrappers for > > seqManip? Where do they go?' Well, my thoughts are that Loci > > will (1) identify the location of the file, and (2) then check > > the 'wrappers' directory (back.private.wrappers?) for a wrapper. > > (3) If no wrapper is found, then (4) Loci uses a default wrapper > > based on file type (executables are processors, etc.) or (5) > > tries to make its own (as you were doing with man file parsing > > in middle.library.modules.wrap). > > Okay, so for 4, what would a default wrapper look like? Would it have > flag options? No. A 'flag' type locus is added by the user, to the workspace, and then the lines are connected. Tada! You now have processor + flag. > Would it specify input and output files? Regarding I/O, that should be done via connecting lines and keeping everything on the workspace. Now that you mention it, the 'filename' type that I mentioned IS the 'document' type :-P I forgot about that. ***Okay, nix what I said in the last message about typing in filename. Connecting a document to the command-line that is under construction, is how filenames should be determined. Loci will have to supply the command-line with the actual location of the file, if it can't be piped in. So... grep 'hello' myfile.txt should be constructed from this WFD: +------------+ +-----------+ +-------+ | document | ---> | processor | ---> | regex | +------------+ +-----------+ +-------+ | myfile.txt | | grep | | hello | +------------+ +-----------+ +-------+ which should be interpreted by Loci as... cat myfile.txt | grep 'hello' But let's say grep can't take pipes or work from stdin. Then Loci would have to interpret the same WFD as... grep 'hello' myfile.txt and IF myfile.txt were not in our sandbox directories, Loci would have to get it from its locale, save it in a temporary file and do... grep 'hello' /home/jdoe/loci/middle/temp/tempfile372873 > I really think > that the chances of being able to develop a "standard" wrapper that > will work for many programs is very slim. Oh no, it's quite simple. All I'm thinking about for an 'unknown executable' is a processor that spits out the _name_ of the executable. You've got a symlink to povray in your sandbox directory; Loci doesn't know povray from jack; Loci says, 'Eh, just spit the name povray out on the command-line'. That's all. The user/developer can then work on defining it better later on. > For 5, please notice that I'm not automatically parsing man files, I > made the one for ls by hand. I just don't want you to expect too much. Yeah, I realize that was a suggestion I made based on an assumption that it was easy to do. > Also, man files seem to be getting outdated, as more and more info on > programs move to the web--it seems like this strategy will miss a lot > of programs. Hmmm. True. > What I am proposing is not to try and have a "catch all" mechanism to > try and get every program, but instead to require an xml file for > every program you want to run. If we are using Loci as an analogy to a > web browser, I think of this xml files as analagous to an html page > for the info you want to display. I don't really think that a gui > interface to a program will work well at all without some information > about a program. Otherwise, the gui interface is just as unintuitive > as using the command line, and then, why use the gui interface? Yes, but the experienced user/developer can _construct_ WFD's and _composite_ them, making something simple for the inexperienced user/nondeveloper. I want Loci to be able to accommodate _both_ types of users. When I started designing Loci, I thought we'd have two main programs: (1) the workspace and (2) an interactive development environment (IDE). But then I realized that most IDE's and most programming languages organized information into 'connectivity trees' (WFD's), which is what the workspace was supposed to be good at doing. So, SHAZAAM, the workspace took on the responsibility of also being an IDE and a programming language. And the concept of 'compositing' loci/WFD's made this possible by hiding the complexity of the low-level stuff. > This is the way things work for appLab with their meta-data files. XML files, sure! But they start out simple, are then built up via WFD construction and composting, and then end up large and descriptive. > However, I think a big problem with AppLab is that there is no way to > get one of these meta-data files for programs that have already been > wrapped. To remedy this situtation, I think it would be relatively > easy to have a repository of xml files written for programs available > along with Loci, Yeah, but the idea behind Loci is that this repository can be anywhere on the Internet. > and some script that automatically installs them for > the user. Simply open a container pointing to the remote filesystem, and get what you need. > Then the user can download all of the xml files they want > and automatically install them. > Am I making any sense? Yes, automagic retrieval of XML representations is a major, fundamental design feature of Loci. (I'll continue this in another 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 Mon Jan 31 12:13:25 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:11 2006 Subject: [Pipet Devel] excerpt from CHANGES References: <200001311430.JAA245752@archa11.cc.uga.edu> Message-ID: <3895C2B5.16A38BAB@geoserve.net> (continuation) > > On the main workspace, simply by DnD-ing the needed loci onto the > > workspace, and then connecting the dots/lines. > > Right, so instead of buttons, you would want the "control-panel" to > have loci that can be drug onto the workspace? *gasp* :-) ONLY CONTAINERS CONTAIN LOCI ;-) > Or do you dislike the control panel idea? I like the idea of having some tutorial/help mechanism for teaching inexperienced users/wannabe-developers how to construct the command-line, which is what I see your control panel as being. But I think it may be a year before we should worry about it. > Also, I really think that when a new loci is added Added == dropped onto the workspace? > the lines should > be automatically connected (the way it works in the current loci that > I'm messing with). Most of the time the user will want them connected > anyways, and it is a serious pain to connect them by hand because all > of the lines are hidden under the gui. So you have to close the gui > for both loci, connect the lines, and then re-open the gui. I'm really > for automatic connecting. But this idea is based on your earlier plan for having every program be well defined about the required options. It's a different plan from my own, as I have been saying. I would argue that the effort needed to define a locus your way is equivalent to just going ahead and connecting all the critters. So, yeah, why bother with user-specified connections at all??? Or using more than one locus??? But I'm saying that the user is/can be the developer who (XML) defines a locus, ON THE WORKSPACE. The workspace is an IDE! :-) > >1) Creating a new gui from a composited WFD. > >Say you are constructing a command line with a switch that requires a > >filename, regex, or some other field. How would you construct the WFD > >such that the switch and the text-field become associated during the > >WFD composition? > > Right on Gary, this was my first followup question--you must have read > my mind. I spent a lot of time trying to figure out a way to try and > do this if we construct the command line on the main workspace, and > couldn't think of one. Again, per my reply to Gary, the experienced user/developer determines the order of command-line options via the order of command-line locus connections. > For instance, lets take Gary's example and make > it even harder by adding an output file: > > loci>x-povray -I def.ini my_povray_file.pov the_output_file.txt > > And say that you wanted the two input files to come in from the > previous loci, and the output file to be transferred to the next loci. Well, there is some confusion about the difference between 'pipe connectors' and 'string adding connectors'. To clear up this confusion, the user/developer might want to composite the command-line based on 'string adding' connectors': *** NOW LET'S RE-INTRODUCE THE FILENAME TYPE LOCUS (sorry about that) (Because my drawing space is limited, and because it may get a little hard to read, I won't produce the example with an output file.) ---->(1)+----------+ ---->(2)| x-povray | +------------------------------------------------------------------+ | | | | | (workspace) \|/ \|/ | | (1) (2) | |+-----------+ +------+ +---------+ +---------+ | || processor | ---> | flag | -----> | infile | -----> | infile | | |+-----------+ +------+ +---------+ +---------+ | || x-povray | | -I | | |+-----------+ +------+ | +------------------------------------------------------------------+ Each 'infile' type locus has 2 connectors: one is 'string adding' (unlabeled) and the other is piping (labeled 1 and 2). Both piping (1 and 2) connectors are disconnected. So, they appear on the composite locus: +----------+ ---->(1)| x-povray | ---->(2)+----------+ (windowlet closed) Now, connect the documents to the respectively numbered input connector, and Da-ta-ta-da!!! +------------+ +-----------+ | document | ---->(1)| x-povray | +------------+ >(2)+-----------+ | def.ini | / +------------+ / / +------------+ | document | +---+------------+---+ | my_povray_file.pov | +--------------------+ Oooo, that's so nice!!! This would tell Loci to take the contents of the documents, put them into temporary files, then construct the command-line as follows: x-povray -I /path/to/temp.def.ini /path/to/temp.my_povray_file.pov > I can't figure out a way to do this if everything is on the main > workspace. That is why I was working inside an internal windowlet. Okay, so you may want to use a composite, as I show above. But, there is no reason why you can't make connections (1) and (2) directly. > If > you look at the newest loci, I started to work on this by having a > button in a file selection widget that is a link. The idea I was > thinking about here is that the inputs and outputs into the main locus > that holds the "internal" command line would be available in a > selection type window when the user clicked on the "add locus link" > button. When a particular input or output was associated with a > segment of the command line, this information would be available in > the little windowlet that will eventually be in each dot. Hmmm. I think I know what you're talking about, but I'm not sure. > > GUI's become merged. Somehow, we'll just have the workspace 'zap' a > > whole WFD and leave a single locus in its place. > > But what about 'zapping' just the command line for one program, > instead of for the whole WFD. I meant the WFD for the command-line; a small WFD with just the command-line loci, like above. > Or what if you want to "undo" a zapped > program to make changes? It seems like this would be very > programmatically difficult to do if everything is on the main > workspace. I just need to make a couple routines for adding and deleting icons with their windowlets. 'Unzapping' (or uncompositing or decomposing) a composite should just require the WFD _inside_ the composite's windowlet (workspace in a workspace) be copied to the main workspace. > ----------------------------------------- > - POVRAY 3.0 - > ----------------------------------------- > - o Config File _def.ini________________- > - o Input File _my_povray_file.pov_____- > - - > ----------------------------------------- > - Helpful message here - > ----------------------------------------- > > What I was thinking about was just about what you showed, with the > addition of a button/option to undo the construction. I think a compose/decompose option could be put in the locus's pop-up menu. > Thanks for writing--I am at the point where I can probably > start implementing a lot of this stuff, so I'd like to make things in > line with what you are thinking. Thank you, Brad, for being so understanding and patient. You can blame me for not explaining things well enough. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Jan 31 12:32:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:11 2006 Subject: [Pipet Devel] :-) References: <200001311430.JAA245752@archa11.cc.uga.edu> <3895B052.5877A983@geoserve.net> Message-ID: <3895C74A.9DBAC519@geoserve.net> "J.W. Bizzaro" wrote: > > XML files, sure! But they start out simple, are then built up via WFD > construction and composting, and then end up large and descriptive. ^^^ It's funny what the omission of a letter will do: First, check the oder of what you made. The next step is composting. || \/ First, check the order of what you made. The next step is compositing. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | THE OPEN LAB | | Open Source Bioinformatics | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu Jan 6 01:19:25 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:20:20 2006 Subject: [Pipet Devel] XML-RPC References: <87ituce4n1.fsf@alpha.cfas.washington.edu> <396B9D4D.38B8458F@geoserve.net> <878zv8e0mk.fsf@alpha.cfas.washington.edu> <396BB0A7.D22450E4@geoserve.net> Message-ID: <387433ED.735C2882@casema.net> "J.W. Bizzaro" wrote: > "A.J. Rossini" wrote: > > > > JWB> From discussions we've had, it > > JWB> seems CORBA is superior in terms of speed and security. > > > > Agreed, in a sense (speed, yes; security, depends and is extremely > > contextual, so let's not go down that route...). > > I'm not an expert on any of the models. I am simply relying on what others > here tell me. Jarl has made favorable comments regarding CORBA's security > model. Also, regarding XML-RPC, SOAP and .NET (which, it appears, are now > related), I have HEARD that the intention is to run them through HTTP in order > to bypass firewalls. These are the reasons why I said CORBA is "superior" > (bad choice of words -- it tends to cause more flame wars). Just a small note on 'corba & security' : I didn't say corba is secure, I said we need a security mechanism, implemented by corba. But the actual security has nothing to do with corba. Corba just gives the option to do thing right. bye, jarl