matplotlib-devel Mailing List for matplotlib (Page 4)

This is a fairly dumb question, but is there a documented procedure
somewhere for developing and submitting patches?  I had developed a
patch a few months ago to allow people to set the legend properties in
the rc file.  It seems this didn't make it into the current version.=20
I recently got an email from someone wanting this feature as well, and
I told them I would follow through with it.

Part of the problem is that I don't have much experience with cvs/svn
beyond checking code out.  That is why I am asking for a procedure.  I
also don't know if someone needs to look at what I have done and make
sure I am not a total hack (I made some changes to it based on John's
feedback).  I will in no way be offended if someone wants to look over
my shoulder, and I don't mind tweaking it to follow better coding
practices or whatever, but I do want to follow it through to getting
it included.

Thanks,

Ryan

This minor release fixes the windows installer issues.  A few updates
snuck in as well.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2006-1-11 Fixed setup.py for win32 build and added rc template to the
MANIFEST.in

2006-1-10 Added xpdf distiller option. matplotlibrc ps.usedistiller can now=
 be
            none, false, ghostscript, or xpdf. Validation checks for
            dependencies. This needs testing, but the xpdf option should pr=
oduce
            the highest-quality output and small file sizes - DSD

2006-01-10 For the usetex option, backend_ps now does all the LaTeX work in=
 the
            os's temp directory - DSD

2006-1-10 Added checks for usetex dependencies. - DSD

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Darren Dale <dd...@co...> writes:

> On Wednesday 11 January 2006 12:21, Darren Dale wrote:
> > On Wednesday 11 January 2006 11:09, Chris Walker wrote:
> > >
> > > In 0.86, which I don't think incorporates your changes[1], there is a
> > > small problem with the text size.
> > >
> > > The text in the postscript version is longer than in the tkagg
> > > version, and also is not centred.
> 
> I get better results with \textbf than with \bf, but still not perfect.
> 
> There are a lot of places this can get screwed up: dvipng, PSFrag, MPL... I 

When I looked at the code, it wasn't clear that the font used for
calculating the width was the same as the one that actually ended up
being used for printing. In addition, the bounding box was calculated
for 10pt text, and then a scale factor used to scale the text. Any
inaccuracy in the bounding box will carry through. 

One solution would be to calculate the bounding box for the text at
the appropriate size - this could have the additional advantage that
12pt fonts would be used for 12pt text, rather than 10 pt scaled by a
factor of 1.2.  I'm sure I've read that TeX positions text slightly
differently in the two cases (though any advantage would be lost if
you end up scaling the eps).


> would like to eventually do the tex support the right way, possibly using the> PyX package, but I am still waiting to hear if PyX will consider releasing 
> under the Python license.

Good luck.

Chris

On Wednesday 11 January 2006 12:21, Darren Dale wrote:
> On Wednesday 11 January 2006 11:09, Chris Walker wrote:
> > Darren Dale <dd...@co...> writes:
> > > This morning I finished some changes to mpl's postscript and usetex
> > > options.
> > >
> > >
> > >
> > > These changes are all available in cvs. Testing and comments
> > > appreciated.
> >
> > In 0.86, which I don't think incorporates your changes[1], there is a
> > small problem with the text size.
> >
> > The text in the postscript version is longer than in the tkagg
> > version, and also is not centred.

I get better results with \textbf than with \bf, but still not perfect.

There are a lot of places this can get screwed up: dvipng, PSFrag, MPL... I 
would like to eventually do the tex support the right way, possibly using the 
PyX package, but I am still waiting to hear if PyX will consider releasing 
under the Python license.

Darren 

On Wednesday 11 January 2006 11:09, Chris Walker wrote:
> Darren Dale <dd...@co...> writes:
> > This morning I finished some changes to mpl's postscript and usetex
> > options.
> >
> >
> >
> > These changes are all available in cvs. Testing and comments appreciated.
>
> In 0.86, which I don't think incorporates your changes[1], there is a
> small problem with the text size.
>
> The text in the postscript version is longer than in the tkagg
> version, and also is not centred.

