matplotlib-users Mailing List for matplotlib

John,

Attached are a slightly modified lines.py, based on CVS download this 
morning, and a demo of plotting masked arrays.

The changes to lines.py are:

1) additional function imports from numerix
2) importing numerix.ma
3) a new function at the top of the file, unmasked_index_ranges.
4) changes to the draw and set_data methods
5) docstring indentation

I think that with these fairly small changes, the plot command (or 
anything that uses Line2D to make lines or sets of markers) will work 
exactly the same as before with unmasked data, and will work correctly 
with masked data.   That is, only the valid points will be plotted, and 
lines will be broken at gaps.

I went for the simplest and least-intrusive changes I could find; maybe 
drawing the line segments could be improved by using the line collection 
renderer instead of a loop over ordinary line segments.  It could also 
be optimized by not plotting line segments (as opposed to markers) when 
there is only one point.  Let me know if you want me to look into any of 
these things; for now, I just wanted to get something working.

The unmasked_index_ranges function, or some variation of it, might be 
useful outside lines.py.  There are many ways it could be altered.  I 
chose the 2-D array return, as opposed to a sequence of tuples, or a 
pair of 1-D arrays, in the hopes that it would be clear, efficient, and 
flexible; for example, it makes calculation of line segment lengths 
doable with a single "diff".

In lines 263,264 of lines.py I put a question, not directly relevant to 
the changes I made, but pointing to what may be a minor oversight.

I hope I haven't overlooked anything major!

If all this is going in the right direction, I will add masked array 
support to contour.py later this week.  It should be trivial.  I would 
then be inclined to remove the "experimental" kwarg, badmask.

Finding the bug in filled contours with masking remains to be done.

Eric

Every once in a while, when enough new features have been added and
the nasty bugs ironed out, I tick the major version number and post a
matplotlib release to the general python commuity.  These releases are
really just bug fix releases of the last release in disguise :-)

I just uploaded matplotlib-0.80 to the web site.  If you folks could
be kind enough to give this a test drive and let me know if you hit
any snags, I'd be much obliged.  If all goes well, I'll do the general
release tomorrow.

What's new in 0.80

kwargs to xlim, ylim, axis

  Applied a variant of Rick Muller's xlim/ylim/axis patch. These
  functions now take kwargs to let you selectively alter only the min
  or max if desired. Eg xlim(xmin=2) or axis(ymax=3). They always
  return the new lim. See, eg help(xlim). The same functionality is
  available in the API with ax.set_xlim and ax.set_ylim .

wx fixes

  Fixed a problem with wx app instantiation. Incorporated Werner's wx
  patch -- wx backend should be compatible with wxpython 2.4 and
  recent versions of 2.5. Some early versions of wxpython 2.5 will not
  work because there was a temporary change in the dc API that was
  rolled back to make it 2.4 compliant

Polygon editors

  Added some proof of concept code to show how to use matplotlib to
  interact with plot elements in a GUI neutral way. The editable
  polygon allows you to insert, delete and move vertices. See
  examples/poly_editor.py. The idea it to add interactor classes to
  support editable lines, text, polygons, etc. This could support a
  cross GUI colormap editor, or spline editor, for example.


http://matplotlib.sf.net


Thanks!
JDH

Hi John,

Changing in pylab.py all the .__doc__ where either __doc__ + (only 1) or 
_shift_string (40 lines) is used to something along these lines:

if not Axes.axhline.__doc__ == None:
     axhline.__doc__ = _shift_string(Axes.axhline.__doc__) + """
     Addition kwargs: hold = [True|False] overrides default hold state"""

This allows to use the py2exe/Python "Optimize: 2" option again and 
still have documentation available.

Just tested it with the simple_plot_wxagg sample.

See you
Werner

P.S. Attached the file for your perusal.

On Apr 12, 2005 3:13 PM, John Hunter <jdh...@ac...> wrote:
> I saw the exact same thing but it appeared to come and go as I made
> minor tweaks to the setup, and could never figure out why I sometimes
> got this error and sometimes did not.  I added nummaray to the
> packages list.
> 

I've googled on this but never found anything definitive. It'd be good
if someone figured out what's happening as it's a fairly nasty error,
but it's just easier to remember to stick that package in the packages
list.

