Glenn, have a look at
http://vm.marist.edu/~pipeline/#Manuals<http://vm.marist.edu/%7Epipeline/#Manuals>

I just uploaded the 2001 formatting of the programming interfaces.  Have a
look at the macros in chapter 4.  Some kind of encoding of those would allow
the pipeline to be read in and executed as well, say a new option on RUNPIPE
could understand this or PIPCMD for that matter.

Cheers,

   j.

2009/3/17 Glenn Knickerbocker <n...@bestweb.net>

> "John P. Hartmann" wrote:
> > And Glenn will have to tell me how he wants the output?  E.g., a stage
> per
> > line with a null line for each pipeline end character?
>
> Oh, the responsibility!  Ideally, it should be trivial both to parse
> everything out and to reassemble a valid pipeline spec.  Here's a first
> thought:
>
>  (
>  globaloption value
>  )
>  streamnum.||*.inout.stream:
>  streamnum.||label.streamID:(localoptions)stage args
>
> where:
>
> * the parentheses for the global options are always present,
> * || are the stagesep or endchars, present or implicit, after and
>  before the stage (after first, so that we can just CHOP it off),
> * the dot and colon are present if and only if there's a label,
>  so we don't have to mess with null labels, and
> * the parentheses are always present only for stream 0,
>  so that we can CHOP AFTER ) to find the stage name.
>
> The redundant sep/end chars are intended to provide a simple way to
> identify first and last stages.  Thinking more about that, I wonder if a
> pair of flags is better (maybe in the same byte:  F0 + first*2 + last).
>
> I thought of using a fixed length rather than a delimiter for the stream
> number, but if there's a maximum it's higher than I can test in the
> biggest machine I have access to now (998M, ran out of storage somewhere
> above 4M streams).  The dot at least doesn't have to be discarded to
> yield a valid whole number.
>
> This still leaves the task of parsing the local options to the user.  It
> sure would be nice to have them parsed out too, but I'm not seeing a way
> that leaves the label and stage name easily connected and is still
> simple to reassemble into a valid pipeline spec.  For examination, they
> could be repeated after the stage:
>
>  streamnum.||label.streamID:(localoptions)stage args
>  (
>  localoption value
>  )
>
> but that doesn't provide an easy way to alter them before reassembly.
>
> ¬R
>

Reply via email to