matplotlib-devel Mailing List for matplotlib (Page 3)

On Tue, Dec 16, 2008 at 15:39, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 16, 2008 at 8:10 AM, Michael Droettboom <md...@st...> wrote:
>
>> Another option would be to not generate the high-res png and pdf
>> examples. (Either or both). Just removing them after the fact won't
>> work, since one would end up with broken links from the docs. We would
>> also have to change the html to not include those links. It should be
>> fairly simple to provide an option to the doc build system to do this,
>> and I'm happy to implement that if we all agree that's the direction to
>> take.
>
> This is fine with me. Just add an rc option
>
> doc.minimal_footprint
>
> or something like that which drops the high res and pdf. This will
> prbably reduce the size 50-60%
yes yes please :) It would be really great to have it
full pylab_examples: 53M
pylab_examples no hires: 26M
pylab_examples no hires and no pdf: 12M
completely another story! ;)
> I have also removed the mpl_data symlink in my doc tree, and am still
> testing before I commit, because that is causing our binaries to get
> much larger on platforms which do not properly support linking.
> Instead, we'll refer explicitly to ../lib/matplotlib/mpl-data in the
> docs. I am leaving the mpl_examples symlink because of all the
> relative path woes in pyplot.
Another patch I can remove as soon as another release is done :)
> Other than simple optimizations like this, I am discinclined to try
> and build smaller manuals simply to reduce their size. The feature
Exactly the same goal I have in mind: I don't want to reduce the
information, but only those parts that adds "little" to the end users
while add a lot of space (if you get what I mean).
> that caused the explosion in size between 98.3 and 98.5 is the
> gallery, and image enhanced examples, which is arguably the most
> useful feature on the site.
And even as a local reference!! I had once to display dates and I was
sure I've seen an example that did it, but I didn't remember which
one, so I run all of them to find it. Now I would have to look up a
nice page full of images: much better!
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Jeff,
Is it possible to install the basemap data into a different directory?
I'm trying to set up a tool delivery layout for our users that allows me to rapidly update packages that tend to change. We have a core set of software that our code is built on and it's a lot of work for us to update that and test it on every platform. What I'm doing is separating out the packages of that core set that we generally need to update at a higher rate (currently that's matplotlib and sphinx) because they're under more active development.
The largest piece (by an order of magnitude) of these active tools is the basemap data. What I'd really like to do is install the basemap data with the core set of tools and then tell basemap where it's located instead of having to redeliver this large chunk of unchanging data every time we do a bug fix update to MPL. Perhaps by setting an environment variable that takes precedence over the default location?
Any thoughts? I could put a patch together for it if you think it's worthwhile.
Thanks,
Ted

On Tue, Dec 16, 2008 at 1:04 PM, Christopher Barker
<Chr...@no...> wrote:
> for instance, I renamed:
> matplotlib-0.98.3-py2.5-macosx-10.3.egg
>
> to:
> matplotlib-0.98.3-py2.5.egg
>
> and easy_install installed it without a hitch on 10.4
>
> Indeed, that name may work for 10.5 too.
I've posted new eggs and a binary mpkg installer for OS X and a new
tarball. I've tried your egg renaming trick. Let me know how it
goes.
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644
You have two choices for OS X :
 * matplotlib-0.98.5.1-py2.5-macosx10.5.zip - a binary mpkg installer
 * matplotlib-0.98.5.1-py2.5-macosx.egg - an egg with the known
