matplotlib-devel Mailing List for matplotlib (Page 2)

Nice to hear about these plans -- and good luck with your surgery.
All that you suggest looks good. I'm personally a fan of svnmerge to do 
this sort of maintenance branch/development branch merging. You can see 
the matplotlib developer docs for instructions on how it's used with 
matplotlib, and you can just adapt the urls for what you're doing.
Mike
Ken McIvor wrote:
> Now that I've got a version of WxMpl that works properly I'd like to 
> transition it over to being a matplotlib toolkit. From poking around 
> in svn, it looks like the correct thing to do would be to import the 
> source directory into '$(SVNROOT)/trunk/toolkits/wxmpl'.
>
> Is that correct?
>
> I'd like to try to get started on version 2.0 before I have my first 
> carpal tunnel release surgery in later March. The goals would be:
>
> 1. Optional full support for MPL events
> 2. API for binding user interactions to selection and zoom behavior 
> (e.g. "I want right-click selections to zoom in and the 'u' key to 
> zoom out, like GNUPLOT")
> 3. API for controlling Axes zoom state
>
> What do you all think would be the best way to do this? Create a 
> branch in '$(SVNROOT)/branches' for 1.3 maintenance?
>
> Ken
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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

Thanks, Fernando. I've applied your patch to matplotlib (branch and trunk).
Mike
Fernando Perez wrote:
> On Mon, Feb 16, 2009 at 3:21 PM, Gael Varoquaux
> <gae...@no...> wrote:
>
> 
>> I am not blaming anyone, just pointing out a non ideal situation. It has
>> already improved a lot with the matplotlib guys and the scipy guys
>> merging some changes in extensions and publishing the extensions in an
>> importable part of their source tree.
>> 
>
> In keeping with the spirit of trying to get all of these extension
> changes upstream so that we can all eventually stop carrying our own
> copies, below is a tiny change I just made to the inheritance diagram
> one. This is needed to ensure that the figure is separated from any
> surrounding text, since otherwise you get hideous off-screen diagrams
> in the rendered PDF.
>
> This has been committed to the nipy trunk already.
>
> Similarly (for the pymvpa crowd), the api autogen code is now a
> module, and it also contains a few small fixes, in particular
> regarding chapter titles. Feel free to grab and update your copy:
>
> http://bazaar.launchpad.net/~nipy-developers/nipy/trunk/annotate/head%3A/tools/apigen.py
>
> I've been told the gods of numpy/sphinx don't like auto-generated
> docs, but I think there's a valid use case for these tools, so
> hopefully in the future it will be possible to include them upstream
> for us lesser mortals to use. If not, I guess we'll just continue to
> carry our copies around :)
>
> Cheers,
>
> f
>
> # diff, inline because it's so trivial:
>
> === modified file 'doc/sphinxext/inheritance_diagram.py'
> --- doc/sphinxext/inheritance_diagram.py	2009年01月30日 02:00:57 +0000
> +++ doc/sphinxext/inheritance_diagram.py	2009年02月20日 21:11:38 +0000
> @@ -370,7 +370,7 @@
>
> graph.run_dot(['-Tpdf', '-o%s' % pdf_path],
> name, parts, graph_options={'size': '"6.0,6.0"'})
> - return '\\includegraphics{%s}' % pdf_path
> + return '\n\\includegraphics{%s}\n\n' % pdf_path
>
> def visit_inheritance_diagram(inner_func):
> """
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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

Thanks for the note on this. It's nice to know who wrote the original 
version. I'll add a note about this in the code comments.
I'm not seeing a noticable change in this regard between 0.98.5 (which 
uses a pretty direct refactoring of your code) to the SVN trunk. The 
trunk does two things rather differently 1) it only ever returns points 
that exist in the original data, and 2) it clips line segments at the 
boundary of the plot. The latter is to get around a shortcoming of Agg 
(and Abode Reader, for that matter) when plotting lines to very 
high-valued coordinates.
But, I'd appreciate you having a comparison look yourself, in case 
you're seeing some detail that I'm missing.
Cheers,
Mike
Allan Haldane wrote:
> a writes:
> 
>> Michael Droettboom <mdroe@...> writes:
>> 
>>> Thanks for the pointers.
>>>
>>> The original simplification code was written by John Hunter (I believe),
>>> and I don't know if it was designed by him also or is a replication of
>>> something published elsewhere. So I take no credit for and have little
>>> knowledge of its original goals.
>>> 
>> I'm not sure on everything it does, but it seems to do clipping and removes
>> line segments where the change in slope is less than some limit. There are
>> probably better algorithms out there, but this one works surprisingly well
>> and is fast and simple. I think it should be a requirement that it returns
>> points which are a subset of the original points- with the change you've
>> made it does this, right?
>> 
>
> Oh Hey! I'm the one who originally wrote the path simplification code. I'd
> have thought it would be gone by now, but I am very happy it turned out to
> be useful. I made it up in order to plot a very large set of noisy data I
> had.
>
> The goal was to simplify two types of plots at once: Smooth curves, as
> well as very noisy data where many lines are 'on top' of each other. (eg
> plot(rand(100000)) ). I noticed both could be taken care of by checking
> for changes in slope.
>
> An important goal (for me) was making sure that the min/max span of the
> points plotted was preserved. (so that eg plot(rand(1000)) spans from the
> lowest to highest point in the data (ie ~ 0 to 1) for any zoom factor).
> I'm not sure if this property survived...: If you do plot(rand(1000)) with
> the latest matplotlib and gradually zoom out on the x axis, you can see
> the top/bottom tips of the plotted line flickering in height, which is
> what I was trying to avoid. I forget whether I actually got it as I wanted
> it though, maybe I gave up.
>
> Allan
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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

Now that I've got a version of WxMpl that works properly I'd like to 
transition it over to being a matplotlib toolkit. From poking around 
in svn, it looks like the correct thing to do would be to import the 
source directory into '$(SVNROOT)/trunk/toolkits/wxmpl'.
Is that correct?
I'd like to try to get started on version 2.0 before I have my first 
carpal tunnel release surgery in later March. The goals would be:
1. Optional full support for MPL events
2. API for binding user interactions to selection and zoom behavior 
(e.g. "I want right-click selections to zoom in and the 'u' key to 
zoom out, like GNUPLOT")
3. API for controlling Axes zoom state
What do you all think would be the best way to do this? Create a 
branch in '$(SVNROOT)/branches' for 1.3 maintenance?
Ken

James,
The scripts in examples/units (and run by backend_driver.py) are broken; 
they have not been updated to match your addition of the new mandatory 
axis argument to convert() and default_units(). Would you fix them, 
please? (While you are in the neighborhood, you might also update the 
methods by switching to the @staticmethod decorator.)
The argument was also missing from the units.py docstring, but I have 
fixed that.
Thank you.
Eric

On Mon, Feb 16, 2009 at 3:21 PM, Gael Varoquaux
<gae...@no...> wrote:
> I am not blaming anyone, just pointing out a non ideal situation. It has
> already improved a lot with the matplotlib guys and the scipy guys
> merging some changes in extensions and publishing the extensions in an
> importable part of their source tree.
In keeping with the spirit of trying to get all of these extension
changes upstream so that we can all eventually stop carrying our own
copies, below is a tiny change I just made to the inheritance diagram
one. This is needed to ensure that the figure is separated from any
surrounding text, since otherwise you get hideous off-screen diagrams
in the rendered PDF.
This has been committed to the nipy trunk already.
Similarly (for the pymvpa crowd), the api autogen code is now a
module, and it also contains a few small fixes, in particular
regarding chapter titles. Feel free to grab and update your copy:
http://bazaar.launchpad.net/~nipy-developers/nipy/trunk/annotate/head%3A/tools/apigen.py
I've been told the gods of numpy/sphinx don't like auto-generated
docs, but I think there's a valid use case for these tools, so
hopefully in the future it will be possible to include them upstream
for us lesser mortals to use. If not, I guess we'll just continue to
carry our copies around :)
Cheers,
f
# diff, inline because it's so trivial:
=== modified file 'doc/sphinxext/inheritance_diagram.py'
--- doc/sphinxext/inheritance_diagram.py	2009年01月30日 02:00:57 +0000
+++ doc/sphinxext/inheritance_diagram.py	2009年02月20日 21:11:38 +0000
@@ -370,7 +370,7 @@
 graph.run_dot(['-Tpdf', '-o%s' % pdf_path],
 name, parts, graph_options={'size': '"6.0,6.0"'})
- return '\\includegraphics{%s}' % pdf_path
+ return '\n\\includegraphics{%s}\n\n' % pdf_path
 def visit_inheritance_diagram(inner_func):
 """

