headers
Jaap Spies | 2 Dec 22:31
Favicon

Re: Installing ETS-3.0.3 in Sage

Robert Kern wrote:
> On Mon, Dec 1, 2008 at 19:43, Jaap Spies <j.spies@...> wrote:
>> Robert Kern wrote:
> 
>>> Let's check a couple of other things. At the shell:
>>>
>> Ok, just before I go to sleep (2.30 AM local time)
>>
>>> $ locate "*site.cfg"
>> [jaap <at> paix sage-3.2.1.rc0]$ locate "*site.cfg"
> 
>> /home/jaap/work/downloads/sage-3.2.1.rc0/local/lib/python2.5/site-packages/numpy/distutils/site.cfg
> 
> Okay, I see the problem. The spkg-install creates this file with a
> [DEFAULT] section. This overrides all of the defaults in
> system_info.py.

I think this is a real design issue. Why use the crappy numpy distutils to get system info.
I think there are better (more portable) ways to get this info.

Jaap
Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 2 Dec 20:15

Re: [M2] New source names?

Gael Varoquaux wrote:
>>> GlyphFactory is seems a little too vague.  SurfaceFactory seems a little
>>> too generic.  Or SimpleSurface/SimpleGlyph or ShapeFactory?  This is a
>>> pain.
> 
>> Technically, I like GlyphFactory and maybe SurfaceFactory.  Thinking about a 
>> MayaVi user's POV, I would suggest something like "Built-in Surfaces" and 
>> "Built-in Images"; maybe that (mangled) could lead to class names as well.
> 
> Yeah, "BuiltInImage" and "BuiltInSurface" seems nice (no plural, to be
> consistent with "ParametricSurface".

I'm going for BuiltinImage and BuiltinSurface (Python's builtin is 
called __builtin__ and not __built_in__) then and will commit this shortly.

Thanks for the feedback.

cheers,
prabhu
Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 2 Dec 19:32

Re: [mv2] Object editor fails for some modules

B. P. Thrane wrote:
>> This is very strange since the warnings are explicitly disabled for this 
>> operation.  Anyway, could you please try the following code:
>>
>> $ cd enthought/mayavi/tests
>> $ ipython
>>
>> from enthought.tvtk.api import tvtk
>> r = tvtk.XMLUnstructuredGridReader(file_name='data/pyramid_ug.vtu')
>> r.update()
>> ug = r.output
>> w = tvtk.DataSetWriter(write_to_output_string=1)
>> w.set_input(ug)
>> w.update()
>> s = w.output_string
>> print s
>> r = tvtk.DataSetReader(read_from_input_string=1, input_string=s)
>> r.update()
>> print r.output
>>
>> It seems like you end up getting a None at the end.  You might get some 
>> warnings in between but ignore them for now.  Could you tell me if this 
>> works at all?  Does "print s" print anything useful?
>>
>>   
> Here is the output:
> In [9]: print s

It looks like this does work!  Very weird.  Would you mind helping 
resolve this off-list with a few simple print statements to help?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 2 Dec 19:23

Re: [mv2] LUT, ImagePlaneWidget and custom import module

B. P. Thrane wrote:
>     r = tvtk.StructuredPoints(origin=zzz.origin(), 
> dimensions=zzz.dims(), spacing=zzz.spacing())
>     r.point_data.scalars = zzz.datadict["Var1"]
>     r.point_data.scalars.name = 'Var1'
>     r.update()
> 
>     src = VTKDataSource(data=r)
>     return src
> 
> I've tried setting scalar_type='float' in the call, but that doesn't 

In which call?  Could you try this:

  id = tvtk.ImageData()
  id.scalar_type = 'float'
  id.set(origin= ...)
  id.update()
  src = VTKDataSource(data=id)
  return src

> help. What I cannot figure out is how the set the lookup table to 
> default, as you have to when you write to file using 
> StructuredPointsWriter.

Hmm, strange, I have never needed to set this at all.

A reproducible example would really help.

cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 2 Dec 19:09

Re: [mv2] Filter UserDefined:ImageMathematics on Windows

B. P. Thrane wrote:
> When using the filter UserDefined:ImageMathematics on the WindowsXP 
> platform, MayaVi2 hangs (trunk version under the latest Python(x,y)). On 

Well, UserDefined is a bit dangerous so caveat emptor. :)

[...]
> Maybe setting a different default operator in the filter will be a 
> work-around, but it may hang anyway if you select an operator that 
> requires two inputs? Anyway, how to get two inputs into this filter in 
> MayaVi2? This is typically easier in a network based user interface. In 
> the MayaVi2 tree editor, it doesn't seem to be possible, a script seem 
> to be the only solution.

