[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plumbing



In response to my suggestion of a multipipe primitive for es,
Steve Kilbane wrote:

> > It would be useful to be able to distinguish between
> > the two kinds of output; but you don't just want to send them
> > to different places, because you want to keep the two
> > synchronised.
> 
> Bzzt! You're onto something of a loser here already, because
> once the output from the fds enters the realm of pipes, you're
> into buffering issues, and you lose the synchronisation.

*click* You're absolutely right, of course. On the other hand,
you keep *some* synchronisation (i.e., two bits of output emitted
at the same time are likely to arrive at about the same time);
it might or might not be enough for practical purposes. I'm not
very clued up on the implementation details; would someone more
expert than I am like to comment here?

and also:

> If you really want to go with this, I'd suggest dropping elegance and
> going for practicality. Perl's IPC::Open3 module will give the
> functionality you require, and Perl is always great for those one-off
> jobs that aren't worth breaking out the C compiler for...

That sounds like a good idea. I hadn't known about Open3, but it
looks like it will do what I want without too much pain. Thanks!


Paul Haahr, on the other hand, wrote in response to my suggestion
for the syntax of the extended %pipe this would require:

> >     %pipe {make universe} '1 2' '0 3' {process_output}
...
> (Er, ugh.)  If I were to do such a thing, I'd probably change the pipe
> primitive to take a list of output-on-left/input-on-right fd pairs,
> either counted or explicitly delimited, something like
> 
>   make universe |[1=0,2=3] process_output | grep errors
> 
> turning into
> 
>   %pipe {make universe} 1 0 2 3 . {process_output} 1 0 . {grep errors}

The reason for my proposed syntax was that it would be backward-compatible
with the existing %pipe syntax. Isn't this relevant?

> But if we did this, then people would start to want things like circular
> pipes, just for the sake of completeness, and the notations get really
> absurd.

Well, you don't have to follow every idea to its illogical conclusion :-)

> Not crazy.  It's just that the number of times it actually would be used
> is probably pretty rare.

I would use it every time I do a "make". (Following the suggestion
of Perl5's Open3 module, I'll probably actually use that instead.)

> Is there any chance of a future release of es seeing the light of day?

;-)

> If you implement it, release it as a patch and see if other es users
> find it useful.

Given that Perl will do the plumbing I need, I'll probably just use
that. But if anyone else on this list thinks the multipipe hack
would be useful, I might do it after all.

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
gjm11@dpmms.cam.ac.uk  Cambridge University, England.