Re: [9fans] dataflow programming from shell interpreter

[roger peppe <rogpeppe@gmail.com>]

i had some ideas along these sorts of lines which i
put into a tool in inferno that i called "alphabet".
it works (with a few rough edges).
http://www.vitanuova.com/inferno/man/1/sh-alphabet.html

for an example of something it can do that's not possible
with a conventional shell pipeline, see
http://www.vitanuova.com/inferno/man/1/alphabet-fs.html

one of these days i intend to dust it off and take
it to the next level - i've had a few ideas in the meantime.
don't hold your breath though.

2010/1/20 Patrick Kelly <kameo76890@gmail.com>:
>
>
> On Jan 20, 2010, at 4:13 PM, Eris Discordia <eris.discordia@gmail.com>
> wrote:
>
>> Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit
>> one possible answer to the video processing question? Filter graphs can be
>> generated by any program, GUI or CLI, and fed to DirectShow provided one
>> learns the in and out of generating them.
>>
>> The OP's question, too, finds one answer in MS PowerShell where instead of
>> byte streams .NET objects are passed between various tools and a C#-like
>> shell language is used for manipulating them. .NET objects can at any point
>> be serialized/deserialized to/from XML using stock classes and routines in
>> System.Xml.Serialization namespace.
>
> Why XML? Surely there are better options.
>>
>> Just a note that at least some implementations of both ideas exist in
>> production settings.
>>
>>
>> --On Tuesday, January 19, 2010 15:40 +0000 Steve Simon
>> <steve@quintile.net> wrote:
>>
>>>> The PBM utilities (now net pbm) did something similar for bitmaps.
>>>> I think V10 also had some pipeline utils for manipulating images.
>>>
>>> Indeed, however I make a firsm distinction between image proccessing (2d)
>>> and video processing (3d).
>>>
>>> In Video processing the image sequences can be of arbitary length, the
>>> processing is often across several fields, and, because we want our
>>> results ASAP tools should present the minimum delay possible (e.g. a
>>> gain control only needs a one pixel buffer).
>>>
>>> Aditionally image processing pipelines often have nasty things like
>>> feedback loops and mixing different paths with differing delays which all
>>> need special care.
>>>
>>> We have a package of good old unix tools developed jointly by us and the
>>> BBC which works as you might expect
>>>
>>>   cat video-stream | interpolate -x 0.7 -y 0.3 | rpnc - 0.5 '*' | display
>>>
>>> however this can get quite ugly when the algorithm gets complex.
>>>
>>> We need to cache intermediate results - processing HD (let alone 2k 3d)
>>> can get time consuming so we want an environment which tee's off
>>> intermediate results automagicially and uses them if possible - sort of
>>> mk(1) combined with rc(1).
>>>
>>> It is also a pain that its not easy to work at different scales i.e.
>>> writing expressions to operate at the pixel level and using large blocks
>>> like interpolate, the rpnc is an attempt to do this but its interpreted
>>> (slow).
>>>
>>> a restricted rc(1)-like language which supports pipelines,
>>> and scalar (configuration) variables combined with a JIT compiler
>>> (in the vein of popi) looks like a solution but I have never go further
>>> than wishful thinking.
>>>
>>> -Steve
>>>
>>
>>
>>
>>
>>
>
>