matplotlib-devel Mailing List for matplotlib (Page 4)

This is neat to see - I mused into the dark about whether this was
possible a couple weeks ago
(https://twitter.com/deeplycloudy/status/3130819107).
The killer-app next step would be to use a JSON callback to do set up
interactive zooming, etc. A web browser is the ultimate portable
backend, if you could make it work as smoothly as a local backend.
Paul, any chance you'll be at the BACON-PIG local python group tonight
in Columbia, MD?
-Eric
On Sat, Aug 22, 2009 at 5:04 PM, John Hunter<jd...@gm...> wrote:
> Paul Kienzle expressed interest at the mpl sprint in working on an
> html5 canvas backend for mpl. When we were taking GSOC applications
> earlier this year, Seo did a partial implementation of an html5 canvas
> which outputs javascript. I forwarding his email here with
> instructions on how to check this out in case someone wants to pick
> this up and run with it
>
>
> 532 hg clone http://bitbucket.org/sanxiyn/matplotlib-canvas/
> 533 cd matplotlib-canvas/
> 536 python simple_plot.py -dmodule://backend_canvas
>
> This creates a file test.js
>
>
>
>
> ---------- Forwarded message ----------
> From: John Hunter <jd...@gm...>
> Date: Thu, Apr 2, 2009 at 10:42 AM
> Subject: Re: Summer of Code 2009: HTML5/Canvas backend for Matplotlib
> To: Seo Sanghyeon <sa...@gm...>
> Cc: Michael Droettboom <md...@st...>
>
>
> On Thu, Apr 2, 2009 at 10:38 AM, Seo Sanghyeon <sa...@gm...> wrote:
>> 2009年4月2日 John Hunter <jd...@gm...>:
>>> OK, thanks for letting us know. Would you mind if we used your
>>> backend work for the html canvas to help the student who will be
>>> pursuing the project get a head start?
>>
>> Not at all! Feel free to use it any way you want. Do you need formal
>> license statement? (I didn't feel like attaching one, since it really is
>> a single day effort.)
>
> No need for a special statement -- I'll have this email on file where
> you gave us permission, we'll just incorporate it under the matplotlib
> license. Thanks a lot.
>
>
>>> Thanks again, and hope to see you on the mpl mailing list!
>>
>> Indeed. I subscribed to matplotlib-devel, and I plan to work on
>> Matplotlib even though I won't do it through SoC.
>
>
> Great -- talk to you there :-)
>
> JDH
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Thanks for posting that Ariel (and thanks to everyone else who pitched in).
I was finally able to install the svn trunk successfully. I will say that I
still had a build problem which was probably due to my libpng version. To
solve it, I rebuilt libpng in /usr/local/ and explicitly pointed the build
to it by modifying Ariels directions:
CFLAGS=-Os -arch i386 -I/usr/local/include/libpng12
LDFLAGS=-Os -arch i386 -L/usr/local/lib
and I set the 'darwin' key in setupext.py to '/usr/local'
I also manually deleted the python egg I had leftover from the EPD
installation.
I am not sure which of these things actually fixed the problem, but I can
finally successfully plot.
Uri
---------- Forwarded message ----------
From: Ariel Rokem <ar...@be...>
To: John Hunter <jd...@gm...>
Date: 2009年8月22日 12:48:41 -0700
Subject: Re: [matplotlib-devel] building from SVN on Mac OS X 10.5
Hi folks -
just to add to the noise. Here is what eventually worked for me (with
OS 10.5.8 and EPD 4.3), with help from Mike McKerns:
0. I removed the ~/.matplotlib folder ("rm -rf ~/.matplotlib").
1. I edited
/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/config/Makefile,
removing all occurrences of "-arch ppc" (3 occurrences), changing the
line "MACOSX_DEPLOYMENT_TARGET=10.3" to
"MACOSX_DEPLOYMENT_TARGET=10.5" and changing the occurrences of
"MacOSX10.54u.sdk" into "MacOSX10.5.sdk" (3 occurrences). Here is the
full diff:
60c60
< BASECFLAGS= -arch i386 -isysroot MacOSX10.5.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic
---
> BASECFLAGS= -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double
-no-cpp-precomp -mno-fused-madd -fno-common -dynamic
66c66
< LDFLAGS= -arch i386 -isysroot MacOSX10.5.sdk -g -L/usr/local/lib
-L/Library/Frameworks/Python.framework/Versions/4.3.0/lib
---
> LDFLAGS= -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -L/usr/local/lib
-L/Library/Frameworks/Python.framework/Versions/4.3.0/lib
115c115
< UNIVERSALSDK=MacOSX10.5.sdk
---
> UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk
123c123
< MACOSX_DEPLOYMENT_TARGET=10.5
---
> MACOSX_DEPLOYMENT_TARGET=10.3
405c405
< $(CC) -o $(LDLIBRARY) -arch i386 -dynamiclib \
---
> $(CC) -o $(LDLIBRARY) -arch i386 -arch ppc -dynamiclib \
2. In
/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/site-packages/easy-install.pth,
I commented out the line containing the directory in which the
previous version of MPL was installed
("./matplotlib-0.98.5.2n2-py2.5-macosx-10.3-fat.egg", in my case). If
I don't do this, when I import matplotlib, it imports the previous
version I had of MPL and just ignores the new installation. This is a
setuptools problem, so if you didn't have setuptools, good for you and
ignore this.
3. I ran the attached shell-script ("sh ./install-matplotlib.sh"),
based on a script by Mike McKerns, in the directory in which I wanted
my source to be. This script sets some local variable (CFLAGS,
LDFLAGS, PKG_CONFIG_PATH, ARCHFLAGS), removes previous installations,
downloads the source, builds and installs it. The backend seems to be
set to MacOSX.
I would be happy if someone who's had similar problems to the ones I
have had could test this procedure and see if it works for them as
well.
Cheers,
Ariel
-- 
Uri Laserson
PhD Candidate, Biomedical Engineering
Harvard Medical School (Genetics)
Massachusetts Institute of Technology (Mathematics)
phone +1 917 742 8019
las...@mi...