I just updated to the latest svn, and unveiled a bug that's evident
when using mixed-mode rendering in the PDF backend. I'm suspect I'm
the only one running my patch that enables set_rasterized on a
per-artist basis, so I'm the only one that's seeing it. :) Artists
that are left in vector mode are plotted correctly, while artists that
are rasterized are squished down toward the lower left corner of the
axes.
Looking at the svn log, I suspect it's the changes to the path
simplification code (r6847) doing something funky at the transforms
level. Is that the right place to start looking? Any tips on how to
track this down?
Thanks,
Eric
Sample code to reproduce the problem:
import numpy
from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
basecolors = get_cmap('gist_yarg')
colormap, normer = basecolors, None #LogNorm()
x = y = c = numpy.arange(10) +1
dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
dummy.set_rasterized(True)
dummy.figure.savefig('raster_test.pdf')

On 2009年2月19日, Michael Droettboom wrote:
> The drawing and then clipping is normal behavior. All of the backend formats 
> have the ability to clip out arbitrary regions for drawing, so we take 
> advantage of that rather than doing our own geometric clipping algorithm. 
> The latter is a great deal of work to get right.
>
> It sounds like the Inkscape PDF export is not exporting the clipping path 
> correctly, which may actually be related to the version of Cairo Inkscape is 
> using. In any case, there's not much we can do here.
I see, thanks for explaining.
This is actually the Inkscape bug 
https://bugs.launchpad.net/inkscape/+bug/168800 with one of the comments 
suggesting to learn from Matplotlib how to export clipping to pdf with 
Cairo. It is supposedly fixed in Inkscape svn trunk.
/Olle