It is harder on the tree interface but doable.  The trick is to use a 
"drop editor" and allow a user to drag and drop the second input to 
this.  This is what you can do with the texture support -- drag and drop 
an image reader (or image data) node on the texture source object dialog 
(which should be cyan colored).

One nice filter would be a multi-input user defined filter that exposes 
just such a UI.

I really wish we had a usable network editor UI in ETS that we could use 
for this sort of thing.  It would really be convenient and I'm sure I'd 
be interested in taking a stab at using it.

cheers,
prabhu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Varun Hiremath | 2 Dec 16:30

Re: Installing ETS on a Debian (Sid) System

Hi,

On Sun, Nov 30, 2008 at 11:37 PM, Ed Swarthout <else-bs+DcK7cjk954TAoqtyWWQ@public.gmane.org> wrote:
On Thursday 20 November 2008 09:45:55 pm Varun Hiremath wrote:
>
> Thanks for testing the packages.

I installed everything from http://newpeople.debian.org/~ varun on my i386
Lenny machine and only found one problem when running mayavi2.
I fixed it by manually installing python-configobj from Lenny:

$ mayavi2
Traceback (most recent call last):
 File "/usr/bin/mayavi2", line 451, in <module>
   raise e
ImportError: No module named configobj
________________________________________________________________________________
Could not load envisage. Do you have the EnvisageCore and EnvisagePlugins
installed?
...

Thanks, that looks like a missing dependency. I shall add that.

Regards,
Varun
_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 0 comments |
headers
Jaap Spies | 2 Dec 15:42
Favicon

Re: Installing ETS-3.0.3 in Sage

Robert Kern wrote:
> On Mon, Dec 1, 2008 at 19:43, Jaap Spies <j.spies@...> wrote:
>> Robert Kern wrote:
> 
>>> Let's check a couple of other things. At the shell:
>>>
>> Ok, just before I go to sleep (2.30 AM local time)
>>
>>> $ locate "*site.cfg"
>> [jaap <at> paix sage-3.2.1.rc0]$ locate "*site.cfg"
> 
>> /home/jaap/work/downloads/sage-3.2.1.rc0/local/lib/python2.5/site-packages/numpy/distutils/site.cfg
> 
> Okay, I see the problem. The spkg-install creates this file with a
> [DEFAULT] section. This overrides all of the defaults in
> system_info.py. Unfortunately, there isn't a terribly convenient way
> out of this. numpy's spkg-install could make individual sections for
> those it is going to use to build scipy:
> 
> [lapack_opt]
> library_dirs = ...
> include_dirs = ...
> 
> [blas_opt]
> library_dirs = ...
> include_dirs = ...
> 
> [fftw]
> library_dirs = ...
> include_dirs = ...
> 
> This would leave [x11] with the correct defaults in system_info.py.
> 

Ok, thanks! I'll contact the maintainers of the package.

There will be an update to numpy-1.21 shortly (next week or so).

But in the mean time is there a possibility to get chaco running?

Jaap
Permalink | Reply | 0 comments |
headers
Martin Chilvers | 2 Dec 13:45

Proposal to change the declaration of Envisage plugins in eggs...

G'day,

As some of you may know Envisage ships with a plugin manager that harvests plugins from eggs (the 
'EggPluginManager'). The egg plugin manager is very simple(istic!) as it assumes that every plugin 
in every egg in the working set (i.e. on sys.path) should be included in your application.

Now, (not coincidentally!), that works just fine for the way that we here at Xype distribute our 
applications! We put all of the eggs that are used in an application into what we call an 'egg 
basket' and dynamically add the eggs to the working set when the application starts up.

However, this approach does not work nicely if you don't use the egg basket approach and you want to 
specify a subset of the plugins on your path to make up your application (which BTW, is how most of 
the egg-based test cases and examples work).

