[SciPy-user] Scipy + Vision = LabView ?

Gael Varoquaux gael.varoquaux at normalesup.org
Fri Nov 2 10:08:21 EDT 2007


On Wed, Oct 31, 2007 at 11:51:07PM +0100, Matthieu Brucher wrote:
>    2007/10/31, Paul Barrett <[1]pebarrett at gmail.com>:

>      No, you are not dreaming.  I also commented on this possibility
>      several years ago to some people in the SciPy community.
>      Unfortunately, I have not had the time or motivation to act on it.  It
>      would certainly be nice to have a basic package to show people.
>      You'll need to create a set of APIs so that you can connect to
>      instrumentation.  It shouldn't be too hard now that the interfaces
>      have been standardized.

>    Sorry, it was in fact Vision and Viper I saw in the past as well.
>    The idea is great but the application, IMHO, is not quite optimal :
>    - even for the tutorial, the rotate bloc should have two inputs, the image
>    and the rotation angle (this last factor could be given by the result of
>    another algorithm)
>    - what about multithreading in this model ?
>    - what about flow control ? (which is really a huge issue that is lacking
>    in ITK for instance)
>    - is there a way to create a bunch of blocks easily ?

>    All this has consequences on the interface. Besides, it would be very
>    great to use Traits as input and output blocks.

Enthought has a very promising deveolppement in this direction, that uses
inspection of a Python script to build the diagram. IMHO it is much more
powerful than vision because most of the work is done automaticaly. Look
at Eric Jones' presentation at this year's Scipy to read a bit more about
it.

Vision is really impressive. I am just worried that it is hard to reuse.
It is an empire of its own. 

As a general note on the mailing list, there are a lot of impressive
projects, but often they are centered on themselves, and do not provide a
good interface and reusable components. Recently Prabhu and I have been
working on Mayavi2 to make it more reusable, turning it into an engine
and widget that can be decoupled from the UI. This kind of approach is
very important to avoid duplication of effort. Concerning vision, there
are at least 3 or 4 projects doing Visual programming for scientific
Python purposes. It tears my heart to see that many different efforts not
sharing code, but the reason is simply that each project is hard to
reuse.

An, yes, I agree that traits would do a perfect basis to build a reusable
visual progamming model. Traits do need a better packaging and
deployement, but that is a problem much easier to solve than build a new
GUI dialog engine.

My 2cents,

Gael



More information about the SciPy-User mailing list