headers
Robert Kern | 6 May 2005 14:19
Favicon

[Envisage-dev] __svn_version__ and Python 2.4.1

I ran into a little snag when trying to compile the enthought package 
with Python 2.4.1 on OS X. The build halts early giving this (excerpted) 
error:

   File

"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy_distutils/misc_util.py", 
line 565, in generate_svn_version_py
     local_path = extension.local_path
AttributeError: Extension instance has no attribute 'local_path'

This doesn't show up for Python 2.3.x. I haven't tracked down the 
culprit here, but I have a feeling that the Extension object for 
__svn_version__ (which has local_path set immediately after its 
creation) is getting incompletely copied somewhere in the 2.4.1 
distutils process.

Joy.

In the meantime, turning off __svn_version__ in setup_enthought.py 
allows building.

--

-- 
Robert Kern
rkern@...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter
(Continue reading)

Permalink | Reply | 0 comments |
headers
David C. Morrill | 9 May 2005 20:49

[Envisage-dev] Traits goes to defcon 2

All,

A while back I mentioned that I wanted to remove the traits 1 deprecated 
function support from traits 2 before we ship the first public version.

Although its taken me a while to get around to it, I've finally checked 
in a change to traits that moves the deprecation warning level to 2. 
What this means is that all deprecated use of traits issues warning 
messages, but there is no automatic coercion of 'foo_changed' event 
handlers to '_foo_changed'.

Ideally, developers should not see any traits warning errors when 
running their code, and should not see any changed behavior (due to no 
'foo_changed' coercions taking place).

I'll make this a topic for next week's Enthought status meeting. If no 
one brings up any problems they hae encountered, then I will proceed to 
the final stage of removing the deprecation code. Besides removing lots 
of legacy code support, it will also remove one potential source for 
errors that currently exists...namely the 'foo_changed' coercion, which 
can actually break correct traits 2 code in some circumstance.

As a quick smoke test, I ran the current Converge app with the new 
warning level set and for the first time ever did not receive any traits 
warnings, and the app behaved as expected.

Dave M.
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 13 May 2005 19:46

[Envisage-dev] M2: feedback on new ".mv" file format

Hi,

Over the last several weeks I've been agonizing (off and on) over
"saving a visualization" with mayavi2 (which explains so few commits).
The core design of M2 is almost done and it is mostly functional.
However, you can't save a visualization to a ".mv" file.

MayaVi1 uses a simple approach to do this by using a pretty brain-dead
file-format.  M1 uses a flat ASCII file with no automatically
parseable structure.  Basically each module/filter/source writes
whatever it wants into the file and is responsible to deal with what
it wrote when opening the ".mv" file.  The fact that the file is ASCII
makes it possible to do interesting things by editing the .mv file.
For several reasons, I had decided to use a pretty-printed dictionary
instead for M2.

Saving a visualization could probably be achieved by picking mayavi
but I don't want to do this for several reasons.

 * Python's pickle, pickles too much and too many pickles can tickle
   the pickles out of you. (Sorry!)

   IOW, pickle ends up pickling almost everything under the sun and my
   general experience with it for robust and future-safe persistence
   has not been pleasant.  I thought of writing a special pickler that
   dumps dictionaries instead of a pickle but there are other
   problems.

 * pickling does not work perfectly with TVTK objects floating around.
   This is simply because it is impossible to pickle everything in a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Fernando Perez | 13 May 2005 19:55
Picon
Favicon

Re: [Envisage-dev] M2: feedback on new ".mv" file format

Prabhu Ramachandran wrote:

>  * Python's pickle, pickles too much and too many pickles can tickle

[...]

> I'd like to solicit some feedback on this.  So comments and
> suggestions are welcome.  If no one really has any better ideas, thats
> fine too.  Unless I or someone else gets any brighter ideas, I'm going
> to slowly start working on this over the course of the next week.

No bright ideas, just adding support from bitter experience to avoiding the 
pickle route.  I tried the same kind of 'save the universe' approach with 
pickle for ipython long ago, and it was a total disaster.  Pickle is useful 
for pickling small objects with relatively simple structures, but forget about 
it for these kinds of scenarios where you are trying to save the state of an 
entire (complex) program.

best,

f
Permalink | Reply | 0 comments |
headers
Stephen Waterbury | 13 May 2005 21:40
Picon

Re: [Envisage-dev] M2: feedback on new ".mv" file format

Prabhu Ramachandran wrote:
> For several reasons, I had decided to use a pretty-printed dictionary
> instead for M2.

