headers
Chris Casey | 1 Aug 2008 01:10

weird Traceback in Mayavi example

When running Mayavi/examples/poll_file.py, I get the following
traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 14095, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
  File "poll_file.py", line 109, in main
    p = Pollster(fname, data)
  File "poll_file.py", line 49, in __init__
    self.last_stat = os.stat(fname)
NameError: global name 'os' is not defined

However, the line 'import os' *IS* in the file. Gael thinks it "maybe possibly" might have something to do
with the standalone decorator. Any other thoughts?
Permalink | Reply | 2 comments |
headers
Gael Varoquaux | 1 Aug 2008 03:08
Favicon
Gravatar

Mayavi[ui, wx]?

Installing mayavi still isn't has easy as it should be. You have to
specify extra requirements if you want to be able to use GUIs. First of
all to get the application running, you need to need to give it the extra
'ui', and I am sure this will fool a lot of people, especially since the
error message that comes out is not helpfull at all.

In addition, this will not be enough to get Mayavi running, as you still
need a backend for traits. For this you have to call:

easy_install "Traits[ui,wx]"

Now we are exposing way too many implementation details to the user who
just wants mayavi (what's this thing called traits? I just want to get
mayavi up and runnin'). I think we can improve things.

First of all, we can add an extra requirement to mayavi, say "wx", that
requires "Traits[ui, wx]". Second idea we could capture the error raised
by  the mayavi2 script, and give more meaningful error message:
ImportError: No module named envisage.ui.workbench.api
that is not terribly helpful. In addition, I am think of implementing a
check somewhere to hint to the user that she needs to install Traits[ui,wx]:
this traceback isn't too helpful:
NotImplementedError: the null pyface backend doesn't implement ApplicationWindow

Whad'y'all think? The last issue is probably more general than mayavi.
Maybe we can imporve this traceback by suggesting to install another
backend, and telling the user how to do it?

Finally, while playing with installing mayavi, it worked a first time,
but now I get, and I have to try again. The second time I try it works.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 1 Aug 2008 04:07
Picon
Gravatar

Re: weird Traceback in Mayavi example

Chris Casey wrote:
> When running Mayavi/examples/poll_file.py, I get the following
> traceback:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 14095, in <lambda>
>     lambda event: event.callable(*event.args, **event.kw) )
>   File "poll_file.py", line 109, in main
>     p = Pollster(fname, data)
>   File "poll_file.py", line 49, in __init__
>     self.last_stat = os.stat(fname)
> NameError: global name 'os' is not defined
> 
> However, the line 'import os' *IS* in the file. Gael thinks it "maybe possibly" might have something to do
with the standalone decorator. Any other thoughts?

It works for me on the Mac and on linux.  I'm not sure the decorator is 
the problem since it only adds a 'mayavi' name binding to the function's 
global namespace.

cheers,
prabhu
Permalink | Reply | 1 comment |
headers
Gael Varoquaux | 1 Aug 2008 04:17
Favicon
Gravatar

Re: weird Traceback in Mayavi example

On Fri, Aug 01, 2008 at 07:37:30AM +0530, Prabhu Ramachandran wrote:
> It works for me on the Mac and on linux.  I'm not sure the decorator is 
> the problem since it only adds a 'mayavi' name binding to the function's 
> global namespace.