I'm creating an ensemble slice viewer written entirely in Python. The
latest version of my code requires the use of MPL0.99 so that I can
take advantage of AxesGrid for multi-panel plots. At present,
everything works perfectly on my Windows Vista machine, using the
latest EPD with the upgraded MPL modules. However, on my Windows XP
machine (same configuration: EPD with latest MPL), if I try to resize
the a plot, I get one of two things, the error mentioned in the
subject of this email or it just hangs forcing a CNTL-C exit.
I should mention that I'm using the WxAgg backend.
Has anyone else had problems using the latest version of MPL on a
Windows XP machine?
============= FULL ERROR =============
Fatal Python error: PyEval_RestoreThread: NULL tstate
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Fatal Python error: PyEval_RestoreThread: NULL tstate
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
-Patrick
---
Patrick Marsh
Graduate Research Assistant
School of Meteorology
University of Oklahoma
http://www.patricktmarsh.com

svnmerge avail -S v0_99_maint works for me now, so it looks like the
problem has been fixed. -Jouni
Ryan May <rm...@gm...> writes:
> Works for me now, but I can't give it a good test until I have actual
> changes to merge.
>
> Ryan
>
> On Mon, Aug 24, 2009 at 7:53 AM, Michael Droettboom <md...@st...> wrote:
>
>> Just catching up with mail now. Is this still a problem for either Ryan or
>> Jouni? It seems to work for me as well. All I can suggest is making sure
>> the working copy of the trunk is fully updated (but I'm sure you've thought
>> of that already).
>>
>> > svnmerge avail
>> svnmerge: multiple sources found. Explicit source argument (-S/--source)
>> required.
>> The merge sources available are:
>> /branches/v0_99_maint
>> /branches/mathtex
>> /branches/v0_98_5_maint
>>
>>
>> John Hunter wrote:
>>
>>> On Sat, Aug 22, 2009 at 3:24 AM, Ryan May<rm...@gm...> wrote:
>>>
>>>
>>>
>>>> Same behavior here. I had been having trouble doing any merges, but never
>>>> had tracked it down. I guess this is related.
>>>>
>>>>
>>>
>>> The following just worked for me
>>>
>>> svnmerge.py merge -Sv0_99_maint
>>>
>>> managed to merge almost 15 commits from the branch to the trunk w/ no
>>> conflicts despite all the docstring changes, etc. Nice!
>>>
>>> JDH
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day trial. Simplify your report design, integration and deployment - and
>>> focus on what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Andrew Straw wrote:
> I'm publishing these onto http://mpl.code.astraw.com/
Which I have now actually created a DNS entry for. If you tried and got
an error like "Address not found, can't find the server at
mpl.code.astraw.com", you should have better luck in a few minutes/hours
as the name propagates around DNS. For the impatient unix users, you can
add the line "67.223.235.187 mpl.code.astraw.com" to your /etc/hosts
to bypass the DNS lookup and hardcode the address.
-Andrew

Works for me now, but I can't give it a good test until I have actual
changes to merge.
Ryan
On Mon, Aug 24, 2009 at 7:53 AM, Michael Droettboom <md...@st...> wrote:
> Just catching up with mail now. Is this still a problem for either Ryan or
> Jouni? It seems to work for me as well. All I can suggest is making sure
> the working copy of the trunk is fully updated (but I'm sure you've thought
> of that already).
>
> > svnmerge avail
> svnmerge: multiple sources found. Explicit source argument (-S/--source)
> required.
> The merge sources available are:
> /branches/v0_99_maint
> /branches/mathtex
> /branches/v0_98_5_maint
>
>
> John Hunter wrote:
>
>> On Sat, Aug 22, 2009 at 3:24 AM, Ryan May<rm...@gm...> wrote:
>>
>>
>>
>>> Same behavior here. I had been having trouble doing any merges, but never
>>> had tracked it down. I guess this is related.
>>>
>>>
>>
>> The following just worked for me
>>
>> svnmerge.py merge -Sv0_99_maint
>>
>> managed to merge almost 15 commits from the branch to the trunk w/ no
>> conflicts despite all the docstring changes, etc. Nice!
>>
>> JDH
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day trial. Simplify your report design, integration and deployment - and
>> focus on what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Just catching up with mail now. Is this still a problem for either Ryan 
or Jouni? It seems to work for me as well. All I can suggest is making 
sure the working copy of the trunk is fully updated (but I'm sure you've 
thought of that already).
 > svnmerge avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) 
