Re: [matplotlib-devel] [Matplotlib-users] check pylab before upcoming release
John, In your list, "load" is duplicated. It would be nice if numpy.rank could be deprecated, since it seems to be an alias for ndim (which is more descriptive and less ambiguous). We could avoid the name clash by using "matrixrank" for the mlab version. I suggest that for every name that conflicts with a numpy name, the docstring should make this explicit. On a more strategic note: what do you see as the future of mlab, and its place in pylab? Should mlab contain every neat function we can think of, and if so, should all of these be exposed in the pylab namespace? Do we have or need any quality-control standards for these functions? Is there a point in exposing more of mlab now than we have in the past? Probably so, but we might want to be conservative about it. I am copying this to the devel list; it seems worth wider exposure. Eric John Hunter wrote: > On Nov 9, 2007 12:09 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > >>> from pyplot import * >>> from matplotlib.mlab import * >> for mlab I would be inclined to use an explicit list for the sake of >> documentation and clarity, if nothing else. > > One of my colleagues using svn just got bitten because she was using > pylab load and save, which have slightly different semantics than > numpy's. In particular, we have an optional converter dictionary. It > would be nice to reconcile these (Travis has already borrowed a fair > amount from mlab which is why so many funcs are deprecated). > > Here is my candidate list, which I will commit shortly but let me know > if you have a problem with any of it: > > from matplotlib.mlab import load, window_hanning, window_none, conv, > detrend, demean, \ > detrend_mean, detrend_none, detrend_linear, entropy, normpdf, levypdf, \ > find, longest_contiguous_ones, longest_ones, prepca, prctile, > prctile_rank, \ > center_matrix, rk4, bivariate_normal, get_xyz_where, > get_sparse_matrix, dist, \ > dist_point_to_segment, segments_intersect, fftsurr, liaupunov, movavg, \ > save, load, slopes, stineman_interp, inside_poly, poly_below, > poly_between, exp_safe, \ > amap, rms_flat, l1norm, l2norm, norm_flat, frange, > diagonal_matrix, identity, \ > base_repr, binary_repr, log2, ispower2, fromfunction_kw, rem, > norm, orth, rank, sqrtm,\ > mfuncC, approx_real, rec_append_field, rec_drop_fields, rec_join, > csv2rec, rec2csv - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] speed
Michael Droettboom wrote: > John Hunter wrote: >> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> >>> I've committed my changes on the transforms branch so you can play with >>> it -- I'm holding off on changing the trunk due to the pending release. >>> But if everyone agrees on the way to expose this, it would be nice to >>> merge this over to trunk before the release. >> >> Am I right in assuming that the only thing we lose in this approach is >> faceting (which Eric hates but others may care about)? Since it is >> orders of magnitudes faster, we could have a pcolor_faceted which >> pcolor calls the old function if shading='faceted'. Of course the two >> functions would return different types (image vs patch collection) >> which is potentially a bit confusing We could play with adding >> faceting to images > > pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses > pcolor), where the edges of the quadrilaterals are not necessarily > parallel to the x or y axes. The NonUniformImage stuff requires that > the quadrilaterals are axis-aligned rectangles. To put it another way, > the X and Y arrays (that define the mesh) can be 2-dimensional for > pcolor, but only 1-dimensional for (the new) imshow. > > pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, > but uses optimized quadmesh drawing under the hood, rather than a > PolyCollection. (Though the comments hint at subtle differences related > to masking.) > > But you are right -- NonUniformImage does not support outlining each > quadrilateral -- though that may not be hard to add if needed. > > The difference in return types is perhaps an argument for > NonUniformImages going in imshow, not pcolor. (I was thinking only of > ease of implementation...) > > Cheers, > Mike > Mike, I have looked at NonUniformImage and found that although in the extension code it is called "pcolor", it is not doing the right thing for pcolor; and I think not quite the right thing for anything "image-like" either. For the latter, the problem is that it extrapolates the edges out indefinitely. I can't think of any circumstance in which this would be desirable. For the former, which is the application that really interests me, this extrapolation is one problem, but worse than that, it does not allow easy specification of the rectangle *boundaries*, which is what pcolor really needs. So, it is a strange hybrid. I thought I might simply make a modified version to do what pcolor really needs, but between general distraction and floundering in C++ I have not succeeded, although it looks like it should be very easy--especially for someone comfortable with C++ and Agg, which I am not. So, if you can get to it, that would be great. If not, I can probably do it within a week or two. The pcolor variant of the nonuniform image code should accept as X and Y vectors giving the *boundaries* of the rectangles, so they should have lengths 1 greater than the corresponding dimensions of the color array. Any pixels that are not within the rectangles should be given the background color, so this needs to be passed in as well, just as it is for the regular image initializer. I will discuss higher level API questions later. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] check pylab before upcoming release
On Nov 12, 2007 12:15 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > In your list, "load" is duplicated. Thanks, purged. > On a more strategic note: what do you see as the future of mlab, and its > place in pylab? Should mlab contain every neat function we can think > of, and if so, should all of these be exposed in the pylab namespace? > Do we have or need any quality-control standards for these functions? > Is there a point in exposing more of mlab now than we have in the past? > Probably so, but we might want to be conservative about it. Generally I use cbook as a repository of general purpose helper functions and classes. mlab started life as a repository of matlab compatible functions to supplement those in Numeric's MLab and it has morphed into something a bit looser than that: something like a cbook for stuff with numerical content. Some of the code that started life in mlab has been moved over into numpy (polyfit, polyval, ...) and is now deprecated, some of it serves the plotting functions (cohere, psd, hist, ...), some of it provides a matlab-like function that clashes with a numpy function of the same name (load), some of it is just helper code written primarily by Fernando, me and others that didn't have a better home( eg, Fernando's code lived in ipython for a while and then he contributed it to mlab) One could argue that everything there belongs somewhere else: the load and save and record array loaders and saves belong in scipy.io, the numerical codes belong in scipy or numpy or some sandbox, some of the stuff could just be scrapped as a relic of the past. I don't have a bone to pick with that argument, but I do have a practical concern: I am not a numpy/scipy committer and don't really have the time to become one and it is easier for me to put them into mpl (where I understand the code organization, build process, commit protocol, tests, etc much better) than to go through a numpy or scipy patch development and submission process. I am more than happy for any of this code to end up there and be pulled from mpl. In the past, I've offered this to Travis and he has taken me up on it for some functions, and the same goes for any other user or developer who has strong feelings on how these codes should be organized. Having taught several courses of "scientific computing for python" I am certainly aware of and sympathetic to the complaint that it is difficult to know where to find stuff in the support packages for scientific computing. I am all in favor of getting as much useful stuff into numpy and scipy and organized and documented -- it's just not likely to be me who is the one doing it, just from a time standpoint. So I currently tend to use cbook and mlab as a place for code I develop that is generally useful and is not available in numpy or scipy. Since we are making good progress with cleaning up the namespaces inside mpl and in the examples and in the import layer (eg pyplot), I am happy to *minimize* the contribution of mlab to the pylab namespace. In my scripts I get only "figure", "close" and "show" from pylab anyway so it won't affect me. If we want to stick to the original view of mlab as a repository of matlab-like functions not in scipy or numpy, we can prune the stuff it provides to pylab significantly. I'm also happy to split stuff out of mlab into a different module for clarity if you or others think that would be useful ( I did that originally adding the rec* functions to "recutils", but reverted thinking it would be preferable to add to an existing module than create another one) As for tests and quality control, I'm open to suggestions. For most things, I tend to write an example and add it to the backend driver, which is a test on "still runs" but generally not "runs correctly". Certainly more unit tests would be welcome. JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib build options
I have been updating the logic in our setup.py and setupext.py files, so all of the build options are now exposed in setup.cfg. This should make it easier for anyone wishing to distribute matplotlib, like package managers. See setup.cfg.template for the details. There are a few changes. The external packages kept in lib/ now report "-mpl" in their versions. Past version provided by matplotlib will be identified and updated on future installs. It is also possible to disable the installation of these external packages, details are listed in setup.cfg.template. Finally, building of extension modules like gtkagg and gdk can be enabled, disabled, or attempted regardless of missing dependencies, in which case the build will fail with a meaningful error message. Please upgrade your svn repository and report any problems, so they dont show up after cutting the next release. Thanks, Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib build options
On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > I have been updating the logic in our setup.py and setupext.py files, so all > of the build options are now exposed in setup.cfg. This should make it easier > for anyone wishing to distribute matplotlib, like package managers. See > setup.cfg.template for the details. I just did a clean build and it went through -- a good start! I tried enabling the new config with by setting NEWCONFIG = True in __init__.py, and also enabled in setup.cfg ## Experimental config package support: enthought.traits = True configobj = True I pulled my matplotlibrc file from ~/.matplotlib and dropped in a copy of site-packages/matplotlib/mpl-data/matplotlib.conf into ~/.matplotlib, and then tried to run simple_plot.py with --verbose-helpful. Here is the error I got: [EMAIL PROTECTED]:examples> python simple_plot.py --verbose-helpful $HOME=/home/titan/johnh CONFIGDIR=/home/titan/johnh/.matplotlib matplotlib data path /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data loaded rc file /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc $HOME=/home/titan/johnh CONFIGDIR=/home/titan/johnh/.matplotlib matplotlib data path /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data loaded rc file /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc Traceback (most recent call last): File "simple_plot.py", line 6, in ? from pylab import * File "/home/titan/johnh/dev/lib/python2.4/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/__init__.py", line 714, in ? from config import rcParams, rcdefaults File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/__init__.py", line 10, in ?from mplconfig import rcParams, mplConfig, save_config, rcdefaults File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/mplconfig.py", line 488, in ? filePriority=True) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/tconfig.py", line 561, in __init__ self.tconf = configClass(self.fconfCombined,monitor=monitor) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/tconfig.py", line 425, in __init__ section = v(sec_config,self,monitor=monitor) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/config/tconfig.py", line 400, in __init__ raise TConfigInvalidKeyError(m) matplotlib.config.tconfig.TConfigInvalidKeyError: In config defined in file: '/home/titan/johnh/.matplotlib/matplotlib.conf' Error processing section: text These subsections are invalid : ['math'] Valid subsection names: ['latex'] I am attaching my setup.cfg as well as ~/.matplotlib/matplotlib.conf. I haven't made any changes to the [text] section that I know of Note there is also the somewhat confusing line in the verbose output loaded rc file /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc Thoughts? One other minor suggestion: you probably want to include the VERBOSE setting from setup.py in the cfg file. One of the things we want to get to here is to allow developers to tweak their local config w/o risking compromising the svn repository. I am frequently guilty of this: I may tweak some variable in setup.py to get the build I need, and then forget to unset it when I commit. If everything in the build is configurable from a file that doesn't live in svn, we won't have this problem. In the same vein, if you can make setup.cfg handle the NEWCONFIG setting, this would be ideal. I realize this is tricky because at runtime you don't know which config file to read until you have your config, so don't worry about it if it is too tricky. One possibility while we are in development testing phase would be assume NEWCONFIG if ~/.matplotlib/matplotlib.conf exists. JDH JDH matplotlib.conf Description: Binary data setup.cfg Description: Binary data - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib build options
On Monday 12 November 2007 05:52:55 pm John Hunter wrote: > On Nov 12, 2007 4:09 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > > I have been updating the logic in our setup.py and setupext.py files, so > > all of the build options are now exposed in setup.cfg. This should make > > it easier for anyone wishing to distribute matplotlib, like package > > managers. See setup.cfg.template for the details. > > I just did a clean build and it went through -- a good start! I tried > enabling the new config with by setting NEWCONFIG = True in > __init__.py, and also enabled in setup.cfg I was going to mask the NEWCONFIG stuff for the upcoming release, including providing the following packages: > ## Experimental config package support: > enthought.traits = True > configobj = True > > I pulled my matplotlibrc file from ~/.matplotlib and dropped in a copy > of site-packages/matplotlib/mpl-data/matplotlib.conf into > ~/.matplotlib, and then tried to run simple_plot.py with > --verbose-helpful. Here is the error I got: [...] > matplotlib.config.tconfig.TConfigInvalidKeyError: In config defined in > file: '/home/titan/johnh/.matplotlib/matplotlib.conf' > Error processing section: text > These subsections are invalid : ['math'] > Valid subsection names: ['latex'] This is unrelated to the changes in the setup scripts. It looks like config.mplconfig has been changed. The section name now is mathtext, not text.math. It is not possible to autocreate the matplotlib.conf files at build time, without requiring configobj and enthought.traits as external dependencies. Instead, the developers should get in the habit of running mplconfig.py as a script whenever we make changes to mplconfig, in order to update the default config file (I just did so). This should also be done immediately before any release that includes the new config package. > I am attaching my setup.cfg as well as ~/.matplotlib/matplotlib.conf. > I haven't made any changes to the [text] section that I know of > > Note there is also the somewhat confusing line in the verbose output > > loaded rc file > /home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data/matpl >otlibrc When the config package encounters a matplotlibrc file but not a matplotlib.conf file, it reads the rc file and creates a .conf file. The message must have been printed during that process. > One other minor suggestion: you probably want to include the VERBOSE > setting from setup.py in the cfg file. One of the things we want to > get to here is to allow developers to tweak their local config w/o > risking compromising the svn repository. I am frequently guilty of > this: I may tweak some variable in setup.py to get the build I need, > and then forget to unset it when I commit. If everything in the build > is configurable from a file that doesn't live in svn, we won't have > this problem. In the same vein, if you can make setup.cfg handle the > NEWCONFIG setting, this would be ideal. I realize this is tricky > because at runtime you don't know which config file to read until you > have your config, so don't worry about it if it is too tricky. One > possibility while we are in development testing phase would be assume > NEWCONFIG if ~/.matplotlib/matplotlib.conf exists. Done. The last option is disabling compilation of the image extension module. Should that still be optional? Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] check pylab before upcoming release
On Nov 12, 2007 1:19 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Nov 12, 2007 12:15 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > > On a more strategic note: what do you see as the future of mlab, and its > > place in pylab? Should mlab contain every neat function we can think > > of, and if so, should all of these be exposed in the pylab namespace? > > Do we have or need any quality-control standards for these functions? > > Is there a point in exposing more of mlab now than we have in the past? > > Probably so, but we might want to be conservative about it. > > One could argue that everything there belongs somewhere else: the load > and save and record array loaders and saves belong in scipy.io, the > numerical codes belong in scipy or numpy or some sandbox, some of the > stuff could just be scrapped as a relic of the past. I don't have a > bone to pick with that argument, but I do have a practical concern: I > am not a numpy/scipy committer and don't really have the time to > become one and it is easier for me to put them into mpl (where I > understand the code organization, build process, commit protocol, > tests, etc much better) than to go through a numpy or scipy patch > development and submission process. > > I am more than happy for any of this code to end up there and be > pulled from mpl. In the past, I've offered this to Travis and he has > taken me up on it for some functions, and the same goes for any other > user or developer who has strong feelings on how these codes should be > organized. Having taught several courses of "scientific computing for > python" I am certainly aware of and sympathetic to the complaint that > it is difficult to know where to find stuff in the support packages > for scientific computing. I am all in favor of getting as much useful > stuff into numpy and scipy and organized and documented -- it's just > not likely to be me who is the one doing it, just from a time > standpoint. So I currently tend to use cbook and mlab as a place for > code I develop that is generally useful and is not available in numpy > or scipy. Hey John, I am willing to commit to helping migrating the relevant mlab code over to SciPy (or NumPy). The next release of SciPy (http://projects.scipy.org/scipy/scipy/milestone/0.7) may be pushed back a little, but it should be out by February at the latest. One of the things I had been planning to work on for this release was going over the various scipy.io code anyway. I probably won't get a chance to take a close look at things until December, but I thought I would mention it in case it has any impact on your own plans. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OS X Leopard install, snag
On Nov 4, 2007 1:06 PM, Boyd Waters <[EMAIL PROTECTED]> wrote: > I believe that "generic" autoconf would pick up CFLAGS: > > CFLAGS="-arch ppc -arch i386" Worked for zlib and freetype, but failed for libpng with: gcc -DHAVE_CONFIG_H -I. -I. -I. -DPNG_CONFIGURE_LIBPNG -arch ppc -arch i386 -MT libpng12_la-png.lo -MD -MP -MF .deps/libpng12_la-png.Tpo -c png.c -fno-common -DPIC -o .libs/libpng12_la-png.o gcc-4.0: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags But, following your suggestion, I built everything with : 536 export ARCHFLAGS="-arch i386" 537 export MACOSX_DEPLOYMENT_TARGET=10.5 538 export CFLAGS="-arch i386" 543 export LDFLAGS="-arch i386" 546 export CXXFLAGS="-arch i386" but am still getting a failure. command history and build output below. It appears the failure is happening at link time when the build tries to link. The code at http://mail.python.org/pipermail/python-checkins/2006-June/054322.html suggests that both platforms are being unconditionally added in the ARCHLIST but I am not sure if that is relevant here. In any case, if I could fix the libpng problem above, I wouldn't have to worry about it. BUILDING MATPLOTLIB matplotlib: 0.90.1 python: 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] platform: darwin REQUIRED DEPENDENCIES numpy: 1.0.4.dev4380 freetype2: found, but unknown version (no pkg-config) OPTIONAL BACKEND DEPENDENCIES Gtk+: no * Building for Gtk+ requires pygtk; you must be able * to "import gtk" in your build/install environment Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4 wxPython: 2.8.3.0 * WxAgg extension not required for wxPython >= 2.8 Qt: no Qt4: no Cairo: no libpng: found, but unknown version (no pkg-config) OPTIONAL DATE/TIMEZONE DEPENDENCIES datetime: present, version unknown dateutil: matplotlib will provide pytz: matplotlib will provide OPTIONAL USETEX DEPENDENCIES dvipng: no ghostscript: /bin/sh: gs: command not found latex: no EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES configobj: matplotlib will provide enthought.traits: matplotlib will provide [Edit setup.cfg to suppress the above messages] running build running build_py copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.macosx-10.5-i386-2.5/matplotlib/mpl-data running build_ext building 'matplotlib.backends._tkagg' extension C compiler: gcc -DNDEBUG -g -O3 -arch i386 compile options: '-I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I. -I/usr/local/include -I/usr/include -I. -I/System/Library/Frameworks/Tcl.framework/Headers/freetype2 -I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/freetype2 -I/System/Library/Frameworks/Tk.framework/Headers/freetype2 -I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c' extra options: '-framework Tcl -framework Tk' g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup -arch i386 -arch i386 build/temp.macosx-10.5-i386-2.5/src/_tkagg.o build/temp.macosx-10.5-i386-2.5/CXX/cxx_extensions.o build/temp.macosx-10.5-i386-2.5/CXX/cxxsupport.o build/temp.macosx-10.5-i386-2.5/CXX/IndirectPythonInterface.o build/temp.macosx-10.5-i386-2.5/CXX/cxxextensions.o -L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o build/lib.macosx-10.5-i386-2.5/matplotlib/backends/_tkagg.so -framework Tcl -framework Tk ld: warning in build/temp.macosx-10.5-i386-2.5/src/_tkagg.o, file is not of required architecture ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxx_extensions.o, file is not of required architecture ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/cxxsupport.o, file is not of required architecture ld: warning in build/temp.macosx-10.5-i386-2.5/CXX/IndirectPythonInterface.o, file is not of required architecture ld: warning in build/temp