For some reason, the kerning is messed up in the eps file. I tried using the 
pslatex font package (set in matplotlibrc) and the kerning there is ok. It 
still is not perfectly centered, and I dont know why that might be.

Darren Dale <dd...@co...> writes:

> This morning I finished some changes to mpl's postscript and usetex options.


> 
> These changes are all available in cvs. Testing and comments appreciated.

In 0.86, which I don't think incorporates your changes[1], there is a
small problem with the text size. 

The text in the postscript version is longer than in the tkagg
version, and also is not centred.

If the label is quite long, it is quite clear that in the eps version,
the text for the axis labels is not centred. I've attached a modified
version of tex_demo.py to demonstrate the effect.


Chris

[1] I did try replacing backend_ps.py with the cvs version, but it
didn't work - and I don't have time at the moment to investigate
further - probably I need to update other files too. 


#!/usr/bin/env python
"""
You can use TeX to render all of your matplotlib text if the rc
parameter text.usetex is set.  This works currently on the agg and ps
backends, and requires that you have tex and the other dependencies
described at http://matplotlib.sf.net/matplotlib.texmanager.html
properly installed on your system.  The first time you run a script
you will see a lot of output from tex and associated tools.  The next
time, the run may be silent, as a lot of the information is cached in
~/.tex.cache

"""
from matplotlib import rc
from matplotlib.numerix import arange, cos, pi
from pylab import figure, axes, plot, xlabel, ylabel, title, \
     grid, savefig, show


rc('text', usetex=True)
rc('ps', usedistiller=False) 
figure(1)
ax = axes([0.1, 0.1, 0.8, 0.7])
t = arange(0.0, 1.0+0.01, 0.01)
s = cos(2*2*pi*t)+2
plot(t, s)

xlabel(r'\bf{time (s) a realy long title that is not centered}')
ylabel(r'\it{voltage (mV) not centered}',fontsize=25)
title(r"\TeX\ is Number $\displaystyle\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$!", 
      fontsize=25, color='r')
grid(True)
savefig('tex_demo.eps')


show()

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:

    Stephen> template = file('matplotlibrc.template').read() IOError:
    Stephen> [Errno 2] No such file or directory:
    Stephen> 'matplotlibrc.template' error: Bad exit status from
    Stephen> /var/tmp/rpm-tmp.93117 (%build)


    Stephen> RPM build errors: Bad exit status from
    Stephen> /var/tmp/rpm-tmp.93117 (%build) error: command 'rpmbuild'
    Stephen> failed with exit status 1

Add matplotlibrc.template to the MANIFEST.in file...

JDH

Charlie Moad wrote:

>   Latest release of matplotlib available with the usual slew of
>updates.
>
I just downloaded 0.86 and "python setup.py bdist_rpm" on a Fedora Core 
4 machine fails with the following output at the end.  "python setup.py 
build" succeeds on the same machine in the same terminal window.

+ env 'CFLAGS=-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 
-march=i386 -mtune=pentium4 -fasynchronous-unwind-tables' python 
setup.py build
installing data to lib/python2.4/site-packages/matplotlib/mpl-data
pygtk present but import failed
Using default library and include directories for Tcl and Tk because a
Tk window failed to open.  You may need to define DISPLAY for Tk to work
so that setup can determine where your libraries are located.
pygtk present but import failed
Traceback (most recent call last):
  File "setup.py", line 281, in ?
    template = file('matplotlibrc.template').read()
IOError: [Errno 2] No such file or directory: 'matplotlibrc.template'
error: Bad exit status from /var/tmp/rpm-tmp.93117 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.93117 (%build)
error: command 'rpmbuild' failed with exit status 1