> Yep, this is mentioned in the comment header of setup.py for the gtk
> example (and in the FAQ).  Still, it's easy to miss, as I spent about
> 15 minutes trying to figure out what was going wrong (it had been many
> months since I wrote the example) before I read my own comment.  I
> added a print reminder to setup.py.
> 

(cough) Continuing my fine tradition of missing the helpful bits in
documentation and comments.

> Curious to know if this works for Andrea too.  It appears to work for
> me with py2exe 0.5.4
> 

I hope this works as it makes life a lot easier all round. If it
doesn't I'd definitely suspect a bug in py2exe.

>     Michael> I've attached a diff showing the minor modifications I
>     Michael> made.
> 
> Thanks, I've updated the examples on the site.
> 
> I also saw your comment on the py2exe matplotlib wiki.  I changed the
> init method slightly -- could you test this on your setup to make sure
> it works
> 

Oh yeah, I'd forgotten about that wiki comment completely.

I'll test the changed code this afternoon, thanks.

cheers,
  Michael

>>>>> "Sajec," == Sajec, Mike TQO <ms...@tq...> writes:

    Sajec,> Is there a simple way to grab x,y coordinates from active
    Sajec,> plot in a manner similar to using matlab's ginput()
    Sajec,> function?

It depends on what you mean by simple :-)

matplotlib provides a GUI independent way to capture basic events, eg
to get the mouse coordinates in screen and data units and button
clicks, key presses, etc.

See http://matplotlib.sourceforge.net/tutorial.html#events

Some people do not find callbacks intuitive.  If you are one of these
people, you might try something like the following


from pylab import *

class MouseMonitor:
    event = None
    def __call__(self, event):
        self.event = event


mouse = MouseMonitor()
connect('button_press_event', mouse)

plot([1,2,3])


Now you can click on the plot, and get the coords like so

print mouse.event.xdata, mouse.event.ydata


See
http://matplotlib.sourceforge.net/matplotlib.backend_bases.html#MouseEvent
for more information on the mouse event attributes


There are a couple of demos for event handling

  examples/keypress_demo.py
  examples/coords_demo.py

JDH

Greetings,

Matplotlib has been helping me a lot, as always. I post so
infrequently to this group because I usually don't have any
problem getting what I want. However, I think I found a bug
in stem.

I've been stressing the stem function a lot, since I deal
with signal processing. When plotting a demonstration of the
overlap and save method (for performing long convolutions),
I got something unexpected which the script below reproduces:

---
from matplotlib.pylab import *

n = arange(0, 2*pi, 2*pi/50, Float)
x = sin(n)

figure(1)
stem(n, x, "k-", "ko", "k-")

x[:26] = 0

savefig("test.eps")
---

The sequence is plotted almost without any problems: the
vertical lines are drawn with the correct amplitudes, but,
because of the setting of some values of x to 0, the markers
"fall down" to the axes. If I couldn't make myself clear, I
can send an image of the result, but I think the script can
reproduce the problem. I'm using the latest version of
matplotlib, downloaded and installed yesterday.

As it turns out, it actually *helped* me. Overlapp and save
method consists in discarding some samples of the result. I
couldn't think of a good way to actually show in a single
figure how it would be done. I mention the bug, if it is really
a bug, and not me doing something wrong, only to report it. I
have no hurry to see it fixed - in fact, as it helped me, I
don't plan to have it fixed soon. But I thought the developers
would like to know it.

Also, I would like to know if there is any way to customize
the markers. There are some figures I need to make where the
markers should be arrows pointing up. I modified "^" to look
like what I wanted, but probably there is a better way to do
that.

Thanks in advance

---
José Alexandre Nalon
na...@te...

>>>>> "Werner" == Werner F Bruhin <wer...@fr...> writes:
    Werner> I am looking at the py2exe optimize problem, would be nice
    Werner> if this could be fixed somehow too.

The basic problem is that pylab wrapper functions get their docstrings
from the respective Axes or Figure functions that they wrap, and then
they add a bit of pylab specific documentation at the end.  Most of
the pylab functions are generated by boilerplate.py, which is python
code to generate the pylab wrapper functions.