required.
The merge sources available are:
 /branches/v0_99_maint
 /branches/mathtex
 /branches/v0_98_5_maint
John Hunter wrote:
> On Sat, Aug 22, 2009 at 3:24 AM, Ryan May<rm...@gm...> wrote:
>
> 
>> Same behavior here. I had been having trouble doing any merges, but never
>> had tracked it down. I guess this is related.
>> 
>
> The following just worked for me
>
> svnmerge.py merge -Sv0_99_maint
>
> managed to merge almost 15 commits from the branch to the trunk w/ no
> conflicts despite all the docstring changes, etc. Nice!
>
> JDH
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi All,
At the SciPy 09 sprints I worked with John Hunter on our automated build
and test infrastructure. It's still not *quite* there, but I thought I'd
point out a few things at this stage. (Much of this email is
more-or-less a status update for John.)
0. We have automated tests now running triggered by SVN commits. Most of
the image comparison tests are running and passing, but there are a few
failures. One seems to be a real bug that has cropped up since James
Evans generated the baseline image suite. Another seems to have been
fixed in that time. The rest seem to be a font rendering issue that is
still unresolved.
Real bug?:
http://mpl.code.astraw.com/#test-matplotlib-testaxes-formatter-ticker-005
Fixed?:
http://mpl.code.astraw.com/#test-plots-testpolar-polar-wrap-180
1. The buildbot waterfall display is online at
http://mpl-buildbot.code.astraw.com/waterfall
2. A number of tests are failing because of font placement and/or font
anti-aliasing. (The baseline images seem to have slightly different font
images than generated ones, and generated ones are different on Mac OS X
and Ubuntu.) I think John is going to have an attempt at allowing font
anti-aliasing to be disabled. We'll see if that fixes it. The bug is
filed at
https://sourceforge.net/tracker/?func=detail&aid=2843243&group_id=80706&atid=560720
3. I've figured out how to get the buildslaves to upload to the
buildmaster. It turns out this is supported in buildbot. (See
http://djmitche.github.com/buildbot/docs/0.7.10/#Transferring-Files )
4. I have made use of the upload ability to gather the rendered,
baseline, and absdiff images in the case of failed tests. Right now,
with the help of a simple script to generate static html pages via rst,
I'm publishing these onto http://mpl.code.astraw.com/ . (We could use a
similar mechanism to publish nightly builds.) I'd like to make links in
the appropriate place in the buildbot output to the image comparison
pages, but I have not dug into the buildbot sources to figure out how to
do that.
5. John (or other devs), I can give you login access to the buildmaster
on my VPS if you send me an ssh public key to use for that purpose.
6. The buildslave that John installed on the Sage project's Mac machine
seems to be failing to resolve the hostname
`matplotlib.svn.sourceforge.net', and thus can no longer build because
it can't pull down svn commits. John--do you have any idea what's going
on here?
Hopefully, we'll have all this sorted out soon.
-Andrew

The problem of building on OSX, in particular the setupext basedir
search path including /sw, /usr and /usr/local, appears so fraught
with peril -- we don't know what kinds of libs built with what kinds
of flags that we will find -- that I removed all the dirs from the
basedir for darwin. Instead, I am hoping that the new makefile.osx
Makefile I have added, which will fetch and build the required libs
and install them into the PREFIX of your choice, will prove more
supportable.
I have tested this on a couple of platforms and it worked well, but
there are other combinations that I do not have access to so please
let me know if this is not viable. I am currently building with
 PREFIX=/Users/jdhunter/dev make -f makefile.osx fetch deps mpl_install
Builds with enthought python make still be broken due to the issues in the FAQ:
 http://matplotlib.sourceforge.net/faq/installing_faq.html#building-and-installing-from-source-on-osx-with-epd
Please kick the tires and give some feedback
JDH

Hi -
following up on this patch, as suggested, I have added a use-case of
mlab.cohere_pairs to examples/pylab_examples/mri_with_eeg.py.
Cheers,
Ariel
On Sat, Aug 22, 2009 at 4:27 PM, John Hunter<jd...@gm...> wrote:
> On Sat, Aug 22, 2009 at 6:00 PM, Ariel Rokem<ar...@be...> wrote:
>
>> so - now, almost two weeks later, I can finally install MPL from
>> source. On to submitting that patch.
>
> Thanks for following up -- applied to the release branch, merged to trunk
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

On Sat, Aug 22, 2009 at 3:24 AM, Ryan May<rm...@gm...> wrote:
> Same behavior here. I had been having trouble doing any merges, but never
> had tracked it down. I guess this is related.
The following just worked for me
 svnmerge.py merge -Sv0_99_maint
managed to merge almost 15 commits from the branch to the trunk w/ no
conflicts despite all the docstring changes, etc. Nice!
JDH

On Sat, Aug 22, 2009 at 6:00 PM, Ariel Rokem<ar...@be...> wrote:
> so - now, almost two weeks later, I can finally install MPL from
> source. On to submitting that patch.
Thanks for following up -- applied to the release branch, merged to trunk

On Sat, Aug 22, 2009 at 5:47 PM, Ariel Rokem<ar...@be...> wrote:
> Resending with CC to list:
>
> Hi - here is the diff with the suggested addition to the documentation.
Thanks! Just pushed this out to the website:
http://matplotlib.sourceforge.net/faq/installing_faq.html#building-and-installing-from-source-on-osx-with-epd

Hi -
so - now, almost two weeks later, I can finally install MPL from
source. On to submitting that patch.
Here's what I get with mlab.cohere_pairs, as it is currently:
In [1]: a=np.array([[1,2,3,4],[1,2,3,4]])
In [2]: b=([1,1],[0,0])
In [3]: mlab.cohere_pairs(a,b)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/Users/arokem/<ipython console> in <module>()
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/mlab.pyc
in cohere_pairs(X, ij, NFFT, Fs, detrend, window, noverlap,
preferSpeedOverMemory, progressCallback, returnPxx)
 597 windowVals = window
 598 else:
--> 599 windowVals = window(np.ones((NFFT,), typecode(X)))
 600 ind = range(0, numRows-NFFT+1, NFFT-noverlap)
 601 numSlices = len(ind)
NameError: global name 'typecode' is not defined
So - as Fernando mentioned above, it is looking for something that
doesn't exist anymore. With the patch (diff attached), this error no
longer occurs.
Cheers,
Ariel
On Wed, Aug 12, 2009 at 11:25 AM, Ariel Rokem<ar...@be...> wrote:
> Hi - scratch that. Only *seems* to be working. Actually it hangs when I run
> scripts that open figures. I am going to undo all this and forget I ever
> started down this path.
>
> Cheers,
>
> Ariel
>
> On Wed, Aug 12, 2009 at 11:10 AM, Ariel Rokem <ar...@be...> wrote:
>>
>> Hi again - a string of strange things just happened. After this recent
>> chain of failures, I decided to try to do some random attempts at making
>> this work.
>>
>> First, I ran 'sudo python setup.py install' in the directory into which I
>> had checked out the mpl source. After going through all of the above, that
>> now went without a hitch(?!). I started ipython and imported matplotlib, but
>> was disappointed to see that I was still importing 0.98.3, which is the
>> version I previously had.
>>
>> I then ran:
>>
>> ASR:~ arokem$ easy_install matplotlib
>> Searching for matplotlib
>> Best match: matplotlib 0.99.0
>> Removing matplotlib 0.98.3.0001 from easy-install.pth file
>> Adding matplotlib 0.99.0 to easy-install.pth file
>>
>> Using
>> /Library/Frameworks/Python.framework/Versions/4.0.30001/lib/python2.5/site-packages
>> Processing dependencies for matplotlib
>> Finished processing dependencies for matplotlib
>>
>> Now, when I open ipython and import matplotlib, the version I have is
>> 0.99, and it seems to work (opens plots and such). So - somehow the process
>> worked, but how?
>>
>> Cheers,
>>
>> Ariel
>>
>>
>>
>> On Wed, Aug 12, 2009 at 10:08 AM, Ariel Rokem <ar...@be...> wrote:
>>>
>>> Hi Fernando and John,
>>>
>>> regardless of the clunky way in which I was trying to introduce our
>>> patch, I still want to be able to build MPL from source on my machine. It is
>>> a distraction, but, hey, it's a distraction on top of a distraction on top
>>> of a distraction, so at this point, I might as well be distracted. Besides,
>>> it should end up being useful, and not only for me. Yesterday, there was
>>> someone on the matplotlib-users list with exactly the same problem in
>>> building MPL from source (sourceforge is not responding at the moment, so I
>>> can't post a link to that message). If this is not a good time to
>>> trouble-shoot this, let me know and we can come back to this in a couple of
>>> weeks. It does seem like cohere_pairs has not gotten a lot of use, so the
>>> patch can also languish for another couple of weeks andI can get stuff done
>>> regardless of solving this problem, but I would love to be able to solve
>>> this, with your help.
>>>
>>> So - I now checked out 0.99, running 'make build_osx105' (you do realize
>>> the 'x' stands for '10', don't you?) didn't work, so I followed the
>>> instructions in source/osx/README
>>>
>>> I still get exactly the same error as before:
>>>
>>> g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk
>>> -bundle -undefined dynamic_lookup -arch ppc -arch i386
>>> -L/Users/arokem/source/mpl99/release/osx/zlib-1.2.3
>>> -L/Users/arokem/source/mpl99/release/osx/libpng-1.2.33
>>> -L/Users/arokem/source/mpl99/release/osx/freetype-2.3.7 -Os -arch ppc -arch
>>> i386 -I/Users/arokem/source/mpl99/release/osx/zlib-1.2.3
>>> -I/Users/arokem/source/mpl99/release/osx/libpng-1.2.33
>>> -I/Users/arokem/source/mpl99/release/osx/freetype-2.3.7/include
>>> build/temp.macosx-10.3-fat-2.5/src/ft2font.o
>>> build/temp.macosx-10.3-fat-2.5/src/mplutils.o
>>> build/temp.macosx-10.3-fat-2.5/CXX/cxx_extensions.o
>>> build/temp.macosx-10.3-fat-2.5/CXX/cxxsupport.o
>>> build/temp.macosx-10.3-fat-2.5/CXX/IndirectPythonInterface.o
>>> build/temp.macosx-10.3-fat-2.5/CXX/cxxextensions.o -L/opt/local/lib
>>> -L/usr/local/lib -L/usr/lib -L/sw/lib -lfreetype -lz -lz -lstdc++ -lm -o
>>> build/lib.macosx-10.3-fat-2.5/matplotlib/ft2font.so
>>> -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices
>>> ld warning: in /opt/local/lib/libfreetype.dylib, file is not of required
>>> architecture
>>> ld warning: in /opt/local/lib/libz.dylib, file is not of required
>>> architecture
>>> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libxml2.2.dylib,
>>> file is not of required architecture for architecture ppc
>>> collect2: ld returned 1 exit status
>>> ld warning: duplicate dylib /opt/local/lib/libz.1.dylib
>>> lipo: can't open input file:
>>> /var/folders/Qb/QbU9SmFNHoWnC7v-nTJYrE+++TI/-Tmp-//cceiN12W.out (No such
>>> file or directory)
>>> error: command 'g++' failed with exit status 1
>>> make: *** [installers] Error 1
>>>
>>> So - there is still some problem with the architecture. BTW - this
>>> closely resembles errors I used to get when trying to install ETS, but in
>>> the recent release of ETS, this problem seems to have been solved. Here's
>>> something from enthought-dev, in that direction:
>>> https://mail.enthought.com/pipermail/enthought-dev/2009-June/022153.html
>>>
>>> I tried following Robert Kern's suggestion and edited
>>> /Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/config/Makefile
>>> in order to remove the '-arch ppc' flag from the CFLAGS and LDFLAGS
>>> variables, and from one other place in that file, but that didn't seem to
>>> help. Even though now g++ is called without the possibly offending '-arch
>>> ppc' flag, somethow that flag is generated later on in the call (after
>>> '-undefined dynamic_lookup') and I still get the same error:
>>>
>>> g++ -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle
>>> -undefined dynamic_lookup -arch ppc -arch i386
>>> -L/Users/arokem/source/mpl99/release/osx/zlib-1.2.3
>>> -L/Users/arokem/source/mpl99/release/osx/libpng-1.2.33
>>> -L/Users/arokem/source/mpl99/release/osx/freetype-2.3.7 -Os -arch ppc -arch
>>> i386 -I/Users/arokem/source/mpl99/release/osx/zlib-1.2.3
>>> -I/Users/arokem/source/mpl99/release/osx/libpng-1.2.33
>>> -I/Users/arokem/source/mpl99/release/osx/freetype-2.3.7/include
>>> build/temp.macosx-10.3-i386-2.5/src/ft2font.o
>>> build/temp.macosx-10.3-i386-2.5/src/mplutils.o
>>> build/temp.macosx-10.3-i386-2.5/CXX/cxx_extensions.o
>>> build/temp.macosx-10.3-i386-2.5/CXX/cxxsupport.o
>>> build/temp.macosx-10.3-i386-2.5/CXX/IndirectPythonInterface.o
>>> build/temp.macosx-10.3-i386-2.5/CXX/cxxextensions.o -L/opt/local/lib
>>> -L/usr/local/lib -L/usr/lib -L/sw/lib -lfreetype -lz -lz -lstdc++ -lm -o
>>> build/lib.macosx-10.3-i386-2.5/matplotlib/ft2font.so
>>> -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices
>>> ld warning: in /opt/local/lib/libfreetype.dylib, file is not of required
>>> architecture
>>> ld warning: in /opt/local/lib/libz.dylib, file is not of required
>>> architecture
>>> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libxml2.2.dylib,
>>> file is not of required architecture for architecture ppc
>>> collect2: ld returned 1 exit status
>>> ld warning: duplicate dylib /opt/local/lib/libz.1.dylib
>>> lipo: can't open input file:
>>> /var/folders/Qb/QbU9SmFNHoWnC7v-nTJYrE+++TI/-Tmp-//ccud2g4d.out (No such
>>> file or directory)
>>> error: command 'g++' failed with exit status 1
>>> make: *** [installers] Error 1
>>>
>>> Any ideas?
>>>
>>> Cheers,
>>>
>>> Ariel
>>>
>>>
>>>
>>> On Wed, Aug 12, 2009 at 3:42 AM, John Hunter <jd...@gm...> wrote:
>>>>
>>>> On Wed, Aug 12, 2009 at 2:26 AM, Fernando Perez<fpe...@gm...>
>>>> wrote:
>>>>
>>>> > By the way John, in this particular case, I don't think the change
>>>> > warrants a before/after example, because the before case is "it
>>>> > doesn't run" :) The code today makes calls to Numeric routines like
>>>> > typecode() that simply don't exist anymore, so it's totally broken:
>>>>
>>>> Great -- this is just the kind of explanation I need. Though if we had
>>>> an example, it is unlikely that the code would go so long w/o being
>>>> exercised. We do supply some eeg data with mpl -- see
>>>> examples/pylab_examples/mri_with_eeg.py, so Ariel may want to write a
>>>> simple cohere_pairs examples which just generates a scatter plot or
>>>> something else to show the output and then we can include it in
>>>> backend driver do it is will be unlikely to suffer bit rot going
>>>> forward.
>>>>
>>>> > Ariel, if you are still struggling with the binary build, since your
>>>> > changes are confined to a pure python file, you can submit the patch
>>>> > by simply running:
>>>> >
>>>> > - svn udpate
>>>> > - modify in-place mlab.py with your version of cohere_pairs
>>>> > - svn diff > mlab_cohere_pairs.diff
>>>>
>>>> udpate = update
>>>>
>>>> That will be fine -- I would like to help Ariel get his svn build
>>>> going, but if that is a distraction it doesn't need to slow the patch
>>>> down. For bugfixes we encourage patches against the release branch
>>>>
>>>> svn co
>>>> https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint
>>>> mpl99
>>>>
>>>> JDH
>>>
>>>
>>>
>>> --
>>> Ariel Rokem
>>> Helen Wills Neuroscience Institute
>>> University of California, Berkeley
>>> http://argentum.ucbso.berkeley.edu/ariel
>>
>>
>>
>> --
>> Ariel Rokem
>> Helen Wills Neuroscience Institute
>> University of California, Berkeley
>> http://argentum.ucbso.berkeley.edu/ariel
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Resending with CC to list:
Hi - here is the diff with the suggested addition to the documentation.
Cheers,
Ariel
On Sat, Aug 22, 2009 at 1:34 PM, John Hunter<jd...@gm...> wrote:
> On Sat, Aug 22, 2009 at 2:48 PM, Ariel Rokem<ar...@be...> wrote:
>> Hi folks -
>>
>> just to add to the noise. Here is what eventually worked for me (with
>> OS 10.5.8 and EPD 4.3), with help from Mike McKerns:
>
> Hey guys, this is great. Any chance I could twist your arm into
> writing this up as a ReST FAQ and updating your script to do an svn
> checkout instead of installing the last release. I would like to post
> this on the FAQ on the website.
>
> JDH
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Paul Kienzle expressed interest at the mpl sprint in working on an
html5 canvas backend for mpl. When we were taking GSOC applications
earlier this year, Seo did a partial implementation of an html5 canvas
which outputs javascript. I forwarding his email here with
instructions on how to check this out in case someone wants to pick
this up and run with it
 532 hg clone http://bitbucket.org/sanxiyn/matplotlib-canvas/
 533 cd matplotlib-canvas/
 536 python simple_plot.py -dmodule://backend_canvas
This creates a file test.js
---------- Forwarded message ----------
From: John Hunter <jd...@gm...>
Date: Thu, Apr 2, 2009 at 10:42 AM
Subject: Re: Summer of Code 2009: HTML5/Canvas backend for Matplotlib
To: Seo Sanghyeon <sa...@gm...>
Cc: Michael Droettboom <md...@st...>
On Thu, Apr 2, 2009 at 10:38 AM, Seo Sanghyeon <sa...@gm...> wrote:
> 2009年4月2日 John Hunter <jd...@gm...>:
>> OK, thanks for letting us know. Would you mind if we used your
>> backend work for the html canvas to help the student who will be
>> pursuing the project get a head start?
>
> Not at all! Feel free to use it any way you want. Do you need formal
> license statement? (I didn't feel like attaching one, since it really is
> a single day effort.)
No need for a special statement -- I'll have this email on file where
you gave us permission, we'll just incorporate it under the matplotlib
license. Thanks a lot.
>> Thanks again, and hope to see you on the mpl mailing list!
>
> Indeed. I subscribed to matplotlib-devel, and I plan to work on
> Matplotlib even though I won't do it through SoC.
Great -- talk to you there :-)
JDH

On Sat, Aug 22, 2009 at 2:48 PM, Ariel Rokem<ar...@be...> wrote:
> Hi folks -
>
> just to add to the noise. Here is what eventually worked for me (with
> OS 10.5.8 and EPD 4.3), with help from Mike McKerns:
Hey guys, this is great. Any chance I could twist your arm into
writing this up as a ReST FAQ and updating your script to do an svn
checkout instead of installing the last release. I would like to post
this on the FAQ on the website.
JDH

Hi folks -
just to add to the noise. Here is what eventually worked for me (with
OS 10.5.8 and EPD 4.3), with help from Mike McKerns:
0. I removed the ~/.matplotlib folder ("rm -rf ~/.matplotlib").
1. I edited /Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/config/Makefile,
removing all occurrences of "-arch ppc" (3 occurrences), changing the
line "MACOSX_DEPLOYMENT_TARGET=10.3" to
"MACOSX_DEPLOYMENT_TARGET=10.5" and changing the occurrences of
"MacOSX10.54u.sdk" into "MacOSX10.5.sdk" (3 occurrences). Here is the
full diff:
60c60
< BASECFLAGS=	-arch i386 -isysroot MacOSX10.5.sdk -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic
---
> BASECFLAGS=	-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic
66c66
< LDFLAGS=	-arch i386 -isysroot MacOSX10.5.sdk -g -L/usr/local/lib
-L/Library/Frameworks/Python.framework/Versions/4.3.0/lib
---
> LDFLAGS=	-arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -L/usr/local/lib -L/Library/Frameworks/Python.framework/Versions/4.3.0/lib
115c115
< UNIVERSALSDK=MacOSX10.5.sdk
---
> UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk
123c123
< MACOSX_DEPLOYMENT_TARGET=10.5
---
> MACOSX_DEPLOYMENT_TARGET=10.3
405c405
< 		$(CC) -o $(LDLIBRARY) -arch i386 -dynamiclib \
---
> 		$(CC) -o $(LDLIBRARY) -arch i386 -arch ppc -dynamiclib \
2. In /Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/site-packages/easy-install.pth,
I commented out the line containing the directory in which the
previous version of MPL was installed
("./matplotlib-0.98.5.2n2-py2.5-macosx-10.3-fat.egg", in my case). If
I don't do this, when I import matplotlib, it imports the previous
version I had of MPL and just ignores the new installation. This is a
setuptools problem, so if you didn't have setuptools, good for you and
ignore this.
3. I ran the attached shell-script ("sh ./install-matplotlib.sh"),
based on a script by Mike McKerns, in the directory in which I wanted
my source to be. This script sets some local variable (CFLAGS,
LDFLAGS, PKG_CONFIG_PATH, ARCHFLAGS), removes previous installations,
downloads the source, builds and installs it. The backend seems to be
set to MacOSX.
I would be happy if someone who's had similar problems to the ones I
have had could test this procedure and see if it works for them as
well.
Cheers,
Ariel
On Fri, Aug 21, 2009 at 9:15 AM, John Hunter<jd...@gm...> wrote:
> On Fri, Aug 21, 2009 at 10:41 AM, Jouni K. Seppänen<jk...@ik...> wrote:
>> Eric Bruning <eri...@gm...> writes:
>>
>>> ld warning: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.10.4.dylib,
>>> missing required architecture ppc in file
>>> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.1.dylib,
>>> missing required architecture ppc in file for architecture ppc
>>
>> Somehow your gcc is picking up libraries from /usr/local/lib, where you
>> have presumably installed an x86-only version of gcc (could be a side
>> effect of installing GNU Fortran). I don't know how to prevent that,
>> except perhaps by moving /usr/local away for the duration of the
>> compilation command, e.g.
>
> I think you should edit setupext.py and edit basedir directory, and
> remove all the /sw, /usr/local, etc from basedir in the 'darwin'
> entry, which reads:
>
> darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
>        '/usr', '/sw'],
>
> Then do a clean rebuild and see if that helps.
>
> JDH
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Yes, that seems to have fixed the problem. I tried to do something 
similar but failed.
Many thanks!
On 22 Aug 2009, at 05:20, Jouni K. Seppänen wrote:
> Tobias Wood <t.w...@im...> writes:
>
>> I've just started getting exactly the same errors, but with Python
>> 2.6.2 and the most recent svn checkout. I haven't updated for a month
>> or so but never had this issue before.
>
>>> src/_macosx.m:1885: error: syntax error before ‘setfont’
>>> src/_macosx.m: In function ‘setfont’:
>>> src/_macosx.m:1895: error: ‘CTFontRef’ undeclared (first use in this
>>> function)
>
> I committed to trunk a change that I think should fix this problem.
> Please test.
>
> -- 
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> trial. Simplify your report design, integration and deployment - and 
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Aug 22, 2009 at 3:01 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> I fixed some doc typos on the v0_99_maint branch and was going to merge
> the fixes to the trunk, but it didn't work:
>
> % svnmerge.py avail -S v0_99_maint
> svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous
> substring of a repository path, nor a working directory
> % svnmerge.py avail
> svnmerge: multiple sources found. Explicit source argument (-S/--source)
> required.
> The merge sources available are:
> /branches/mathtex
> /branches/v0_91_maint
> /branches/v0_98_5_maint
>
> I'm pretty sure that this used to work. What has changed in the repository?
Same behavior here. I had been having trouble doing any merges, but never
had tracked it down. I guess this is related.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Los Angeles, California, United States

I fixed some doc typos on the v0_99_maint branch and was going to merge
the fixes to the trunk, but it didn't work:
% svnmerge.py avail -S v0_99_maint
svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous substring of a repository path, nor a working directory
% svnmerge.py avail 
svnmerge: multiple sources found. Explicit source argument (-S/--source) required.
The merge sources available are:
 /branches/mathtex
 /branches/v0_91_maint
 /branches/v0_98_5_maint
I'm pretty sure that this used to work. What has changed in the repository?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Tobias Wood <t.w...@im...> writes:
> I've just started getting exactly the same errors, but with Python 
> 2.6.2 and the most recent svn checkout. I haven't updated for a month 
> or so but never had this issue before.
>> src/_macosx.m:1885: error: syntax error before ‘setfont’
>> src/_macosx.m: In function ‘setfont’:
>> src/_macosx.m:1895: error: ‘CTFontRef’ undeclared (first use in this
>> function)
I committed to trunk a change that I think should fix this problem.
Please test.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Tobias Wood <t.w...@im...> writes:
> Out of curiosity, why is the 10.4 SDK specified and how? Is this part 
> of distutils? And why, even with the 10.4 SDK, is the resulting output 
> bundle called 10.3 fat?
I think Python remembers the compiler flags used to compile the Python
interpreter and uses them when compiling extensions. The downloadable
Python interpreter has been compiled with maximal compatibility in mind:
it's Universal (i.e., both ppc and i386), and probably works on any
version of OS X from 10.3.9 onwards.
I just compiled Python 2.6.2 myself on OS X 10.5, and it wasn't
difficult at all:
./configure --enable-framework
make
sudo make install
sudo chmod g+w /Library/Frameworks/Python.framework/Versions/\
2.6/{bin,lib/python2.6/site-packages}
That last command is there to let me install further packages without
sudo. Installing numpy from numpy-1.3.0-py2.6-macosx10.5.dmg worked
well, and I had no problems compiling matplotlib. The resulting files
are of course specific to i386, OS X version 10.5, and probably some
libraries on my system, so they are not good for distribution, but I
seemed to avoid all the usual problems with compiling matplotlib.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I may have found a bug in the __setitem__ method of the maxdict class.
Since a dictionary is a mapping class, if an item is set that already
exists, it overwrites the previous. However, you are still appending that
item to _killkeys regardless.
In the case where 2 items with the same key were added and later removed due
to size constraints, the line in bold would throw an exception on the second
call.
By checking for the key existance, you handle that situation gracefully. 
The item can still be removed from _killkeys, since it's the next to go
anyway.
Ryan
Original code (circa line 776):
 if len(self)>=self.maxsize:
 del self[self._killkeys[0]]
 del self._killkeys[0]
 dict.__setitem__(self, k, v)
 self._killkeys.append(k)
Possible solution:
 if len(self)>=self.maxsize:
 if self.has_key(self._killkeys[0]):
 del self[self._killkeys[0]]
 del self._killkeys[0]
 dict.__setitem__(self, k, v)
 self._killkeys.append(k)
-- 
View this message in context: http://www.nabble.com/cbook.py%2C-maxdict-class-key-checking-on-__setitem__-tp25090453p25090453.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

With regards to the update() function, is it supposed to actually add the
data point to the graph? After making the change and re-running the
program, the plot does not contain the new data point. 
Thanks,
Ryan
John Hunter-4 wrote:
> 
> On Fri, Aug 21, 2009 at 6:24 PM, Ryanitus<rya...@ho...> wrote:
>>
>> Hello.
>>
>> I was doing a simple test using a FIFOBuffer. I set the dataLim
>> parameter
>> to the dataLim of a Line2D plot. After adding a value to the FIFO, it
>> raises an exception. It looks like the FIFO is trying to call
>> Bbox.update(), but that method does not exist. Other update_*() methods
>> do.
>> Any ideas?
> 
> In mpl 0.98 we did a big refactoring of the transformations
> infrastructure but this class was not properly poprted. I've fixed it
> in the svn release branch so it should be fixed in the next release
> (0.99.1)
> 
> Thanks for the report,
> JDH
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://www.nabble.com/FIFOBuffer.add%28%29-calls-Bbox.update%28%29%2C-not-a-method-tp25088841p25090188.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.