On Tue, 10 Jan 2006, John Hunter apparently wrote: 
> My guess is that the default rc file is using GTKAgg -- 
> I usually reset this to TkAgg for the windows distro, and 
> manually set Numeric for the numerix setting.  In this 
> release the rc file is autogenerated depending on what was 
> found at build time. 

> Quick fix: just set TkAgg (or whatever) in your rc manually. 

I made that change in matplotlib/mpl-data/matplotlibrc
Is that what you meant?  Anyway, I seem to be up and 
running.

Thanks!
Alan

>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:

    Alan> Something seems to be broken here ...  Alan Isaac

My guess is that the default rc file is using GTKAgg -- I usually
reset this to TkAgg for the windows distro, and manually set Numeric
for the numerix setting.  In this release the rc file is
autogenerated depending on what was found at build time.

Quick fix: just set TkAgg (or whatever) in your rc manually.

Charlie: make a mental note on the bug-fix build to automatically set
the right defaults in setup.py for win32 builds.

JDH

Something seems to be broken here ...
Alan Isaac

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylab
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\Lib\site-packages\pylab.py", line 1, in ?
    from matplotlib.pylab import *
  File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 217, in ?
    new_figure_manager, draw_if_interactive, show = pylab_setup()
  File "C:\Python24\Lib\site-packages\matplotlib\backends\__init__.py", line 24,
 in pylab_setup
    globals(),locals(),[backend_name])
  File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_gtkagg.py", li
ne 10, in ?
    from backend_gtk import gtk, FigureManagerGTK, FigureCanvasGTK,\
  File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_gtk.py", line
6, in ?
    import gobject
ImportError: No module named gobject
>>>

   Latest release of matplotlib available with the usual slew of
updates.  Notable changes are:
     - Support for numpy (was scipy_core)
     - Support for setuptools (eggs to appear soon on cheeseshop)
          -- more on eggs: http://peak.telecommunity.com/DevCenter/setuptoo=
ls
     - Matplotlib data files moved inside the matplotlib module for
better portability

http://sourceforge.net/project/showfiles.php?group_id=3D80706&package_id=3D=
82474&release_id=3D384391
http://cheeseshop.python.org/pypi/matplotlib/

Full changelog below....

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2006-1-9 Released 0.86

2006-1-4 Changed to support numpy (new name for scipy_core) - TEO

2006-1-4 Added Mark's scaled axes patch for shared axis

2005-12-28 Added Chris Barker's build_wxagg patch - JDH

2005-12-27 Altered numerix/scipy to support new scipy package
           structure - TEO
2005-12-20 Fixed Jame's Boyles date tick reversal problem - JDH

2005-12-20 Added Jouni's rc patch to support lists of keys to set on -
           JDH

2005-12-12 Updated pyparsing and mathtext for some speed enhancements
           (Thanks Paul McGuire) and minor fixes to scipy numerix and
           setuptools

2005-12-12 Matplotlib data is now installed as package_data in
           the matplotlib module.  This gets rid of checking the
           many possibilities in matplotlib._get_data_path() - CM

2005-12-11 Support for setuptools/pkg_resources to build and use
           matplotlib as an egg. Still allows matplotlib to exist
           using a traditional distutils install. - ADS

2005-12-03 Modified setup to build matplotlibrc based on compile time
           findings.  It will set numerix in the order of scipy,
           numarray, Numeric depending on which are founds, and
           backend as in preference order GTKAgg, WXAgg, TkAgg, GTK,
           Agg, PS

2005-12-03 Modified scipy patch to support Numeric, scipy and numarray
=09   Some work remains to be done because some of the scipy
=09   imports are broken if only the core is installed.  Eg
=09   apparently we need from scipy.basic.fftpack import * rather
=09   than from scipy.fftpack import *

2005-12-03 Applied some fixes to Nicholas Young's nonuniform image
           patch

2005-12-01 Applied Alex Gontmakher hatch patch - PS only for now