One solution to change boilerplate.py to embed the doc strings
manually in the pylab wrappers.  Eg, instead of generating

plot.__doc__ = _shift_string(Axes.plot.__doc__) + """
Addition kwargs: hold = [True|False] overrides default hold state"""

Actually embed the Axes.plot.__doc__ directly.

This should work with py2exe optimize.

JDH

Hi John,

John Hunter wrote:

>>>>>>"Werner" == Werner F Bruhin <wer...@fr...> writes:
>>>>>>            
>>>>>>
>
>    Werner> Which example file are you using were you see a
>    Werner> difference?
>
>It appears to be a problem with pylab scripts, eg
>
>  > python2.3 examples/simple_plot.py -dWXAgg
>
>I am pretty sure this is a 2.4 versus 2.5 problem.  I installed wx 2.4
>in my python2.4 tree and 2.5 in my python2.3 tree and find that the
>size was wrong only on wx2.4.
>
>This was also true for matplotlib-0.74 and CVS which includes your
>patch, so it is not something that was caused by your patch, but it is
>a bug.
>
>Since it only occurred for pylab mode and not apps, I poked around the
>embedding examples to see what the difference was, and found that the
>embedding examples passed the size kwarg to the wx.Frame.__init__
>function.
>
>So I added these lines to FigureFrameWx
>
>class FigureFrameWx(wx.Frame):
>    def __init__(self, num, fig):
>        ...snip...
>        l,b,w,h = fig.bbox.get_bounds()
>        wx.Frame.__init__(self, parent=None, id=-1, pos=pos,
>                          title="Figure %d" % num,
>                          size=(w,h))
>
>
>
>which appears to work for wx2.4 and 2.5.
>
>So I think all the known problems with wx are fixed for now.
>  
>
Great.

I am looking at the py2exe optimize problem, would be nice if this could 
be fixed somehow too.

See you
Werner

>JDH
>
>
>
>  
>

>>>>> "Werner" == Werner F Bruhin <wer...@fr...> writes:

    Werner> Which example file are you using were you see a
    Werner> difference?

It appears to be a problem with pylab scripts, eg

  > python2.3 examples/simple_plot.py -dWXAgg

I am pretty sure this is a 2.4 versus 2.5 problem.  I installed wx 2.4
in my python2.4 tree and 2.5 in my python2.3 tree and find that the
size was wrong only on wx2.4.

This was also true for matplotlib-0.74 and CVS which includes your
patch, so it is not something that was caused by your patch, but it is
a bug.

Since it only occurred for pylab mode and not apps, I poked around the
embedding examples to see what the difference was, and found that the
embedding examples passed the size kwarg to the wx.Frame.__init__
function.

So I added these lines to FigureFrameWx

class FigureFrameWx(wx.Frame):
    def __init__(self, num, fig):
        ...snip...
        l,b,w,h = fig.bbox.get_bounds()
        wx.Frame.__init__(self, parent=None, id=-1, pos=pos,
                          title="Figure %d" % num,
                          size=(w,h))



which appears to work for wx2.4 and 2.5.

So I think all the known problems with wx are fixed for now.

JDH

Hello NG,

>Curious to know if this works for Andrea too.  It appears to work for
>me with py2exe 0.5.4

Yes, the simple plot example works on my machine (Windows 2000, py2exe 0.=
5.4,
Matplotlib 0.74, wxPython 2.5.5.1). I don't know if it will work also for=

my big application, but I will try as soon as I can, and I don't see any
particular reason for which it should not run.
Thanks, however, for all the work you are doing!

Andrea.

Hi John,

I actually think that the OnPaint event in embedding_in_wx is not needed 
at all.

See you
Werner

Werner F. Bruhin wrote:

