acmelab broken

Hey Martin,

I am trying to get some block diagrams put together that describe how 
modules/packages/plugins etc relate to each other.  It looked like 
Acmelab is the most recent example of an evisage app.  Is this correct?  
If so, it failed to run with the traceback below.  Could you check and 
see if there is a simple fix?

thanks,
eric

Traceback (most recent call last):
  File "c:\wrk\enthought\src\lib\enthought\traits\trait_notifiers.py", 
line 213,
 in rebind_call_0
    getattr( self.object(), self.name )()
  File 
"c:\wrk\enthought\src\lib\enthought\envisage\core\core_plugin.py", line 2
92, in _on_application_started
    for extension in self.load_extensions(Runnable):
  File "c:\wrk\enthought\src\lib\enthought\envisage\core\plugin.py", 
line 188, i
n load_extensions
    return self.application.load_extensions(extension_point_id)
  File 
"c:\wrk\enthought\src\lib\enthought\envisage\core\application.py", line 4
13, in load_extensions
    self.plugin_activator.start_plugin(extension._definition_.id)
  File 
"c:\wrk\enthought\src\lib\enthought\envisage\core\plugin_activator.py", l

Re: Applying numpy branch patches to enthought trunk.

Scripting Mayavi2

    Hi,

	I am trying to build a "quiver3d" function out of Mayavi2 (Mayavi
is the only program I know that is able to display a sensible view of a
3D field of 3D vectors). I have written the following code. It works as I
expect it to, the first time it is called. The second time I call it I
can see that I am creating modules and a scene on top of what I created
in the previous call. This makes Mayavi unhappy and the code does not
run.

Here is the code :

######################## quiver3d.py ############################
# Standard library imports
import scipy

# Enthought library imports
from enthought.mayavi.app import Mayavi

class QuiverMayavi(Mayavi):

    vectors=scipy.ones([4,4,4,3])

    def script(self):

        from enthought.mayavi import script
        from enthought.mayavi.modules.outline import Outline
        from enthought.mayavi.modules.glyph import Glyph
        from enthought.mayavi.sources.array_source import ArraySource

        script.new_scene()
        src = ArraySource()
        src.vector_data = self.vectors
        script.add_source(src)
        o = Outline()
        script.add_module(o)

        g = Glyph()
        script.add_module(g)
        g.glyph.scale_mode = 'scale_by_vector'
        g.glyph.color_mode = 'color_by_vector'
        # Use arrows to view the scalars.
        g.glyph.glyph_source = g.glyph.glyph_list[1]

def quiver3d(u,v,w):
    """
    Expects 3 l*n*m matrices u,v,w with the u,v,w components of vector
field.
    """

    if not ( u.shape==v.shape and v.shape==w.shape):
        raise TypeError, "u, v and w must be of same shape."

    shape=u.shape

    if not (len(shape)==3):
        raise TypeError, "the input arrays must be 3D."

    u=scipy.ravel(u)
    v=scipy.ravel(v)
    w=scipy.ravel(w)
    vectors=scipy.array([u,v,w])
    vectors=scipy.transpose(vectors)
    vectors=scipy.reshape(vectors,shape+(3,))

    m = QuiverMayavi()
    m.vectors = vectors
    m.main() 

###############End of quiver3d.py#########################

And a test to expose the behavior that gives me trouble :

[u,v,w]=scipy.mgrid[1:3,1:3,1:3]

import quiver3d
# first call goes well
quiver3d.quiver3d(u,v,w)
# Now if we close the mayavi session and call quiver3d again it fails.
quiver3d.quiver3d(u,v,w)

    What are the approach you suggest to implement a quiver3d function
while reusing Mayavi's "Glyph" code. Should I keep trying to call Mayavi
(if so do you have a workaround for my current problem), or should I try
to plug Mayavi's Glyph code in ivtk (I haven't started looking if this
is possible).

	Cheers,

--

-- 
    Gaël

Re: Scripting Mayavi2

>>>>> "Gaël" == Gaël Varoquaux <gael.varoquaux@...> writes:

    Gaël> first time it is called. The second time I call it I can see
    Gaël> that I am creating modules and a scene on top of what I
    Gaël> created in the previous call. This makes Mayavi unhappy and
    Gaël> the code does not run.

