[TransWarp] input-driven application

[Phillip J. Eby]

Okay, I've checked in fixes for the bugs.  Once I fixed them, your example 
ran fine for me.  Please let me know whether it works as you expect.

To answer your question about connecting items, I would say that the 
general algorithm might look something like:

pipeline = [filter1, filter2, ...]

for i in range(len(pipeline)-1):
     pipe = MakeAPipe()
     pipeline[i].stdout = pipe.input
     pipeline[i+1].stdin = pipe.output

pipeline[0].stdin=self.stdin
pipeline[-1].stdout=self.stdout

Keep in mind that for this to work, each of your filter objects needs to be 
a "real" ICmdLineApp in the sense that it uses only its stdin and stdout, 
OR, you must run each filter one after the other, with the intervening 
pipes having sufficient space to hold the results until you're ready to run 
the next filter.  If you take that approach, then you might as well use 
temporary files rather than pipes, and just run the commands one after the 
other.

Note, by the way, that for an I/O driven system like this, you may not want 
to use periodic tasks, but instead have each filter register as a reader 
and writer with the 'IBasicReactor' utility's "select" loop.  As you say, 
though, this won't work on windows except for sockets.  You could perhaps 
use localhost sockets, though, connecting to yourself, as a crude sort of 
pipe.  :)


At 05:26 PM 5/15/03 -0400, Phillip J. Eby wrote:
>At 11:03 PM 5/15/03 +0300, alexander smishlajev wrote:
>>that did not do anything.  where am i wrong?
>
>You're not.  There's a bug in the assembly events system, that's keeping 
>your component from registering with a task queue.  For now, you can work 
>around it by adding:
>
>     self.uponAssembly()
>
>to your 'run()' method, before invoking the mainloop.  This is just a 
>temporary workaround until I figure out how to fix the problem with 
>assembly events.  :(
>
>What's happening is that if a component receives an assembly event before 
>its children request notification of assembly events, then when later 
>requests occur, it will simply add them to its notification queue and 
>never notify them.  In order to fix this, I think I'm going to have to add 
>another state variable.  At any rate, I'll need to add new tests to cover 
>this condition.
>
>Attempting to use your code, I also discovered that I was a bit premature 
>in simplifying the utility registry code last week as well; as a result, 
>PEAK tries to use Twisted's reactor even when a simpler reactor is 
>sufficient.  I'll need to fix this, too.