Olle Engdegård wrote:
>
> Sorry for not being clear enough.
>
> I see this only when exporting to svg, importing it to Inkscape and 
> then saving as pdf there. Never interactively. And never if exporting 
> directly to pdf from matplotlib.
>
> It could very well be a bug in Inkscape, but matplotlib is still 
> saving data that should not be there, this is what I wanted to point out.
>
> And I take it back that it doesn't show in Inkscape, it was just 
> hidden from view. The extra bars are there.
You were clear -- it was just early in the morning for me here and my 
eyes to brain converter wasn't working properly ;)
The drawing and then clipping is normal behavior. All of the backend 
formats have the ability to clip out arbitrary regions for drawing, so 
we take advantage of that rather than doing our own geometric clipping 
algorithm. The latter is a great deal of work to get right.
It sounds like the Inkscape PDF export is not exporting the clipping 
path correctly, which may actually be related to the version of Cairo 
Inkscape is using. In any case, there's not much we can do here.
Mike

Sorry for not being clear enough.
I see this only when exporting to svg, importing it to Inkscape and then 
saving as pdf there. Never interactively. And never if exporting directly 
to pdf from matplotlib.
It could very well be a bug in Inkscape, but matplotlib is still saving 
data that should not be there, this is what I wanted to point out.
And I take it back that it doesn't show in Inkscape, it was just hidden 
from view. The extra bars are there.
/Olle
On 2009年2月19日, Michael Droettboom wrote:
> I take this back -- I hadn't read your initial bug very carefully.
>
> If Inkscape is rendering the SVG correctly, but it's PDF output is not 
> correct, then that seems like an Inkscape bug or a PDF viewer bug -- there's 
> not too much we could do on the matplotlib end.
>
> When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see it in 
> the interactive window, or just this behavior when you save an SVG, load it 
> in Inkscape and then output a PDF? In the latter case, the SVG output from 
> all backends (except Cairo) follows the same code path so should be 
> identical.
>
> Does directly outputting PDF from matplotlib work for you ? -- (it works 
> here)
>
> Mike
>
>
> Michael Droettboom wrote:
>> I see it with 0.98.5.x, but not with SVN trunk. I'll look into this 
>> further and see what I can determine.
>> 
>> Mike
>> 
>> Olle Engdegård wrote:
>> 
>>> On 2009年2月18日, Joshua Lippai wrote:
>>> 
>>>> Interesting. I can't reproduce your result using either the MacOSX or
>>>> WXAgg backend. Which backend are you using, and does the problem
>>>> persist if you use a different one?
>>>> 
>>> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>>> 
>>> /Olle
>>>
>>> 
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, 
>>> CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the 
>>> Enterprise
>>> -Strategies to boost innovation and cut costs with open source 
>>> participation
>>> -Receive a 600ドル discount off the registration fee with the source code: 
>>> SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> 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
>
>

