Menu
▾
▴
matplotlib-users
|
From: <and...@ti...> - 2005-04-07 09:03:48
|
Hello NG,
this morning I have done the really BIG mistake of uninstalling the
following things:
- Numeric 23.5
- ctypes 0.9.2
- numarray 1.1.1
- Matplotlib 0.72
And I have installed the following:
- Numeric 23.8
- ctypes 0.9.6
- numarray 1.2.3
- Matplotlib 0.74
Using py2exe 0.5.4, now I get some errors on not-found modules, that I pu=
t
at the end of the mail. I have never encountered these problems with olde=
r
versions of the aforementioned tools. Please note that, a part the VTK th=
ings,
almost all the missing modules are from numerix/backends. If I try to sta=
rt
the application, I get a Visual C++ runtime error (and not the usual MYEX=
E.exe.log
message from py2exe, so I do not know how to track the error).
I am on a Windows 2000 machine.
Deinstalling the new tools and re-installing the old ones didn't help any=
more...
Does anyone have a suggestion?
['backends.draw_if_interactive', 'backends.new_figure_manager', 'backends=
.show',
'cephes', 'dl', 'libvtkCommonPython', 'libvtkFilteringPython', 'libvtkGr=
aphicsP
ython', 'libvtkHybridPython', 'libvtkIOPython', 'libvtkImagingPython', 'l=
ibvtkPa
rallelPython', 'libvtkPatentedPython', 'libvtkRenderingPython', 'numerix.=
ArrayTy
pe', 'numerix.Complex', 'numerix.Complex32', 'numerix.Complex64', 'numeri=
x.Float
', 'numerix.Float32', 'numerix.Float64', 'numerix.Int', 'numerix.Int16',
'numeri
x.Int32', 'numerix.Int8', 'numerix.Matrix', 'numerix.UInt16', 'numerix.UI=
nt32',
'numerix.UInt8', 'numerix.absolute', 'numerix.add', 'numerix.allclose',
'numerix
.alltrue', 'numerix.arange', 'numerix.arccos', 'numerix.arccosh', 'numeri=
x.arcsi
n', 'numerix.arcsinh', 'numerix.arctan', 'numerix.arctan2', 'numerix.arct=
anh',
'
numerix.argmax', 'numerix.argmin', 'numerix.argsort', 'numerix.around',
'numerix
.array', 'numerix.arrayrange', 'numerix.asarray', 'numerix.asum', 'numeri=
x.bitwi
se_and', 'numerix.bitwise_or', 'numerix.bitwise_xor', 'numerix.ceil', 'nu=
merix.c
hoose', 'numerix.clip', 'numerix.compress', 'numerix.concatenate', 'numer=
ix.conj
ugate', 'numerix.convolve', 'numerix.cos', 'numerix.cosh', 'numerix.cross=
_correl
ate', 'numerix.cumproduct', 'numerix.cumsum', 'numerix.diagonal', 'numeri=
x.divid
e', 'numerix.dot', 'numerix.equal', 'numerix.exp', 'numerix.fabs', 'numer=
ix.fft.
fft', 'numerix.floor', 'numerix.fmod', 'numerix.fromfunction', 'numerix.f=
romstri
ng', 'numerix.greater', 'numerix.greater_equal', 'numerix.hypot', 'numeri=
x.ident
ity', 'numerix.indices', 'numerix.innerproduct', 'numerix.less', 'numerix=
.less_e
qual', 'numerix.log', 'numerix.log10', 'numerix.logical_and', 'numerix.lo=
gical_n
ot', 'numerix.logical_or', 'numerix.logical_xor', 'numerix.matrixmultiply=
',
'num
erix.maximum', 'numerix.minimum', 'numerix.mlab.amax', 'numerix.mlab.amin=
',
'num
erix.mlab.cov', 'numerix.mlab.diff', 'numerix.mlab.flipud', 'numerix.mlab=
.hannin
g', 'numerix.mlab.rand', 'numerix.mlab.std', 'numerix.mlab.svd', 'numerix=
.multip
ly', 'numerix.negative', 'numerix.nonzero', 'numerix.not_equal', 'numerix=
.nx',
'
numerix.ones', 'numerix.outerproduct', 'numerix.pi', 'numerix.power', 'nu=
merix.p
roduct', 'numerix.put', 'numerix.putmask', 'numerix.rank', 'numerix.ravel=
',
'num
erix.repeat', 'numerix.reshape', 'numerix.resize', 'numerix.searchsorted'=
,
'nume
rix.shape', 'numerix.sin', 'numerix.sinh', 'numerix.size', 'numerix.somet=
rue',
'
numerix.sort', 'numerix.sqrt', 'numerix.subtract', 'numerix.swapaxes', 'n=
umerix.
take', 'numerix.tan', 'numerix.tanh', 'numerix.trace', 'numerix.transpose=
',
'num
erix.where', 'numerix.which', 'numerix.zeros', 'vtkParallelPython', 'matp=
lotlib.
numerix.absolute', 'matplotlib.numerix.equal', 'numarray.Complex', 'numar=
ray.Com
plex32', 'numarray.Complex64', 'numarray.Float', 'numarray.Float32', 'num=
array.F
loat64', 'numarray.Int', 'numarray.Int16', 'numarray.Int32', 'numarray.In=
t8',
'n
umarray.NumArray', 'numarray.UInt16', 'numarray.UInt32', 'numarray.UInt8'=
,
'numa
rray._dotblas', 'numarray.asarray', 'numarray.dot', 'numarray.fromlist',
'numarr
ay.shape', 'numarray.typecode', 'numarray.zeros', 'wx.BitmapFromImage',
'wx.Empt
yIcon']
|
|
From: <and...@ti...> - 2005-04-10 21:31:31
|
Hello NG,
I found where the incompatibilities between Matplotlib and py2exe res=
ide,
at least on my configuration (Windows XP or 2000, Matplotlib 0.74 or 0.72=
pre,
wxPython 2.5.5.1 or previous). The following line in dates.py:
UTC =3D timezone('UTC') (line 94)
Breaks the executable with the error "Unknown timezone" or something simi=
lar.
Next, the way the Matplotlib developers are handling docstrings in pylab.=
py
(and others), like:
figimage.__doc__ =3D Figure.figimage.__doc__ + """
Addition kwargs: hold =3D [True|False] overrides default hold state"""
Breaks py2exe with an error like:
"Can not concatenate NoneType with str"
I just commented out these lines because I don't need docstrings in my ex=
ecutable,
but if someone has a better idea, I welcome all suggestions.
Thank you a lot.
Andrea.
|
|
From: Michael T. <mic...@gm...> - 2005-04-11 12:17:44
|
Hi,
I've had some fun building py2exe stuff with matplotlib too, see below
for some comments and help.
On Apr 10, 2005 10:31 PM, and...@ti... <and...@ti...> wrote:
> Hello NG,
>
> I found where the incompatibilities between Matplotlib and py2exe reside,
> at least on my configuration (Windows XP or 2000, Matplotlib 0.74 or 0.72pre,
> wxPython 2.5.5.1 or previous). The following line in dates.py:
>
> UTC = timezone('UTC') (line 94)
>
> Breaks the executable with the error "Unknown timezone" or something similar.
>
I've encountered this one before, it's to do with the pytz module and
py2exe's modulefinder. Basically pytz dynamically imports modules, so
py2exe has some difficulty with it. For my pyexe I added the following
to the includes list:
"pytz",
"pytz.zoneinfo",
"pytz.zoneinfo.UTC",
"pytz.zoneinfo.US",
"pytz.zoneinfo.US.Eastern",
"pytz.zoneinfo.US.Central",
"pytz.zoneinfo.US.Mountain",
"pytz.zoneinfo.US.Pacific",
"pytz.zoneinfo.Europe.London",
"pytz.zoneinfo.Europe.Paris",
"pytz.zoneinfo.Europe.Berlin",
"pytz.zoneinfo.Europe.Moscow",
For me this seemed to cover all the timezones I encountered.
> Next, the way the Matplotlib developers are handling docstrings in pylab.py
> (and others), like:
>
> figimage.__doc__ = Figure.figimage.__doc__ + """
> Addition kwargs: hold = [True|False] overrides default hold state"""
>
> Breaks py2exe with an error like:
>
> "Can not concatenate NoneType with str"
>
> I just commented out these lines because I don't need docstrings in my executable,
> but if someone has a better idea, I welcome all suggestions.
>
I've never seen this one before, it might be because I'm building with
an older copy of matplotlib.
For reference here is my complete set of matplotlib includes:
"encodings",
"encodings.ascii",
"encodings.idna",
"encodings.iso8859_1",
"encodings.utf_8",
"encodings.string_escape",
"matplotlib",
"matplotlib._na_image",
"matplotlib._na_transforms",
"matplotlib._nc_image",
"matplotlib._nc_transforms",
"matplotlib.ft2font",
"matplotlib.backends",
"matplotlib.backends._backend_agg",
"matplotlib.backends._tkagg",
"matplotlib.backends._gtkagg",
"matplotlib.backends.backend_agg",
"matplotlib.backends.backend_tkagg",
"matplotlib.backends.backend_gtkagg",
"matplotlib.numerix",
"matplotlib.numerix.fft",
"matplotlib.numerix.linear_algebra",
"matplotlib.numerix.mlab",
"matplotlib.numerix.random_array",
"pytz",
"pytz.zoneinfo",
"pytz.zoneinfo.UTC",
"pytz.zoneinfo.US",
"pytz.zoneinfo.US.Eastern",
"pytz.zoneinfo.US.Central",
"pytz.zoneinfo.US.Mountain",
"pytz.zoneinfo.US.Pacific",
"pytz.zoneinfo.Europe.London",
"pytz.zoneinfo.Europe.Paris",
"pytz.zoneinfo.Europe.Berlin",
"pytz.zoneinfo.Europe.Moscow",
"numarray",
"numarray.convolve._correlate",
"numarray.convolve._lineshape",
"numarray.fft.fftpack",
"numarray.image._combine",
"numarray.linear_algebra.lapack_lite2",
"numarray.nd_image._nd_image",
"numarray.random_array.ranlib2",
"numarray._bytes",
"numarray._chararray",
"numarray._conv",
"numarray._converter",
"numarray._ndarray",
"numarray._numarray",
"numarray._objectarray",
"numarray._operator",
"numarray._sort",
"numarray._ufunc",
"numarray._ufuncBool",
"numarray._ufuncComplex32",
"numarray._ufuncComplex64",
"numarray._ufuncFloat32",
"numarray._ufuncFloat64",
"numarray._ufuncInt16",
"numarray._ufuncInt32",
"numarray._ufuncInt64",
"numarray._ufuncInt8",
"numarray._ufuncUInt16",
"numarray._ufuncUInt32",
"numarray._ufuncUInt8",
"numarray.libnumarray",
"numarray.libnumeric",
"numarray.memory",
I don't use numeric so I can't comment on the includes there (I have a
half hearted attempt, but I don't think it's complete).
regards,
Michael
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-11 13:39:23
|
Hi Andrea and others,
I think the timezone stuff you can solve by putting "pytz" into the
packages to include.
Isn't the optimize : 2 getting rid of the doc stuff?
# options for py2exe
options = {"py2exe": {"compressed": 1,
"optimize": 2,
"packages": ["encodings", "kinterbasdb", "pytz"],
"includes": ["ntpath"]}
}
I get an error about ntpath, that is why I put it to includes, but it
doesn't solve the problem - posted it on the py2exe newsgroup.
See you
Werner
and...@ti... wrote:
> Hello NG,
>
> I found where the incompatibilities between Matplotlib and py2exe reside,
> at least on my configuration (Windows XP or 2000, Matplotlib 0.74 or 0.72pre,
> wxPython 2.5.5.1 or previous). The following line in dates.py:
>
> UTC = timezone('UTC') (line 94)
>
> Breaks the executable with the error "Unknown timezone" or something similar.
>
> Next, the way the Matplotlib developers are handling docstrings in pylab.py
> (and others), like:
>
> figimage.__doc__ = Figure.figimage.__doc__ + """
> Addition kwargs: hold = [True|False] overrides default hold state"""
>
> Breaks py2exe with an error like:
>
> "Can not concatenate NoneType with str"
>
> I just commented out these lines because I don't need docstrings in my executable,
> but if someone has a better idea, I welcome all suggestions.
>
> Thank you a lot.
>
> Andrea.
>
>
>
>
> -------------------------------------------------------
> 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_ide95&alloc_id396&op=click
|
|
From: <and...@ti...> - 2005-04-11 14:44:34
|
Hello Werner & NG,
>I think the timezone stuff you can solve by putting "pytz" into the
>packages to include.
This is how my setup.py looks like:
# incl are other includes
includes =3D incl + ["pytz","pytz.zoneinfo"]
excludes =3D ["Tkconstants", "Tkinter", "tcl", '_gtkagg', '_tkagg']
dll_excludes =3D ['libgdk-win32-2.0-0.dll', 'libgobject-2.0-0.dll']
setup(
version =3D "1.0.0",
description =3D "MyApp",
name =3D "MyApp",
data_files =3D [('matplotlibdata', glob.glob(r'c:\python23\share\matp=
lotlib\*')),
('matplotlibdata', [r'c:\python23\share\matplotlib\.mat=
plotlibrc'])],
options =3D {"py2exe": {"compressed": 1,
"optimize": 2,
"includes": includes,
"excludes": excludes,
"dll_excludes": dll_excludes}},
windows =3D ["MyApp.py"]
)
I still get the TimeZone error...
>Isn't the optimize : 2 getting rid of the doc stuff?
I didn't even imagine that the optimize option would interfere with the
doc strings... is it a normal thing?!?
Thanks to you all.
Andrea.
|
|
From: John H. <jdh...@ac...> - 2005-04-11 17:01:58
|
>>>>> "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...
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?
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.
JDH
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-11 17:55:51
Attachments:
backend_wx.py
|
Hi John,
I took your zip file and changed the simple_plot_agg sample to just this
and it looks like it works:
data = glob.glob(r'C:\Python24\share\matplotlib\*')
#data.append(r'C:\Enthon23\share\matplotlib\.matplotlibrc')
setup(console=["simple_plot.py"],
data_files=[("matplotlibdata",data)],
options = {"py2exe": {"compressed": 1,
# optimize may break pylab docstring handling
#"optimize": 2,
#"includes": includes,
#"excludes": excludes,
"packages": ["encodings", "pytz"],
}},
)
Note that I use "packages" and NOT include, all the matplotlib and
numeric stuff seems to get detected correctly by py2exe.
The excludes don't seem to make a difference, I think py2exe removes
them now by itself.
Only error/warnings I get is that I did not include an .matplotlibrc
file. Could you send me yours?
By doing this I found a few more oversights (wx to wx.) in backend,
updated version is attached.
See you
Werner
John Hunter 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...
>
> 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?
>
> 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.
>
> 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
|
|
From: John H. <jdh...@ac...> - 2005-04-11 19:38:33
|
>>>>> "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?
JDH
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 09:29:19
|
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 |
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 10:03:33
|
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 |
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 10:23:14
|
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
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 14:25:35
|
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 |
|
From: John H. <jdh...@ac...> - 2005-04-12 14:46:22
|
>>>>> "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
|
|
From: Michael T. <mic...@gm...> - 2005-04-12 10:25:13
|
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 |
|
From: Michael T. <mic...@gm...> - 2005-04-12 12:53:35
Attachments:
py2exe.diff
|
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 |
|
From: John H. <jdh...@ac...> - 2005-04-12 14:13:03
|
>>>>> "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
|
|
From: <and...@ti...> - 2005-04-12 14:33:09
|
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. |
|
From: Michael T. <mic...@gm...> - 2005-04-12 15:50:04
|
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 |
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 15:54:09
Attachments:
pylab.py
|
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.
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 14:14:04
|
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
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-12 15:01:21
|
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 > > > > > |
|
From: John H. <jdh...@ac...> - 2005-04-12 15:09:19
|
>>>>> "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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X