headers
Prabhu Ramachandran | 1 May 10:31
Picon
Gravatar

Re: ImportError problem with test_array_handler.py under TVTK

>>>>> "John" == John Lindner <john.lindner@...> writes:

    John> I am having a problem with the test_array_handler.py script
    John> under enthought.tvtk-1.0.0_r10588-py2.4-win32.egg (it is
    John> called when I try to run MayaVI). Running it with Python 2.4
    John> returns the following error message:

    John>     Traceback (most recent call last): File
    John> "test_array_handler.py", line 12, in ?  from enthought.tvtk
    John> import array_handler File
    John> "c:\python24\lib\site-packages\enthought.tvtk-1.0.0_r10588-py2.4-win32.eg
    John> g\enthought\tvtk\array_handler.py", line 25, in ?  from
    John> enthought.tvtk.array_ext import empty_array,
    John> set_id_type_array ImportError: No module named array_ext

It seems that the array_ext package (for Numeric) was not built with
the egg.  To make TVTK use the numpy package set the environment
variable NUMERIX=1 and things should work.  

Should we have enthought.util.numerix default to numpy?

cheers,
prabhu
Permalink | Reply | 2 comments |
headers
Prabhu Ramachandran | 1 May 12:07
Picon
Gravatar

Re: Problems using PyInstaller

>>>>> "Eirik" == Eirik Svendsen <eirik@...> writes:

    Eirik> Hello, I am trying to build an .exe file of my application
    Eirik> with PyInstaller, but I keep getting import errors such as
    Eirik> this when trying to run the .exe file:
[...]
    Eirik> Has anyone encountered this or similar problems? Any
    Eirik> suggestions regarding how to solve this problem will be
    Eirik> highly appreciated. Also, if anyone knows about an
    Eirik> alternative way of buliding executables where
    Eirik> envisage/wx/traits are involved I will be most grateful to
    Eirik> hear them (I have already tried py2exe without getting it
    Eirik> to work).

I don't think anyone has had success using these tools to bundle ETS
apps.  I haven't tried so can't help either.

cheers,
prabhu
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 1 May 12:08
Picon
Gravatar

Re: All now working

>>>>> "Rob" == Rob  <rob@...> writes:

    Rob> Thanks Bryce and Prabhu, All examples seem to be working now.
    Rob> (except Kiva/agg)

What fixed the wxversion problems?

cheers,
prabhu
Permalink | Reply | 5 comments |
headers
Prabhu Ramachandran | 1 May 14:03
Picon
Gravatar

Re: Update on mayavi mlab refactoring

>>>>> "Gael" == Gael Varoquaux <gael.varoquaux@...> writes:

    Gael> I have worked a bit on mayavi mlab. I am hacking at it with
    Gael> a big axes and many things have been modified. I think it is
    Gael> time to ask the list a few technical questions (Prabhu :->
    Gael> ?) and discuss some possible changes.

Sorry about the super delayed response.  The semester is done and I
now have a bit of time.

    Gael> The goal I have set for mayavi.mlab is to provide a simple
    Gael> procedural way of controling mayavi from python to do simple
    Gael> visualization. I want it to be mainly procedural and similar
    Gael> to pylab for ease of use for newcomers.  However procedure
    Gael> can return objects (just like in pylab) which opens the path
    Gael> to some object oriented controls, which is nice when you are
    Gael> writing eg. and interactive program. How do people feel
    Gael> about so a goal ?

Sounds good.

    Gael> While modifying mlab I have identified 5 types of procedures
    Gael> :

    Gael>  1 Functions to create the data. They create the first node
    Gael> of a VTK tree. They have no current equivalent in mayavi2.

    Gael>  2 Functions to apply a module or a filter to the data. They
    Gael> create the module manager and the nodes further down the
    Gael> tree. They correspond the menu entries in the Visualize
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gary Pajer | 1 May 16:22
Picon

Re: My traitsUI tutorial is finally out

On 4/29/07, rharder@...
<rharder@...> wrote:
>
> Gael Varoquaux wrote:
> > Hi all,
> >
> > It took me ages, but I finally got a first version of my tutorial out. I
> >
>
> This tutorial has been great.  It's got me thinking about ETS again.
> A while back I asked for a simple Envisage App example which Prabhu
> graciously produced.  It's still been difficult for me to wrap my head
> around though.
>
> [...]