The Mayavi class is meant to create a MayaVi app, i.e. the full
application.  So each time you instantiate QuiverMayavi it will try to
create a new app and fail.  So you must take a different approach to
do this.  The easiest way for you to implement the quiver is like so:

# quiver3.py
from enthought.mayavi import script
from enthought.mayavi.modules.outline import Outline
from enthought.mayavi.modules.glyph import Glyph
from enthought.mayavi.sources.array_source import ArraySource

def quiver3d(vectors):
    src = ArraySource()
    src.vector_data = vectors
    script.add_source(src)
    o = Outline()
    script.add_module(o)

    g = Glyph()
    script.add_module(g)
    g.glyph.set(scale_mode='scale_by_vector', 'color_by_vector')
    # Use arrows to view the scalars.
    g.glyph.glyph_source =3D g.glyph.glyph_list[1]

# EOF

Put this in your path (or current directory)

To use this start up mayavi2, create a new scene.  Then on the
interpreter type:

 import quiver3
 # create your vectors.
 quiver3.quiver3d(vectors)

I think you get the general idea of what I am trying to do here.

cheers,
prabhu

Re: Scripting Mayavi2

    OK, I get you. Looking at the examples I hadn't understood that
mayavi could be controlled by the scripts once it was started. Thanks for
the explanations.

--

-- 
    Gaël

Re: Problems using Enthought python

Thanks Pearu, I've applied your patch but I'm still in trouble... 
The patch seems to work although I get a strange warning:

missing header for unified diff at line 14 of patch
patching file graphics_context.i
Hunk #1 succeeded at 281 with fuzz 2.

If run diff for comparing the original and the patched 
graphics_context.i all I get is:

279c279
<                     if self.thisown2: destroy(self)
---
 >                     if self.thisown: destroy(self)

Probably something is missing because when I run the command:

  from enthought.chaco.wx import plt

I get new large error message ending with:

/home/victor/enthought/src/lib/enthought/kiva/__init__.py in 
_backend_passthrough()
      74             _backend = name
      75             return
---> 76     raise RuntimeError, "no usable backend found"
      77
      78 def backend():

RuntimeError: no usable backend found

En/na Pearu Peterson ha escrit:
> 
> 
> On 3/30/06, *Víctor Martínez-Moll* <victor.martinez@... 
> <mailto:victor.martinez@...>> wrote:
> 
> 
>     Instead, if I do a In-place Build, everything seems to work (at least I
>     do not get any critical error message) but lots of packages are broken.
>     For example, if I start IPython and try to import the plt package:
> 
>     from enthought.chaco.wx import plt
> 
>     all I get a large error message ending with:
> 
>     /home/victor/enthought/src/lib/enthought/kiva/agg/agg.py in
>     _swig_getattr(self,
>     class_type, name)
>           26     method = class_type.__swig_getmethods__.get(name,None)
>           27     if method: return method(self)
>     ---> 28     raise AttributeError,name
>           29
>           30 import types
> 
>     AttributeError: own
> 
> 
> You are probably using swig  1.3.28 or newer. Here follows a piece of a 
> patch from Numpy port of enthought that fixes this problem:
> 
>                  _swig_setattr(self, GraphicsContextArray, 'this', obj)
> -                _swig_setattr(self, GraphicsContextArray, 'thisown', 1)
> -                   
> +                # swig 1.3.28 does not have real thisown, thisown is mapped
> +                # to this.own() but with previous 'self.this=obj' an
> +                # attribute 'own' error is raised. Does this workaround
> +                # work with pre-1.3.28 swig?
> +                _swig_setattr(self, GraphicsContextArray, 'thisown2', 1)
> +
>                  self.bmp_array = ary               
>                 
>                  if array_locally_allocated is True:
>  <at>  <at>  -276,7 +281,7  <at>  <at> 
>  
>              def __del__(self, destroy=_agg.destroy_graphics_context):
>                  try:
> -                    if self.thisown: destroy(self)
> +                    if self.thisown2: destroy(self)
>                  except: pass
> 
> 
> The status of numpy port enthought is reported in
> 
>   http://svn.enthought.com/enthought/wiki/NumpyPort
> 
> that contain installation notes that work ok here in my debian sid box.
> 
> HTH,
> Pearu
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev@...
> https://mail.enthought.com/mailman/listinfo/enthought-dev