problems fixed.
Please give it another whirl and let me know.
JDH
>
> -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
>
> Chr...@no...
>
> ------------------------------------------------------------------------------
> 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 Tue, Dec 16, 2008 at 19:09, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 16, 2008 at 12:03 PM, Sandro Tosi <mat...@gm...> wrote:
>> Hello,
>> I see API_CHANGES is removed from tarball. it's a nice-to-have file,
>> in order to allow a smooth transition from old to new version.
>>
>> Is it intentional? Is there another source from this information? is
>> it not useful anymore?
>
> doc/api/api_changes.rst
So now it's even nicely formatted, great!
Thanks,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Charlie Moad wrote:
> 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.
This may be moot due to what John H. has done, but I thought all you 
need to do to stop setuptools from going and grabbing the source is to 
re-name the egg -- couldn't we just put the same egg up on the website 
with different names for different OS versions?
for instance, I renamed:
matplotlib-0.98.3-py2.5-macosx-10.3.egg
to:
matplotlib-0.98.3-py2.5.egg
and easy_install installed it without a hitch on 10.4
Indeed, that name may work for 10.5 too.
-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
Chr...@no...

On Tue, Dec 16, 2008 at 09:12:24AM -0800, Drain, Theodore R wrote:
> Continued from: requesting permission to remove traits and configobj...
> Gael,
> There might be ways to handle these problems. A lot of depends on what we're trying to test. I agree that if we take the example scripts, run them, and save the plots, we'll never get an automated test harness to figure things out because of machine differences.
Absolutely. I was just saying that we where giving up because, in our
case the cost was bigger than the benefit. However, we rely strongly on
hardware acceleration, so we don't control completely our rendering
pipeline, and images can vary by a huge amount (eg when the z-ordering is
screwed up). You can always design more robust test by proper analysis of
the images, but that could also be a PhD research program :).
I am not saying MPL shouldn't be going down that way, though.
Gaël

On Tue, Dec 16, 2008 at 12:03 PM, Sandro Tosi <mat...@gm...> wrote:
> Hello,
> I see API_CHANGES is removed from tarball. it's a nice-to-have file,
> in order to allow a smooth transition from old to new version.
>
> Is it intentional? Is there another source from this information? is
> it not useful anymore?
doc/api/api_changes.rst
JDH

Hello,
I see API_CHANGES is removed from tarball. it's a nice-to-have file,
in order to allow a smooth transition from old to new version.
Is it intentional? Is there another source from this information? is
it not useful anymore?
Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Tue, Dec 16, 2008 at 11:12 AM, Drain, Theodore R
<the...@jp...> wrote:
> - Embed a font with the tests to eliminate font server differences (no experience with this so I'm not sure how hard this would be). We could even create a dummy font that just has black squares for each character - it still tests that everything is drawn in the correct place and runs properly and eliminates subtle character differences.
Since we ship our own fonts, it is pretty easy to test against a known
set. Just set up the rc to use Vera, and cm* or stix* for math.
> - Create a testing backend that records the drawing commands as a set of meta-data like (draw red line from point 1 to point 2). The test case then checks that the proper commands were issued by the test script. This eliminates drawing completely. A nice comparison suite would allow loose comparisons like "make sure a vertical line was drawn from (10,20) to (30,40) with a pixel slop of 2 pixels.
I think this idea has promise.
I'll also add that we can do *a lot* more with simple API tests that
do not look at the output but at least make sure the inputs, in all
their variety, are at least accepted. backend_driver does this to an
extent, but I will be adding nose tests for any new features I add.
Eg, for the recent markevery, which can be None, an integer or a
length 2 tuple, I added this simple test to unit/nose_tests
def test_markevery():
 x, y = np.random.rand(2, 100)
 # check marker only plot
 fig = plt.figure()
 ax = fig.add_subplot(111)
 ax.plot(x, y, 'o', label='default')
 ax.plot(x, y, 'd', markevery=None, label='mark all')
 ax.plot(x, y, 's', markevery=10, label='mark every 10')
 ax.plot(x, y, '+', markevery=(5, 20), label='mark every 5 starting at 10')
 ax.legend()
 fig.canvas.draw()
 plt.close(fig)
 # check line/marker combos
 fig = plt.figure()
 ax = fig.add_subplot(111)
 ax.plot(x, y, '-o', label='default')
 ax.plot(x, y, '-d', markevery=None, label='mark all')
 ax.plot(x, y, '-s', markevery=10, label='mark every 10')
 ax.plot(x, y, '-+', markevery=(5, 20), label='mark every 5 starting at 10')
 ax.legend()
 fig.canvas.draw()
 plt.close(fig)
Having well defined tests that heavily exercise the frontend API would
be a significant step forward, and the harder question of output
comparison could be added in.
JDH

Continued from: requesting permission to remove traits and configobj...
Gael,
There might be ways to handle these problems. A lot of depends on what we're trying to test. I agree that if we take the example scripts, run them, and save the plots, we'll never get an automated test harness to figure things out because of machine differences.
However, if we set the goal of the testing to be that we make sure that MPL runs, that it accepts the correct options, and produces a plot, then we can be more creative with the testing harness. We can do significant amounts of testing with a fixed back end (Agg probably) that generates an image for comparison. We've tried a number of things in our own testing work which could help. The first step is to identify why plots on different machines are different: numeric differences in input data, agg output, font differences, colors, etc, etc.
Some ideas that might (or might not) help:
- Use wide lines that are grey in color for everything. The plot looks crazy but then if you get one pixel shifts, it isn't a case of the pixels going "white, black, white" on one machine and "white, white, black" on another - you end up with most of the line overlapping which makes image comparisons easier.
- Never generate the input data on the machine you're on. For example, never do this:
 t = arange(0.0,3.01,0.01)
 s = sin(2*pi*t)
Because you can get differences between machines. A better way is to run this on the machine that will generate the "correct" image and then save the numbers using pickle or by embedding them in the script.
- Embed a font with the tests to eliminate font server differences (no experience with this so I'm not sure how hard this would be). We could even create a dummy font that just has black squares for each character - it still tests that everything is drawn in the correct place and runs properly and eliminates subtle character differences.
- Create a testing backend that records the drawing commands as a set of meta-data like (draw red line from point 1 to point 2). The test case then checks that the proper commands were issued by the test script. This eliminates drawing completely. A nice comparison suite would allow loose comparisons like "make sure a vertical line was drawn from (10,20) to (30,40) with a pixel slop of 2 pixels.
- Smarter image comparison algorithms. We currently use something that processes the image with PIL and looks at an averaged pixel difference (it's not perfect by any means). I'll try to talk to some of the people here who work in image processing to see if there are any fuzzy image comparison algorithms they can recommend.
Ted
> -----Original Message-----
> From: Gael Varoquaux [mailto:gae...@no...]
> Sent: Thursday, December 11, 2008 10:06 PM
> To: Andrew Straw
> Cc: Drain, Theodore R; mat...@li...
> Subject: Re: [matplotlib-devel] requesting permission to remove traits
> and configobj
>
> On Thu, Dec 11, 2008 at 01:37:01PM -0800, Andrew Straw wrote:
> > Prabhu Ramachandran has also done similar things for mayavi2 using
> VTK's
> > image comparison (see compare_image_with_saved_image in
> >
> https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtes
> ts/mayavi/common.py
> > ).
>
> Yeah, and it always fails due to the hardware rendering being slightly
> different on different computers :). I think we are giving up on this
> approach.
>
> Gaël
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.9.17/1844 - Release Date:
> 12/11/2008 8:58 PM

On Tue, Dec 16, 2008 at 8:42 AM, John Hunter <jd...@gm...> wrote:
>> Yep, 0.5 it is
>
> Let me correct that -- I will test Darren's patch and if we can make
> it work with an earlier sphinx I'm happy to try. Stay tuned. Darren,
> can I assume you have tested this with 0.4.2 and the docs are building
> for you with your patch. I will test on my tree.
OK, after hearing the correction from Darren, the answer is that the
docs depend on sphinx 0.5 or later
Thanks,
JDH

On Tue, Dec 16, 2008 at 4:20 AM, Sandro Tosi <mo...@de...> wrote:
> - shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
> + shutil.copy('../lib/matplotlib/mpl-data/matplotlibrc',
> '_static/matplotlibrc')
>
This has already been committed to the 98.5 branch.
JDH

On Tue, Dec 16, 2008 at 9:39 AM, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 16, 2008 at 8:10 AM, Michael Droettboom <md...@st...>
> wrote:
>
> > Another option would be to not generate the high-res png and pdf
> > examples. (Either or both). Just removing them after the fact won't
> > work, since one would end up with broken links from the docs. We would
> > also have to change the html to not include those links. It should be
> > fairly simple to provide an option to the doc build system to do this,
> > and I'm happy to implement that if we all agree that's the direction to
> > take.
>
> This is fine with me. Just add an rc option
>
> doc.minimal_footprint
>
> or something like that which drops the high res and pdf. This will
> prbably reduce the size 50-60%
>
> I have also removed the mpl_data symlink in my doc tree, and am still
> testing before I commit, because that is causing our binaries to get
> much larger on platforms which do not properly support linking.
> Instead, we'll refer explicitly to ../lib/matplotlib/mpl-data in the
> docs. I am leaving the mpl_examples symlink because of all the
> relative path woes in pyplot.
>
> Other than simple optimizations like this, I am discinclined to try
> and build smaller manuals simply to reduce their size. The feature
> that caused the explosion in size between 98.3 and 98.5 is the
> gallery, and image enhanced examples, which is arguably the most
> useful feature on the site.
>
It seems like the documentation should be a separately installable package
as far as package managers are concerned.

Index: doc/sphinxext/inheritance_diagram.py
===================================================================
--- doc/sphinxext/inheritance_diagram.py	(revision 6626)
+++ doc/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: doc/sphinxext/mathmpl.py
===================================================================
--- doc/sphinxext/mathmpl.py	(revision 6626)
+++ doc/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: doc/sphinxext/only_directives.py
===================================================================
--- doc/sphinxext/only_directives.py	(revision 6626)
+++ doc/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 10:02 AM, Darren Dale <dsd...@gm...> wrote:
> 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:
I am getting errors trying to apply this patch on the 0.98.5 branch.
Could you send a fresh diff against the HEAD of that branch, and
attach it rather than paste it.
Thanks,
JDH

On Tue, Dec 16, 2008 at 8:40 AM, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 16, 2008 at 6:12 AM, Sandro Tosi <mat...@gm...> wrote:
>
>> So, should the doc be build using sphinx 0.5? Would it be the standard
>> version of sphinx used by mpl now on? Just to know what dependency to
>> throw in once building mpl for Debian :)
>
> Yep, 0.5 it is
Let me correct that -- I will test Darren's patch and if we can make
it work with an earlier sphinx I'm happy to try. Stay tuned. Darren,
can I assume you have tested this with 0.4.2 and the docs are building
for you with your patch. I will test on my tree.
JDH

On Tue, Dec 16, 2008 at 6:12 AM, Sandro Tosi <mat...@gm...> wrote:
> So, should the doc be build using sphinx 0.5? Would it be the standard
> version of sphinx used by mpl now on? Just to know what dependency to
> throw in once building mpl for Debian :)
Yep, 0.5 it is.