I use a similar (perhaps identical) approach for saving
state in my PanGalactic application's client.  It might
be of interest to know that that approach is essentially
the same as "JavaScript Object Notation" (<json.org>).
While its syntax is "native" to Python, there are parsers
for it in several languages ... that might be useful.
(As mentioned on that site, that makes it a "standard"
format, based on the ECMA-262 standard for JavaScript,
but I don't know the details.)

Cheers,
Steve
Permalink | Reply | 2 comments |
headers
Peter Wang | 14 May 2005 00:51

[Envisage-dev] made some changes to Enable and Kiva

Hi everyone,

I just checked in (what should be) a minor change in Enable and Kiva. 
Basically EnableGraphicsContext is now subclassing Kiva's top-level 
GraphicsContext instead of the Agg backend's GraphicsContextSystem.  I also 
renamed the Kiva environment variable that specifies desired backends from 
CHACO_WISHLIST to KIVA_WISHLIST.  I have done some testing with CPLab and 
things seem to run fine with this change.

If you have no idea what I'm talking about, just keep this in mind: if you see 
any sort of graphics-level glitches or errors, or get any crashes that 
complain about graphics-library-y stuff, then drop me an email.

-peter
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 14 May 2005 09:48

Re: [Envisage-dev] M2: feedback on new ".mv" file format

>>>>> "Steve" == Stephen Waterbury <golux@...> writes:

    Steve> Prabhu Ramachandran wrote:
    >> For several reasons, I had decided to use a pretty-printed
    >> dictionary instead for M2.

    Steve> I use a similar (perhaps identical) approach for saving
    Steve> state in my PanGalactic application's client.  It might be
    Steve> of interest to know that that approach is essentially the
    Steve> same as "JavaScript Object Notation" (<json.org>).  While
    Steve> its syntax is "native" to Python, there are parsers for it
    Steve> in several languages ... that might be useful.  (As
    Steve> mentioned on that site, that makes it a "standard" format,
    Steve> based on the ECMA-262 standard for JavaScript, but I don't
    Steve> know the details.)

Thanks for the link to JSON.  I hadn't seen it before and it is an
interesting file format.  IIUC, the only trouble with it as a general
file-format is that you can't store floating point data with much
precision or efficiency.  For these cases I think PyTables/HDF5 is the
way to go.

I think I'm going to go for the more Pythonic solution of just storing
a dictionary either as a pickle or an ASCII file.

Thanks.

cheers,
prabhu
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Waterbury | 14 May 2005 19:34
Picon

Re: [Envisage-dev] M2: feedback on new ".mv" file format

Prabhu Ramachandran wrote:
> Thanks for the link to JSON.  I hadn't seen it before and it is an
> interesting file format.  IIUC, the only trouble with it as a general
> file-format is that you can't store floating point data with much
> precision or efficiency.  For these cases I think PyTables/HDF5 is the
> way to go.

Absolutely -- there is no contest.  I only plan to use
a JSON-like format for configuration files -- I don't
expect it to scale very well for real application data.

> I think I'm going to go for the more Pythonic solution of just storing
> a dictionary either as a pickle or an ASCII file.

Yes, the latter is exactly what I do -- I just found
JSON's similarity to pretty-printed Python dicts and
lists intriguing.  As far as "standard formats", JSON
isn't even on the radar in my domain, so I don't see
any benefit to becoming familiar with its details.
The Pythonic solution is better, IMO.

- Steve
Permalink | Reply | 0 comments |
headers
David C. Morrill | 18 May 2005 21:39

[Envisage-dev] Programming tip

All,

I just checked in a new module defining a couple of utility functions 
that I wrote to solve a messy design problem. Since this problem is 
fairly general, I thought I might describe briefly how these functions 
can be used to solve it...

Problem: You've written a nice event-driven piece of code, but the code 
can take a fair amount of time to run, and sometimes the events (which 
might be redundant) come in very close together. The net result can 
either be a lot of screen flicker caused by the event code performing 
multiple screen updates, or sluggish response caused by the event code 
taking too much time to respond to the individual events. What you'd 
like is to run the event code once after the event burst is over.

Solution: Use the 'do_later' and 'do_after' functions in the new
enthought.util.wx.do_later module.

For example, in my case I had the following event-driven method called 
whenever a change in the graph editor required the 'input editor' view 
to be refreshed:

def update_editor( self, canvas ):
    ...lots of time consuming GUI refresh code...

Sometimes a complex editing operation on the canvas would trigger 
several 'update' events, which would cause the 'update_method' to run 
several times in a row, causing a lot of screen flicker, and generally 
slowing things down unnecessarilly.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Prabhu Ramachandran | 20 May 2005 20:22

[Envisage-dev] GUI testing from Python

Hey folks,

Ever wondered how you can test GUI apps from Python?  I've been
looking for a free tool for this (under X) for a while and found
nothing of use apart from the Tcl based Android.  Nothing really solid
seems available for this in Python apart from some 'SendKeys' recipes
for Win32 on ASPN.

Last Sunday I chanced upon Perl's X11::GUITest.  On Wednesday I ported
this Perl module to Python.  It really was an irresistible urge, I had
a million other things to do, but I could not resist the urge to do
this.  Anyway, I have something that works under X11.  You can do the
following things,

  * get the root window
  * get children of a given window,
  * get the name of a window,
  * move/resize/iconify/raise/lower any window
  * move the mouse
  * click the mouse (any mouse button)
  * send _any_ keystroke
  * get/set the focus
  ...

all from Python.  This works regardless of GUI toolkit or programming
language even.  It could be used under X11 via VNC to test Win32 apps
but thats pushing it a bit.  Docs for the perl module are here:

  http://search.cpan.org/dist/X11-GUITest/GUITest.pm
(Continue reading)

Permalink | Reply | 0 comments |

Gmane