> Hi John,
> 
> Werner F. Bruhin wrote:
> 
>> Hi John,
>>
>> John Hunter wrote:
>>
>>>>>>>> "Werner" == Werner F Bruhin 
>>>>>>>> <wer...@fr...> writes:
>>>
>>>
>>>
>>>
>>>
>>>     Werner> By doing this I found a few more oversights (wx to wx.) in
>>>     Werner> backend, updated version is attached.
>>>
>>> OK, I've got it working with wxpython 2.5.5.1
>>>
>>> The only glitch I've noticed so far is that the figsize parameter does
>>> not appear to be respected.  The windows that are created a
>>> considerably smaller than they should be.
>>>
>>> Any ideas?
>>
>>
>> Just did a little test, copied back the originals for backend_wx and 
>> backend_wx_agg and run embedding_in_wx4 and the figure size in both 
>> cases is about 390x318.
>>
>> Which example file are you using were you see a difference?
>>
>> BTW, also noticed with the embedding_in_wx4 the CPU usage stays at 
>> 100% and I can't close it (at least not always) - again with original 
>> or modified code.
> 
> To correct the CPU usage change the OnPaint event to include an 
> event.Skip() as this:
> 
>     def OnPaint(self, event):
>         self.canvas.draw()
>         event.Skip()
> 
> That also makes the toolbar show up correctly.
> 
> See you
> Werner
> 
>>
>>>
>>> JDH
>>>
>> See you
>> Werner
>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Hi Michael,

This is all I need:

Obviously the two first lines you need to adapt.

data = glob.glob(r'C:\Python24\share\matplotlib\*')
data.append(r'C:\Python24\share\matplotlib\.matplotlibrc')

setup(console=["simple_plot.py"],
       data_files=[("matplotlibdata",data)],
       options = {"py2exe": {"compressed": 1,
                             # optimize breaks pylab docstring handling
                             #"optimize": 2,
                             "packages": ["encodings", "pytz"],
                            }},
       )


Note that I use "packages" and NOT include, all the matplotlib and 
numeric stuff seems to get detected correctly by py2exe.

I am not even sure about encodings, but as I had problems with this 
before I just always put it there.

I see in your later post that you came to a similar conclusion.

See you
Werner


Michael Twomey wrote:

> Hi,
> 
> On Apr 11, 2005 6:02 PM, John Hunter <jdh...@ac...> wrote:
> 
>>>>>>>"andrea" == andrea gavana <and...@ti...> writes:
>>
>>    andrea> I still get the TimeZone error...
>>
>>I spent a little time looking at this this morning.  I found that I
>>needed to explicitly put the utc timezone in my script that I was
>>freezing, it was not enough to include it in my includes list.  Oddly,
>>this was not consistent.  In the simple_plot_wxagg example, I had the
>>timezone info in my includes list only and it worked w/o incident.  In
>>the simple_plot_gtk example, I needed to manually add
>>
>>import pytz.zoneinfo.UTC
>>
>>to my simple_plot.py script.  Strange...
>>
> 
> 
> For me I've found that I've needed to include every level of a given
> module individually to get it working, e.g. 'pytz', 'pytz.timezone'
> and 'pytz.timezone.UTC'. After that py2exe works for me.
> 
> This (to me) is an example of how stuff which dynamically imports
> modules at runtime trips up stuff like py2exe (I believe the py.test
> folks are losing a lot of hair over dynamic imports in their testing
> magic too). What I think is happening here (and in encodings) is that
> normal usage involves just importing the toplevel module in your app's
> code, and at runtime you invoke a call which then goes and imports the
> module supplying the code you need. So when py2exe analyses the code,
> it doesn't see your runtime import and misses the relevant module.
> 
> Adding an explicit import in your app should be pretty much the same
> as using a py2exe include, except that it introduces some overhead at
> runtime. To handle every timezone your would have to import every
> timezone in your app, whereas with py2exe's includes you just specify
> what to stick in the zip and the app can import just the timezone it
> needs at runtime. Theoretically anyway :)
> 
> To add fun to the mix, any package which dynamically imports stuff at
> runtime usually has to be careful to either be aware of how it lives
> in a zip when frozen, or not to do anything dependant on it's file
> path.
> 
> 
>>Also, what kinds of files should be in the includes list? For example,
>>in Michael's list, he includes
>>
>>    "matplotlib._na_image",
>>    "matplotlib._na_transforms",
>>    "matplotlib._nc_image",
>>    "matplotlib._nc_transforms",
>>
>>but not
>>
>>    "matplotlib._image"
>>    "matplotlib._transforms"
>>
>>The latter two are python files, the former extension code.  Do you
>>typically need to manually point py2exe to the extension files?
>>
> 
> 
> I've found py2exe has given me difficulty when looking for extensions,
> so my list of includes represents partially extensions I've found to
> be missing in frozen apps when trying to run them and partially every
> other extension I've come across for good measure (since I was doing a
> build, crash, add missing extension loop, I decided to add them all).
> Depending on how apps and modules handle imports, py2exe seems to be
> able to pick up pure python stuff more easily than python extensions.
> 
> All this could be just a mix of my particular setup and the
> applications I deal with, no two people's py2exe problems ever seem to
> be the same :)
> 
> All the problems centre around py2exe's module finding logic, every
> problem I've encountered has been due to py2exe missing out on one or
> two modules (in particular ones which do very dynamic imports at run
> time as oppose to import time), so there is a lovely cargo cult feel
> to my includes list, I decided the five minutes of adding all the
> includes I might need from a given package was worth it, rather than
> the repeated half hour of tracking down people's problems when running
> the apps.
> 
> 
>>Anyway, the wxagg and gtk examples in the updated
>>http://matplotlib.sourceforge.net/py2exe_examples.zip build and run on
>>my machine.  They are a bit of a hack in that I don't really
>>understand why/how/when the includes work.  If someone can rationalize
>>these scripts, improve them, extend them, whatever, send the updates
>>my way.
>>
> 
> 
> I'll have a go with them and see how they fair under my esoteric
> setup. I'm going to bet that I'll have problems no one else does ;)
> 
> Michael
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