On Tue, Dec 16, 2008 at 8:10 AM, Michael Droettboom <md...@st...> wrote:
> Another option would be to not generate the high-res png and pdf
> examples. (Either or both). Just removing them after the fact won't
> work, since one would end up with broken links from the docs. We would
> also have to change the html to not include those links. It should be
> fairly simple to provide an option to the doc build system to do this,
> and I'm happy to implement that if we all agree that's the direction to
> take.
This is fine with me. Just add an rc option
 doc.minimal_footprint
or something like that which drops the high res and pdf. This will
prbably reduce the size 50-60%
I have also removed the mpl_data symlink in my doc tree, and am still
testing before I commit, because that is causing our binaries to get
much larger on platforms which do not properly support linking.
Instead, we'll refer explicitly to ../lib/matplotlib/mpl-data in the
docs. I am leaving the mpl_examples symlink because of all the
relative path woes in pyplot.
Other than simple optimizations like this, I am discinclined to try
and build smaller manuals simply to reduce their size. The feature
that caused the explosion in size between 98.3 and 98.5 is the
gallery, and image enhanced examples, which is arguably the most
useful feature on the site.

One question to ask is whether we need both the .pdf and .html manuals, 
or whether that could be broken up into two packages. That seems like 
an easy one if that fits Debian policies (which I know nothing about) -- 
and wouldn't degrade the documentation experience at all.
Is there any way to transparently gzip compress the html files (as I 
believe Debian does with manpages)?
Another option would be to not generate the high-res png and pdf 
examples. (Either or both). Just removing them after the fact won't 
work, since one would end up with broken links from the docs. We would 
also have to change the html to not include those links. It should be 
fairly simple to provide an option to the doc build system to do this, 
and I'm happy to implement that if we all agree that's the direction to 
take.
Beyond that, we'd be looking at selectively including certain examples, 
which I worry would add additional maintenance burden if there's too 
much divergence between the "full" and "small" manuals. I think that 
road should be a last resort.
 
