From jeff at bioinformatics.org Thu Nov 2 17:47:25 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:36 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration Message-ID: <3A01EEFD.DD42746B@bioinformatics.org> This may be somewhat relevant, as we need a way to "describe, discover, and integrate" Piper services: http://www.uddi.org/ Jeff From jeff at bioinformatics.org Thu Nov 2 17:50:57 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:36 2006 Subject: [Pipet Devel] piper mention Message-ID: <3A01EFD1.82C076F3@bioinformatics.org> Piper was mentioned in a Linux Gazette article about our friends at Narval: http://www.linuxgazette.com/issue59/chauvat.html Jeff From jeff at bioinformatics.org Thu Nov 2 18:00:29 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:36 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: <3A01EEFD.DD42746B@bioinformatics.org> Message-ID: <3A01F20D.F56E4DF9@bioinformatics.org> "J.W. Bizzaro" wrote: > > This may be somewhat relevant, as we need a way to "describe, discover, and > integrate" Piper services: Ooops. We know how to describe and integrate :-) Discovery, which will require directory services of some sort, is still kind of fuzzy to me. I've been thinking along the line of how one searches Gnutella, as it is a similar P2P system. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Thu Nov 2 18:33:05 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:36 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: <3A01EEFD.DD42746B@bioinformatics.org> <3A01F20D.F56E4DF9@bioinformatics.org> Message-ID: <3A01F9B1.B868C092@casema.net> > > > Ooops. We know how to describe and integrate :-) Discovery, which will > require directory services of some sort, is still kind of fuzzy to me. I've > been thinking along the line of how one searches Gnutella, as it is a similar > P2P system. Some time ago we agreed upon building a central registration server (on bioinformatics.org at first). I think this will solve the discovery problem as long as Piper remains unpopular. Once many people use Piper we'll be screwed. Avoid too much advertising please ;) If we were to build something beyond this limitation, we need a complex piece of software called a hiarchial cache. Like squid can do. There are solutions to the discovery prob., but they wont be easy. I have something else that worries me more, let's keep up the atmosphere and call it the pattern problem. It's about how to represent the executables. How will we layout the XML that describes the applications? I know we can stream stdout and stdin data, we can build many 'templates' for a N number of applications, but this will die a very chaotic death I'm afraid. I myself dont know what the best approach is to this XML patterning Piper will use. I'm very much interested in your comment. bye, jarl From Nicolas.Chauvat at logilab.fr Fri Nov 3 05:15:11 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Fri Feb 10 19:20:36 2006 Subject: [Pipet Devel] piper mention In-Reply-To: <3A01EFD1.82C076F3@bioinformatics.org> Message-ID: On Thu, 2 Nov 2000, J.W. Bizzaro wrote: > Piper was mentioned in a Linux Gazette article about our friends at Narval: > > http://www.linuxgazette.com/issue59/chauvat.html That's because we like what you're doing :-) -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From jarl at casema.net Fri Nov 3 09:40:19 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: <3A01EEFD.DD42746B@bioinformatics.org> <3A01F20D.F56E4DF9@bioinformatics.org> <3A01F9B1.B868C092@casema.net> Message-ID: <3A02CE52.4CBDDF44@casema.net> > > I have something else that worries me more, let's keep up the atmosphere and > call it the pattern problem. It's about how to represent the executables. How > will > we layout the XML that describes the applications? I know we can stream > stdout and stdin data, we can build many 'templates' for a N number of > applications, but this will die a very chaotic death I'm afraid. I myself dont > know > what the best approach is to this XML patterning Piper will use. I'm very much > interested in your comment. > Not that much reply, so maybe this clears things up: http://www.cs.wustl.edu/~schmidt/patterns.html bye, jarl From jeff at bioinformatics.org Fri Nov 3 19:05:21 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: <3A01EEFD.DD42746B@bioinformatics.org> <3A01F20D.F56E4DF9@bioinformatics.org> <3A01F9B1.B868C092@casema.net> <3A02CE52.4CBDDF44@casema.net> Message-ID: <3A0352C1.FB9BE6C3@bioinformatics.org> I can hear the crickets chirping. Chirp, chirp, chirp. Can anyone provide a comment for Jarl? Cheers. Jeff jarl van katwijk wrote: > > > I have something else that worries me more, let's keep up the atmosphere and > > call it the pattern problem. It's about how to represent the executables. How > > will > > we layout the XML that describes the applications? I know we can stream > > stdout and stdin data, we can build many 'templates' for a N number of > > applications, but this will die a very chaotic death I'm afraid. I myself dont > > know > > what the best approach is to this XML patterning Piper will use. I'm very much > > interested in your comment. > > > > Not that much reply, so maybe this clears things > up: http://www.cs.wustl.edu/~schmidt/patterns.html -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From SCoffman at CBSINC.com Mon Nov 6 12:17:24 2000 From: SCoffman at CBSINC.com (COFFMAN Steven) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration Message-ID: Jarl, I didn't speak up, because I'm still not clear what you mean. You're concerned that there is no standard schema for the XML of the input and output of individual applications (or components)? What does that have to do with software engineering design patterns? Design patterns are more abstract than data formats. -Steve -----Original Message----- From: J.W. Bizzaro [mailto:jeff@bioinformatics.org] Sent: Friday, November 03, 2000 7:05 PM To: pipet-devel@bioinformatics.org Subject: Re: [Pipet Devel] Universal Description, Discovery, and Integration I can hear the crickets chirping. Chirp, chirp, chirp. Can anyone provide a comment for Jarl? Cheers. Jeff jarl van katwijk wrote: > > > I have something else that worries me more, let's keep up the atmosphere and > > call it the pattern problem. It's about how to represent the executables. How > > will > > we layout the XML that describes the applications? I know we can stream > > stdout and stdin data, we can build many 'templates' for a N number of > > applications, but this will die a very chaotic death I'm afraid. I myself dont > > know > > what the best approach is to this XML patterning Piper will use. I'm very much > > interested in your comment. > > > > Not that much reply, so maybe this clears things > up: http://www.cs.wustl.edu/~schmidt/patterns.html -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- _______________________________________________ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel From jarl at casema.net Mon Nov 6 13:14:31 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: Message-ID: <3A06F507.3E9F3682@casema.net> > Jarl, I didn't speak up, because I'm still not clear what you mean. > > You're concerned that there is no standard schema for the XML of the input > and output of individual applications (or components)? What does that have > to do with software engineering design patterns? Design patterns are more > abstract than data formats. > I'm not saying we should use design patterns for describing in\output of applications that are executed by Piper, but I've the feeling we can make use of the technology. Both situations are very close: a pattern that describes a modules of a legacy system so that the module can be re-used in an other system without loosing the functionality is very close to describing an application that will be used in a distributed environment. You talk about abstraction, which to me is the clue to a proper XML scheme for application description. Piper needs to have the applications described beyond their legacy functionality. Like the way UML does abstracts data. But we need something for functionality, instead of data. Sorry I'm not very clear, but this is simply because I hardly know how to tackle this problem. bye, jarl From Alexandre.Fayolle at logilab.fr Mon Nov 6 13:32:51 2000 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration In-Reply-To: <3A01F9B1.B868C092@casema.net> Message-ID: On Fri, 3 Nov 2000, jarl van katwijk wrote: > I have something else that worries me more, let's keep up the atmosphere and > call it the pattern problem. It's about how to represent the executables. How > will > we layout the XML that describes the applications? I know we can stream > stdout and stdin data, we can build many 'templates' for a N number of > applications, but this will die a very chaotic death I'm afraid. I myself dont > know > what the best approach is to this XML patterning Piper will use. I'm very much > interested in your comment. Hello, Maybe you could give a glance at what we have for Narval. I don't think it will apply to your architecture, but it may give you ideas... To sum it up, I think what best applies to your problem is Narval's concept of an action. An action has two parts: and XML prototype and a python stub which will implement the action (or act as a proxy to the Real Thing). The prototype can be viewed as a contract, that is: the action garantees that if it is given the input it requires, it will return the output specified in the prototype (otherwise, it's an error). The DTD for an action is the following: The name attribute is what you expect, the func attribute is the name of the python stub (with the packages prefixed). Mostly GUI stuff. This describes an Input: if the input in set optional, the action will be run event if no matching elements are found. If the list attribute is set to 'yes', then several matching elements can be passed to the action, and if use is 'yes', an element will not be used twice for this action in two consecutive executions of the recipe. For outputs, specifying optional='yes' will not cause an error if no matching element can be found in the output of the action. The match element really is an XPath. An input (or output) can have several match children, and an element must match all the XPaths in order to be considered valid as an input (or as an output). Cheers. Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From chapmanb at arches.uga.edu Mon Nov 6 17:57:59 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration In-Reply-To: References: <3A01F9B1.B868C092@casema.net> Message-ID: <14855.14199.668216.967010@taxus.athen1.ga.home.com> Jarl: > > I have something else that worries me more, let's keep up the > > atmosphere and call it the pattern problem. It's about how to > > represent the executables. How will > > we layout the XML that describes the applications? Alexandre: > Maybe you could give a glance at what we have for Narval. I don't think it > will apply to your architecture, but it may give you ideas... [very nice description of Narval's way of describing actions/nodes] Jarl, what we have been using so far for describing actions in Piper is a combination of what we had in Loci combined together with the way Overflow handled things. Basically, this is also very similar to the way things are done in Narval. I wrote some documentation (now out of date, of course) about how this works, which can be found at: http://www.bioinformatics.org/piper/documentation/piper_plugin.pdf Although this is not really accurate with how things are currently (mostly we changed from using the name locus to describe an action to using the name NodeClass), it gives the general picture of how things works. The current DTD, with all of the current correct information, can be found in cvs in dtd/locusPlugin.dtd. Basically, a NodeClass (which seems analagous to a Narval action) has inputs and outputs, which look like: o The type attribute specifies, as the name suggests, the type of input that is represented. This is kind of a quick-n-dirty way of verifying inputs and outputs match up, and is borrowed from the way overflow works. I admit this is not ideal, but was at least a starting point to work from. o The xlink will point to the output that the input gets linked to. o The expand attribute, if set to yes, will allow an Input to be "duplicated" within a Node, so that you could have an input that could take an arbitrary number of connectors (this seems analagous, in spirit, to Narval's list attribute). o The opt attribute describes whether or not the input has to be set for the Node to work properly. Piper also has an additional Parameter attribute, which I didn't see an analogue of in Narval. This looks similar to an input or output: The idea of Parameters are "borrowed" from the UNIX command line, so that Parameters are supposed to be like command line options. So inputs and outputs describe the information that passes in and out of a Node, and the parameters can affect how the Node processes the inputs to produce the outputs. I hope this is the kind of answer you were looking for and helps some... My apologies it took me so long to write on this. Brad From jeff at bioinformatics.org Mon Nov 6 19:04:00 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: <3A01F9B1.B868C092@casema.net> <14855.14199.668216.967010@taxus.athen1.ga.home.com> Message-ID: <3A0746F0.FDE86A81@bioinformatics.org> Brad Chapman wrote: > > The idea of Parameters are "borrowed" from the UNIX command line, so > that Parameters are supposed to be like command line options. So > inputs and outputs describe the information that passes in and out of > a Node, and the parameters can affect how the Node processes the > inputs to produce the outputs. This is because Piper draws very strongly from the UNIX paradigm, and it should continue to do so in any new features. Not very helpful, but it's my $0.02 on the subject :-) Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From Nicolas.Chauvat at logilab.fr Tue Nov 7 04:51:53 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration In-Reply-To: <3A0746F0.FDE86A81@bioinformatics.org> Message-ID: > > The idea of Parameters are "borrowed" from the UNIX command line, so > > that Parameters are supposed to be like command line options. So > > inputs and outputs describe the information that passes in and out of > > a Node, and the parameters can affect how the Node processes the > > inputs to produce the outputs. > > This is because Piper draws very strongly from the UNIX paradigm, and it > should continue to do so in any new features. Not very helpful, but it's my > $0.02 on the subject :-) A guy at work with whom I was discussing the idea of a graphical shell used to call that the standard control stream (stdctrl for short). That offers a nice symetry: stdin/stdout, stdctrl/stderr. I've been looking for a killer application (i.e. really good use case) of the dynamic standard control since then, but haven't found it yet (it quickly gets quite complex if you allow it to change during the processing of the stream). It shallows somewhere in Narval's design, but you have to know it's there to spot it. My opinion is that piper should use it for static parameters and keep it in long enough for the good idea to show up by itself. If you're interested in software composition in general, it may worth it to have a look at CHAIMS (http://www-db.stanford.edu/CHAIMS/) and it's concept of "Megaprogramming" (funny name isn't it :-) -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From jarl at casema.net Tue Nov 7 09:01:42 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration References: <3A01F9B1.B868C092@casema.net> <14855.14199.668216.967010@taxus.athen1.ga.home.com> Message-ID: <3A080B46.15392D5D@casema.net> Brad Chapman wrote: > I wrote some documentation (now out of date, of course) about how this > works, which can be found at: > > http://www.bioinformatics.org/piper/documentation/piper_plugin.pdf You could have spared yourself a lengthy email and just gave me this link Brad :) This is what I understand of Alexandre's and Brad's e-mail about Narval's and Piper's pattern to describe 'applications': both methods are more or less the same in the aspect of both focussing on the application as a unix user in a shell would do. The name, input and output are well handled. I will wait for this to become more detailed once we can do some testing, and as Jeff said: we should not touch the stdin\out. But at the same time I see some critical issues missing, which are noticed by Brad and documented by some ?'s. The first is 'environment description'. By this I mean things like path (-relocation), dependencies and local issues (like hardware dependent stuff). The 2nd is about errors. I think Piper needs some basic form of exception handling, this can be just a simple retry of node execution. Maybe the PL already has something like this build in. (JeanMarc?). The 3th is event handling. Many applications only make sense to execute when there an special situation. Anybody has thoughts about these three points I feel missing? bye, jarl From Alexandre.Fayolle at logilab.fr Tue Nov 7 09:27:21 2000 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Universal Description, Discovery, and Integration In-Reply-To: <3A080B46.15392D5D@casema.net> Message-ID: On Tue, 7 Nov 2000, jarl van katwijk wrote: > The 2nd is about errors. I think Piper needs some basic form of exception > handling, > this can be just a simple retry of node execution. Maybe the PL already has > something > like this build in. (JeanMarc?). The 3th is event handling. Many applications > only make > sense to execute when there an special situation. > > Anybody has thoughts about these three points I feel missing? For the last two points, here's what we have in Narval: * error handling: an action can output an error element, even if it is not in its prototype. In that case, Narval checks for a special transition in the step's outgoing transitions, with the onError attribute set to 'yes'. If the conditions of this transition can be matched immediately, it is fired and the execution of the plan resumes from that point. Otherwise (or if no onError transitions are found), the plan fails. This error handling behaviour can only occur if the action returned an element, and not if the action raised an exception or if its outputs did not match the prototype: these cases cause the plan to fail. * events: Well, the whole point of having transitions is handling events. Many recipes in Narval will begin with a Basic.NOP action (which does nothing), followed by a transition that will wait for an element to be present in memory, or for a time condition to be matched. This makes it easy to have specialized recipes work in team. For instance, if you consider the Gazo recipe that's described in the Linux Gazette, you'll notice that it doesn't actually read the mail: another recipe does that, and produces elements, which in turn are captured by Gazo. We could have many other recipes working simultaneously on these elements. This feature enables us to use Narval as if we had a rule-based language. Cheers, Alexandre Fayolle -- http://www.logilab.org Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From jarl at casema.net Thu Nov 9 09:02:28 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] BL status References: Message-ID: <3A0AAE74.C8377A6D@casema.net> HI All, I want to to share this good news with me: I got Overflow running Helloworld under GMS. In other words: the PL is executing something the BL wants it to. Now I still need to separate both (the BL-BBL-PL construction), which is done for 50% already. I also expanded the autoconf\make stuff so that it builds everything, and I made skeleton sources\modules for the DL connectivity. Bring on the champagne! :) -- cut -- Message: Piper BL 0.4.0pre9 Loading plugin /usr/local/lib/libplugin_sensor_DL.so... OK. Loading plugin /usr/local/lib/libplugin_sensor_PL.so... OK. Loading plugin /usr/local/lib/libplugin_sensor_localhost.so... OK. Loading plugin /usr/local/lib/libplugin_sensor_syslogd.so... OK. Loading plugin /usr/local/lib/libplugin_visual_DL.so... OK. Loading plugin /usr/local/lib/libplugin_visual_PL.so... OK. Loading plugin /usr/local/lib/libplugin_visual_devel.so... OK. Loading plugin /usr/local/lib/libplugin_visual_festival.so... OK. Loading plugin /usr/local/lib/libplugin_visual_localhost.so... OK. Loading plugin /usr/local/lib/libplugin_visual_statusbar.so... OK. Loading configuration REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. activating DL plugin sensor Activated DL sensor activating PL plugin sensor activating Localhost plugin sensor activating Syslogd plugin sensor activating visual DL MO activating visual PL MO activating visual SCRATCH MO activating visual Festival MO activating visual LOCALHOST MO Saving DFP status file UIDocument::build UINetwork::build netname = MAIN building node node1 adding node node1 0x818cc10 nodes built links built collector built before ::build exceptions after ::build exceptions Hello World! -- cut -- Note that the REDEFINE conflict's are normal. The strange thing I'm working on at the moment is that running the BL goes fine, but running it under gdb (a debugger) results in a crash.. (??). bye, jarl From jarl at casema.net Thu Nov 9 11:44:57 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] BL status - Update References: <3A0AAE74.C8377A6D@casema.net> Message-ID: <3A0AD489.E025AE59@casema.net> > Now I still need to separate both (the BL-BBL-PL construction), which is done for > 50% already. Done! I'll do some cleaning up and put the sources into cvs tonight\tomorrow.. after which you all are invited to do some testing ;) bye, jarl From bizzaro at mercury.capeonramp.com Thu Nov 9 13:01:22 2000 From: bizzaro at mercury.capeonramp.com (bizzaro) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] BL status - Update Message-ID: <200011091301.AA146407662@mercury.capeonramp.com> Most excellent, Dude! Now I need to commit some of my Pied changes, and we can release the long-awated 0.0.2. Any suggestions for the release name? I propose "Gates of Dawn" Cheers. Jeff ---------- Original Message ---------------------------------- From: jarl van katwijk Reply-To: pipet-devel@bioinformatics.org Date: Thu, 09 Nov 2000 17:44:57 +0100 >> Now I still need to separate both (the BL-BBL-PL construction), which is done for >> 50% already. > >Done! I'll do some cleaning up and put the sources into cvs tonight\tomorrow.. after >which you all are invited to do some testing ;) > >bye, >jarl From SCoffman at CBSINC.com Thu Nov 9 13:20:17 2000 From: SCoffman at CBSINC.com (COFFMAN Steven) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] BL status - Update Message-ID: What does Bill Gates have to do with this? :) "Gates of Dawn" would be neat. Then the next release could be something cool like "Dawn Crusher". I've always been fond of the rarely seen "Elucubration" (comes from latin meaning to work until dawn). If I could work that into mainstream culture, I'd be a happy guy. My Mom's an english teacher. :) -Steve -----Original Message----- From: bizzaro [mailto:bizzaro@mercury.capeonramp.com] Sent: Thursday, November 09, 2000 1:01 PM To: pipet-devel@bioinformatics.org Subject: Re: [Pipet Devel] BL status - Update Most excellent, Dude! Now I need to commit some of my Pied changes, and we can release the long-awated 0.0.2. Any suggestions for the release name? I propose "Gates of Dawn" Cheers. Jeff ---------- Original Message ---------------------------------- From: jarl van katwijk Reply-To: pipet-devel@bioinformatics.org Date: Thu, 09 Nov 2000 17:44:57 +0100 >> Now I still need to separate both (the BL-BBL-PL construction), which is done for >> 50% already. > >Done! I'll do some cleaning up and put the sources into cvs tonight\tomorrow.. after >which you all are invited to do some testing ;) > >bye, >jarl _______________________________________________ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel From Alexandre.Fayolle at logilab.fr Thu Nov 9 13:27:07 2000 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] BL status - Update In-Reply-To: Message-ID: On Thu, 9 Nov 2000, COFFMAN Steven wrote: > I've always been fond of the rarely seen "Elucubration" (comes from latin > meaning to work until dawn). If I could work that into mainstream culture, > I'd be a happy guy. You might be interested to know that in French, 'elucubration' is a well known word, which means 'wild imaginings', with pejorative connotation (according to my Robert & Collins dictionnary). Alexandre Fayolle -- http://www.logilab.com Narval is the first software agent available as free software (GPL). LOGILAB, Paris (France). From jarl at casema.net Thu Nov 9 16:07:11 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] BL status - Update References: Message-ID: <3A0B11FE.F56E3209@casema.net> > What does Bill Gates have to do with this? :) "Gates of Dawn" would be neat. > Then the next release could be something cool like "Dawn Crusher". > > I've always been fond of the rarely seen "Elucubration" (comes from latin > meaning to work until dawn). If I could work that into mainstream culture, > I'd be a happy guy. > > My Mom's an english teacher. :) > -Steve > -----Original Message----- > From: bizzaro [mailto:bizzaro@mercury.capeonramp.com] > Sent: Thursday, November 09, 2000 1:01 PM > To: pipet-devel@bioinformatics.org > Subject: Re: [Pipet Devel] BL status - Update > > Most excellent, Dude! Now I need to commit some of my Pied changes, and we > can release the long-awated 0.0.2. Any suggestions for the release name? I > propose > > "Gates of Dawn" > "Gates of Dawn" sounds nice. I have the feeling it means some more as just the literal translation?? ("Poort van de Dagenraad" in dutch, which is pretty vague) bye, jarl From jeff at bioinformatics.org Thu Nov 9 19:01:08 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] release names (was: BL status - Update) References: <200011091301.AA146407662@mercury.capeonramp.com> Message-ID: <3A0B3AC4.1D35A2D3@bioinformatics.org> bizzaro wrote: > > "Gates of Dawn" I should have explained the meaning behind this phrase/name. It probably escaped most people, except for Brad ;-) The first album by Pink Floyd was named "Piper at the Gates of Dawn": http://www.amazon.com/exec/obidos/ASIN/B000002UA0/qid=973813048/sr=1-/104-7817221-1868754 Fittingly, Piper is truly "at the gates of dawn". (And strangely enough, one of the songs on the album is "The Gnome"......hmmm.) I like the scheme/theme of naming releases after rock songs and albums, since they tend to have the coolest names :-) The 0.0.1 release, BTW, was named "Beginnings" after Chicago's song by the same name. (Brad, I promise not to use any songs by The Doobie Brothers ;-)) But, I'd like to keep the development of Piper democratic and not get into trouble (again) with the other developers, so let me know your opinions and suggestions. So far, the name has caused no objections. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Thu Nov 9 21:24:33 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] release names (was: BL status - Update) References: <200011091301.AA146407662@mercury.capeonramp.com> <3A0B3AC4.1D35A2D3@bioinformatics.org> Message-ID: <3A0B5C61.1BB684C6@casema.net> > > The first album by Pink Floyd was named "Piper at the Gates of Dawn": > (And strangely enough, one of the songs on the album is "The > Gnome"......hmmm.) ic. I'm not that much a fan of the old Floyd stuff, but the wierdness of it is comform the current status of Piper > > But, I'd like to keep the development of Piper democratic and not get into > trouble (again) with the other developers, so let me know your opinions and > suggestions. So far, the name has caused no objections. this name is fine to me.. I volunteerly vote for it :) From Nicolas.Chauvat at logilab.fr Fri Nov 10 08:43:07 2000 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] release names (was: BL status - Update) In-Reply-To: <3A0B3AC4.1D35A2D3@bioinformatics.org> Message-ID: > The first album by Pink Floyd was named "Piper at the Gates of Dawn": > Fittingly, Piper is truly "at the gates of dawn". (And strangely > enough, one of the songs on the album is "The Gnome"......hmmm.) "There is no such thing as a coincidence". I vote for "GoD" ;-) -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From jarl at casema.net Sat Nov 11 13:34:38 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Using Gnome with other Corba implementations Message-ID: <3A0D913E.445C9BC5@casema.net> Hi All, I think I need to share this fix with you (and the search engines cq the whole inet), because it's about a very nasty side effect of gnome. What's about? It's about using gnome with other Corba Orb implementations. A part of Gnome is gnorba, the corba\ORBit extensions of gnome. Gnorba has some nice features, among security is one. This security feature is nice when you only use gnome\gnorba applications, but it makes it impossible to have gnome applications communicate with other Orb implementations. The only fix I could find suggested hacking the gnome sources and recompiling them. Which of course is unsatisfing. So I made a good fix to overrule this security mechanism: 1. Code the gnome application just the way it's supposed to be done, with the gnome-init stuff etc. 2. Hook the ORBit connection handlers to the glib main event loop by writing your own handlers. This is explained at http://www.gimp.org/~imain/ORBit-GTK/ORBit-GTK-1.html 3. Now comes the real fix. Gnorba initializes by setting up a new validation- and default principal handlers. You need to reset those again in order to disable the security mechanism. Just before you execute the gnome main loop (or applet main, gtk main, glib main which are all the same) you place this code: --- cut --- ORBit_set_request_validation_handler(ORBit_request_validate_Hook); ORBit_set_default_principal(&_gnorba_request_cookie); --- cut --- Where ORBit_request_validate_Hook is like this: --- cut --- ORBit_MessageValidationResult ORBit_request_validate_Hook(CORBA_unsigned_long request_id,CORBA_Principal *principal,CORBA_char *operation) { return ORBIT_MESSAGE_ALLOW_ALL; } --- cut --- and _gnorba_request_cookie is defined like this: --- cut --- static CORBA_Principal _gnorba_request_cookie = { 0, 0, NULL, CORBA_TRUE }; --- cut --- Sometimes gnome isn't that easy ;-) bye, jarl From jeff at bioinformatics.org Sat Nov 11 11:50:06 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Using Gnome with other Corba implementations References: <3A0D913E.445C9BC5@casema.net> Message-ID: <3A0D78BE.8AA46DCF@bioinformatics.org> Jarl, Did you mention this on the ORBit list? If ORBit is intended to be a standard CORBA ORB, it should play nice with other ORB's. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Sat Nov 11 14:27:54 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:37 2006 Subject: [Pipet Devel] Using Gnome with other Corba implementations References: <3A0D913E.445C9BC5@casema.net> <3A0D78BE.8AA46DCF@bioinformatics.org> Message-ID: <3A0D9DBA.1FDEB0D1@casema.net> > Did you mention this on the ORBit list? If ORBit is intended to be a standard > CORBA ORB, it should play nice with other ORB's. In fact it aint a ORBit problem, it's a Gnome problem. And the gnome people have had a lengthy discussion about this on their list, so it's probably isolation that they want :) My post was to help people out once they are in the (rare?) situation they want to mix Gnome with another Orb as ORbit, and because google.com scans the Piper list regularly people will find my post. bye, jarl From jarl at casema.net Sat Nov 11 18:17:36 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] BL testing for everybody Message-ID: <3A0DD390.2078DF1F@casema.net> Hi All, With some help of Jeff the BL is now in cvs, so I would like all of you to give it a try. I'm mostly interested in bugs that arise because of another platform as I have. (Slackware 7.1\gcc 2.95.2\linux 2.4pre9\xamp playing Mahler's 1st symphony). Some additional note for the current version (0.4.0pre10): - needs Overflow - needs omniOrb 3.02 (maybe 2.x will do?) - ORBit 0.50 - gnome (I think any 'recent' version will do?) Also to compile the festival plugin, you need to have festival 1.4.1 installed. Once ./configure;make;make install has run you are ready to test executing the BL, which is done in this order: 1. run the BabyBL: 'BBL' 2. run the BL core: 'BL' 3. run the admin tool (that has a initialisation stall of about 10 seconds): 'BL_admin' Note that running the BBL inside gdb somehow results in a crash.. I'm trying to fix this. So go checkout cvs piper and give me some feedback, jarl From jeff at bioinformatics.org Sun Nov 12 05:14:20 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot Message-ID: <3A0E6D7C.458EAAFC@bioinformatics.org> There is a new snapshot of the Piper module on the FTP server: ftp://bioinformatics.org/pub/piper/piper-20001112.tar.gz This includes the source code for the BL recently added by Jarl. Since we don't have anon CVS working yet, this is the only way to get the most recent sources, unless you have a shell account. As Jarl said, we IMPLORE you to try compiling, even examining, the source code. This is the best way to work out bugs and come up with new ideas (remember "The Cathedral and the Bazaar"). Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From jarl at casema.net Sun Nov 12 16:50:03 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot References: <3A0E6D7C.458EAAFC@bioinformatics.org> Message-ID: <3A0F108A.15C7A07D@casema.net> > > ftp://bioinformatics.org/pub/piper/piper-20001112.tar.gz > As Jarl said, we IMPLORE you to try compiling, even examining, the source > code. This is the best way to work out bugs and come up with new ideas > (remember "The Cathedral and the Bazaar"). > 1. Running sh ./autogen.sh screws up the compilation of the BL on my machine.. if I remove the lines responsible for execution aclocal in the actogen.sh script it is fixed. Why is aclocal run again? Can I remove this & commit changes to cvs or will this break the code on another setup? 2. running the generated ./configure scripts breaks, when I place the aclocal.m4 of the bl directory in the root of the piper sources ./configure runs fine. Do I have a broken aclocal setup? How can I add m4 macro's so that configure can find them? 3. during ./configure I get "./configure: AM_PATH_PYTHON: command not found". This probably again is because a wrong m4 macro's setup? bye, jarl From chapmanb at arches.uga.edu Sun Nov 12 15:23:12 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot In-Reply-To: <3A0F108A.15C7A07D@casema.net> References: <3A0E6D7C.458EAAFC@bioinformatics.org> <3A0F108A.15C7A07D@casema.net> Message-ID: <14862.64560.634874.989215@taxus.athen1.ga.home.com> [new snapshot] Jarl, before I start with this, I think the biggest problem is that you all should make snapshots using 'gmake dist.' If you have autoconf et al set up properly, this should automatically give you a tarball of everything you need to build things, so that users can build the code without having to have auto[conf|make]. Just tarring up CVS will make it hard, especially since you guys let 'configure' scripts slip into CVS. Bad, bad :-) Anyways, I'll help with what I can. I still can't install omniORB because of FreeBSD gcc brokenness, but I'll try to help with what I can (and am trying to fix omniORB compiling as we speak). > Running sh ./autogen.sh screws up the compilation of the BL on my > machine.. if I remove the lines responsible for execution aclocal > in the actogen.sh script it is fixed. > > Why is aclocal run again? Can I remove this & commit changes to > cvs or will this break the code on another setup? You need aclocal to generate macros for you, specifically aclocal.m4 which deals with the macros you need. I'm not an automake guru, but I do know you can't get rid of it. Sorry! :-) > 2. running the generated ./configure scripts breaks, when I place > the aclocal.m4 of the bl directory in the root of the piper sources > ./configure runs fine. Do I have a broken aclocal setup? > How can I add m4 macro's so that configure can find them? It sounds like you have a broken macro set up somehow. Normally when configure whines after running autogen.sh it is because of macro issues. You should be able to watch during autogen.sh running to see what macros it is complaining about. New *.m4 macros are normally in $PREFIX/aclocal (I think new ones go here) and $PREFIX/autoconf. Automake *.am macros are in $PREFIX/automake. > 3. during ./configure I get "./configure: AM_PATH_PYTHON: > command not found". This probably again is because a wrong m4 > macro's setup? Yup, as I just mentioned to you on IRC, you'll see the patches to autoconf/make to allow it to deal with python. You can grab them from: ftp://ftp.daa.com.au/pub/james/python/ Hope this helps some... I'll try to help more if I have luck with gcc over here. Brad From jeff at bioinformatics.org Mon Nov 13 02:06:24 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot References: <3A0E6D7C.458EAAFC@bioinformatics.org> <3A0F108A.15C7A07D@casema.net> <14862.64560.634874.989215@taxus.athen1.ga.home.com> Message-ID: <3A0F92F0.8AFFA1F6@bioinformatics.org> Brad Chapman wrote: > > Jarl, before I start with this, I think the biggest problem is that > you all should make snapshots using 'gmake dist.' Jarl, if you go ahead and do this, I'll put it on the FTP server. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "Injustice anywhere is a threat to justice everywhere." -- Martin Luther King, Jr. -- From dgrisby at uk.research.att.com Mon Nov 13 06:17:07 2000 From: dgrisby at uk.research.att.com (Duncan Grisby) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] Using Gnome with other Corba implementations In-Reply-To: Message from jarl van katwijk of "Sat, 11 Nov 2000 19:34:38 +0100." <3A0D913E.445C9BC5@casema.net> Message-ID: <200011131117.LAA29645@pineapple.uk.research.att.com> On Saturday 11 November, jarl van katwijk wrote: > What's about? It's about using gnome with other Corba Orb implementations. A > part of Gnome is gnorba, the corba\ORBit extensions of gnome. Gnorba has some > nice features, among security is one. This security feature is nice when you > only use gnome\gnorba applications, but it makes it impossible to have gnome > applications communicate with other Orb implementations. omniORB can use Gnome's authentication mechanism. Just set the OMNIORB_PRINCIPAL environment variable to the Gnome cookie string. You can find that by running "xprop -root GNOME_SESSION_CORBA_COOKIE". Of course that doesn't help if you're using a different ORB, but Piper seems to be using omniORB. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From jarl at casema.net Mon Nov 13 12:31:53 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot References: <3A0E6D7C.458EAAFC@bioinformatics.org> <3A0F108A.15C7A07D@casema.net> <14862.64560.634874.989215@taxus.athen1.ga.home.com> <3A0F92F0.8AFFA1F6@bioinformatics.org> Message-ID: <3A102589.F5643E7B@casema.net> > > > > Jarl, before I start with this, I think the biggest problem is that > > you all should make snapshots using 'gmake dist.' > > Jarl, if you go ahead and do this, I'll put it on the FTP server. > I did! (Before Brad mentioned it that is) I'll contact brad about this.. I'll come back to this once it's settled. Because Brad is telling me to fix thing by methodes that screw up compilation @ my machine. laters, jarl From jarl at casema.net Mon Nov 13 12:38:41 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] Using Gnome with other Corba implementations References: <200011131117.LAA29645@pineapple.uk.research.att.com> Message-ID: <3A102721.1EDE52D0@casema.net> > > omniORB can use Gnome's authentication mechanism. Just set the > OMNIORB_PRINCIPAL environment variable to the Gnome cookie string. You > can find that by running "xprop -root GNOME_SESSION_CORBA_COOKIE". > > Of course that doesn't help if you're using a different ORB, but Piper > seems to be using omniORB. Thnx Duncan! This methode is better as simply disabling the authenication. Darn, if only I had know this sooner ;-) bye, jarl From jarl at casema.net Mon Nov 13 14:25:19 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot References: <3A0E6D7C.458EAAFC@bioinformatics.org> <3A0F108A.15C7A07D@casema.net> <14862.64560.634874.989215@taxus.athen1.ga.home.com> <3A0F92F0.8AFFA1F6@bioinformatics.org> <3A102589.F5643E7B@casema.net> Message-ID: <3A10401F.D669953C@casema.net> Hi All, I got the UIL\DL running on my machine, but had to do some recompilations. I dont know if this is 'normal', but it was quite some work. 1. had to install the python m4 macro's 2. had to recompile the python interpeter with crypt enabled (in Modules/Setup, -lcrypt also enabled) 3. also needed threads enabled in python (./configure --enable-threads) 4. had to install omniORBpy 1.2 We have got to check all these issues during the configure phase otherwise people will go crazy just trying to compile Piper ;) bye, jarl From bizzaro at mercury.capeonramp.com Mon Nov 13 13:20:27 2000 From: bizzaro at mercury.capeonramp.com (bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] new snapshot Message-ID: <200011131320.AA292225258@mercury.capeonramp.com> I was aware of 1 and 4, and they are mentioned in the INSTALL file. But, I wasn't aware of 2 and 3. I guess I just had Python set up that way already. Jeff >I got the UIL\DL running on my machine, but had to do some recompilations. I dont >know if this is 'normal', but it was quite some work. > >1. had to install the python m4 macro's >2. had to recompile the python interpeter with crypt enabled (in Modules/Setup, >-lcrypt also enabled) >3. also needed threads enabled in python (./configure --enable-threads) >4. had to install omniORBpy 1.2 > >We have got to check all these issues during the configure phase otherwise people >will go crazy just trying to compile Piper ;) From jeff at bioinformatics.org Mon Nov 20 17:47:27 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] RPMS for Overflow Message-ID: <3A19A9FF.AE1AA652@bioinformatics.org> Greetings fellow Pipers. You may be aware that the Processing Layer of Piper is based on the application "Overflow", developed by Jean-Marc: http://freespeech.sourceforge.net/overflow.html Even so, it was decided that Overflow remain a separate package, akin to how GTK+ is separate from GNOME. Well, Overflow is relatively mature and complete at this time, unlike the rest of Piper. It is also very large and can be a challenge to compile. Given all of this, I think it's high time we make RPM's/Deb's for Overflow. Some people (e.g., Steve) have volunteered to do this for the Piper project in general. Any takers? Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From doumdi at hotmail.com Tue Nov 21 02:09:15 2000 From: doumdi at hotmail.com (Dominic Létourneau) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] RPMS for Overflow Message-ID: Hi everybody, I've been thinking of RPMS for a while, and yes, it worth doing it really soon. We (Jean-Marc & Dominic) are fixing few bugs right now and will release RPMS as soon as possible. I'll keep everybody informed when it's done. Cheers, Dominic >From: "J.W. Bizzaro" >Reply-To: pipet-devel@bioinformatics.org >To: pipet-devel@bioinformatics.org >Subject: [Pipet Devel] RPMS for Overflow >Date: Mon, 20 Nov 2000 22:47:27 +0000 > >Greetings fellow Pipers. > >You may be aware that the Processing Layer of Piper is based on the >application "Overflow", developed by Jean-Marc: > > http://freespeech.sourceforge.net/overflow.html > >Even so, it was decided that Overflow remain a separate package, akin to >how >GTK+ is separate from GNOME. > >Well, Overflow is relatively mature and complete at this time, unlike the >rest >of Piper. It is also very large and can be a challenge to compile. Given >all >of this, I think it's high time we make RPM's/Deb's for Overflow. Some >people >(e.g., Steve) have volunteered to do this for the Piper project in general. >Any takers? > >Cheers. >Jeff >-- >J.W. Bizzaro >jeff@bioinformatics.org >Director, Bioinformatics.org: The Open Lab >http://bioinformatics.org/~jeff >"All those scientists--they're all alike! They say they're working for us, >but what they really want is to rule the world!" > -- Angry Villager, Young Frankenstein >-- > >_______________________________________________ >pipet-devel maillist - pipet-devel@bioinformatics.org >http://bioinformatics.org/mailman/listinfo/pipet-devel > _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From jeff at bioinformatics.org Tue Nov 21 22:23:21 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] No such file or directory Message-ID: <3A1B3C29.11A05988@bioinformatics.org> I think I'll increase the noise level on the list a little, since this invloves more than a couple people. I wrote: > > What's causing this error? What is BASE_TB_DIR? > > -------------------------------- > jeff@dexter:jeff> Starting definition layer... > Starting pied... > ior file: /home/jeff/piper_info/ior/dl2bl.ior > Getting document... > omniORB: Caught an unexpected Python exception during up-call. > Traceback (innermost last): > File "/home/piper/dl/modules/dl2uilserver.py", line 81, in addDocument > temp_locus = TempCompositeLocus(self.commit_queue) > File "/home/piper/dl/modules/compositelocus.py", line 440, in __init__ > toolboxes = os.listdir(BASE_TB_DIR) > OSError: [Errno 2] No such file or directory > -------------------------------- Then Brad wrote: > > This is the overflow toolbox directory. The definition of BASE_TB_DIR > is at the top of that file, and overflow_toolbox_dir is imported from > the piperconfig.py module containing the configuration variables. This > directory should be OVERFLOW_PREFIX/toolbox, which is where overflow > puts all of the XML definitions of the nodes. > > If you look in piperconfig.py, which is created during ./configure > from piperconfig.py.in, you can see the value of overflow_prefix. This > should be set to the location of overflow (otherwise I'm not sure how > things would build since the dl wouldn't be able to find the overflow > libs). > > So I'm not sure why you aren't finding the directory -- I would guess > that your install is abnormal in some way -- did you move libraries > around, etc after they were installed by Overflow? Okay, I see the reference to the directory: overflow_toolbox_dir = os.path.join(overflow_prefix, "toolbox") But, there is no directory named "toolbox" in Overflow, at least not any more. There is this directory: 1 drwxrwxr-x 5 root root 1024 Nov 20 18:28 tools/ Perhaps Jean-Marc changed the name? Also, I set the overflow_prefix to /Overflow/vflow and NOT to /Overflow because the include directory is under the vflow directory. Yo, what up wit dat? Is that what it should be set to? Or should I have "installed" Overflow into my system directories? In short, compiling Piper worked fine, but I can't run it now 8-( It seems like a quick fix though, however I'd like to get a concensus. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From chapmanb at arches.uga.edu Tue Nov 21 23:44:21 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] No such file or directory In-Reply-To: <3A1B3C29.11A05988@bioinformatics.org> References: <3A1B3C29.11A05988@bioinformatics.org> Message-ID: <14875.20261.258901.956794@taxus.athen1.ga.home.com> Jeff: > Or should I have "installed" Overflow > into my system directories? Of course, you need to install Overflow. It is just like any other software, so you need to do a make install as well. Then you'll get things put into the right include/lib directories. The toolbox directory is created automagically from comments in the source files using a perl script when you do make install. Then you'll see this directory and things will make more sense. Brad From valj01 at gel.usherb.ca Wed Nov 22 00:06:58 2000 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] No such file or directory References: <3A1B3C29.11A05988@bioinformatics.org> <14875.20261.258901.956794@taxus.athen1.ga.home.com> Message-ID: <3A1B5472.CCE29569@gel.usherb.ca> > > Or should I have "installed" Overflow > > into my system directories? > > Of course, you need to install Overflow. It is just like any other > software, so you need to do a make install as well. Then you'll get > things put into the right include/lib directories. > > The toolbox directory is created automagically from comments in the > source files using a perl script when you do make install. Then you'll > see this directory and things will make more sense. As Brad said, you need to install (with "make install") Overflow. I would, however, recomment *not* installing with /usr or /usr/local as prefix, as I cannot guaranty it won't screw up anything. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From valj01 at gel.usherb.ca Wed Nov 22 01:26:56 2000 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] Overflow update Message-ID: <3A1B6730.955A8E8E@gel.usherb.ca> Hi everybody! I just committed major Overflow changes and would like to get some feedback. One of these changes is a redesign of the Overflow Stream classes which, I hope will allow egcs 1.1.2 (that ships with Redhat 6.x) to compile. So give it a try! I hope I didn't break anything, but there's just one way to know ;-) The changes include: - Stream class rewite (should work with egcs 1.1.2?) - Node optimizations (the overhead is down from 2 us/node to 1.2 us/node!) - New (faster) Vector allocation scheme - New Bugs(TM) - ... So test it, have fun, report bugs! Jean-Marc P.S. Note that for now, any node that derives from FrameOperation is broken and will need to be rewritten to use BufferedNode instead. -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jarl at casema.net Wed Nov 22 09:50:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] No such file or directory References: <3A1B3C29.11A05988@bioinformatics.org> <14875.20261.258901.956794@taxus.athen1.ga.home.com> <3A1B5472.CCE29569@gel.usherb.ca> Message-ID: <3A1BDD19.A94EFA22@casema.net> > > As Brad said, you need to install (with "make install") Overflow. I would, > however, recomment *not* installing with /usr or /usr/local as prefix, as I > cannot guaranty it won't screw up anything. I installed in /usr/local, and seem to have no problems with it jarl From jeff at bioinformatics.org Wed Nov 22 09:16:55 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] No such file or directory References: <3A1B3C29.11A05988@bioinformatics.org> <14875.20261.258901.956794@taxus.athen1.ga.home.com> <3A1B5472.CCE29569@gel.usherb.ca> Message-ID: <3A1BD557.54FCCF74@bioinformatics.org> Jean-Marc Valin wrote: > > As Brad said, you need to install (with "make install") Overflow. I would, > however, recomment *not* installing with /usr or /usr/local as prefix, as I > cannot guaranty it won't screw up anything. Ohhh. So, if I installed it in /usr, it would make a /usr/toolbox directory? Or would the toolbox directory still be in the source directory? Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From jeff at bioinformatics.org Wed Nov 22 09:23:11 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] Overflow update References: <3A1B6730.955A8E8E@gel.usherb.ca> Message-ID: <3A1BD6CF.CCC9FEF2@bioinformatics.org> Jean-Marc Valin wrote: > > I just committed major Overflow changes and would like to get some feedback. One > of these changes is a redesign of the Overflow Stream classes which, I hope will > allow egcs 1.1.2 (that ships with Redhat 6.x) to compile. So give it a try! I > hope I didn't break anything, but there's just one way to know ;-) Alright, I'm going to compile Overflow with the new commits. And this time I'll install it ;-) Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From jarl at casema.net Wed Nov 22 12:12:47 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] DL - BL communications Message-ID: <3A1BFE8F.8F26DBCB@casema.net> Hi All, have a look at the lastest cvs sources, they now actually have all DL -> BL corba stuff functional. Or basically functioning should I say, the BL orb server is not fully implemented, but the 'dummy' functions give the DL what is wants for now. bye, jarl From chapmanb at arches.uga.edu Wed Nov 22 10:57:13 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] No such file or directory In-Reply-To: <3A1BD557.54FCCF74@bioinformatics.org> References: <3A1B3C29.11A05988@bioinformatics.org> <14875.20261.258901.956794@taxus.athen1.ga.home.com> <3A1B5472.CCE29569@gel.usherb.ca> <3A1BD557.54FCCF74@bioinformatics.org> Message-ID: <14875.60633.764160.846401@taxus.athen1.ga.home.com> Jeff: > Ohhh. So, if I installed it in /usr, it would make a /usr/toolbox > directory? > Or would the toolbox directory still be in the source directory? I installed it with --prefix=/usr/home/chapmanb/test/overflow passed to the configure. The directory looks like this: $ ls -l /usr/home/chapmanb/test/overflow total 10 drwxr-xr-x 3 chapmanb 1000 512 Nov 13 03:23 HMM drwxr-xr-x 3 chapmanb 1000 512 Nov 13 03:22 audio_blocks drwxr-xr-x 2 chapmanb 1000 512 Nov 22 05:31 bin drwxr-xr-x 3 chapmanb 1000 512 Nov 13 03:22 data-flow drwxr-xr-x 2 chapmanb 1000 1536 Nov 22 05:31 include drwxr-xr-x 2 chapmanb 1000 1024 Nov 22 05:31 lib drwxr-xr-x 2 chapmanb 1000 512 Nov 22 05:31 m drwxr-xr-x 4 chapmanb 1000 512 Nov 13 03:23 share drwxr-xr-x 10 chapmanb 1000 512 Nov 13 03:24 toolbox Brad From jeff at bioinformatics.org Wed Nov 22 16:45:00 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] running the latest source Message-ID: <3A1C3E5C.D54BF52B@bioinformatics.org> Woo-Hoo! I got the very latest Overflow and Piper+BL compiled and running (RedHat 6.2 for Intel). No problems yet :-) Jarl asked us to test the BL for him. Jarl, could you write a tutorial on a simple test of the BL using the GMS GUI? Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From jeff at bioinformatics.org Wed Nov 22 17:30:07 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:38 2006 Subject: [Pipet Devel] Internet pioneer urges overhaul Message-ID: <3A1C48EF.CE4E7EEB@bioinformatics.org> ``Similar to the way a host name is resolved to an IP address, the handle will be resolved into information the computer needs to know about the object. Only since the information is now about the object, the location of the object is just one of the bits of information that is important. The handle record will also tell the computer things like what kind of file the object it is, how often it will be updated and how the object is allowed to be used - whether there are any copyright or privacy protections. The record can also have any industry-specific information about the object, like a book's International Standard Book Number (ISBN) code.'' Sound familiar? Skip down to the picture of Kahn unless you want a lesson on what the Internet is. http://www.msnbc.com/news/492681.asp?cp1=1 Cheers. Jeff From valj01 at gel.usherb.ca Wed Nov 22 22:28:09 2000 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] Overflow update References: <3A1B6730.955A8E8E@gel.usherb.ca> <3A1BD6CF.CCC9FEF2@bioinformatics.org> Message-ID: <3A1C8EC9.4735D60A@gel.usherb.ca> > Alright, I'm going to compile Overflow with the new commits. And this time > I'll install it ;-) Did you use gcc 2.95 or egcs 1.1.2 (which I hope works now)? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From jeff at bioinformatics.org Wed Nov 22 23:39:12 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] Overflow update References: <3A1B6730.955A8E8E@gel.usherb.ca> <3A1BD6CF.CCC9FEF2@bioinformatics.org> <3A1C8EC9.4735D60A@gel.usherb.ca> Message-ID: <3A1C9F70.4D523ABC@bioinformatics.org> Jean-Marc Valin wrote: > > Did you use gcc 2.95 or egcs 1.1.2 (which I hope works now)? gcc (g++) 2.95.2 on RedHat 6.2 for Intel. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From jarl at casema.net Thu Nov 23 05:31:52 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] running the latest source References: <3A1C3E5C.D54BF52B@bioinformatics.org> Message-ID: <3A1CF218.99ADDB08@casema.net> > Woo-Hoo! I got the very latest Overflow and Piper+BL compiled and running > (RedHat 6.2 for Intel). No problems yet :-) Even on Redhat ;) > > > Jarl asked us to test the BL for him. Jarl, could you write a tutorial on a > simple test of the BL using the GMS GUI? > My plans for the BL_admin are that it should be disposed of as soon as possible. But for now you can do some simple testing with it; simple because using some features will let the tool crash. Firstly you need to remember the design of the BL: A.- Based on a signle type of node that has a name based on the situation, it can be a : Aa.- Sensor when it's routing data from the environment into the BL. In Piper there will be 2 sensors: from the DL and from the PL. The rest are just the old GMS plugins, that gather data from syslogd, localhost and irc (not compiled by default). Sensors are linked to the Piperline by default and can't be given other links. Ab.- Piperline. There is always just one pipeline for one instance of the BL, where things such as authorisation and scheduling will be handled. You can't play with this one. Ac.- Collectors are nodes that have a 1-on-1 relation to sensors, for every sensor there's one collector. Collectors are the 'instance of a sensor that has passed the pipeline's criteria' so to say. Collector's differ from sensons in that they can be given multiple relations to other nodes (Filters and Visuals) Ad.- Visuals are the nodes that output datastreams to the environment, the DL or PL in the Piper framework. The old GMS plugins can also output to irc, scrath panel, alarm applet, speechtsynthesis, etc. Ae.- Filters are nodes that just process data, they're positioned between the collectors and visuals. They wont be used in Piper so you wont find them in the BL_admin. Crashing the BL_admin is too easy: 1.- crashing when you select a Visual or a Sensor. This is because after a selection of such a plugin should display the configuration it in the window below the component, which makes use of a feature of gtk that wouldn't work after the C -> C++ port. I let this be to work on the connections between the DL and PL. 2. - Also the output windows of the visuals are empty (the empty tabs), because these make use of the same gtk stuff as 1. Testing is a bit harder ;) 1. Viewing the 4th tab, which shows all loaded & initialized plugins 2. Using the 3th tab (Collectors), which can be given relations to visuals. Select on of the collectors, 'Add' new relations. The problem with testing is that the only 'usefull' sensor (input data stream) is the syslogd monitor plugin, and that this one needs to have root permissions. You can give the irc sensor a try, but this one need to be configured at source level because the configuration panels dont work yet. So the real testing is yet to come when it's possible to upload the networks from the UI to the PL and monitor it by using the BL_admin. bye, jarl From jeff at bioinformatics.org Thu Nov 23 10:22:21 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] tarball snapshots of Piper and Overflow Message-ID: <3A1D362D.256AA677@bioinformatics.org> I made new snapshots of Piper and Overflow. They are on the FTP server: ftp://bioinformatics.org/pub/piper They were made from CVS this morning (Nov. 23). Here are the commands that *I* used to compile Overflow. Change the options as necessary: sh autogen.sh --enable-shared --disable-static --prefix=/opt/overflow --with-fftw-dir=/usr FFTW is needed for Overflow, so I put fftw-2.1.3 in the FTP directory. Here are the commands I used to compile Piper: sh autogen.sh --prefix=/usr --with-piperhome=/home/piper --with-overflow=/opt/overflow --with-omniorb=/opt/omniORB_300 --with-omnilibs=/opt/omniORB_300/lib/i586_linux_2.0_glibc2.1 omniORB3 and omniORBpy are needed for Piper, so I put them in the FTP directory too. Please try to download and compile this stuff, and let us know how it worked out. And, to everyone in the US, happy Thanksgiving :-) Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From jeff at bioinformatics.org Thu Nov 23 14:27:12 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] Internet pioneer urges overhaul References: <3A1C48EF.CE4E7EEB@bioinformatics.org> Message-ID: <3A1D6F90.365D8725@bioinformatics.org> There are some interesting comments about this on Slashdot: http://slashdot.org/articles/00/11/22/1432219.shtml The whole discussion is applicable to Piper, since we want to tag objects with metadata and register other instances of Piper running on the Net, at the very least, if not all objects. Jeff "J.W. Bizzaro" wrote: > > ``Similar to the way a host name is resolved to an IP address, the handle will > be resolved into information the computer needs to know about the object. Only > since the information is now about the object, the location of the object is > just one of the bits of information that is important. The handle record will > also tell the computer things like what kind of file the object it is, how > often it will be updated and how the object is allowed to be used - whether > there are any copyright or privacy protections. The record can also have any > industry-specific information about the object, like a book's International > Standard Book Number (ISBN) code.'' > > Sound familiar? Skip down to the picture of Kahn unless you want a lesson on > what the Internet is. > > http://www.msnbc.com/news/492681.asp?cp1=1 -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org: The Open Lab http://bioinformatics.org/~jeff "All those scientists--they're all alike! They say they're working for us, but what they really want is to rule the world!" -- Angry Villager, Young Frankenstein -- From jeff at bioinformatics.org Thu Nov 23 14:55:08 2000 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] Gnutella: To the Bandwidth Barrier and Beyond Message-ID: <3A1D761C.AEF6325C@bioinformatics.org> Here is another article about Gnutella and "the problem with P2P": http://dss.clip2.com/gnutella.html A few months back we discussed centralization vs. decentralization (P2P) for Piper and have considered Napster and Gnutella, respectively, as models of each. I think we reached a general concensus (at least among the founders of the Piper project) that decentralization was the way to go. So, it is interesting to read about some of the "problems" with Gnutella. Is the discussion moot? And, as usual, there are SOME good comments about this on Slashdot: http://slashdot.org/articles/00/11/22/1432219.shtml Cheers. Jeff From SCoffman at CBSINC.com Mon Nov 27 09:43:05 2000 From: SCoffman at CBSINC.com (COFFMAN Steven) Date: Fri Feb 10 19:20:39 2006 Subject: [Pipet Devel] Gnutella: To the Bandwidth Barrier and Beyond Message-ID: The way I see it, Piper is much more analagous to a web browser than to a file trader. Just as the overwhelming majority of people who browse the web will not have any original HTML or image files on their hard drive, the majority of Piper users will not have public, useful XML data that they (or others) would care to share. However, piper content repositories (servers) may behave amongst themselves more similarly to file trading systems such as Freenet, or Gnutella proxies with cacheing/aggregation, or napster for that matter. Designing the system so that casual, dial-up users are treated as equally viable sources for XML as persistant repositories is a mistake, in my view. Further, non-persistant connections are useless repositories if the information does not behave in a freenet-style, demand mobile manner. Freenet behavior allows highly demanded content from non-persistant connections to travel to persistant repositories, where it will be more reliably accessable. What sorts of data files do you think will be highly demanded of Piper users across the internet? I can't think of any which is not time-dependent (news, weather, stock, etc.) which must come from a maintained server. All of my other examples are of purely local interest (internal company, family, etc.). -Steve -----Original Message----- From: J.W. Bizzaro [mailto:jeff@bioinformatics.org] Sent: Thursday, November 23, 2000 2:55 PM To: pipet-devel@bioinformatics.org Subject: [Pipet Devel] Gnutella: To the Bandwidth Barrier and Beyond Here is another article about Gnutella and "the problem with P2P": http://dss.clip2.com/gnutella.html A few months back we discussed centralization vs. decentralization (P2P) for Piper and have considered Napster and Gnutella, respectively, as models of each. I think we reached a general concensus (at least among the founders of the Piper project) that decentralization was the way to go. So, it is interesting to read about some of the "problems" with Gnutella. Is the discussion moot? And, as usual, there are SOME good comments about this on Slashdot: http://slashdot.org/articles/00/11/22/1432219.shtml Cheers. Jeff _______________________________________________ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel