scipy-user@onnodb.com wrote:

Hi Fernando,

...

...

like Traits, Chaco and Envisage, but I just can't seem to wrap my head

FP> From your description, those three (esp. the first two) are probably FP> your best bets. Have you tried playing with the examples and asking FP> specific questions on the enthought-dev list? The developers there FP> are typically very responsive to specific queries.

No, I haven't tried that yet, but I certainly will!

FP> You may also want to have a look at Vision:

FP> http://mgltools.scripps.edu/packages/vision/overview

Looks very extensive, and worth experimenting with.

although I haven't worked with them both, I understand that Traits and Vision are each others opposite. So if you like them both, you should also take a look at everything in between ;-) * Orange <http://magix.fri.uni-lj.si/orange/screenshots.asp> * Elefant <https://elefant.developer.nicta.com.au/> * Enthought with Traits UI, they are developping it for a customer, and planned to show us something in december 2007, but I guess it's somewhat delayed. * Vision <http://www.scripps.edu/%7Esanner/python/viper/index.html> * Pyphant <http://www.fmf.uni-freiburg.de/service/Servicegruppen/sg_wissinfo/Software/Pyphant> * mathGUIde <http://www.math.uni-siegen.de/ring/mathGUIde/index.html> * PyLab_Works: http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_animations_screensho... cheers, Stef

hi Bryan, unfortunately you're not able to post your code, (btw why not ?) but maybe you can answer a few questions .... Bryan Cole wrote:

Hi,

I'm an ex-LabView user, now using python for lab data-acquisition and analysis for some years now. It's well worth the switch.

I'm too a former MatLab / LabView user, and I'm quit happy with Python / Scipy / wxPython for now. At the moment I'm trying to write an open source LabView equivalent, first results can be seen here: http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_animations_screensho...

Your best bet is http://pyqwt.sourceforge.net/

You're right, matplotlib/chaco are too slow for "interactive real-time" type work. The strengths of these packages are their presentation-quality output (vector and anti-aliased bitmap graphics).

For data-acquisition applications, I prefer wxPython to Qt (I may move to something based on Traits/ETS once I figure out how to install it). For GUIs I have a home-made plotting widget which is fast enough for real-time work. Unfortunately, I'm not yet in a position to post it publicly. If you need *really* high performance, it's not too hard to write a plot-widget using PyOpenGL directly.

I'm in the middle of writing a real time plot widget, based on direct canvas drawing, don't know yet how fast it is. I hope to make a video of it next week. But I wonder if you've a good data-acquisition module. I've one now (can use Soundcard , some NI-modules and several dedicated DAQ cards), but it's in fact a windows executable that I can control from Python. And of course I', looking for a more OS-indepedant solution. cheers, Stef

Alan G Isaac wrote:

On Sat, 01 Mar 2008, Stef Mientki apparently wrote:

...

I'm too a former MatLab / LabView user, and I'm quit happy with Python / Scipy / wxPython for now. At the moment I'm trying to write an open source LabView equivalent, first results can be seen here: http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_animations_screensho...

Looks promising. Please post updates as the project moves along.

off course I will. cheers, Stef

Hi Stef,

...

unfortunately you're not able to post your code, (btw why not ?)

Although I started developing the plot-widget in my own time (I did publish this first version on my home web-site (now defunct due to lack of time)), development continued at my workplace over 2 years or more now so now the code ownership is ambiguous. The best plan is for me to get permission to release the code. Unfortunately, upper management are a bit suspicious of OSS at my workplace. I'm working on this...

...

but maybe you can answer a few questions ....

Bryan Cole wrote:

...

Hi,

I'm an ex-LabView user, now using python for lab data-acquisition and analysis for some years now. It's well worth the switch.

I'm too a former MatLab / LabView user, and I'm quit happy with Python / Scipy / wxPython for now. At the moment I'm trying to write an open source LabView equivalent, first results can be seen here:

http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_animations_screensho...

...

Your best bet is

Nice work. I must confess, I'm not a huge fan of the "graphical programming" concept (otherwise I'd probably still be using labview). I don't think LabView and Visual Programming are identical. In my humble opinion, LabView violated against some vey basic rules,

Bryan Cole wrote: like flattness of information, and uniformity / simplicity.

My wish would be a nice set of technical widgets (plots, knobs, sliders, gauges etc.) which are 1) documented and 2) integrated with a wxPython GUI-designer like wxGlade. In fact, a "technical edition" of wxGlade with such things integrated would make creating data-acquisition application easy to the newcomer without compromising flexibility.

the you're lucky, ... ... I tried to get wxGlade running on 2 different machines, both failed ;-)

...

...

I'm in the middle of writing a real time plot widget, based on direct canvas drawing, don't know yet how fast it is. I hope to make a video of it next week.

The NI-DAQmx drivers probably represent as good a data-acquisition API as you'll get. It's pretty much a 1:1 mapping to LabView nodes. The task-based approach is easy to work with although the NI documentation is far from perfect. You could make NI-DAQmx task nodes for your pylab_works framework. If you need cross-platform, re-implement the required functionality on linux with Comedi.

NI-DAQmx would be a good standard, and I think I've even seen a Python wrapper for it, but I can't find it anymore. In fact the windows program I use in PyLab_Works also contains a NI-DAQmx wrapper.

The main recommendation I would make to anyone writing data-acquisition stuff in python is Use Traits/TraitsUI! The ability to auto-generate a GUI to configure hardware objects based on their Traits definitions is a *huge* productivity saving.

You might be quit right, I've heard this reasoning more than once, but .... ... I'm looking at the wrong documents or ... I'm simply too stupid or ... I'm a completely spoiled windows user but I really really don't understand one bit of Traits :-( cheers, Stef

Gael Varoquaux wrote:

On Sun, Mar 02, 2008 at 06:24:12PM +0100, Stef Mientki wrote:

...

...

The main recommendation I would make to anyone writing data-acquisition stuff in python is Use Traits/TraitsUI! The ability to auto-generate a GUI to configure hardware objects based on their Traits definitions is a *huge* productivity saving.

...

You might be quit right, I've heard this reasoning more than once, but .... ... I'm looking at the wrong documents or ... I'm simply too stupid or ... I'm a completely spoiled windows user but I really really don't understand one bit of Traits :-(

Have you tried looking at: http://gael-varoquaux.info/computers/traits_tutorial I wrote it specificaly targetting someone with no prior knowledge of GUI developement or even object oriented programming.

thanks Gael, I didn't know these manuals, but I think I'm still missing the clue completely. What I understand is that traits is a smart replacement of "*arg, **kwargs" (which I've never used either). But being a smart replacement, it also makes it a complex / difficult replacement. As far as I understand, your presentation is about how you can easily create a GUI interface with Traits. Please don't understand me wrong, I don't want to upset you, I think you're very valuable contributor to both this list and the Python community, but as follower of the KISS principle, again I don't understand it. Please tell me in 2 lines what's the essential difference between TraitsUI in your presentation, and the lines below (note that with a little effort even "Types" can be removed), so maybe I can add those essentials to my code, or even might switch to traits ;-) Names = [ 'For All Signals', 'AutoScale', 'Upper Value', 'Lower Value' ] Values = [ False, True, 200, 20 ] Types = [ bool, bool ] OK, Values = MultiLineDialog ( Names, Values, Types, 'Set Border Values', width = 70 ) cheers, Stef

hi Gael, I might even agree more with you than you or I thought at first sight ... Gael Varoquaux wrote:

Traits can be seen as three things:

* Type validation of attributes: good point, if you know how to handle the exceptions, instead of "error 1229: contact your distributor" * Reactive/callback programming made easy. very good point, should be done all the time ! * Visualization made easy: it's boring, but also a very good point, although I'm not a MS fan at all, all programs should be good as Excel at this point.

...

but as follower of the KISS principle, again I don't understand it.

KISS is great, but remember: 1 month of hard work can save you one week end of learning. If you start doing interactive GUIs, you won't be able to get around learning a few things, and I think it is easier to learn Traits than the alternatives.