2005-11-30 Added Rob McMullen's EMF patch

2005-11-30 Added Daishi's patch for scipy

2005-11-30 Fixed out of bounds draw markers segfault in agg

2005-11-28 Got TkAgg blitting working 100% (cross fingers) correctly. - CM

2005-11-27 Multiple changes in cm.py, colors.py, figure.py, image.py,
           contour.py, contour_demo.py; new _cm.py, examples/image_masked.p=
y.
           1) Separated the color table data from cm.py out into
           a new file, _cm.py, to make it easier to find the actual
           code in cm.py and to add new colormaps.  Also added
           some line breaks to the color data dictionaries. Everything
           from _cm.py is imported by cm.py, so the split should be
           transparent.
           2) Enabled automatic generation of a colormap from
           a list of colors in contour; see modified
           examples/contour_demo.py.
           3) Support for imshow of a masked array, with the
           ability to specify colors (or no color at all) for
           masked regions, and for regions that are above or
           below the normally mapped region.  See
           examples/image_masked.py.
           4) In support of the above, added two new classes,
           ListedColormap, and no_norm, to colors.py, and modified
           the Colormap class to include common functionality. Added
           a clip kwarg to the normalize class.  Reworked color
           handling in contour.py, especially in the ContourLabeller
           mixin.
           - EF

2005-11-25 Changed text.py to ensure color is hashable. EF

This morning I finished some changes to mpl's postscript and usetex options.

1) In matpltolibrc, ps.usedistiller should now be set to None, ghostscript, or 
xpdf. If you had usedistiller = True, it needs to be changed to ghostscript. 
The xpdf option is preferable where available, producing publication quality 
output and small file sizes. It requires ghostscript, xpdf and ps2eps.

2) It used to be that for the usetex option, backend_ps created a bunch of 
temporary files in the current directory. These steps have been moved to the 
os's temp directory.

3) (usetex = True) and (usedistiller = ghostscript or xpdf) all require 
external dependencies. When these rc-options are validated, these deps are 
checked and an error is raised when something is missing.

These changes are all available in cvs. Testing and comments appreciated.

Darren

On Jan 8, 2006, at 9:55 AM, Charlie Moad wrote:
> I ended up using their win-devel pkg and got the same results.

If wxPython was built with Microsoft Visual C++, then this behavior  
makes some kind of sense.  Should matplotlib be built with VC++, I'd  
still recommend using the win-devel package to ensure compatibility  
with the stable version of wxPython.

> Well, decision time.  Should we go ahead and push a mpl release
> without wx blitting on windows?  I personally think there have been
> more than enough changes to justify it.

By all means.  WXAgg still works without the _wxagg module, as does  
FigureCanvasWxAgg.blit().  It's just slower, because the Agg- 
 >wx.Bitmap conversion is done in pure Python when the _wxagg module  
isn't present.

Ken

> That's pretty strange behavior in a compiler.  The compiler output
> you posted earlier doesn't make it clear how your build environment
> was set up.  It seems to me that the _wxagg extension must be built
> using the wxPython-win32-devel headers and libraries to ensure
> compatibility with the current stable version of wxPython and wxWidgets.

I ended up using their win-devel pkg and got the same results.

Well, decision time.  Should we go ahead and push a mpl release
without wx blitting on windows?  I personally think there have been
more than enough changes to justify it.

- Charlie

Greetings,

I was able to make a small change to axes.py which augments errorbar() with a 
keyword, 'ealpha' (similar to 'ecolor'), which controls the alpha blending of 
the error bar lines.  The motivation was to make overlapping error bars of 
different color slightly less confusing (or at least more interesting).  It's 
up to the user to resist the temptation to utilize it for "error 
reduction."  ;)

Patch attached, use ad lib.

Mike