I take this back -- I hadn't read your initial bug very carefully.
If Inkscape is rendering the SVG correctly, but it's PDF output is not 
correct, then that seems like an Inkscape bug or a PDF viewer bug -- 
there's not too much we could do on the matplotlib end.
When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see 
it in the interactive window, or just this behavior when you save an 
SVG, load it in Inkscape and then output a PDF? In the latter case, the 
SVG output from all backends (except Cairo) follows the same code path 
so should be identical.
Does directly outputting PDF from matplotlib work for you ? -- (it works 
here)
Mike
Michael Droettboom wrote:
> I see it with 0.98.5.x, but not with SVN trunk. I'll look into this 
> further and see what I can determine.
>
> Mike
>
> Olle Engdegård wrote:
> 
>> On 2009年2月18日, Joshua Lippai wrote:
>> 
>> 
>>> Interesting. I can't reproduce your result using either the MacOSX or
>>> WXAgg backend. Which backend are you using, and does the problem
>>> persist if you use a different one?
>>> 
>>> 
>> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>>
>> /Olle
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a 600ドル discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> 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

On Wed, Feb 18, 2009 at 2:43 PM, James Evans <jre...@ea...> wrote:
> All,
>
> I have just submitted a first-cut at a unit-test harness. The unit-tests
> do require the use of the 'nose' python module.
> Everything has been placed in the 'test' directory off of the root trunk
> branch. There is a README file with lots of information on
> how to use it. This is in addition to a few test cases already bundled in
> (they make great examples)! The idea is that whenever
> somebody adds a new feature or makes a change they update/add the
> appropriate test case and re-run the harness to make sure nothing
> is broken.
>
> There is most definitely room for improvement with this, but it gives a
> starting point from which discussions and modifications can
> take place.
>
> Any questions or comments?
What is the naming convention for the test harness? I see
filenames_with_underscores, camelCase, CapWords, and it looks like all the
methods in MplTestCase are camelCase, whereas mpl uses only
names_with_underscores. Although it would probably be a lot of busy work to
convert at this point, I think it would be a good idea to follow the
existing mpl naming conventions.
Darren

I see it with 0.98.5.x, but not with SVN trunk. I'll look into this 
further and see what I can determine.
Mike
Olle Engdegård wrote:
> On 2009年2月18日, Joshua Lippai wrote:
> 
>> Interesting. I can't reproduce your result using either the MacOSX or
>> WXAgg backend. Which backend are you using, and does the problem
>> persist if you use a different one?
>> 
>
> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>
> /Olle
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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

On Wed, Feb 18, 2009 at 11:43 AM, James Evans <jre...@ea...> wrote:
> All,
>
> I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the 'nose' python module.
[...]
> Any questions or comments?
This is great, many thanks! I'd just suggest, if possible, adding a
top-level .test() function, so that the usual idiom for package
testing 'import foo;foo.test()' can be applied. I have a shell
function for that:
function pytest {
 # Run the test suite for a python package by name.
 # This assumes the package has a top-level .test() routine to run its
 # test suite.
 local pname=1ドル
 python -c "import $pname;${pname}.test()"
}
that I use for things like testing numpy or scipy easily:
uqbar[~]> pytest numpy
Running unit tests for numpy
[...]
----------------------------------------------------------------------
Ran 1931 tests in 4.999s
OK (KNOWNFAIL=1, SKIP=11)
Cheers,
f

On 2009年2月18日, Joshua Lippai wrote:
> Interesting. I can't reproduce your result using either the MacOSX or
> WXAgg backend. Which backend are you using, and does the problem
> persist if you use a different one?
Hmm, I see it in at least WXAgg, WX, GTKAgg ...
/Olle

python -i svn/matplotlib/test/run-mpl-test.py
...
======================================================================
FAIL: Test numpy shaped data.
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/home/nwagner/svn/matplotlib/test/test_plots/TestPlot.py", 
line 129, in test_shaped_data
 self.checkImage( fname )
 File 
"/home/nwagner/svn/matplotlib/test/mplTest/MplTestCase.py", 
line 57, in checkImage
 self.fail( msg + "\n" + errorMessage )
AssertionError:
 Error: Image files did not match.
 RMS Value: 3.26978179241
 Expected:
 /home/nwagner/svn/matplotlib/test/test_plots/baseline/TestPlot/shaped_data.png
 Actual:
 /home/nwagner/svn/matplotlib/test/test_plots/outputs/shaped_data.png
 Tolerance: 0.001
----------------------------------------------------------------------
Ran 16 tests in 6.476s
FAILED (failures=1)
 