I'm surprised no one has commented.

Your point is a good one, and I suspect that the Enthought people are
fully aware:  to reach the target physicists (as an example)  docs
along the lines of what you suggest will be needed.   But those people
are clearly very busy judging by how fast and how much the svn
changes.  They could have kept the whole thing to themselves and
completely avoided the task of helping us.  But they didn't.

I agree with you.  Learning Envisage is slow work, and is done mostly
(at the moment) by osmosis:  copy something, change it to suit and in
the process learn a bit more.  I'm still well within the
copy-and-change group.
(Continue reading)

Permalink | Reply | 1 comment |
headers
bryce hendrix | 1 May 16:37

Re: ImportError problem with test_array_handler.py under TVTK

Prabhu Ramachandran wrote:
"John" == John Lindner <john.lindner-gGG0hiypDniOBs8FqcNp8A@public.gmane.org> writes:
John> I am having a problem with the test_array_handler.py script John> under enthought.tvtk-1.0.0_r10588-py2.4-win32.egg (it is John> called when I try to run MayaVI). Running it with Python 2.4 John> returns the following error message: John> Traceback (most recent call last): File John> "test_array_handler.py", line 12, in ? from enthought.tvtk John> import array_handler File John> "c:\python24\lib\site-packages\enthought.tvtk-1.0.0_r10588-py2.4-win32.eg John> g\enthought\tvtk\array_handler.py", line 25, in ? from John> enthought.tvtk.array_ext import empty_array, John> set_id_type_array ImportError: No module named array_ext It seems that the array_ext package (for Numeric) was not built with the egg. To make TVTK use the numpy package set the environment variable NUMERIX=1 and things should work. Should we have enthought.util.numerix default to numpy?

The eggs are built with NUMERIX=numpy, I'm not sure why it didn't build array_ext with numpy. Maybe the clean step of the build doesn't clean array_ext? I'll manually clean it out & watch the build steps.

bryce

_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 1 comment |
headers
Dave Peterson | 1 May 17:44

Re: My traitsUI tutorial is finally out

rharder@... wrote:
> I'd have to say that my "problem", for lack of a better word, with ETS  
> is that I look at the examples and I just don't understand what all of  
> the bits are for.

I certainly wish we had more time to document all the ETS packages, 
particularly Envisage, much better!  We know this is a problem for 
community uptake of the technologies and are trying to make time to 
improve / develop this documentation, it is just slow going giving the 
necessity of satisfying paying customers so that we can continue to 
exist.  That said, if you continue to e-mail this list with questions 
you have, or point out areas where the docs are lacking, we can probably 
provide much more timely information to you and help you ramp up on the 
tools.