>>>>> "Michael" == Michael Twomey <mic...@gm...> writes:

    Michael> C:\temp\py2exe\simple_plot_gtk\dist>date_demo.exe Fatal
    Michael> Python error: Call to API function without first calling
    Michael> import_libnumarra y() in Src\_convmodule.c

I saw the exact same thing but it appeared to come and go as I made
minor tweaks to the setup, and could never figure out why I sometimes
got this error and sometimes did not.  I added nummaray to the
packages list.


    Michael> (I also had to copy in the lib and etc directories from
    Michael> my GTK install to keep GTK+ happy, since it needs
    Michael> supporting files and libraries, that's a pygtk/GTK+
    Michael> specific thing.)

Yep, this is mentioned in the comment header of setup.py for the gtk
example (and in the FAQ).  Still, it's easy to miss, as I spent about
15 minutes trying to figure out what was going wrong (it had been many
months since I wrote the example) before I read my own comment.  I
added a print reminder to setup.py.

    Michael> Even when I remove the pytz imports from the
    Michael> simple_plot_gtk scripts py2exe doesn't seem to have any
    Michael> problems, the pytz package include does the trick for me.

Curious to know if this works for Andrea too.  It appears to work for
me with py2exe 0.5.4

    Michael> I've attached a diff showing the minor modifications I
    Michael> made.

Thanks, I've updated the examples on the site.

I also saw your comment on the py2exe matplotlib wiki.  I changed the
init method slightly -- could you test this on your setup to make sure
it works

    if sys.platform=='win32' and sys.frozen: 
    path = os.path.join(os.path.split(sys.path[0])[0], 'matplotlibdata') 
    if os.path.isdir(path):  return path 
    else:
        # Try again assuming sys.path[0] is a dir not a exe 
        path = os.path.join(sys.path[0], 'matplotlibdata') 
        if os.path.isdir(path): return path
    raise RuntimeError('Could not find the matplotlib data files')

Thanks,
JDH

Well, after looking at the examples you'll be pleased to hear they
cleared up a fundamental misunderstanding I had with py2exe's
configuration. You won't be so pleased to hear that they blew up
dramatically and in an interesting new way (for me) when I tried to
run the frozen exes :)

I had been mixing up distutils' packages directive (which lists
packages in your source tree) and py2exe's 'packages' option (which
does what my lengthy includes do in one go with the package). Using
the packages directive leads to errors, 'packages' does what I
expected.

So you can pretty much ignore my includes, though I think my comments
about hand holding py2exe's module finding still stand.

Now, on to the problem:

C:\temp\py2exe\simple_plot_gtk\dist>date_demo.exe
Fatal Python error: Call to API function without first calling import_libnumarra
y() in Src\_convmodule.c

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


If I add numarray to the packages list it works fine for me.