All,
I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the 'nose' python module.
Everything has been placed in the 'test' directory off of the root trunk branch. There is a README file with lots of information on
how to use it. This is in addition to a few test cases already bundled in (they make great examples)! The idea is that whenever
somebody adds a new feature or makes a change they update/add the appropriate test case and re-run the harness to make sure nothing
is broken.
There is most definitely room for improvement with this, but it gives a starting point from which discussions and modifications can
take place.
Any questions or comments?
--James Evans

Interesting. I can't reproduce your result using either the MacOSX or
WXAgg backend. Which backend are you using, and does the problem
persist if you use a different one?
Josh
On Wed, Feb 18, 2009 at 11:12 AM, Olle Engdegård <ol...@fy...> wrote:
>
> Doing
>
> from pylab import *
> x=normal(10, size=1000)
> hist(x)
> xlim(0,10)
> savefig("Image.svg")
>
> and then importing the file to Inkscape and saving it there as a pdf gives
> the attached result. The stuff right of x=10 is suddenly there. The weirdest
> thing is that Inkscape _does not see this overspill_!
>
> Not sure what is happening here, cannot reproduce it with plot() instead of
> hist().
>
> Cheers,
> Olle
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Doing
from pylab import *
x=normal(10, size=1000)
hist(x)
xlim(0,10)
savefig("Image.svg")
and then importing the file to Inkscape and saving it there as a pdf gives 
the attached result. The stuff right of x=10 is suddenly there. The 
weirdest thing is that Inkscape _does not see this overspill_!
Not sure what is happening here, cannot reproduce it with plot() instead 
of hist().
Cheers,
Olle

That's a great suggestion. I'm not familiar at all with the doc test 
extension, so the plot directive doesn't do this. It gets a fresh 
namespace (though not a fresh interpreter) for each plot.
To avoid complicating the merge further, I'd like to wait for Pauli 
Vertanen's merge of the new plot directive features from Numpy back into 
matplotlib before looking at implementing this. It will probably just 
involve inheriting/emulating whatever the doctest extension is doing to 
make that work. And if the directive is used in the old way (providing 
a filename), we'll just clear any state at that point.
Mike
Matthew Brett wrote:
> Hi guys,
>
> 
>> You can now do:
>>
>> .. plot::
>>
>> from matplotlib.pyplot import *
>> plot([1,2,3])
>> 
>
> This is very nice - thank you for doing that.
>
> But, thinking about the online tutorials, you often want to do
> something as you can do with the sourcecode directive, as in:
>
> .. testcode::
>
> import numpy as np
> print np.inf
>
> Some text then
>
> .. testoutput::
>
> inf
>
> More text
>
> .. testcode::
>
> # I still have the context from the blocks above
> print np.nan
>
> More text
>
> .. testoutput::
>
> nan
>
>
> In that way, I can build up a tutorial, setting and calculating
> variables, doing plots as I go, without having to recreate the
> calculations at each step.
>
> Is it possible to make the ..plot directive pick up the context in the same way?
>
> Thanks a lot,
>
> Matthew
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom schrieb:
> Gael,
> 
> You raise a very good point about the duplication of code around. As a 
> case in point, the patches you provided no longer apply to the 
> "canonical" (or at least original) versions of the plugins that began 
> life in matplotlib. Recent versions of Sphinx have a proper extension 
> API, so that "try ... except" importing is no longer necessary.
> 
> For mathmpl.py --- I will move that into the matplotlib installed code 
> tree, so, as you suggest, "from matplotlib.sphinxext import mathmpl" 
> will work. Obviously, that won't really provide traction until the next 
> release of matplotlib. And it relies on only_directive.py, so I will 
> probably have to put that in matplotlib as well for now, though that is 
> a reasonable candidate for inclusion in Sphinx.
The "only" is so trivial that it will, in this or a more extended form,
certainly be part of 0.6, which will not come out later than Feb 31 ;)
> I have submitted inheritance_diagram.py to Sphinx already. There didn't 
> seem to be much interest, and there were some details (particularly how 
> it deals with files), that weren't "the Sphinx way", and there few 
> documents and/or examples etc. at the time about how to do it right. 
> Someone else ended up re-engineering it to use pygraphviz which felt 
> pretty heavy weight to me. So the thing kind of stalled. But it's 
> probably worth another push.
The mails are still in my "look at it again" folder. I kind of agree
that using pygraphviz is counterproductive, since many systems have
graphviz but no so many, I suspect, pygraphviz.
Is the current version of the inheritance_diagram.py the one in matplotlib?
cheers,
Georg