> # The plugin definitions required by the application.
> PLUGIN_DEFINITIONS = [
> 	    # Envisage plugins.
> 	    join(envisage_path, 'core/core_plugin_definition.py'),
> 	    join(envisage_path, 'action/action_plugin_definition.py'),
> 	    join(envisage_path, 'resource/resource_plugin_definition.py'),
> 	    join(envisage_path, 'workbench/workbench_plugin_definition.py'),
> 	    join(envisage_path, 'workbench/action/action_plugin_definition.py'),
> 	    join(enthought_plugins_path, 'python_shell  
> python_shell_plugin_definition.py'),
> 	    join(enthought_plugins_path,  
> 'text_editor/text_editor_plugin_definition.py'),
>
> 	    # Application plugins.
> 	    join('app_plugin_definition.py'),
> 	]
>
> What is all this stuff?  How would I know, starting from scratch with  
> an empty editor, that this needs to be here?  I wasn't even able to  
> find documention for the join command!
>   

I believe the Envisage section of the Enthought wiki does indicate that 
you must provide a listing of the plugins that you want your application 
to be composed of, and does say that each item in the list should be the 
absolute path to the plugin_definition.py file. 

The join command is just a convenience to do that and it was imported 
from a specific package/module, so you could always look up what it does 
there, right?  You can always browse the source online through our Trac 
instance if you don't want to expand the eggs, etc.

If the question is what are each of these plugins and why do you need 
them, the answer is that they aren't really 'necessary' to build an 
Envisage app.  They are only needed if you want to use the capabilities 
in each of these plugins.  A delicate line, yes, but a critical one!  
Envisage itself is just a small tool that manages plugins and provides 
mechanisms for them to communicate with each other.  It does not enforce 
any look, feel, or behavior on your application at all since all of that 
comes from plugins that make up your application, including the GUI 
itself!  Therefore, these plugins in Prabhu's example app are totally 
optional from the Envisage point-of-view!

Now, specifically, each of those plugins does roughly the following.  
You should be able to figure out more by reading the 
plugin_definition.py files themselves.

    core: Additional utilities and concepts for building 
plugin-applications but not required for an Envisage app.

    action: A mechanism for declaring user actions and grouping them 
into menus and toolbars.

    resource: A method of associating meta info (persistence, look and 
feel, etc.) with specific data types.

    workbench: An "IDE like" GUI provider.

    workbench action: Allows extension of the menubar and toolbar within 
the workbench GUI.

    python shell: An interactive console to the Python interpreter 
within the workbench GUI.

    text editor: Menu items to load, edit, and save text files within 
the workbench GUI.  If the file is a Python script, it can also be run 
and interact with the Python interpreter.

    app plugin: The plugin providing the new behavior of Prabhu's 
example application that is not listed in these other plugins.

Enthought has generated many, many, many plugins for Envisage 
applications and the set above is only a small portion of those, though 
it is probably the most commonly used subset.

Hope this helps somewhat!

-- Dave
Permalink | Reply | 0 comments |
headers
Martin Chilvers | 1 May 18:29
Picon

Re: My traitsUI tutorial is finally out

G'day,

> Snippet from plugin_definitions:
> # The plugin definitions required by the application.
> PLUGIN_DEFINITIONS = [
> 	    # Envisage plugins.
> 	    join(envisage_path, 'core/core_plugin_definition.py'),
> 	    join(envisage_path, 'action/action_plugin_definition.py'),
> 	    join(envisage_path, 'resource/resource_plugin_definition.py'),
> 	    join(envisage_path, 'workbench/workbench_plugin_definition.py'),
> 	    join(envisage_path, 'workbench/action/action_plugin_definition.py'),
> 	    join(enthought_plugins_path, 'python_shell  
> python_shell_plugin_definition.py'),
> 	    join(enthought_plugins_path,  
> 'text_editor/text_editor_plugin_definition.py'),
> 
> 	    # Application plugins.
> 	    join('app_plugin_definition.py'),
> 	]
> 
> What is all this stuff?  How would I know, starting from scratch with  
> an empty editor, that this needs to be here?  I wasn't even able to  
> find documention for the join command!

Funny you should mention this... we are currently having a sweep though 
Envisage trying to simplify it wherever we can, and we've been looking at ways 
to make this particular bit more obvious.

To recap:-

An Envisage application is simply a collection of co-operating plugins. Plugins 
currently consist of two pieces:-

1) A plugin definition (mandatory)

This is where the plugin's extension points and contributions are defined, and 
the plugin implementation class (if required is specified).

2) A plugin implementation (optional)

This is where the plugin can use any contributions made to its extension points 
to create and publish application objects.

So when you create a new instance of 'Application' you really just want to tell 
it which plugin definitions you want to include in it.

Now our old strategy for doing this was based on absolute filenames, because at 
the time we used to put code into our package '__init__.py' files which meant 
that we couldn't just import a plugin definition module without importing 
nearly everything in every package! This is obviously a huge pain, doesn't 
scale and makes application startup time horrendous. Hence we came up with a 
way of snarfing the plugin definitions out of modules without touching the 
surrounding package via the absolute filename malarky.

Since then of course, us, and pretty much the whole Python community has 
switched to using api.py files to advertise the API from a package, and hence 
all of our __init__.py files are (or soon will be) empty (since this is a 
requirement for Eggs anyway).

Now that we are nearly there it seems like time to simplify things, so here are 
some thoughts...

It seems to me that in the simplest case I might want to to create an 
application and pass in a list of plugin definition instances:-

e.g.

# Enthought library imports.
from enthought.envisage.api import Application

# MyCompany imports ;^)
from mycompany.foo_plugin_definition import FooPluginDefinition
from mycompany.bar_plugin_definition import BarPluginDefinition