(I also had to copy in the lib and etc directories from my GTK install
to keep GTK+ happy, since it needs supporting files and libraries,
that's a pygtk/GTK+ specific thing.)

Even when I remove the pytz imports from the simple_plot_gtk scripts
py2exe doesn't seem to have any problems, the pytz package include
does the trick for me.

I've attached a diff showing the minor modifications I made.

The complete set of commands I used to build (under cygwin with
official python, not the cygwin python):

$ python.exe setup.py py2exe
$ cp -r /c/GTK/etc dist
$ cp -r /c/GTK/lib dist
$ ./dist/date_demo.exe

cheers,
  Michael

John and Philippe,

thank you for your help. I have followed John's updated examples and now I
get an exe-file of my application. However, now I run into the same
timezone/UTC key error problems that was discussed the last few days on
this list.

As I understand the problem is not completely resolved yet, so I'll jsut
wait and see ... ;-). I would like to help, but this is way above my head.
Sorry!

Oliver


                                                                           
             John Hunter                                                   
             <jdh...@ac...                                             
             .uchicago.edu>                                             To 
             Sent by:                  oli...@ma...            
             matplotlib-users-                                          cc 
             ad...@li...         mat...@li.... 
             eforge.net                net                                 
                                                                   Subject 
                                       Re: [Matplotlib-users] problems     
             11.04.2005 19:05          with py2exe                         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




>>>>> "oliver" == oliver tomic <oli...@ma...> writes:



    oliver> data = glob.glob(r'C:\Python24\Lib\site-packages\matplotlib\*')


The python modules should not be included in the "data" listing.  Eg,
you write

  data = glob.glob(r'C:\Python24\Lib\site-packages\matplotlib\*')

but this is wrong because the files in that directory are python
modules.

The data are the fonts, icons, etc, found in

  data = glob.glob(r'C:\Python24\share\matplotlib\*')

See the examples simple_plot_wxagg which I just updated at

  http://matplotlib.sourceforge.net/py2exe_examples.zip

Hope this helps,
JDH


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
 https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

On Apr 11, 2005 6:02 PM, John Hunter <jdh...@ac...> wrote:
> >>>>> "andrea" == andrea gavana <and...@ti...> writes:
> 
>     andrea> I still get the TimeZone error...
> 
> I spent a little time looking at this this morning.  I found that I
> needed to explicitly put the utc timezone in my script that I was
> freezing, it was not enough to include it in my includes list.  Oddly,
> this was not consistent.  In the simple_plot_wxagg example, I had the
> timezone info in my includes list only and it worked w/o incident.  In
> the simple_plot_gtk example, I needed to manually add
> 
> import pytz.zoneinfo.UTC
> 
> to my simple_plot.py script.  Strange...
> 

For me I've found that I've needed to include every level of a given
module individually to get it working, e.g. 'pytz', 'pytz.timezone'
and 'pytz.timezone.UTC'. After that py2exe works for me.

This (to me) is an example of how stuff which dynamically imports
modules at runtime trips up stuff like py2exe (I believe the py.test
folks are losing a lot of hair over dynamic imports in their testing
magic too). What I think is happening here (and in encodings) is that
normal usage involves just importing the toplevel module in your app's
code, and at runtime you invoke a call which then goes and imports the
module supplying the code you need. So when py2exe analyses the code,
it doesn't see your runtime import and misses the relevant module.

Adding an explicit import in your app should be pretty much the same
as using a py2exe include, except that it introduces some overhead at
runtime. To handle every timezone your would have to import every
timezone in your app, whereas with py2exe's includes you just specify
what to stick in the zip and the app can import just the timezone it
needs at runtime. Theoretically anyway :)

To add fun to the mix, any package which dynamically imports stuff at
runtime usually has to be careful to either be aware of how it lives
in a zip when frozen, or not to do anything dependant on it's file
path.

> Also, what kinds of files should be in the includes list? For example,
> in Michael's list, he includes
> 
>     "matplotlib._na_image",
>     "matplotlib._na_transforms",
>     "matplotlib._nc_image",
>     "matplotlib._nc_transforms",
> 
> but not
> 
>     "matplotlib._image"
>     "matplotlib._transforms"
> 
> The latter two are python files, the former extension code.  Do you
> typically need to manually point py2exe to the extension files?
> 