I'll hope the future will change that: simple programming for everyone !

No object oriented programming. I don't believe you can do complexe codebases without OOP. agreed. In addition you don't have any reactive programming: the code above cannot be interactive. This is what I call a "visual script". Going from program-driven logics, where the user is presented sequentially a set of dialogs, to user-driven logics, where the user (or an experiment) keeps interacting with the program, will require a paradigm shift. More than agree, my adagiao: "the best programs are written by users", unfortunately programming is yet too difficult for most domain experts. I believe that Traits will make this paradigm shifte easier than any alternative. I also believe your second best bet is PyQt. But Traits has a nice model/view separation in which you can get the reactive programming without the GUI event-loop, and that's really nice.

In short, yes you do have to learn things, but you won't get an interactive program for free, sorry.

And now I get a strange feeling, ... ... that I'm working on some kind of traits, maybe a lot less sophisticated, but on the other hand much easier ;-) thanks for the explanation, cheers, Stef

hi Gael, Gael Varoquaux wrote:

On Mon, Mar 03, 2008 at 09:29:11PM +0100, Stef Mientki wrote:

...

And now I get a strange feeling, ... ... that I'm working on some kind of traits, maybe a lot less sophisticated, but on the other hand much easier ;-)

Neware, you might be reinventing the wheel. Don't think so, let's say I'm trying to make an octagon, not as well as a wheel, but better than a square. (or am I creating a hoovercraft ;-)

We started this discussion in november last year, I had the plan to use Vision to develop a LabView like environment. You were the one who told me that Enthought's product based on TraitsUI would be the best. I agreed with you, but as nobody has seen the Enthought product, and it would last to the end of 2007 before it was made public, I decided that it didn't fit my time schedule. (And by now I still haven't seen anything from Enthought ;-) Going for thé best, is not always thé best choice, if we would go for fusion now, you wouldn't be able to read this mail ;-)

As you try to take your ideas further, you will probably end up with the same problems Traits ahd to face three years ago. I don't believe in the "this is too complicated for me, let me reinvent something similar but different" approach.

Anyhow, I which you good luck. I am interested in what might come out, however I'll stick with Traits, because I know it has been used for years in real-world large project and is now at its third major version, with many changes benefiting from experience.

