matplotlib-devel Mailing List for matplotlib (Page 4)

On Mon, Dec 15, 2008 at 7:15 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom <md...@st...> wrote:
<SNIP>
Hi,
> I have access to a win32 and linux machine that are up and on the
> network most of the time, and could use these as build/test bots for
> those platforms. I have an OS X laptop, but it is not up or on the
> network most of the time so is not a good candidate for this. Does
> anyone have a suitable OSX 10.5 box on the network with ssh access
> that would be suitable to host nightly builds?
I can provide you with ssh access to a decent OSX 10.5 box (Dual Xeon,
8GB) at the University of Washington at Seattle. Just ping me off list
and I can hook you up.
<SNIP>
Cheers,
Michael

On Sat, Dec 13, 2008 at 10:32 AM, John Hunter <jd...@gm...> wrote:
> On Sat, Dec 13, 2008 at 9:22 AM, Darren Dale <dsd...@gm...> wrote:
>
> >> I haven't been able to get to the root of this problem, but an
> "svn-clean"
> >> in the doc directory always fixes it for me.
> >
> > I tried that but the problem persists. I have sphinx-0.4.2 installed, are
> > you using the same version?
>
>
(John suggested in a private email to try upgrading to sphinx-0.5.)
You're right, the error does not occur with sphinx-0.5. It looks like the
API for registering nodes has changed as of 0.5. The development branch of
sphinx was throwing errors when it got to latex, so I had a look and came up
with some changes that work with both version 0.5 and the development
branch. The changes are not compatible with sphinx-0.4.2, but it looks like
we are requiring version 0.5 or later now anyway. If this is the case, I'll
go ahead and commit the changes. Here is the diff, please let me know if I
should commit or if I should hold off:
$ svn diff sphinxext/
Index: sphinxext/inheritance_diagram.py
===================================================================
--- sphinxext/inheritance_diagram.py (revision 6612)
+++ sphinxext/inheritance_diagram.py (working copy)
@@ -39,8 +39,6 @@
 from md5 import md5
 from docutils.nodes import Body, Element
-from docutils.writers.html4css1 import HTMLTranslator
-from sphinx.latexwriter import LaTeXTranslator
 from docutils.parsers.rst import directives
 from sphinx.roles import xfileref_role
@@ -409,12 +407,9 @@
 inheritance_diagram_directive)
 def setup(app):
- app.add_node(inheritance_diagram)
-
- HTMLTranslator.visit_inheritance_diagram = \
- visit_inheritance_diagram(html_output_graph)
- HTMLTranslator.depart_inheritance_diagram = do_nothing
-
- LaTeXTranslator.visit_inheritance_diagram = \
- visit_inheritance_diagram(latex_output_graph)
- LaTeXTranslator.depart_inheritance_diagram = do_nothing
+ app.add_node(inheritance_diagram,
+ html=(visit_inheritance_diagram(html_output_graph),
+ do_nothing))
+ app.add_node(inheritance_diagram,
+ latex=(visit_inheritance_diagram(latex_output_graph),
+ do_nothing))
Index: sphinxext/mathmpl.py
===================================================================
--- sphinxext/mathmpl.py (revision 6612)
+++ sphinxext/mathmpl.py (working copy)
@@ -6,8 +6,6 @@
 from docutils import nodes
 from docutils.parsers.rst import directives
-from docutils.writers.html4css1 import HTMLTranslator
-from sphinx.latexwriter import LaTeXTranslator
 import warnings
 # Define LaTeX math node:
@@ -69,8 +67,6 @@
 self.body.append(latex2html(node, source))
 def depart_latex_math_html(self, node):
 pass
- HTMLTranslator.visit_latex_math = visit_latex_math_html
- HTMLTranslator.depart_latex_math = depart_latex_math_html
 # Add visit/depart methods to LaTeX-Translator:
 def visit_latex_math_latex(self, node):
@@ -83,9 +79,14 @@
 '\\end{equation}'])
 def depart_latex_math_latex(self, node):
 pass
- LaTeXTranslator.visit_latex_math = visit_latex_math_latex
- LaTeXTranslator.depart_latex_math = depart_latex_math_latex
+ app.add_node(latex_math, html=(visit_latex_math_html,
+ depart_latex_math_html))
+ app.add_node(latex_math, latex=(visit_latex_math_latex,
+ depart_latex_math_latex))
+ app.add_role('math', math_role)
+
+
 from matplotlib import rcParams
 from matplotlib.mathtext import MathTextParser
 rcParams['mathtext.fontset'] = 'cm'
Index: sphinxext/only_directives.py
===================================================================
--- sphinxext/only_directives.py (revision 6612)
+++ sphinxext/only_directives.py (working copy)
@@ -4,8 +4,6 @@
 #
 from docutils.nodes import Body, Element
-from docutils.writers.html4css1 import HTMLTranslator
-from sphinx.latexwriter import LaTeXTranslator
 from docutils.parsers.rst import directives
 class html_only(Body, Element):
@@ -63,9 +61,6 @@
 directives.register_directive('latexonly', LatexOnlyDirective)
 def setup(app):
- app.add_node(html_only)
- app.add_node(latex_only)
-
 # Add visit/depart methods to HTML-Translator:
 def visit_perform(self, node):
 pass
@@ -76,12 +71,7 @@
 def depart_ignore(self, node):
 node.children = []
- HTMLTranslator.visit_html_only = visit_perform
- HTMLTranslator.depart_html_only = depart_perform
- HTMLTranslator.visit_latex_only = visit_ignore
- HTMLTranslator.depart_latex_only = depart_ignore
-
- LaTeXTranslator.visit_html_only = visit_ignore
- LaTeXTranslator.depart_html_only = depart_ignore
- LaTeXTranslator.visit_latex_only = visit_perform
- LaTeXTranslator.depart_latex_only = depart_perform
+ app.add_node(html_only, html=(visit_perform, depart_perform))
+ app.add_node(html_only, latex=(visit_ignore, depart_ignore))
+ app.add_node(latex_only, latex=(visit_perform, depart_perform))
+ app.add_node(latex_only, html=(visit_ignore, depart_ignore))

On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom <md...@st...> wrote:
> 4) Automating (scripting) more of the process where possible (I'm sure
> that's not straightforward... just thinking out loud)
>
> 5) Release formal "release candidates" -- IMHO these would be most
> useful if we expect more people to download and try them than are
> already tracking SVN. But even without that, it may help find packaging
> bugs (such as the configobj stuff) before declaring something a "release".
Looks like we are on the same page, since I just hit send in another
thread in the same vein, and have updated the release_guide with
similar suggestions :-)
I think one other thing that could help here would be to have nightly
builds and sdists. The Makefile for OS X, with some easy
modifications to get snapshots from HEAD, would enable this. With
nightly builds and prominent links on the home page, we will get early
warning on problems that creep into the code base since presumably we
will have more people running from HEAD and exercising the installers
in all the wild and woolly environments that are out there. It would
also force us to have a fully automated checkout/build/test/post
process that will serve us well in the actual releases.
I have access to a win32 and linux machine that are up and on the
network most of the time, and could use these as build/test bots for
those platforms. I have an OS X laptop, but it is not up or on the
network most of the time so is not a good candidate for this. Does
anyone have a suitable OSX 10.5 box on the network with ssh access
that would be suitable to host nightly builds? I could handle all the
code in svn and you could just svn up and point a cron job to some
script in release/osx, or you could give me ssh access to the machine
and I could maintain the job.
As I pointed out in another thread, I would like to have a build
script for win32 in svn that works the same way, but this is a harder
problem, since getting a working build environment is a harder
process. The ideal script would bootstrap the entire build dependency
tree, manipulate setup.cfg automatically, and build the binaries.

On Sun, Dec 14, 2008 at 11:24 AM, Charlie Moad <cw...@gm...> wrote:
> First of all let me apologize for the problems we have been
> ...snip...
> seeing with the binaries as of late. Frankly the root of the problem
> seeing osx fat binaries with 4 architectures! I am more than happy to
> continue to contribute my time to create these builds, but I think it
> only makes sense to have a release candidate cycle before formally
> pushing to sourceforge.
I think this is a good suggestion which we will adopt going forward.
I rushed the process because I was interested in getting a release out
before my talk last week since I wanted to show off some of the new
stuff, and thought we had done this enough times that it would go
smoothly under an expedited schedule, but clearly it did not. So
going forward we will make the release branch first, post release
candidates with binaries, announce testing of them, give them at least
a week to shake out the bugs, fix the changes on the branch and merge
into trunk, and then build the final release from the branch.
I have updated the release_guide instructions in the developer's guide
 http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/devel/release_guide.rst?view=markup
What are the architectures you are referring to when you write "osx
fat binaries with 4 architectures". I am not sure what they are, but
I doubt we will choose to support all of them :-)
I do think having platform specific make scripts which do everything
necessary to checkout and build the dependencies and releases is the
right way to go. As you probably saw from my post yesterday, I wrote
one of these for OSX yesterday and put it in release/osx, so we should
update and use that going forward -- we can refine this even further
to incorporate some testing, etc, but it is a good start. If you have
time to work on an analog for win32, that would be great, otherwise I
may hold my nose and give it a try.
Sorry for the extra workload and stress created by this fumble of a release....
JDH

It's been an unusually bumpy release cycle through no fault of the 
people involved. We've just been unlucky this time, I guess... ;)
So -- more bad news:
Julien pointed out a very serious bug this morning, that may warrant 
another release... The gridlines jump around while panning and 
zooming. I fully take credit for introducing this bug a few weeks ago 
trying to fix a log scaling problem. It is now fixed in SVN on 0.98.5 
maint and trunk.
Julien also pointed out another bug related to antialiasing which was 
caused by code that I intended to be experimental (it was committed only 
to the trunk) but made it into the release. I just want to make a 
gentle reminder to the hard-working and exhausted release team to please 
make the next bugfix release from the branch, not the trunk.
Unfortunately, I think because of the seriousness of these bugs, another 
release should be made asap. I sincerely apologize for the work this 
causes others. I'm willing to volunteer to do a release to make it up 
to Charlie and John, but I'm worried, having seen how finicky the 
build/release process is, that I may not actually help... ;(
As for the release following that -- maybe we should step back and try 
to find some ways to make it easier. I'm not trying to second guess us 
here -- I think we're doing a lot of things right, but just want to get 
a discussion going about whether there's any more tweaks that would be 
beneficial.
We're doing some good things already -->
1) The release guide in the developer docs
2) John's recent commits of OS-X release tools
3) Using maintenance branches
We may also want to consider -->
4) Automating (scripting) more of the process where possible (I'm sure 
that's not straightforward... just thinking out loud)
5) Release formal "release candidates" -- IMHO these would be most 
useful if we expect more people to download and try them than are 
already tracking SVN. But even without that, it may help find packaging 
bugs (such as the configobj stuff) before declaring something a "release".
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Bruning wrote:
> I think of artists as having visual properties that persist (e.g.,
> filled vs. outlined, a colormap with min and max values) even as data
> associated with the artist is changed. In the edge case described
> below, this doesn't seem to hold true.
> 
> I have code that animates a scatter plot by sub-selecting the data
> stored in a collection artist. In cases where some frames contain no
> data, the scatter artist's data is temporarily empty. On subsequent
> frames (once there is data again) some of the visual properties my
> filled point becomes an outlined point, as in the code below.
> 
> # Filled single point with no outline
> sc = scatter([1],[1],c=[1], edgecolors='none')
> 
> # Cache the data
> xy=sc.get_offsets()
> s=sc.get_array()
> 
> sel=s<0
> sc.set_offsets(xy[sel,:])
> sc.set_array(s[sel])
> 
> # No data, so nothing shown. No problem.
> sc.figure.canvas.draw()
> 
> # Now restore the original data
> sc.set_offsets(xy)
> sc.set_array(s)
> 
> # Outlined single point with no fill
> sc.figure.canvas.draw()
> sc.get_edgecolors()
> sc.get_facecolors()
> sc.get_array()
> 
> The fix probably has to do with Collection.update_scalarmappable.
> When set_array([ ]) happens,
> len(self._facecolors) > 0, therefore
> self._facecolors = to_rgba([ ]),
> When set_array([1]) restores data,
> len(self._facecolors) == 0, therefore
> self._edgecolors = self.to_rgba([1])
> 
> Should is_filled vs. is_stroked be preserved in this case? If so, is
> there a more elegant fix than to add is_filled and is_stroked
> properties that are checked by update_scalarmappable?
I don't see a better way, so I implemented your suggestion.
Eric

On Sun, Dec 14, 2008 at 07:33:57PM -0800, fraka6 wrote:
> It is a little annoying because I wast thinking of using Extension module
> from distutils.core to create my library setup.py that seems to use
> easy_install.
AFAIK, Extension doesn't need setuptools (setuptools is the libraryy
providing easy_install). If you have a problem here, you'll have to tell
us a bot more about it.
Cheers,
Gaël

It is a little annoying because I wast thinking of using Extension module
from distutils.core to create my library setup.py that seems to use
easy_install. As suggested in my 
http://fraka6.blogspot.com/2008/12/swig-and-python.html blog I will try to
use scipy.mlab interface instead. Yes aptitude is great for ubuntu users.
Fran6 
Gael Varoquaux-2 wrote:
> 
> On Sun, Dec 14, 2008 at 07:30:19AM -0800, fraka6 wrote:
> 
>> I have experienced the same problem with easy_install on ubuntu-8.4.10
>> but
>> it is working with aptitude, so I have done :
>> sudo aptitude install python-matplotlib
> 
> Yes, but unfortunately, not every OS has a good packaging system like
> apt-get/aptitude (and this is actually the reason I use Ubuntu, but
> people should be free to choose their OS).
> 
> Gaël
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://www.nabble.com/error-installing-matplotlib-0.98.5-tp20982264p21007850.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Sun, Dec 14, 2008 at 07:30:19AM -0800, fraka6 wrote:
> I have experienced the same problem with easy_install on ubuntu-8.4.10 but
> it is working with aptitude, so I have done :
> sudo aptitude install python-matplotlib
Yes, but unfortunately, not every OS has a good packaging system like
apt-get/aptitude (and this is actually the reason I use Ubuntu, but
people should be free to choose their OS).
Gaël

On Sun, Dec 14, 2008 at 8:31 PM, Michael Abshoff
<mab...@go...> wrote:
> Slightly OT: What is the preferred way to submit bug fixes? The sf
> tracker? I have two tiny build fixes for 0.98.3 (that also apply to
Even though it's not a FAQ, we have a FAQ entry for it :-)
 http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch
JDH

On Sun, Dec 14, 2008 at 7:46 PM, Sandro Tosi <mat...@gm...> wrote:
> Well, what I'm actually asking is: can I use any matplotlibrc file (be
> it from any location in the tarball or forged during build process) or
> the one in doc/mpl_data has something specific to documentation that
> needs to be preserved.
In svn, doc/mpl_data is just a symlink to lib/matplotlib/mpl-data
 http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/mpl_data?view=markup
Apparently symlinks are lost in building an sdist, and doc/mpl_data
becomes a copy. So in the actual src, the rc files are not just
identical in the two locations, they are the same file. It makes the
most sense for the users to see in the docs the default rc file they
are getting with your actual install.

On Sun, Dec 14, 2008 at 10:55 AM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Dec 14, 2008 at 1:28 PM, Michael Abshoff <mab...@go...>
> wrote:
>> On Sun, Dec 14, 2008 at 10:22 AM, Darren Dale <dsd...@gm...> wrote:
>> > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote:
Hi,
<SNIP>
>> The express edition can only produce 32 bit binaries, but I guess this
>> is better than nothing.
>
> According to wikipedia
> (http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express) :
>
> "natively compiling 64-bit applications through the IDE is not supported. If
> the freely available Windows SDK is installed, 64-bit applications can be
> built on the command line using the x64 cross-compiler (Cl.exe) supplied
> with the SDK." The documentation at python.org does not indicate whether or
> not it is possible to cross-compile with the express edition if the Windows
> SDK is installed
> (http://docs.python.org/distutils/builtdist.html#cross-compiling-on-windows)
Ok, I didn't know that. There is also some movement with the 64 bit
MinGW port, so hopefully in 2009 one might see a stable release there,
too.
>>
>> > I the past
>> > I have built and distributed extension modules built with mingw32 on
>> > windows
>> > XP, but I have not been able to put together a working mingw32/msys on a
>> > 64-bit windows vista machine. This is my only windows computer, so it
>> > looks
>> > like I will only be supporting py2.6 in the near future.
>>
>> Since numpy 1.3 (probably out January 2009) will start supporting
>> python 2.6 and official Python 3k support for numpy is currently
>> anticipated not for a while I would guess Python 3k support is a
>> non-issue for now. OTOH the many Python libraries depending on numpy
>> might make Python 3K support happen sooner.
>
> Last I heard, the numpy folks think py-3 support is at least a year out.
>
Yes, I have seen that figure thrown around on the list last week, too.
The reasoning seems to be that it would take until 2010 until "major"
distributions shipped Py3K, but given the dependency of many libs I
would be surprised if there wasn't enough pressure earlier to get this
fixed. Given that numpy uses the Python C API directly this might be
more work than some people think. In the end it would probably greatly
help if the same codebase could support Python 2.x and Py3K at the
same time, but we will see.
Slightly OT: What is the preferred way to submit bug fixes? The sf
tracker? I have two tiny build fixes for 0.98.3 (that also apply to
0.98.5) that fix the build on FreeBSD 7 and also works around some
tcl/tl detection strangeness. Both patches are one liners to
setupext.py.
Cheers,
Michael

On Sun, Dec 14, 2008 at 1:58 PM, Charlie Moad <cw...@gm...> wrote:
> On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsd...@gm...> wrote:
> > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote:
> >>
> >> First of all let me apologize for the problems we have been
> >> seeing with the binaries as of late. Frankly the root of the problem
> >> might be my detachment from the matplotlib source for some time.
> >> Unfortunately due to my time constraints, this won't be changing soon.
> >> I used to think being somewhat on the outside helped me keep the ease
> >> of the build process in check. This gap has apparently grown too
> >> wide.
> >
> > I appreciate that this is a difficult task and that you have plenty of
> other
> > responsibilities, and appreciate your effort. However, I've been trying
> to
> > get to the bottom of why the windows installer is overwriting configobj
> and
> > I could use some feedback from you. I really need to know whether you
> delete
> > the build/ directory before creating a new installer.
>
> I don't have my build directories anymore, but they were made from
> extracting the source release so there was no previous build
> directory. It is possible that I missed those settings in setup.cfg,
> because I do not have either of those module installed.
>
If you did not explicitly disable these modules in setup.cfg, then I think
we understand the problem. Would you please make a note that configobj and
traits should be explicitly disabled in setup.cfg for future releases of the
maintenance branches? It will not be an issue for the trunk.
Thanks,
Darren

On Sun, Dec 14, 2008 at 1:46 PM, Sandro Tosi <mat...@gm...> wrote:
> Hello,
>
> On Sun, Dec 14, 2008 at 17:07, Darren Dale <dsd...@gm...> wrote:
> > On Sun, Dec 14, 2008 at 8:12 AM, Sandro Tosi <mo...@de...> wrote:
> >>
> >> Hello,
> >> while preparing the debian package update for 0.98.5 I went thru a
> >> problem: we remove doc/mpl_data/matplotlibrc because it will be
> >> modified (to change backend (that now is set to MacOSX in the tarball
> >> distributed..?)) and up to now it wasn't used.
> >>
> >> Now, doc/make.py fails because of
> >>
> >> shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
> >>
> >> So, can we use another 'matplotlibrc' file or the one in doc/mpl_data
> >> has something specific to doc and needs to maintained?
> >
> > The default matplotlibrc file in mpl-data/ is created by setup.py during
> the
> > build process. The default backend is selected according to which gui
> > toolkits are available, and defaults to Agg if no supported toolkit is
> > available. setup.py only selects the macosx backend if the build is being
> > performed on a macosx system. The source tarball is apparently prepared
> on a
> > Mac, but I dont think it matters that the source dist contains this
> > platform-specific backend, since the file will be overwritten with more
> > appropriate settings anyway when you run setup.py build.
> >
> > It would really be best to not remove the file that is created as a
> result
> > of running setup.py build. The mpl documentation suggests users to copy
> this
> > file into their ~/.matplotlib/ or wherever if they want to modify the
> > default properties, and it contains some documentation for each of the
> > settings.
> >
> > On the other hand, if you are running setup.py build and the resulting
> > matplotlibrc file still says the default backend is macosx, and you are
> not
> > running macosx, and you have configured setup.cfg to set some other
> default
> > backend, then it is a bug that needs to be fixed.
>
> Well, what I'm actually asking is: can I use any matplotlibrc file (be
> it from any location in the tarball or forged during build process) or
> the one in doc/mpl_data has something specific to documentation that
> needs to be preserved.
>
> Don't worry, we ship matplotlibrc file (the one built), but I need to
> know if that particular one has something ad-hoc for doc.
>
The rc file in mpl_data does get pulled into the the docs, you can see the
result at http://matplotlib.sourceforge.net/users/customizing.html. But it
does not have to be preserved, like I said, it gets overwritten when you run
setup.py build, with new settings depending on what setup.py determines are
the most appropriate and what settings you insist on having by editing
setup.cfg.