I've found py2exe has given me difficulty when looking for extensions,
so my list of includes represents partially extensions I've found to
be missing in frozen apps when trying to run them and partially every
other extension I've come across for good measure (since I was doing a
build, crash, add missing extension loop, I decided to add them all).
Depending on how apps and modules handle imports, py2exe seems to be
able to pick up pure python stuff more easily than python extensions.

All this could be just a mix of my particular setup and the
applications I deal with, no two people's py2exe problems ever seem to
be the same :)

All the problems centre around py2exe's module finding logic, every
problem I've encountered has been due to py2exe missing out on one or
two modules (in particular ones which do very dynamic imports at run
time as oppose to import time), so there is a lovely cargo cult feel
to my includes list, I decided the five minutes of adding all the
includes I might need from a given package was worth it, rather than
the repeated half hour of tracking down people's problems when running
the apps.

> Anyway, the wxagg and gtk examples in the updated
> http://matplotlib.sourceforge.net/py2exe_examples.zip build and run on
> my machine.  They are a bit of a hack in that I don't really
> understand why/how/when the includes work.  If someone can rationalize
> these scripts, improve them, extend them, whatever, send the updates
> my way.
> 

I'll have a go with them and see how they fair under my esoteric
setup. I'm going to bet that I'll have problems no one else does ;)

Michael

Hi John,

Werner F. Bruhin wrote:
> Hi John,
> 
> John Hunter wrote:
> 
>>>>>>> "Werner" == Werner F Bruhin 
>>>>>>> <wer...@fr...> writes:
>>
>>
>>
>>
>>     Werner> By doing this I found a few more oversights (wx to wx.) in
>>     Werner> backend, updated version is attached.
>>
>> OK, I've got it working with wxpython 2.5.5.1
>>
>> The only glitch I've noticed so far is that the figsize parameter does
>> not appear to be respected.  The windows that are created a
>> considerably smaller than they should be.
>>
>> Any ideas?
> 
> Just did a little test, copied back the originals for backend_wx and 
> backend_wx_agg and run embedding_in_wx4 and the figure size in both 
> cases is about 390x318.
> 
> Which example file are you using were you see a difference?
> 
> BTW, also noticed with the embedding_in_wx4 the CPU usage stays at 100% 
> and I can't close it (at least not always) - again with original or 
> modified code.
To correct the CPU usage change the OnPaint event to include an 
event.Skip() as this:

     def OnPaint(self, event):
         self.canvas.draw()
         event.Skip()

That also makes the toolbar show up correctly.

See you
Werner
> 
>>
>> JDH
>>
> See you
> Werner
> 
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Hi John,

John Hunter wrote:
>>>>>>"Werner" == Werner F Bruhin <wer...@fr...> writes:
> 
> 
> 
>     Werner> By doing this I found a few more oversights (wx to wx.) in
>     Werner> backend, updated version is attached.
> 
> OK, I've got it working with wxpython 2.5.5.1
> 
> The only glitch I've noticed so far is that the figsize parameter does
> not appear to be respected.  The windows that are created a
> considerably smaller than they should be.
> 
> Any ideas?
Just did a little test, copied back the originals for backend_wx and 
backend_wx_agg and run embedding_in_wx4 and the figure size in both 
cases is about 390x318.

Which example file are you using were you see a difference?

BTW, also noticed with the embedding_in_wx4 the CPU usage stays at 100% 
and I can't close it (at least not always) - again with original or 
modified code.
> 
> JDH
> 
See you
Werner
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Hi John,

John Hunter wrote:

>>>>>>"Werner" == Werner F Bruhin <wer...@fr...> writes:
> 
> 
> 
>     Werner> By doing this I found a few more oversights (wx to wx.) in
>     Werner> backend, updated version is attached.
> 
> OK, I've got it working with wxpython 2.5.5.1
> 
> The only glitch I've noticed so far is that the figsize parameter does
> not appear to be respected.  The windows that are created a
> considerably smaller than they should be.
> 
> Any ideas?
Only float to int change I did was in the Printer_Print method to remove 
a deprecation warning.

I'll have another look this afternoon.
> 
> JDH
> 
See you
Werner
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click