Yes, it works for me too. This is very weird. It just reminds me the
problems you might have with "execfile", sometimes, with globals (sorry I
can't pin point something precise, just a vague feeling).

Gaël
Permalink | Reply | 0 comments |
headers
Martin Chilvers | 1 Aug 2008 09:33
Picon

Re: [ANNOUNCE] ETS 3.0.0b1 released!

G'day,

Dave Peterson wrote:
> I am very pleased to announce that ETS 3.0.0b1 has just been tagged and 
> released!
> 
> All ETS sub-projects, including Traits, Chaco, Mayavi, and Envisage, 
> have been tagged and released in one form or another (alpha, beta, 
> final) as part of this effort. All ETS projects have now been registered 
> with PyPi and source tarballs have been uploaded! As a result, for the 
> first time ever, you can now easy_install all of ETS via a simple 
> command like:
> easy_install ETS

Awesome!

Martin
Permalink | Reply | 0 comments |
headers
Alexander Michael | 1 Aug 2008 14:52
Picon

Re: Kiva Build Failure with MS Visual Studio .NET 2003

On Thu, Jul 31, 2008 at 4:06 PM, Robert Kern <robert.kern@...> wrote:
> On Thu, Jul 31, 2008 at 15:04, Robert Kern <robert.kern@...> wrote:
>> On Thu, Jul 31, 2008 at 14:49, Peter Wang <pwang@...> wrote:
>>> On Jul 31, 2008, at 2:45 PM, Alexander Michael wrote:
>>>
>>>> On Thu, Jul 31, 2008 at 3:39 PM, Robert Kern <robert.kern@...>
>>>> wrote:
>>>>> On Thu, Jul 31, 2008 at 14:31, Alexander Michael
>>>>> <lxander.m@...> wrote:
>>>>>> I'm having trouble building kiva with MS Visual Studio 2003 again.
>>>>>> What version of SWIG should I be using? Here's the last few lines
>>>>>> where the failure occurs:
>>>>>>
>>>>>> C:\Program Files\Microsoft Visual Studio .NET
>>>>>> 2003\Vc7\PlatformSDK\Include\BaseTsd.h(33) : error C2632: '__int64'
>>>>>> followed by '__int64' is illegal
>>>>>
>>>>> That's odd. That header file is VS's, not ours. Are there any
>>>>> messages
>>>>> just before this for the gl_graphics_context.cpp file?
>>>>
>>>> I thought that was odd as well, but that is the only error message in
>>>> the output. There are no other warnings either. I've seen this
>>>> behavior before when header files collide. Something in the line:
>>>>
>>>> typedef signed __int64      INT64, *PINT64;
>>>>
>>>> has possibly been re#define'd in an incompatible way before this
>>>> header loads. It's been quite a while since I tried to build kiva with
>>>> VS, so I'm not sure when this crept in.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Bond | 1 Aug 2008 14:59
Picon

Ubuntu Mayavi2 rollout

Hello,

Firstly - Dave, many thanks for your help last night with the
Mayavi2 problems I was having. A new check-out of 3.0.0b2 has
solved our problems!

Secondly - we have a large mayavi userbase here within a
university research group who are looking to transition to
mayavi2. I'd like to get them using it as soon as possible to
stress-test the beta and make use of the new functionality Daryl
Harrison is writing for us, hence would like to roll out 3.0.0b2
to many tens of systems at once.

Is there a current recommended method for packaging the software
up into debs to do this? Or is there a repository somewhere I
should be looking at with the betas as debs? At the moment all we
have packaged is the 2.1.0 build from Ubuntu 8.04. 

Advice on this would be much appreciated so we can get the
software into everyday use.

Regards,

Tim
--

-- 
Dr. Timothy M Bond, Operations Manager
Applied Modelling and Computation Group
http://amcg.ese.ic.ac.uk/index.php?title=Dr_Tim_Bond
Permalink | Reply | 14 comments |
headers
Gael Varoquaux | 1 Aug 2008 15:34
Favicon
Gravatar

Re: Ubuntu Mayavi2 rollout

On Fri, Aug 01, 2008 at 01:59:54PM +0100, Tim Bond wrote:
> Secondly - we have a large mayavi userbase here within a
> university research group who are looking to transition to
> mayavi2.

That's a good news.

> Is there a current recommended method for packaging the software
> up into debs to do this?

There is Andrew Straw's stdeb, http://stdeb.python-hosting.com/.

> Or is there a repository somewhere I should be looking at with the
> betas as debs? At the moment all we have packaged is the 2.1.0 build
> from Ubuntu 8.04. 

Actually, in the backport repository of ubuntu hardy, there now is 2.2.0.
But anyhow, the right thing to do here is to build debs manually. I was
planing to try and do this this week end. I am especially happy to hear
that some people are indeed waiting for that. Do you know how to build
debs? If so, we could join forces, as building debs for the whole ETS
will be a lengthy process.

In the mean time, I'll give a go at stdeb, to see if I can get usable
package's out of it. This will be fast, though not as good.

Cheers,

Gaël
(Continue reading)

Permalink | Reply | 10 comments |
headers
Ondrej Certik | 1 Aug 2008 16:01
Picon
Gravatar

Re: Ubuntu Mayavi2 rollout

On Fri, Aug 1, 2008 at 3:34 PM, Gael Varoquaux
<gael.varoquaux@...> wrote:
> On Fri, Aug 01, 2008 at 01:59:54PM +0100, Tim Bond wrote:
>> Secondly - we have a large mayavi userbase here within a
>> university research group who are looking to transition to
>> mayavi2.
>
> That's a good news.
>
>> Is there a current recommended method for packaging the software
>> up into debs to do this?
>
> There is Andrew Straw's stdeb, http://stdeb.python-hosting.com/.
>
>> Or is there a repository somewhere I should be looking at with the
>> betas as debs? At the moment all we have packaged is the 2.1.0 build
>> from Ubuntu 8.04.
>
> Actually, in the backport repository of ubuntu hardy, there now is 2.2.0.
> But anyhow, the right thing to do here is to build debs manually. I was
> planing to try and do this this week end. I am especially happy to hear
> that some people are indeed waiting for that. Do you know how to build
> debs? If so, we could join forces, as building debs for the whole ETS
> will be a lengthy process.
>
> In the mean time, I'll give a go at stdeb, to see if I can get usable
> package's out of it. This will be fast, though not as good.

I would suggest you just join us maintaining the packages currently in
Debian/Ubuntu, instead of creating another ones from scratch, because
(Continue reading)

Permalink | Reply | 9 comments |
headers
Gael Varoquaux | 1 Aug 2008 16:18
Favicon
Gravatar

Re: Ubuntu Mayavi2 rollout

On Fri, Aug 01, 2008 at 04:01:20PM +0200, Ondrej Certik wrote:
> I would suggest you just join us maintaining the packages currently in
> Debian/Ubuntu, instead of creating another ones from scratch, because
> then we'd have to merge them.

No, we have to start from scratch, because this time we want more then 4
debian packages, we one one per project, that is 19 (if I counted right)
packages total. When I have been building debs, so far, I had used your
debian sources, and right now I am taking inspiration from them, but this
time I feel that we really want a different architecture.

This is also why I think that we will have eg:

 python-traits: the actual package for the Traits project
 python-enthought-traits: just a transitional package requiring python-traits

 python-traitsgui: the package for the TraitsGUI project
 python-enthoughtbase: the package for the EnthoughtBase project
 python-traitsbackendwx: the package for the TraitsBackendWX project
 python-enthought-traits-ui: a wrapper project to require all three above.

And so on. This is more work, but this would match more the layout of our
SVN, and the layout of PyPI. In addition, there is a fair amount of
effort invested at Enthought to make these projects independant. It is a
waist to bundle them in the same debian package. Why would you have to
install wxpython when you want to use mayavi with qt?

However, I'd be more than happy to do this packaging effort on a publicly
available svn. If I have time, I would like to make those packages clean
so that they can be the start for the ETS 3 package in Debian.
(Continue reading)

Permalink | Reply | 8 comments |

Gmane