The 'EggPluginManager' already supports the notion of an 'include' list, which is simply a list of 
the Ids of the plugins that you want to actually use (we should also have an 'exclude' list of 
course, but I'll defer that to another test case ;^). Howeever, the problem with the current scheme 
is that we don't know the Id of a plugin until we have imported and instantiated it which is quite 
smelly if you ask me!

To fix this, I propose changing the way we declare plugin entry points in 'setup.py' modules.

Currently, it looks something like this (taken from the MOTD example):-

     entry_points = """

     [enthought.envisage.plugins]
     motd = acme.motd.motd_plugin:MOTDPlugin

     """

The left-hand-side (LHS) of the expression is currently not used anywhere - it just has to be there 
because that is how you declare egg entry points. My suggestion is that we make the LHS meaningful 
and set it to be the same as the plugin Id like so:-

     entry_points = """

     [enthought.envisage.plugins]
     acme.motd = acme.motd.motd_plugin:MOTDPlugin

     """

Now this means that plugin managers like the egg plugin manager can *completely* ignore plugins that 
they are not interested in, which means that you can have applications that use a subset of the eggs 
on sys.path and it is easier to write test cases/examples etc.

One obvious downside is the duplication of the plugin Id as it would still have to be in the plugin 
itself so that the plugin is useable in a non-egg environment.

Thoughts?

Martin
Permalink | Reply | 1 comment |
headers
Robert Kern | 2 Dec 02:20

Re: Installing ETS-3.0.3 in Sage

On Mon, Dec 1, 2008 at 18:51, Jaap Spies <j.spies@...> wrote:
> Robert Kern wrote:
>> On Mon, Dec 1, 2008 at 18:28, Jaap Spies <j.spies@...> wrote:
>>> Robert Kern wrote:
> /lib', 'search_static_first': '0'}
>>
>> Okay, that's just odd. Did the Sage packager of numpy modify
>> numpy/distutils/system_info.py at all?
>
> I asked around, but with no reslut yet.

I've looked at the numpy-1.2.0.p0.spkg, and there doesn't seem to be
anything suspicious. Is that the version of numpy you have installed?

>> Anyways, the workaround is to make a file ~/.numpy-site.cfg with the contents
>>
>> [x11]
>> library_dirs=/usr/lib
>> include_dirs=/usr/include
>>
>
> Don't know. How will this help installing ets with my install-pkg?

This file will tell numpy.distutils (and consequently Enable's setup
scripts) to look in those locations for the X11 libraries and headers
and ignore the defaults. The defaults appear to be broken in your
installation; I don't know why.

> Not only for me, but also for the person who downloads this package?

If Sage's numpy has been altered somehow to not look in the default
locations for X11, then the user will need to provide a
~/.numpy-site.cfg file to tell it.

> To be honnest I had no idea that numpy is causing this trouble!

We use numpy.distutils to build the extension modules in Enable. In
particular, we use its configuration system to discover where the X11
libraries are located. There are defaults set in that module that
should have discovered your X11 libraries. I'm not really sure why
they are different.

Let's check a couple of other things. At the shell:

$ locate "*site.cfg"

>From Python:

from numpy.distutils import system_info
print system_info.default_x11_lib_dirs
print system_info.default_x11_include_dirs
print system_info.default_lib_dirs
print system_info.default_include_dirs

--

-- 
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
Permalink | Reply | 1 comment |
headers
Jaap Spies | 1 Dec 20:41
Favicon

Re: Installing ETS-3.0.3 in Sage

bryce hendrix wrote:
> Jaap Spies wrote:
>> bryce hendrix wrote:

> 
> Strangely, distutils used the X11 headers, but didn't bother to link 
> with the X11 library. You might have success setting your LD_FLAGS 
> environment variable, "LD_FLAGS=-lX11", then rebuilding Enable.
> 

Rebuilding with "LD_FLAGS=-lX11" gives the same result :(

Jaap

> Bryce
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev@...
> https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 7 comments |
headers
bryce hendrix | 1 Dec 20:41

Re: Installing ETS-3.0.3 in Sage

Jaap Spies wrote:
bryce hendrix wrote:
Jaap Spies wrote:
bryce hendrix wrote:
Jaap Spies wrote:
Hi, I gathered some circumstantial evidence: [jaap <at> paix examples]$ ldd /home/jaap/downloads/sage-3.2.1.rc0/local/lib/python2.5/site-packages/Enable-3.0.2-py2.5-linux-i686.egg/enthought/kiva/agg/_plat_support.so linux-gate.so.1 => (0x00110000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0011f000) libm.so.6 => /lib/libm.so.6 (0x00211000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0023a000) libpthread.so.0 => /lib/libpthread.so.0 (0x00248000) libc.so.6 => /lib/libc.so.6 (0x00289000) /lib/ld-linux.so.2 (0x0026b000) ... But where it is defined?
Ah, its coming back to me now... The method is part of the Xlib API and the real issue here is that _plat_support.so is not linked with it. You will probably see some warning in the install log about not being able to find the X library, but the build will continue. Do you have XFree86-devel installed? If so, please attach the log file in this thread (gz it if its too big).
No, I don't see any XFree* installed. The part of the install log regarding enable can be found here: http://sage.math.washington.edu/home/jsp/tests/enable_install.log.gz
Strangely, distutils used the X11 headers, but didn't bother to link with the X11 library. You might have success setting your LD_FLAGS environment variable, "LD_FLAGS=-lX11", then rebuilding Enable.
I rather see this happen in source because the install-script is run automatically.

I would to, but we need to know if this fixes the problem on your platform :) 
_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 0 comments |

Gmane