Mike
Sandro Tosi wrote:
> Hello,
> the problem is this:
>
> $ ls -l python-matplotlib-doc_0.98.5-1_all.deb
> -rw-r--r-- 1 morph morph 91141234 2008年12月16日 10:39
> python-matplotlib-doc_0.98.5-1_all.deb
>
> 90M of doc package is a "little bit"... and expanded it's
>
> $ du . -hs
> 119M
>
> In this package we install: doc/build/html/
> doc/build/latex/Matplotlib.pdf examples/*
>
> So I dig into a bit to identify the cause of such a big jump (0.98.3
> has a 16M doc package) and the biggest dir seems to be
> html/_static/plot_directive/mpl_examples/pylab_examples with >50M (a
> full result of "find examples/ html/ -type d -exec du -s {} \;" is
> attached; if you need I can add a full file list). In that particular
> dir (like in many other) i see a png, and hi-res png and a pdf file:
> are those all needed?
>
> At the end, is there a way we packagers can reduce this package size?
> (a fast stat showed it would be the second biggest -doc package in
> Debian.)
>
> Thanks,
> 
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello,
the problem is this:
$ ls -l python-matplotlib-doc_0.98.5-1_all.deb
-rw-r--r-- 1 morph morph 91141234 2008年12月16日 10:39
python-matplotlib-doc_0.98.5-1_all.deb
90M of doc package is a "little bit"... and expanded it's
$ du . -hs
119M
In this package we install: doc/build/html/
doc/build/latex/Matplotlib.pdf examples/*
So I dig into a bit to identify the cause of such a big jump (0.98.3
has a 16M doc package) and the biggest dir seems to be
html/_static/plot_directive/mpl_examples/pylab_examples with >50M (a
full result of "find examples/ html/ -type d -exec du -s {} \;" is
attached; if you need I can add a full file list). In that particular
dir (like in many other) i see a png, and hi-res png and a pdf file:
are those all needed?
At the end, is there a way we packagers can reduce this package size?
(a fast stat showed it would be the second biggest -doc package in
Debian.)
Thanks,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Mon, Dec 15, 2008 at 17:02, Darren Dale <dsd...@gm...> wrote:
> (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:
So, should the doc be build using sphinx 0.5? Would it be the standard
version of sphinx used by mpl now on? Just to know what dependency to
throw in once building mpl for Debian :)
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello John and Darren,
On Sun, Dec 14, 2008 at 22:05, John Hunter <jd...@gm...> wrote:
> 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.
Ah, now it's clear! I added a patch to just:
- shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
+ shutil.copy('../lib/matplotlib/mpl-data/matplotlibrc',
'_static/matplotlibrc')
And now the doc is built (but another problem, worth another thread, comes out).
Thanks & Cheers,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Thanks for the fix - works for me on this afternoon's SVN.
-Eric
On Mon, Dec 15, 2008 at 1:27 AM, Eric Firing <ef...@ha...> 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
>

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

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
Chr...@no...