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 >