On Jan 7, 2006, at 3:33 PM, Charlie Moad wrote:
> I was on the wx list a little and got some help, but no solutions.
> Basically I get the same linker errors if I pass no wx libs, so mingw
> is not finding any symbols in the libraries.  It is not complaining
> about the libraries either.

That's pretty strange behavior in a compiler.  The compiler output  
you posted earlier doesn't make it clear how your build environment  
was set up.  It seems to me that the _wxagg extension must be built  
using the wxPython-win32-devel headers and libraries to ensure  
compatibility with the current stable version of wxPython and wxWidgets.

This may result in an extension that only works with one version of  
wxPython.  I'm not sure how best to deal with that situation in a  
binary distribution.  It may be to build a _wxagg extension for  
several versions of wxPython and select the right one at run time.

> Someone on the list said the c++ symbols are mangled by visual studio,
> so the only way to get it to work is compile _wxagg wil vs.

That's something I hadn't considered before now, but is no doubt the  
case.  There isn't a standard application binary interface for C++  
compilers, so they tend to use different name mangling schemes to  
discourage you from shooting your foot (e.g. by linking incompatible  
object files together into an application that doesn't work).

I'm afraid I'm not going to be of much help here, since don't have  
easy access to a windows computer.  I just got back from the lab,  
where I spent several hours trying to get the build environment setup  
so I could build matplotlib.  I gave up in the end, having failed to  
get the Agg backend to build due to weird linking errors.

If anyone needs me I'll be hugging my iBook and crying.  ;-)

Ken

I was on the wx list a little and got some help, but no solutions.=20
Basically I get the same linker errors if I pass no wx libs, so mingw
is not finding any symbols in the libraries.  It is not complaining
about the libraries either.  Someone on the list said the c++ symbols
are mangled by visual studio, so the only way to get it to work is
compile _wxagg wil vs.  Kinda hit a road block now.

On 1/7/06, Ken McIvor <mc...@ii...> wrote:
> On Jan 6, 2006, at 1:04 PM, Charlie Moad wrote:
> >      I am now just using the provided wxPython2.6-win32-devel download
> > and getting the exact same error, after renaming all the .lib files to
> > .a.
>
> Curiouser and curiouser.  I'll try to get to a windows machine later
> today and attempt to reproduce/diagnose the problem.
>
> > What version of wxPython was _wxagg originally built with?
>
> It was originally developed using version 2.5.3.1 under Mac OS 10.3.
>
> Ken
>

On Jan 6, 2006, at 1:04 PM, Charlie Moad wrote:
>      I am now just using the provided wxPython2.6-win32-devel download
> and getting the exact same error, after renaming all the .lib files to
> .a.

Curiouser and curiouser.  I'll try to get to a windows machine later  
today and attempt to reproduce/diagnose the problem.

> What version of wxPython was _wxagg originally built with?

It was originally developed using version 2.5.3.1 under Mac OS 10.3.

Ken

On Jan 6, 2006, at 12:11 PM, Charlie Moad wrote:
> Googling these errors hasn't led me to anything obvious.
> There are a lot of mentions of the vtable for xxx undefined
> references.  Does anybody have any clues?

I was able to find one clear explanation of what g++ means when it  
starts carrying on about undefined references to vtables:

	http://gcc.gnu.org/ml/gcc-bugs/2002-09/msg00083.html

It sounds to me like a build environment problem, but I can't see any  
obvious problems in the output you pasted.

Ken

     I am now just using the provided wxPython2.6-win32-devel download
and getting the exact same error, after renaming all the .lib files to
.a.  What version of wxPython was _wxagg originally built with?

On 1/6/06, Charlie Moad <cw...@gm...> wrote:
> Hi all.  Trying to build the next mpl release, and I am running into a
> hurdle with wx.  We are trying to include the _wxagg module in the
> next release and this has not been done before.  I am able to
> successfully build wx under mingw, and the entire mpl compilation goes
> fine until I hit the linking stage for _wxagg.  Error output pasted
> below.  Googling these errors hasn't led me to anything obvious.
> There are a lot of mentions of the vtable for xxx undefined
> references.  Does anybody have any clues?
>
> Thanks,
>
> --------------------------------------------------
> building 'matplotlib.backends._wxagg' extension
> gcc options: '-O2 -Wall -Wstrict-prototypes'
> compile options: '-Iwin32_static\include -I. -Isrc -Iswig
> -Iagg23/include -I. -Iwin32_static\include -I.
> -Iwin32_static\include\freetype2 -I.\freetype2 -Isrc\freetype2
> -Iswig\freetype2 -Iagg23/include\freetype2 -I.\freetype2
> -Iwin32_static\include\freetype2 -I.\freetype2 -Ic:\Python24\include
> -Ic:\Python24\PC -c'
> g++ -shared build\temp.win32-2.4\Release\src\_wxagg.o
> build\temp.win32-2.4\Release\src\mplutils.o
> build\temp.win32-2.4\Release\cxx\cxxsupport.o
> build\temp.win32-2.4\Release\cxx\cxx_extensions.o
> build\temp.win32-2.4\Release\cxx\indirectpythoninterface.o
> build\temp.win32-2.4\Release\cxx\cxxextensions.o -Lwin32_static\lib
> -Lwin32_static\lib -Lc:\Python24\libs -Lc:\Python24\PCBuild -lpng -lz
> -lstdc++ -lm -lfreetype -lz -lgw32c -lstdc++ -lm -lwxmsw26 -lwxpng
> -lwxregex -lwxzlib -lwxexpat -lwxjpeg -lwxtiff -lpython24 -lmsvcr71 -o
> build\lib.win32-2.4\matplotlib\backends\_wxagg.pyd
> build\temp.win32-2.4\Release\src\_wxagg.o(.text+0x7c3):_wxagg.cpp:
> undefined reference to `wxImage::wxImage(int, int, unsigned char*,
> bool)'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x38d):_wxagg.cpp: undefined reference to
> `wxImage::wxImage(wxImage const*)'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x3b8):_wxagg.cpp: undefined reference to `vtable for
> wxBitmap'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x3df):_wxagg.cpp: undefined reference to
> `wxBitmap::CreateFromImage(wxImage const&, int)'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x3e6):_wxagg.cpp: undefined reference to `vtable for
> wxObject'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x3fc):_wxagg.cpp: undefined reference to `wxObject::UnRef()'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x415):_wxagg.cpp: undefined reference to
> `wxImage::Destroy()'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x55d):_wxagg.cpp: undefined reference to `vtable for
> wxObject'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x56b):_wxagg.cpp: undefined reference to `wxObject::UnRef()'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x580):_wxagg.cpp: undefined reference to `vtable for
> wxObject'
> build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24conve=
rt_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(P=
y::Tuple
> const&)]+0x593):_wxagg.cpp: undefined reference to `wxObject::UnRef()'
> collect2: ld returned 1 exit status
> --------------------------------------------------------------
>