I agree, Traits might be a very good choice (once you've mastered it), so again I fully agree there's no single argument to leave Traits, but there are a few obstacles to start with Traits. cheers, Stef

Alan G Isaac wrote:

On Tue, 04 Mar 2008, Stef Mientki apparently wrote:

...

there are a few obstacles to start with Traits.

I have not really played with Traits yet, but at first approach it seems pretty natural. What are the obstacles?

Don't let you stop by my remarks ! But for a non-programmer like me, it doesn't feel natural at all, so my learning curve is just too steep. Although I'll certainly will look at it when I've some more time. cheers, Stef

hi Allen, Alan G Isaac wrote:

On Tue, 04 Mar 2008, Stef Mientki apparently wrote:

...

But for a non-programmer like me, it doesn't feel natural at all, so my learning curve is just too steep.

I'm just a user too. Did you try it at all?

no, I only try things when I see it's "direct" relevance ...

You can start by just letting Traits handle some simple type checking with predefined traits: <URL:http://code.enthought.com/traits/doc/UM/Traits2_UM_3.html> This is not mind bending, but it may not meet a need of yours either ...

indeed I see no connection to the major headlines of my application :-( nonetheless, thanks for the link, Stef

Stef Mientki a écrit :

I agree, Traits might be a very good choice (once you've mastered it), so again I fully agree there's no single argument to leave Traits, but there are a few obstacles to start with Traits. Stef,

This is only my 2 cts of a Traits's user-but-not-programmer guy. I can say that building a simple app with Traits (using Chaco2) works like a charm. I do like using Traits and so on. And people at enthought are very nice ;-) BTW, you have a lot of examples in source code tree, to begin. http://fredantispam.free.fr/snapshot.png Cheers, -- http://scipy.org/FredericPetit

On Mon, 3 Mar 2008, Gael Varoquaux apparently wrote:

* Type validation of attributes: the attributes of an object can be given a type descriptor (more precisely a validation method) and the compliance of the attribute is checked at run-time when this attribute is set. This is very useful for complex codebase, but probably not for you.

Can you easily state briefly how this differs from the use of properties (with type checking on the setter)? Thank you, Alan Isaac

...

On Mon, 3 Mar 2008, Gael Varoquaux apparently wrote:

...

* Type validation of attributes: the attributes of an object can be given a type descriptor (more precisely a validation method) and the compliance of the attribute is checked at run-time when this attribute is set. This is very useful for complex codebase, but probably not for you.

On Mon, Mar 03, 2008 at 07:20:05PM -0500, Alan G Isaac wrote:

...

Can you easily state briefly how this differs from the use of properties (with type checking on the setter)?

On Tue, 4 Mar 2008, Gael Varoquaux apparently wrote:

Fundementaly, I don't think this differs much. You have a lot of syntactic sugar around it, which makes the code more readable, and easier to reuse, as it gives the commonly used patterns (dynamical initialisation, delegation, as well as a lot of existing validation types). Don't under-estimate the work to get the syntax and the different patterns right. When you use it a lot, Traits simply "feels right". ... In addition, the property-calling code is written in C, which makes it orders of magnitude faster than standard Python properties.

Thanks! Alan

Peter Wang wrote:

On Mar 3, 2008, at 1:21 PM, Stef Mientki wrote:

...

What I understand is that traits is a smart replacement of "*arg, **kwargs" (which I've never used either).

Not at all, not more so than a car is just a smart replacement of horses with circular legs. :)

yes, just like a "deux Chevaux Vapeur", or "ugly duck" as it called in our country, but at least I get forward ;-) thanks, Stef Mientki

Bryan Cole wrote:

Hi,

I'm an ex-LabView user, now using python for lab data-acquisition and analysis for some years now. It's well worth the switch.

Your best bet is http://pyqwt.sourceforge.net/

You're right, matplotlib/chaco are too slow for "interactive real-time" type work. The strengths of these packages are their presentation-quality output (vector and anti-aliased bitmap graphics).

Are you sure you meant that *chaco* is too slow? The stated difference of chaco with matplotlib is interactive plotting and I know a bit of effort goes in to making it fast. I'm curious what problems you tried chaco on for which it was too slow. -Travis O.

On Mar 2, 2008, at 3:55 PM, Bryan Cole wrote:

...

Are you sure you meant that *chaco* is too slow? The stated difference of chaco with matplotlib is interactive plotting and I know a bit of effort goes in to making it fast.

You're quite right to pull me up on this. In fact, I've not tested chaco for this type of application so I can't say for sure if it's fast enough or not. I guess, my expectation was that it would not be much faster than matplotlib (given they both use Antigrain for rendering, which tends to be the bottleneck). Whenever I tried any type of anti-aliased drawing (antigrain or cairo) there is always a significant performance hit (on linux anyway).

Although Chaco uses Agg, the nature of *how* it uses Agg is very different from matplotlib. Also, Chaco's internal architecture is designed around interactivity. There are several examples with displaying live updating data: https://svn.enthought.com/enthought/browser/Chaco/trunk/examples/advanced/da... The spectrum analyzer example at the very bottom of the Chaco gallery uses PyAudio to display a realtime FFT and spectrogram of the sound input: http://code.enthought.com/chaco/gallery/index.shtml Also, Chaco has several different backends it can use for output, not just Agg. I recently greatly improved the OpenGL backend so it is extremely fast on all three major platforms (although this has not been merged into the trunk just yet).

Sounds like I should revisit chaco (I haven't tried it in a while). My main problem with it is lack of documentation (this is really what has prevented me from testing it extensively).

I apologize for the continuing lack of extensive documentation. The examples are a good place to start, and the classes all have some level of comments describing the common traits. I think the data_strea.py example would probably be a good place for you to try out your data acquisition and display. (It does require wxPython.) And, as always, you can email the list with questions. -Peter