[SciPy-user] Scipy + Vision = LabView ?

[Stef Mientki]

Gael Varoquaux wrote:
> On Fri, Nov 02, 2007 at 07:31:53PM +0100, Stef Mientki wrote:
>   
>>> Concerning vision, there are at least 3 or 4 projects doing Visual
>>> programming for scientific Python purposes.
>>>       
>
>   
>> Well I'm very interested to see these projects !
>>     
>
> OK, now I have to name them, huho.
thanks very much Gael,
it's very good to have such an overview.
>  
>
> So we have Vision, that is indeed impressive, but really built around
> custom tools. It would be a large amount of work to abstract out the
> visual programming part of the rest, but it is probably possible.
>   
Yes I took a quick look, and doesn't seems easy to extract the Vision 
part form the total package.
> Then we have orange, that dies no seem to be fully written in Python, but
> certainly uses Python (http://www.ailab.si/orange/screenshots.asp)
>
>   
Looks nice, but is very dedicated to statistics  (and Qt-based :-(  ,
so I don't know if we can build a hardware control loop in it.
If you get more library modules, it will be hard to manage them.
> Elefant also uses a visual programming engine. see
> http://scipy.org/SciPy2007/Presentations for Christfried Webers' slides
> on elefant, or their main webpage (
> http://elefant.developer.nicta.com.au/ ). I talked to Christfried at
> scipy, and he definitly seemed open for collaborations.
>   
Looks very nice, also statistical oriented, graphing is almost the same 
as ogl-like.py.
Not yet suited for windows :-(
> And we have enthought's approach. If you want to have a glimpse at the
> UI, you can look on page 24 of Eric's slides.
couldn't find that :-(
>  The two interesting things
> about enthought's approach is that they reuse their knowhow in layout
> engine to generate the dialogs (I am not to sure it is pure traits, but it
> seems linked), and, most interesting, that they use standard python
> functions to build their visual blocks, and do not need descriptions of
> input and output. Obviously this imposes a lot of restriction on the way
> the functions behave (basically pure functionnal-like behavior, where
> side effects are banned), and last time I talked with them, they had
> problems adding flow control to this. But they are using this engine in a
> commercial app, which means that there is money going in it to improve
> it, so it is definetaly worth the look.
>   
I don't think any of the mentioned packages is capable of (pseudo-) 
realtime programming,
so there might be room for one more package ;-)

cheers,
Stef