Hi all.  Trying to build the next mpl release, and I am running into a
hurdle with wx.  We are trying to include the _wxagg module in the
next release and this has not been done before.  I am able to
successfully build wx under mingw, and the entire mpl compilation goes
fine until I hit the linking stage for _wxagg.  Error output pasted
below.  Googling these errors hasn't led me to anything obvious.=20
There are a lot of mentions of the vtable for xxx undefined
references.  Does anybody have any clues?

Thanks,

--------------------------------------------------
building 'matplotlib.backends._wxagg' extension
gcc options: '-O2 -Wall -Wstrict-prototypes'
compile options: '-Iwin32_static\include -I. -Isrc -Iswig
-Iagg23/include -I. -Iwin32_static\include -I.
-Iwin32_static\include\freetype2 -I.\freetype2 -Isrc\freetype2
-Iswig\freetype2 -Iagg23/include\freetype2 -I.\freetype2
-Iwin32_static\include\freetype2 -I.\freetype2 -Ic:\Python24\include
-Ic:\Python24\PC -c'
g++ -shared build\temp.win32-2.4\Release\src\_wxagg.o
build\temp.win32-2.4\Release\src\mplutils.o
build\temp.win32-2.4\Release\cxx\cxxsupport.o
build\temp.win32-2.4\Release\cxx\cxx_extensions.o
build\temp.win32-2.4\Release\cxx\indirectpythoninterface.o
build\temp.win32-2.4\Release\cxx\cxxextensions.o -Lwin32_static\lib
-Lwin32_static\lib -Lc:\Python24\libs -Lc:\Python24\PCBuild -lpng -lz
-lstdc++ -lm -lfreetype -lz -lgw32c -lstdc++ -lm -lwxmsw26 -lwxpng
-lwxregex -lwxzlib -lwxexpat -lwxjpeg -lwxtiff -lpython24 -lmsvcr71 -o
build\lib.win32-2.4\matplotlib\backends\_wxagg.pyd
build\temp.win32-2.4\Release\src\_wxagg.o(.text+0x7c3):_wxagg.cpp:
undefined reference to `wxImage::wxImage(int, int, unsigned char*,
bool)'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x38d):_wxagg.cpp: undefined reference to
`wxImage::wxImage(wxImage const*)'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x3b8):_wxagg.cpp: undefined reference to `vtable for
wxBitmap'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x3df):_wxagg.cpp: undefined reference to
`wxBitmap::CreateFromImage(wxImage const&, int)'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x3e6):_wxagg.cpp: undefined reference to `vtable for
wxObject'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x3fc):_wxagg.cpp: undefined reference to `wxObject::UnRef()'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x415):_wxagg.cpp: undefined reference to
`wxImage::Destroy()'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x55d):_wxagg.cpp: undefined reference to `vtable for
wxObject'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x56b):_wxagg.cpp: undefined reference to `wxObject::UnRef()'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x580):_wxagg.cpp: undefined reference to `vtable for
wxObject'
build\temp.win32-2.4\Release\src\_wxagg.o(.text$_ZN13_wxagg_module24convert=
_agg_to_wx_bitmapERKN2Py5TupleE[_wxagg_module::convert_agg_to_wx_bitmap(Py:=
:Tuple
const&)]+0x593):_wxagg.cpp: undefined reference to `wxObject::UnRef()'
collect2: ld returned 1 exit status
--------------------------------------------------------------