--

-- 
Víctor Martínez Moll           | Universitat de les Illes Balears
Departament de Física          | Edifici Mateu Orfila
Àrea d'Enginyeria Mecànica     | E-07122, Palma de Mallorca, SPAIN
e-mail: victor.martinez@... | Tel:34-971171374 Fax:34-971173426

Re: Problems using Enthought python

Re: acmelab broken

eric jones wrote:
> Hey Martin,
> 
> I am trying to get some block diagrams put together that describe how 
> modules/packages/plugins etc relate to each other.  It looked like 
> Acmelab is the most recent example of an evisage app.  Is this correct?  
> If so, it failed to run with the traceback below.  Could you check and 
> see if there is a simple fix?

Fixed the bug - it was the result of a partial cleanup ;^)

Anyway, I don't run acmelab much (obviously!), I use the app in 
enthought/src/apps/envisage as my test app...

Martin

build break

I'm getting a build break when trying to build enthought. It started to 
fail around 9:30am this morning. Looking at the stack dump, it appears 
to be related to Numerix, but I didn't see anything in the changelog 
that would indicate responsibility for the failure. Here is the stack dump:

Traceback (most recent call last):
  File 
"C:\projects\enthought\src\lib\enthought\kiva\agg\test_numeric_weakref.py", 
line 3, in ?
    import weave
  File "C:\Python23\lib\site-packages\weave\__init__.py", line 21, in ?
    from scipy_test.testing import ScipyTest
  File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 794, in ?
    from scipy_base.numerix import alltrue, equal, shape, ravel, around, 
zeros,\
  File "C:\Python23\lib\site-packages\scipy_base\__init__.py", line 5, in ?
    import numerix
  File "C:\Python23\lib\site-packages\scipy_base\numerix.py", line 75, in ?
    from function_base import any, all
  File "C:\Python23\lib\site-packages\scipy_base\function_base.py", line 
3, in ?
    from numerix import ravel, nonzero, array, choose, ones, zeros, \
ImportError: cannot import name ravel
Traceback (most recent call last):
  File "setup.py", line 338, in ?
    setup_package()
  File "setup.py", line 314, in setup_package
    config_list += get_ext_configs_from_setups(ext_modules)
  File "setup.py", line 190, in get_ext_configs_from_setups
    config = setup_module.configuration(parent_package = parent_package)
  File "C:\projects\enthought\src\lib\enthought\kiva/agg\setup_agg.py", 
line 104, in configuration
    raise RuntimeError, "Unable to determine if Numeric has weakref 
support.  Unable to contibue building Kiva."
RuntimeError: Unable to determine if Numeric has weakref support.  
Unable to contibue building Kiva.

Re: build break

Bryce Hendrix wrote:
> I'm getting a build break when trying to build enthought. It started to
> fail around 9:30am this morning. Looking at the stack dump, it appears
> to be related to Numerix, but I didn't see anything in the changelog
> that would indicate responsibility for the failure. Here is the stack dump:
> 
> Traceback (most recent call last):
>  File
> "C:\projects\enthought\src\lib\enthought\kiva\agg\test_numeric_weakref.py",
> line 3, in ?
>    import weave
>  File "C:\Python23\lib\site-packages\weave\__init__.py", line 21, in ?
>    from scipy_test.testing import ScipyTest
>  File "C:\Python23\lib\site-packages\scipy_test\testing.py", line 794, in ?
>    from scipy_base.numerix import alltrue, equal, shape, ravel, around,
> zeros,\
>  File "C:\Python23\lib\site-packages\scipy_base\__init__.py", line 5, in ?
>    import numerix
>  File "C:\Python23\lib\site-packages\scipy_base\numerix.py", line 75, in ?
>    from function_base import any, all
>  File "C:\Python23\lib\site-packages\scipy_base\function_base.py", line
> 3, in ?
>    from numerix import ravel, nonzero, array, choose, ones, zeros, \
> ImportError: cannot import name ravel

That's a nice little circular import there. When did that change?

--

-- 
Robert Kern
robert.kern@...

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco