[matplotlib-devel] Next release
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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Binary release process
On Sun, Dec 14, 2008 at 11:24 AM, Charlie Moad 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Next release
On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom 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. -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
On Sat, Dec 13, 2008 at 10:32 AM, John Hunter wrote:
> On Sat, Dec 13, 2008 at 9:22 AM, Darren Dale 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_o
Re: [matplotlib-devel] Next release
On Mon, Dec 15, 2008 at 7:15 AM, John Hunter wrote: > On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom wrote: 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. Cheers, Michael -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] os x egg fubar?
John Hunter 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. Maybe it's hopeless, but one solution is to try to standardize, in the MacPython community, on using William Kyngesburye's UnixImageIO and Freetype Frameworks for the dependencies: http://www.kyngchaos.com/wiki/doku.php?id=software:frameworks They are Universal, Binary, and packaged as nice frameworks and also with traditional unix-style layouts for building against. > 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. That's good route too, though it always feels a bit silly to have a different copy of libpng inside MPL, and PIL,and wxPython, and Why the heck Apple doesn't provide these really common libs is still beyond me! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering
Darren Dale wrote:
>
> I think it would be worth stating in the docs that # $ % & ~ _ ^ \ { }
> \( \) \[ \] have special meaning in latex but not in regular mpl text,
> so buyer beware. It might be nice if mpl regular text rendered the
> escaped version of all these characters the same way latex does, that
> would make it easier to go from text to usetex.
For now, I'll just resolve the one straightforward bug (that \$ does not
work in regular text with usetex off), and document these special
characters as you suggest -- just so the fix will be in the next
0.98.6. I'm going to hold off on these other issues of compatibility
until they have clearer answers.
>
> Speaking of implicitly doing the right thing, last night I was in the
> middle of working through a difficult bug when Windows Vista *kicked
> me out without asking or issuing a warning*, installed updates, and
> rebooted. I'm still mumbling under my breath about it. Friggin jerks.
I feel your pain. I've been there.
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Loss of filled vs. stroked distinction by Collections
Thanks for the fix - works for me on this afternoon's SVN. -Eric On Mon, Dec 15, 2008 at 1:27 AM, Eric Firing wrote: > 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 > -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