On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote:
>>
>> First of all let me apologize for the problems we have been
>> seeing with the binaries as of late. Frankly the root of the problem
>> might be my detachment from the matplotlib source for some time.
>> Unfortunately due to my time constraints, this won't be changing soon.
>> I used to think being somewhat on the outside helped me keep the ease
>> of the build process in check. This gap has apparently grown too
>> wide.
>
> I appreciate that this is a difficult task and that you have plenty of other
> responsibilities, and appreciate your effort. However, I've been trying to
> get to the bottom of why the windows installer is overwriting configobj and
> I could use some feedback from you. I really need to know whether you delete
> the build/ directory before creating a new installer.
I don't have my build directories anymore, but they were made from
extracting the source release so there was no previous build
directory. It is possible that I missed those settings in setup.cfg,
because I do not have either of those module installed.
>
>>
>> Moving ahead, python 2.6 and 3.0 are going to pose new challenges
>> since they require new versions of visual studio I do not have access
>> to.
>
> I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free
> Visual C++ 2008 express can be used to create extension modules. I the past
> I have built and distributed extension modules built with mingw32 on windows
> XP, but I have not been able to put together a working mingw32/msys on a
> 64-bit windows vista machine. This is my only windows computer, so it looks
> like I will only be supporting py2.6 in the near future.
>
Good to know there is a free option.
>>
>> Doing builds for 4 windows versions poses a great time to work on
>> a standard cygwin build setup (not that the cygwin build process
>> doesn't work as is). In addition to that we are going to possibly be
>> seeing osx fat binaries with 4 architectures! I am more than happy to
>> continue to contribute my time to create these builds, but I think it
>> only makes sense to have a release candidate cycle before formally
>> pushing to sourceforge.
>
> What are the four architectures? I'd be willing to get things together on my
> windows install so I can build mpl from source and help test with
> python-2.6. (I know I'm going to regret this.)
>
"32-bit PowerPC, 32-bit x86, 64-bit PowerPC, and 64-bit x86"
http://en.wikipedia.org/wiki/Fat_binary

On Sun, Dec 14, 2008 at 1:28 PM, Michael Abshoff <mab...@go...>wrote:
> On Sun, Dec 14, 2008 at 10:22 AM, Darren Dale <dsd...@gm...> wrote:
> > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote:
>
> Hi,
>
> >> First of all let me apologize for the problems we have been
> >> seeing with the binaries as of late. Frankly the root of the problem
> >> might be my detachment from the matplotlib source for some time.
> >> Unfortunately due to my time constraints, this won't be changing soon.
> >> I used to think being somewhat on the outside helped me keep the ease
> >> of the build process in check. This gap has apparently grown too
> >> wide.
> >
> > I appreciate that this is a difficult task and that you have plenty of
> other
> > responsibilities, and appreciate your effort. However, I've been trying
> to
> > get to the bottom of why the windows installer is overwriting configobj
> and
> > I could use some feedback from you. I really need to know whether you
> delete
> > the build/ directory before creating a new installer.
> >
> >>
> >> Moving ahead, python 2.6 and 3.0 are going to pose new challenges
> >> since they require new versions of visual studio I do not have access
> >> to.
> >
> > I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the
> free
> > Visual C++ 2008 express can be used to create extension modules.
>
> The express edition can only produce 32 bit binaries, but I guess this
> is better than nothing.
>
According to wikipedia (
http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express) :
"natively compiling 64-bit
<http://en.wikipedia.org/wiki/64-bit>applications through the IDE is
not supported. If the freely available Windows
SDK <http://en.wikipedia.org/wiki/Windows_SDK> is installed, 64-bit
applications can be built on the command line using the x64 cross-compiler
(Cl.exe) supplied with the SDK." The documentation at python.org does not
indicate whether or not it is possible to cross-compile with the express
edition if the Windows SDK is installed (
http://docs.python.org/distutils/builtdist.html#cross-compiling-on-windows)
>
> > I the past
> > I have built and distributed extension modules built with mingw32 on
> windows
> > XP, but I have not been able to put together a working mingw32/msys on a
> > 64-bit windows vista machine. This is my only windows computer, so it
> looks
> > like I will only be supporting py2.6 in the near future.
>
> Since numpy 1.3 (probably out January 2009) will start supporting
> python 2.6 and official Python 3k support for numpy is currently
> anticipated not for a while I would guess Python 3k support is a
> non-issue for now. OTOH the many Python libraries depending on numpy
> might make Python 3K support happen sooner.
>
Last I heard, the numpy folks think py-3 support is at least a year out.

Hello,
On Sun, Dec 14, 2008 at 17:07, Darren Dale <dsd...@gm...> wrote:
> On Sun, Dec 14, 2008 at 8:12 AM, Sandro Tosi <mo...@de...> wrote:
>>
>> Hello,
>> while preparing the debian package update for 0.98.5 I went thru a
>> problem: we remove doc/mpl_data/matplotlibrc because it will be
>> modified (to change backend (that now is set to MacOSX in the tarball
>> distributed..?)) and up to now it wasn't used.
>>
>> Now, doc/make.py fails because of
>>
>> shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
>>
>> So, can we use another 'matplotlibrc' file or the one in doc/mpl_data
>> has something specific to doc and needs to maintained?
>
> The default matplotlibrc file in mpl-data/ is created by setup.py during the
> build process. The default backend is selected according to which gui
> toolkits are available, and defaults to Agg if no supported toolkit is
> available. setup.py only selects the macosx backend if the build is being
> performed on a macosx system. The source tarball is apparently prepared on a
> Mac, but I dont think it matters that the source dist contains this
> platform-specific backend, since the file will be overwritten with more
> appropriate settings anyway when you run setup.py build.
>
> It would really be best to not remove the file that is created as a result
> of running setup.py build. The mpl documentation suggests users to copy this
> file into their ~/.matplotlib/ or wherever if they want to modify the
> default properties, and it contains some documentation for each of the
> settings.
>
> On the other hand, if you are running setup.py build and the resulting
> matplotlibrc file still says the default backend is macosx, and you are not
> running macosx, and you have configured setup.cfg to set some other default
> backend, then it is a bug that needs to be fixed.
Well, what I'm actually asking is: can I use any matplotlibrc file (be
it from any location in the tarball or forged during build process) or
the one in doc/mpl_data has something specific to documentation that
needs to be preserved.
Don't worry, we ship matplotlibrc file (the one built), but I need to
know if that particular one has something ad-hoc for doc.
Thanks,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote:
> First of all let me apologize for the problems we have been
> seeing with the binaries as of late. Frankly the root of the problem
> might be my detachment from the matplotlib source for some time.
> Unfortunately due to my time constraints, this won't be changing soon.
> I used to think being somewhat on the outside helped me keep the ease
> of the build process in check. This gap has apparently grown too
> wide.
I appreciate that this is a difficult task and that you have plenty of other
responsibilities, and appreciate your effort. However, I've been trying to
get to the bottom of why the windows installer is overwriting configobj and
I could use some feedback from you. I really need to know whether you delete
the build/ directory before creating a new installer.
>
> Moving ahead, python 2.6 and 3.0 are going to pose new challenges
> since they require new versions of visual studio I do not have access
> to.
I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free
Visual C++ 2008 express can be used to create extension modules. I the past
I have built and distributed extension modules built with mingw32 on windows
XP, but I have not been able to put together a working mingw32/msys on a
64-bit windows vista machine. This is my only windows computer, so it looks
like I will only be supporting py2.6 in the near future.
> Doing builds for 4 windows versions poses a great time to work on
> a standard cygwin build setup (not that the cygwin build process
> doesn't work as is). In addition to that we are going to possibly be
> seeing osx fat binaries with 4 architectures! I am more than happy to
> continue to contribute my time to create these builds, but I think it
> only makes sense to have a release candidate cycle before formally
> pushing to sourceforge.
>
What are the four architectures? I'd be willing to get things together on my
windows install so I can build mpl from source and help test with
python-2.6. (I know I'm going to regret this.)
Darren

 First of all let me apologize for the problems we have been
seeing with the binaries as of late. Frankly the root of the problem
might be my detachment from the matplotlib source for some time.
Unfortunately due to my time constraints, this won't be changing soon.
 I used to think being somewhat on the outside helped me keep the ease
of the build process in check. This gap has apparently grown too
wide.
 Moving ahead, python 2.6 and 3.0 are going to pose new challenges
since they require new versions of visual studio I do not have access
to. Doing builds for 4 windows versions poses a great time to work on
a standard cygwin build setup (not that the cygwin build process
doesn't work as is). In addition to that we are going to possibly be
seeing osx fat binaries with 4 architectures! I am more than happy to
continue to contribute my time to create these builds, but I think it
only makes sense to have a release candidate cycle before formally
pushing to sourceforge.
- Charlie

On Sat, Dec 13, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
> I think the src egg approach for os x is hopeless because too many
> people are having problems with architecture on png and zlib
> dependencies, and we don't have a lot of control over this because
> they are getting these dependencies from a variety of providers. I
> think we need a binary installer, eg using bdist_mpkg, with the
> freetype, png and zlib dependencies built in, as we have on windows.
I worked on this yesterday on my flight back from the conference. I
added a dir to the mpl src tree called release/osx that has a Makefile
which has all the logic to fetch the bdist_mpkg (and patch it for
10.5), zlib, png, and freetype dependencies and build them using the
protocol Charlie wrote at
http://ipython.scipy.org/moin/MatplotlibOSXBuildNotes. It has a
custom setup.cfg which is incorporated by the Makefile. In this way,
we can get "1-click" or better yet "1-command" binary mpkg installers
and binary eggs for OS X. I'm including the README below.
We should be able to modify this approach to do the same for win32,
and thus doing releases will become both easier and less error prone.
One thing that was vexing me -- Charlie takes pains to avoid
dynamically linking png and freetype in his instructions, and yet when
I checked _png.so in the egg with ::
 otool -L _png.so
it was pointing to /usr/X11R6/lib/libpng.dylib. I think I figured
this out -- because I had PKG_CONFIG_PATH set in my local environment,
the setupext check_for_libpng was picking it up on my local machine
even though I had built a static libpng to link with for the binry
installer. By unsetting this environment var, I get the static
linkage we are shooting for. Is it possible that you have pkgconfig
on your box Charlie, which is why the dynamic linking was creeping in?
 We need to fix setupext to respect a setup.cfg flag to not use
pkgconfig in certain environments, eg when building installers.
I've uploaded snapshots to
 http://matplotlib.sourceforge.net/snapshots/matplotlib-0.98.5-py2.5-macosx10.5.zip
 and
 http://matplotlib.sourceforge.net/snapshots/matplotlib-0.98.5_r0-py2.5-macosx-10.3-fat.egg
So take a look.
Here is the README from release/osx::
Building binary releases of OS X
Included here is everything to build a binay package installer for OS
X
Dir Contents
-------------
* :file:`bdist_mkpg` - the distutils.extension to build Installer.app
 mpkg installers. It is patched from the tarball with
 file:`data/bdist.patch` because 0.4.3 is broken on OS X 10.5.
 Instructions on how to patch and install are below
* :file:`data` - some config files and patches needed for the build
* :file:`*.tar.gz` - the bdist_mkpg, zlib, png, freetype and mpl
 tarballs
* :file:`Makefile` - all the build commands
How to build
--------------
* You need to make sure to unset PKG_CONFIG_PATH to make sure the
 static linking below is respected. Otherwise the mpl build script
 will dynamically link using the libs from pkgconfig if you have this
 configured on your box::
 unset PKG_CONFIG_PATH
* OPTIONAL: edit :file:`Makefile` so that the *VERSION variables point
 to the latest zlib, png, freetype
* First fetch all the dependencies and patch bdist_mpkg for OSX 10.5.
 You can do this automatically in one step with::
 make fetch_deps
* install the patched bdist_mpkg, that the fetch_deps step just created::
 cd bdist_mpkg-0.4.3
 sudo python setup.py install
* build the dependencies::
 make dependencies
* copy over the latest mpl *.tar.gz tarball to this directory, update
 the MPLVERSION in the Makefile::
 cp /path/to/mpl/matplotlib.0.98.5.tar.gz .
* build the mkpg binary and egg
 make installers
 The mpkg and egg binaries will reside in :file:`matplotlib-VERSION/dist`

 This build should be the same as all the previous. I do them as
I documented on the ipython pages. bdist_mpkg has been flat broke the
times I have tried it. bdist_egg seems pretty helpless too due to
setuptools lack of understanding of osx architectures. Most people
get a successful install, but then setuptools tries to go out and grab
the source anyways. I can't say that I know a good solution for osx.
- Charlie
On Sat, Dec 13, 2008 at 4:31 PM, John Hunter <jd...@gm...> wrote:
> On Sat, Dec 13, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
>> Because several people are reporting problems with the OS X egg, I
>> grabbed matplotlib-0.98.5-py2.5-macosx-10.3.egg from sourceforge and
>> unzipped it to see what was in there. It seems to contain no of the
>> extension code and no object files. What exactly is this thing? I am
>> no egg expert, but I don't see how this thing *could* work ...
>
> Hmm, it appears that I missed all the *.so files -- must work on my
> grep skills. Sorry for the noise
>
> JDH
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sun, Dec 14, 2008 at 8:12 AM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> while preparing the debian package update for 0.98.5 I went thru a
> problem: we remove doc/mpl_data/matplotlibrc because it will be
> modified (to change backend (that now is set to MacOSX in the tarball
> distributed..?)) and up to now it wasn't used.
>
> Now, doc/make.py fails because of
>
> shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
>
> So, can we use another 'matplotlibrc' file or the one in doc/mpl_data
> has something specific to doc and needs to maintained?
>
The default matplotlibrc file in mpl-data/ is created by setup.py during the
build process. The default backend is selected according to which gui
toolkits are available, and defaults to Agg if no supported toolkit is
available. setup.py only selects the macosx backend if the build is being
performed on a macosx system. The source tarball is apparently prepared on a
Mac, but I dont think it matters that the source dist contains this
platform-specific backend, since the file will be overwritten with more
appropriate settings anyway when you run setup.py build.
It would really be best to not remove the file that is created as a result
of running setup.py build. The mpl documentation suggests users to copy this
file into their ~/.matplotlib/ or wherever if they want to modify the
default properties, and it contains some documentation for each of the
settings.
On the other hand, if you are running setup.py build and the resulting
matplotlibrc file still says the default backend is macosx, and you are not
running macosx, and you have configured setup.cfg to set some other default
backend, then it is a bug that needs to be fixed.
Darren

I have experience the same problem with easy_install but it is working with
aptitude, so do :
sudo aptitude install python-matplotlib
-Fran6
Charlie Moad wrote:
> I
> I'm not seeing this on OSX. Is anyone else experiencing this issue?
> 
> - Charlie
> 
> On Fri, Dec 12, 2008 at 2:39 PM, Neal Becker <ndb...@gm...> wrote:
>> sudo easy_install -U matplotlib
>> Searching for matplotlib
>> Reading http://pypi.python.org/simple/matplotlib/
>> Reading http://matplotlib.sourceforge.net
>> Reading
>> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
>> Reading
>> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
>> Reading http://sourceforge.net/project/showfiles.php?group_id=80706
>> Best match: matplotlib 0.98.5
>> Downloading
>> http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtime=1229034572&big_mirror=0
>> Processing matplotlib-0.98.5.tar.gz
>> Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir
>> /tmp/easy_install-CC1jw7/matplotlib-0.98.5/egg-dist-tmp-NSNvcC
>> ============================================================================
>> BUILDING MATPLOTLIB
>> matplotlib: 0.98.5
>> python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) [GCC
>> 4.3.2 20080917 (Red Hat 4.3.2-4)]
>> platform: linux2
>>
>> REQUIRED DEPENDENCIES
>> numpy: 1.2.0
>> freetype2: 9.18.3
>>
>> OPTIONAL BACKEND DEPENDENCIES
>> libpng: 1.2.33
>> Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5
>> * Guessing the library and include directories for
>> * Tcl and Tk because the tclConfig.sh and
>> * tkConfig.sh could not be found and/or parsed.
>> wxPython: 2.8.9.1
>> * WxAgg extension not required for wxPython >= 2.8
>> Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0,
>> pygobject: 2.15.4
>> Mac OS X native: no
>> Qt: Qt: 3.3.8, PyQt: 3.17.4
>> Qt4: Qt: 4.4.1, PyQt4: 4.4.3
>> Cairo: 1.4.12
>>
>> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>> datetime: present, version unknown
>> dateutil: 1.4
>> pytz: 2006p
>>
>> OPTIONAL USETEX DEPENDENCIES
>> dvipng: 1.11
>> ghostscript: 8.63
>> latex: 3.141592
>>
>> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
>> configobj: 4.5.2
>> enthought.traits: no
>>
>> [Edit setup.cfg to suppress the above messages]
>> ============================================================================
>> error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or
>> directory
>> Exception exceptions.OSError: (2, 'No such file or directory',
>> 'src/image.cpp') in <bound method CleanUpFile.__del__ of
>> <setupext.CleanUpFile instance at 0x7fc85b3c51b8>> ignored
>> Exception exceptions.OSError: (2, 'No such file or directory',
>> 'src/path.cpp') in <bound method CleanUpFile.__del__ of
>> <setupext.CleanUpFile instance at 0x7fc85b3c4638>> ignored
>> Exception exceptions.OSError: (2, 'No such file or directory',
>> 'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of
>> <setupext.CleanUpFile instance at 0x7fc85978c7a0>> ignored
>> Exception exceptions.OSError: (2, 'No such file or directory',
>> 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of
>> <setupext.CleanUpFile instance at 0x7fc85b3c4fc8>> ignored
>>
>>
>>
>> ------------------------------------------------------------------------------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>> Nevada.
>> The future of the web can't happen without you. Join us at MIX09 to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://www.nabble.com/error-installing-matplotlib-0.98.5-tp20982264p21001317.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hello,
while preparing the debian package update for 0.98.5 I went thru a
problem: we remove doc/mpl_data/matplotlibrc because it will be
modified (to change backend (that now is set to MacOSX in the tarball
distributed..?)) and up to now it wasn't used.
Now, doc/make.py fails because of
 shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
So, can we use another 'matplotlibrc' file or the one in doc/mpl_data
has something specific to doc and needs to maintained?
Thanks,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sat, Dec 13, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
> Because several people are reporting problems with the OS X egg, I
> grabbed matplotlib-0.98.5-py2.5-macosx-10.3.egg from sourceforge and
> unzipped it to see what was in there. It seems to contain no of the
> extension code and no object files. What exactly is this thing? I am
> no egg expert, but I don't see how this thing *could* work ...
Hmm, it appears that I missed all the *.so files -- must work on my
grep skills. Sorry for the noise
JDH