application = Application(
     id                 = 'mycompany.myapplication',
     plugin_definitions = [FooPluginDefinition(), BarPluginDefinition()]
)

application.start()

Now, I might also want to just pass in the plugin definition *classes* and have 
Envisage create the instances for me... (no biggie, but one less thing for me 
to do)...

e.g.

<... snip ...>

application = Application(
     id                 = 'mycompany.myapplication',
     plugin_definitions = [FooPluginDefinition, BarPluginDefinition]
)

<... snip ...>

I might also want to take the list of plugin definitions out of the application 
constructor entirely, maybe into a configuration file (based on the syntax used 
by ConfigObj):-

e.g.

In mycompany.myapplication.ini

[mycompany.myapplication.plugins]
foo = foo_plugin_definition.FooPluginDefinition
bar = bar_plugin_definition.BarPluginDefinition

and now the application creation is simply...

# Enthought library imports.
from enthought.envisage.api import Application

application = Application(
     id  = 'mycompany.myapplication'
)

application.start()

This assumes of course that by default the application has a configuration 
system that looks for a configuration file with the same name as the 
application's Id.

I might also want to specify the plugin definitions as Egg entry points 
although I'm not to clear about how we would do that since the plan for the ETS 
  deployment is using Eggs and we would need some way to say *which* plugin 
definitions were needed for a particular application Id.

Comments? Thoughts? Complaints?

Martin
Permalink | Reply | 5 comments |
headers
David C. Morrill | 1 May 18:43

Re: My traitsUI tutorial is finally out

Gary Pajer wrote:
> I agree with you.  Learning Envisage is slow work, and is done mostly
> (at the moment) by osmosis:  copy something, change it to suit and in
> the process learn a bit more.  I'm still well within the
> copy-and-change group.
>   

Actually, that's the same way that most of us non-Envisage developers 
here at Enthought do it too :-) No shame in that!
> Traits / Traits UI  itself takes some getting used to.  I was very
> confused until I wrote my own version of Gael's example using pure
> MVC.  With that I began to catch on and started using shortcuts.  I'm
> still much in the dark concerning Envisage,  but I must say that I
> took a Traits application and mimicked the process for creating an
> Envisage app, and it worked at the first shot.  No changes at all to
> the original Traits code.  Black magic.
>   

Actually it's not black magic. One of the things we've spent some time 
working on this last year is trying to make creating plug-ins simpler. 
And one of the techniques we've worked on is the ability to easily 
convert a Traits UI based "app" into an Envisage plug-in with little or 
no change to the "app" code. And I think we've (for the most part) 
succeeded in doing this, as you have found out. What remains to be done 
is to develop docs/tutorials showing just how easy the process is becoming.
>
> BTW, I also get excited when I see some new docs on the web page.
> It's like opening a birthday present ...
>   

While I'm not working on Envisage, I am busy preparing a new version of 
Traits (version 2.1) that should be ready Real Soon Now. One of the 
things I'm working on (even as we speak), is a set of interactive 
tutorials that will document what's new and improved in Traits 2.1. So 
happy birthday :-)

Dave Morrill
Permalink | Reply | 0 comments |
headers
Bryce Hendrix | 1 May 18:43

Configuring envisage plugins (was 'My traitsUI tutorial is finally out')

Martin Chilvers wrote:
> ...
> This assumes of course that by default the application has a configuration 
> system that looks for a configuration file with the same name as the 
> application's Id.
>
> I might also want to specify the plugin definitions as Egg entry points 
> although I'm not to clear about how we would do that since the plan for the ETS 
>   deployment is using Eggs and we would need some way to say *which* plugin 
> definitions were needed for a particular application Id.
>
> Comments? Thoughts? Complaints?
>
> Martin
>
>   
I think egg entry points is the obvious way to go. The question I have 
is where do you intend to put the discovery code and how to configure an 
app to require a set of plugins (I know, same question you had)? Doesn't 
eclipse combine these two, and just auto-load any plugins in a set of 
directories? Perhaps the app can define where to look for plugins, not 
which plugins to look for?

For those interested, here's the description of how to use setuptool's 
"entry points":
http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins

Bryce

> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev@...
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
Permalink | Reply | 1 comment |

Gmane