This is to let people know that the CVS version of matplotlib now 
supports numpy as the other numerix package instead of scipy...

All backend_driver.py tests worked for me....

-Travis

Darren Dale wrote:

>>If anyone on the mpl team wants to test the new ipython
> 
> 
> I updated from svn, rc8 seems to have cleared it up for me as well.

Great, thanks for the confirmation.

Please keep me posted on any problems as soon as you see them.  The diff I 
committed was over 5000 lines in one week, so I'm a little apprehensive here 
about bugs lurking beneath (though I've already caught and killed quite a few).

Cheers,

f

On Wednesday 04 January 2006 15:01, Fernando Perez wrote:
> Charlie Moad wrote:
> >>the next thing to try would be to change
> >>
> >> > +        if self.gtk.pygtk_version >= (2,4,0):
> >> > +            import gobject
> >> > +            gobject.idle_add(self.on_timer)
> >>
> >>into
> >>
> >>         if self.gtk.pygtk_version >= (2,4,0):
> >>             import gobject
> >>             gobject.timeout_add(self.TIMEOUT, self.on_timer)
> >
> > Yup, that does it.
>
> Great, thanks for the help.  Fix committed to SVN and uploaded as rc8
> (along with a few other fixes I had in waiting).
>
> If anyone on the mpl team wants to test the new ipython

I updated from svn, rc8 seems to have cleared it up for me as well.