Gael Varoquaux schrieb:
> Hi all,
> 
> Sorry for the multiple posting, this concerns various groups, and I'd
> rather the information not be lost.
> 
> While working on getting our in-lab library ready to be merged with NiPy,
> I ran into some sort of 'sphinx extension mess' where various sphinx
> extension would have side effects on each other, and most important, the
> extensions did not work with sphinx trunk.
Which is of course kind of my fault, because I keep changing the API :)
But it must also be said that during 0.x, I tend to view cleanliness and
good code as more important than 100% backwards compatibility.
> I got the side effects to be limited by cleaning up the generated code
> from autosummary before each run: I added the following code in my
> sphinx conf.py:
> 
> ################################################################################
> # Hack: run the autosummary generation script 
> import shutil
> if os.path.exists('generated'):
> shutil.rmtree('generated')
> os.system('%s sphinxext/autosummary_generate.py -o generated *.rst' %
> sys.executable)
> ################################################################################
> 
> I am attaching a diff of all the modifications I made to get the various
> extensions to work. I hope you can use it to get your various extensions
> working on sphinx trunk quicker. For the NiPy guys, I will be committing
> these changes in the fff2 tree soon, and we can go over this at the
> sprint.
> 
> This does raise a problem: this extension code is all over the place, in
> various repository. Some of the code cannot live in the sphinx repo, as
> it introduces dependencies. However, as the extensions are not importable
> from Python (I can't do 'from matplotlib.sphinxext import mathmpl'), the
> different projects using them end up copying them in their repo, and thus
> there are several versions floating around not updated. Some of the
> extensions would do not add externa dependencies to sphinx. These should
> be pushed into sphinx, with tests. That way as sphinx evolves, they do
> not break.
I'm all for it. In the case of autosummary, I'm guilty of not getting it
in sooner. This will change soon. In other cases, I don't even know of
the extension, probably because those who write it deem it as too
project-specific to contribute it.
I don't ask for too much if an extension is contributed, so by all means
do at least post about your extensions!
Georg

Hi guys,
> You can now do:
>
> .. plot::
>
> from matplotlib.pyplot import *
> plot([1,2,3])
This is very nice - thank you for doing that.
But, thinking about the online tutorials, you often want to do
something as you can do with the sourcecode directive, as in:
.. testcode::
 import numpy as np
 print np.inf
Some text then
.. testoutput::
 inf
More text
.. testcode::
 # I still have the context from the blocks above
 print np.nan
More text
.. testoutput::
 nan
In that way, I can build up a tutorial, setting and calculating
variables, doing plots as I go, without having to recreate the
calculations at each step.
Is it possible to make the ..plot directive pick up the context in the same way?
Thanks a lot,
Matthew

On Tue, Feb 17, 2009 at 12:17:17AM +0100, Georg Brandl wrote:
> I'm all for it. In the case of autosummary, I'm guilty of not getting it
> in sooner. This will change soon. In other cases, I don't even know of
> the extension, probably because those who write it deem it as too
> project-specific to contribute it.
> I don't ask for too much if an extension is contributed, so by all means
> do at least post about your extensions!
I am not blaming anyone, just pointing out a non ideal situation. It has
already improved a lot with the matplotlib guys and the scipy guys
merging some changes in extensions and publishing the extensions in an
importable part of their source tree.
It is true that I'll be happier when I will be able to import the
only_directive, and the auto_summary from sphinx :).
Thanks for your great work,
Gaël

2009年2月16日 13:36:07 -0600, Robert Kern wrote:
[clip]
> At one point, some of us had a plan to keep all of these "scientific"
> extensions collected here:
> 
> http://sphinx.googlecode.com/svn/contrib/trunk/numpyext/
> 
> SVN-using projects could use svn:externals to include these in their
> projects without diverging the code. I really don't know why this plan
> changed. Pauli?
I think my reasons for moving the extensions to Scipy SVN was mainly that
(i) it seemed clearer to keep the code where it was mainly used,
also for bug tracking and mailing list purposes,
(ii) Sphinx's google-code SVN seemed quite dead and obscure, and was 
difficult to find,
(iii) svn:externals would work also against Numpy's repository.
A better thing to do might have been to rally people to put also their 
extensions there and press for better advertisement. We can of course 
still do this and revive the idea; it would be good to get a slightly 
bigger starting mass, though.
-- 
Pauli Virtanen