done.
I just discovered l
# The name of an image file (within the static path) to place at the top of
# the sidebar.
#html_logo = 'logo.png'
so I have to get to work creating a new cool mpl figure for the logo.
Our old banner is so 70s.
JDH
On Fri, May 23, 2008 at 3:31 PM, Darren Dale <darren.dale@...143...> wrote:
commit yout customizing.txt?
I wasn't going to say it... but yeah. 
I think we need to set a policy on how we are going to handle code in
docstrings. There are lots of places where indentation and asterisks are
causing trouble. Should examples be codeblocks (: or doctests (>>>)? I
think inlines should just be `` quoted, like:
data are plotted as ``plot(lags, c, **kwargs)``
Here is an example from axes.Axes:
def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, maxlags=None, **kwargs):
"""
XCORR(x, y, normed=False, detrend=mlab.detrend_none, usevlines=False,
**kwargs):a
Can we eliminate the call signature? I think this is only necessary for
extension code, the call signature will already be displayed by sphinx and by
pythons interactive help.
Regarding the crazy pyplot error, I'm doing it the slow, painful way,
including a few members at a time in the members list and fixing the errors
that arise.
Darren
On Friday 23 May 2008 04:34:11 pm John Hunter wrote:
On Fri, May 23, 2008 at 3:31 PM, Darren Dale <darren.dale@...143...> wrote:
> commit yout customizing.txt?done.
I just discovered l
# The name of an image file (within the static path) to place at the
top of # the sidebar.
#html_logo = 'logo.png'so I have to get to work creating a new cool mpl figure for the logo.
Our old banner is so 70s.
so I have to get to work creating a new cool mpl figure for the logo.
Our old banner is so 70s.I wasn't going to say it... but yeah.
Thanks for your sensitivity I made that a long time ago when I was
really proud that I could set the font size on text!
I think we need to set a policy on how we are going to handle code in
docstrings. There are lots of places where indentation and asterisks are
causing trouble. Should examples be codeblocks (:
think inlines should just be `` quoted, like:data are plotted as ``plot(lags, c, **kwargs)``
Works for me -- we should prefer code blocks whether than inlines just
because they are more readable w/o the quotes, but if we need inlines
in some cases we'll use 'em
Here is an example from axes.Axes:
def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, maxlags=None, **kwargs):
"""
XCORR(x, y, normed=False, detrend=mlab.detrend_none, usevlines=False,
**kwargs):aCan we eliminate the call signature? I think this is only necessary for
extension code, the call signature will already be displayed by sphinx and by
pythons interactive help.
Unfortunately, I think we need it. pyplot xcorr is just a *args,
**kwargs pass though to Axes.xcorr, so if you do help pyplot.xcorr you
won't see the signature, which is why we manually copy the signature
in axes.py.
In [89]: help pyplot.xcorr
Help on function xcorr in module matplotlib.pyplot:
xcorr(*args, **kwargs)
XCORR(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):
Plot the cross correlation between x and y. If normed=True,
normalize the data but the cross correlation at 0-th lag. x
and y are detrended by the detrend callable (default no
normalization. x and y must be equal length
We could use a codeblock in axes.py
def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False,
maxlags=None, **kwargs):
"""
pyplot signature:
xcorr(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):
Plot the cross correlation between x and y. If normed=True,
normalize the data but the cross correlation at 0-th lag. x
and y are detrended by the detrend callable (default no
Regarding the crazy pyplot error, I'm doing it the slow, painful way,
including a few members at a time in the members list and fixing the errors
that arise.
Ugg, I don't envy you. Perhaps a message to the maintainer about the
need for some verbose context in these error messages would be more
expeditious. We have a lot of these to do.
Another feature I'd like to see is a macro location parameter. Eg
define location:`mplexamples` = ../../examples/pyplot
and then later be able to refer to that
.. literalinclude:: location:`mplexamples`/simple_plot.py
with whatever syntax is appropriate so as we reorganize we don't have
to keep fixing the relative path structure. Eg, I am including icons
from mpl/data/images in the navigation toolbar section....
JDH
On Fri, May 23, 2008 at 3:47 PM, Darren Dale <darren.dale@...143...> wrote:
>> so I have to get to work creating a new cool mpl figure for the logo.
>> Our old banner is so 70s.
>
> I wasn't going to say it... but yeah.Thanks for your sensitivity
haha! I hope you stick with your eeg, its just the colorscheme and fonts that
are outdated.
I made that a long time ago when I was
really proud that I could set the font size on text!> I think we need to set a policy on how we are going to handle code in
> docstrings. There are lots of places where indentation and asterisks are
> causing trouble. Should examples be codeblocks (:
> think inlines should just be `` quoted, like:
>
> data are plotted as ``plot(lags, c, **kwargs)``Works for me -- we should prefer code blocks whether than inlines just
because they are more readable w/o the quotes, but if we need inlines
in some cases we'll use 'em> Here is an example from axes.Axes:
>
> def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
> usevlines=False, maxlags=None, **kwargs):
> """
> XCORR(x, y, normed=False, detrend=mlab.detrend_none, usevlines=False,
> **kwargs):a
>
> Can we eliminate the call signature? I think this is only necessary for
> extension code, the call signature will already be displayed by sphinx
> and by pythons interactive help.Unfortunately, I think we need it. pyplot xcorr is just a *args,
**kwargs pass though to Axes.xcorr, so if you do help pyplot.xcorr you
won't see the signature, which is why we manually copy the signature
in axes.py.
Oh, right.
In [89]: help pyplot.xcorr
Help on function xcorr in module matplotlib.pyplot:xcorr(*args, **kwargs)
XCORR(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):Plot the cross correlation between x and y. If normed=True,
normalize the data but the cross correlation at 0-th lag. x
and y are detrended by the detrend callable (default no
normalization. x and y must be equal lengthWe could use a codeblock in axes.py
def xcorr(self, x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False,
maxlags=None, **kwargs):
"""
pyplot signature:xcorr(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):Plot the cross correlation between x and y. If normed=True,
normalize the data but the cross correlation at 0-th lag. x
and y are detrended by the detrend callable (default no
How about Use:, or Usage: or Signature:? Most of these exist outside of
pyplot.
On Friday 23 May 2008 04:57:24 pm John Hunter wrote:
On Fri, May 23, 2008 at 3:47 PM, Darren Dale <darren.dale@...143...> wrote:
xcorr(*args, **kwargs)
XCORR(x, y, normed=False, detrend=mlab.detrend_none,
usevlines=False, **kwargs):
Sorry I'm not helping yet, but while you are in the middle of all this, please ditch the ugly and misleading Matlab-style capitalization of the function names.
Thanks for all the work and amazing progress.
Eric
Some of these docstrings are *really* hard to trace. Where does pyplot.arrow
get its docstring? It looks like it comes from axes.arrow, which gets a bit
from patches.FancyArrow, which gets a bit from patches.Patch, which gets a
bit from artist.kwdocd['Patch'] at the top of patches.py. However, I have
completely rewritten artist.kwdocd['Patch']:
artist.kwdocd['Patch'] = """
================= ==============================================
Property Description
================= ==============================================
alpha float
animated [True | False]
antialiased or aa [True | False]
clip_box a matplotlib.transform.Bbox instance
clip_on [True | False]
edgecolor or ec any matplotlib color
facecolor or fc any matplotlib color
figure a matplotlib.figure.Figure instance
fill [True | False]
hatch unknown
label any string
linewidth or lw float
lod [True | False]
transform a matplotlib.transform transformation instance
visible [True | False]
zorder any number
================= ==============================================
"""
but the change has not propagated up to pyplot.arrow.
I have to break here for the weekend, I'll be back monday afternoon. Leave
some for me! (although I'll owe doughnut to whoever can fix the arrow
docstring).
Darren
On Friday 23 May 2008 6:06:30 pm Eric Firing wrote:
> xcorr(*args, **kwargs)
> XCORR(x, y, normed=False, detrend=mlab.detrend_none,
> usevlines=False, **kwargs):Sorry I'm not helping yet, but while you are in the middle of all this,
please ditch the ugly and misleading Matlab-style capitalization of the
function names.Thanks for all the work and amazing progress.
I'll claim that doughnut.
This is a bit complicated. The problem is that we have to do the
interpolation into the patch doc strings at class definition time (eg
for Patch and Rectangle), but we can't use the object inspector and
doc string generator artist.kwdoc to automatically generate them until
*after* they are defined. So we have a bit of a race condition. The
solution, which is not terribly elegant, is to define the string for
the *classes* manually with the setting at the top of
matplotlib.patches:
artist.kwdocd['Patch'] = """\
alpha: float
animated: [True | False]
antiali
We interpolate this into the class docstrings. Once the classes are
defined, we can introspect the class and auto generate the strings for
use in *methods* that operate on class instances. At the bottom of
patches:
artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
for k in ('Rectangle', 'Circle', 'RegularPolygon', 'Polygon',
'Wedge', 'Arrow',
'FancyArrow', 'YAArrow', 'CirclePolygon', 'Ellipse'):
artist.kwdocd[k] = patchdoc
so the changes you make in the kwdocd dict will affect the classes in
matplotlib.patches, bu will not affect the docstrings in the plotting
functions, eg matplotlib.axes.Axes.arrow, which will use the
auto-generated version from artist.kwdoc. So you need to make your
changes in two places: in the kwdocd dict at the top of patches, as
you did before, *and* in the artist.kwdoc function which
auto-generates the property tables. If this function returns rest
tables, you will be in good shape. It is not good design to have to
make the changes in two places, but when we implemented this we could
not find a way to do the class doc string interpolation after the
class was defined, but we still wanted to use the autogenerated docs
where possible (eg in methods that handle artists like the plotting
methods) since the auto-generated stuff is more likely to remain
current.
Maybe an entry in the developer's guide is warranted....
Enjoy your vacation.
JDH
On Fri, May 23, 2008 at 6:14 PM, Darren Dale <darren.dale@...143...> wrote
I have to break here for the weekend, I'll be back monday afternoon. Leave
some for me! (although I'll owe doughnut to whoever can fix the arrow
docstring).
I don't know if you were planning to accept submissions, but here's a logo with some of my favorite plots from examples.zip:
On May 23, 2008, at 4:34 PM, John Hunter wrote:
On Fri, May 23, 2008 at 3:31 PM, Darren Dale > <darren.dale@...143...> wrote:
commit yout customizing.txt?
done.
I just discovered l
# The name of an image file (within the static path) to place at the top of
# the sidebar.
#html_logo = 'logo.png'so I have to get to work creating a new cool mpl figure for the logo.
Our old banner is so 70s.
Submissions are extremely welcome, and I like the approach. I think
you might experiment with another font for the main text, and try to
incorporate some display of mathtext since this is a real selling
point. We also need one version that is no wider that 200 pages for
the sphinx navigation toolbar, so we will need to be judicious for
that one. But the one for the web page can be much larger, and I like
this as start. Is there anything we can do with the background to
make it a little more interesting? A very large equation that spans
most of the background but is so light in color (a gray with a low
alpha) that it very faint?
Also, the banner should be generated as a matplotlib figure rather
than put together in inkscape or something like that. How did you
make this -- if is code, please post so we can play along. If not,
see if you can write the logo example by laying out the axes just so.
JDH
On Sat, May 24, 2008 at 11:21 PM, Tony Yu <tsyu80@...149...> wrote:
I don't know if you were planning to accept submissions, but here's a logo
with some of my favorite plots from examples.zip:
I played around with this a bit this morning -- it may be too busy for
your OS X sensibilities, but let me know if you think think this is an
approach wotrh pursuing. I've added the mathtext background and a few
axes and there are a few more axes to do. In svn as
examples/api/logo2.py
JDH
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm
import matplotlib.mlab as mlab
axalpha = 0.05
figcolor = '#FFFFCC'
dpi = 80
fig = plt.figure(figsize=(8, 2),dpi=dpi)
fig.figurePatch.set_edgecolor(figcolor)
fig.figurePatch.set_facecolor(figcolor)
# the polar bar plot
ax = fig.add_axes([0.05, 0.05, 0.2, 01], polar=True)
ax.axesPatch.set_alpha(axalpha)
N = 20
theta = np.arange(0.0, 2*np.pi, 2*np.pi/N)
radii = 10*np.random.rand(N)
width = np.pi/4*np.random.rand(N)
bars = ax.bar(theta, radii, width=width, bottom=0.0)
for r,bar in zip(radii, bars):
bar.set_facecolor( cm.jet(r/10.))
bar.set_alpha(0.5)
for label in ax.get_xticklabels() + ax.get_yticklabels():
label.set_visible(False)
# the histogram
axhist = fig.add_axes([0.275, 0.075, 0.2, 0.4])
axhist.axesPatch.set_alpha(axalpha)
mu, sigma = 100, 15
x = mu + sigma*np.random.randn(10000)
# the histogram of the data
n, bins, patches = axhist.hist(x, 50, normed=1, facecolor='green',
edgecolor='green', alpha=0.75)
y = mlab.normpdf( bins, mu, sigma)
l = axhist.plot(bins, y, 'r', lw=1)
axhist.set_title('Density of IQ',fontsize=6)
axhist.set_xlabel('IQ', fontsize=6)
axhist.set_ylabel('P(IQ)', fontsize=6)
ax.set_xlim(-2*sigma, 2*sigma)
for label in axhist.get_xticklabels() + axhist.get_yticklabels():
label.set_visible(False)
axback = fig.add_axes([0., 0., 1., 1.])
#the math background
tex = r"W^\{3\\beta\}\_\{\\delta\_1 \\rho\_1 \\sigma\_2\} = U^\{3\\beta\}\_\{\\delta\_1
\\rho\_1\} \+ \\frac\{1\}\{8 \\pi 2\} \\int^\{\\alpha\_2\}\_\{\\alpha\_2\} d
\\alpha^\\prime\_2 \\left\[\\frac\{ U^\{2\\beta\}\_\{\\delta\_1 \\rho\_1\} \-
\\alpha^\\prime\_2U^\{1\\beta\}\_\{\\rho\_1 \\sigma\_2\} \}\{U^\{0\\beta\}\_\{\\rho\_1
\\sigma\_2\}\}\\right\]"
axback.text(0.5, 0.5, tex,
transform=axback.transAxes, color="0.5", alpha=0.5, fontsize=40,
ha='center', va='center')
axback.set_axis_off()
# the matplotlib title
axback.text(0.3, 0.95, 'matplotlib', color='black', fontsize=75,
ha='left', va='top', alpha=1.0,
transform=axback.transAxes)
fig.savefig('logo2.png', facecolor=figcolor, edgecolor=figcolor, dpi=dpi)
plt.show()
On Sun, May 25, 2008 at 8:18 AM, John Hunter <jdh2358@...149...> wrote:
Also, the banner should be generated as a matplotlib figure rather
than put together in inkscape or something like that. How did you
make this -- if is code, please post so we can play along. If not,
see if you can write the logo example by laying out the axes just so.
I must admit, I was a little worried when you suggested adding a big equation in the background, but I think you did a good job of making it look nice. Unfortunately, I get an error when I try to run the logo2 script:
AttributeError: ‘NoneType’ object has no attribute ‘get_ticklabels’
module body in logo2.py at line 23
for label in ax.get_xticklabels() + ax.get_yticklabels():
If I comment-out that for-block, I run into another error:
NotImplementedError: xlim not meaningful for polar axes
On May 25, 2008, at 12:13 PM, John Hunter wrote:
I played around with this a bit this morning – it may be too busy for
your OS X sensibilities, but let me know if you think think this is an
approach wotrh pursuing. I’ve added the mathtext background and a few
axes and there are a few more axes to do. In svn as
examples/api/logo2.py
module body in logo2.py at line 43*
ax.set_xlim(-2sigma, 2sigma)
I’m guessing the first error is a trunk vs. v0_91_maint issue? Is the second a naming error in the commit? Maybe axhist.set_xlim instead of ax.set_xlim?
Overall I really like the new logo, but I’d like play around with it a bit for kicks.
Thanks!
-Tony
I must admit, I was a little worried when you suggested adding a big
equation in the background, but I think you did a good job of making it look
nice. Unfortunately, I get an error when I try to run the logo2 script:
I'm not wed to it, so just experiment.
AttributeError: 'NoneType' object has no attribute 'get_ticklabels'
module body in logo2.py at line 23
for label in ax.get_xticklabels() + ax.get_yticklabels():
If I comment-out that for-block, I run into another error:
NotImplementedError: xlim not meaningful for polar axes
module body in logo2.py at line 43
ax.set_xlim(-2*sigma, 2*sigma)
I'm guessing the first error is a trunk vs. v0_91_maint issue? Is the second
You need to be on the trunk and I think I was a commit behind -- try it now.
We will probably want to set the various ticklabel and title sizes to
something really small using rc
import matplotlib
matplotlib.rcParams['xtick.labelsize'] = 6
so that we can tweak all these in one place at the top of the script.
JDH
On Sun, May 25, 2008 at 11:50 AM, Tony Yu <tsyu80@...149...> wrote:
My 2 cents:
I think it looks better if you reduce the number of histogram bins from 50 down to 15 or 20.
Gary R.
John Hunter wrote:
I played around with this a bit this morning -- it may be too busy for
your OS X sensibilities, but let me know if you think think this is an
approach wotrh pursuing. I've added the mathtext background and a few
axes and there are a few more axes to do. In svn as
examples/api/logo2.py
Unfortunately, I'm not running the trunk right now because I use numpy 1.0.4 (not 1.1).
I played around with the script, but in the process I ended up rewriting it a bunch. I'm sure I've violated come coding guidelines along the way; my apologies.
logo2.py (3.62 KB)
On May 25, 2008, at 1:01 PM, John Hunter wrote:
You need to be on the trunk and I think I was a commit behind -- try it now.
We will probably want to set the various ticklabel and title sizes to
something really small using rcimport matplotlib
matplotlib.rcParams['xtick.labelsize'] = 6
I'll be working on converting docstrings to rest this weekend. Should any of
this be done on the branch? Or should we just focus on the trunk?
As far as I am concerned, the documentation effort is for the trunk.
The only reason to do them on the branch too is to make merges of
other code changes easier, which may be a compelling reason. If the
docstrings get far out of whack, it may make merging other changes
very painful. But at the same time, I don't want the burden of
trying to keep the two in sync stopping you from getting the work done
that you need to do. Maybe you can try it and see how hard it is, and
if proves to be too much of an impediment, just concentrate on the
trunk. Michael, any advice here?
JDH
On Sat, May 31, 2008 at 9:19 AM, Darren Dale <darren.dale@...143...> wrote:
I'll be working on converting docstrings to rest this weekend. Should any of
this be done on the branch? Or should we just focus on the trunk?
I would really prefer to concentrate on the trunk. There's enough work as it
is.
Darren
On Saturday 31 May 2008 12:36:11 pm John Hunter wrote:
On Sat, May 31, 2008 at 9:19 AM, Darren Dale <darren.dale@...143...> wrote:
> I'll be working on converting docstrings to rest this weekend. Should any
> of this be done on the branch? Or should we just focus on the trunk?As far as I am concerned, the documentation effort is for the trunk.
> I have to break here for the weekend, I'll be back monday afternoon.
> Leave some for me! (although I'll owe doughnut to whoever can fix the
> arrow docstring).I'll claim that doughnut.
When was the last time you received one in the mail?
(more at the end...)
This is a bit complicated. The problem is that we have to do the
interpolation into the patch doc strings at class definition time (eg
for Patch and Rectangle), but we can't use the object inspector and
doc string generator artist.kwdoc to automatically generate them until
*after* they are defined. So we have a bit of a race condition. The
solution, which is not terribly elegant, is to define the string for
the *classes* manually with the setting at the top of
matplotlib.patches:artist.kwdocd['Patch'] = """\
alpha: float
animated: [True | False]
antialiWe interpolate this into the class docstrings. Once the classes are
defined, we can introspect the class and auto generate the strings for
use in *methods* that operate on class instances. At the bottom of
patches:artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
for k in ('Rectangle', 'Circle', 'RegularPolygon', 'Polygon',
'Wedge', 'Arrow',
'FancyArrow', 'YAArrow', 'CirclePolygon', 'Ellipse'):
artist.kwdocd[k] = patchdocso the changes you make in the kwdocd dict will affect the classes in
matplotlib.patches, bu will not affect the docstrings in the plotting
functions, eg matplotlib.axes.Axes.arrow, which will use the
auto-generated version from artist.kwdoc. So you need to make your
changes in two places: in the kwdocd dict at the top of patches, as
you did before, *and* in the artist.kwdoc function which
auto-generates the property tables. If this function returns rest
tables, you will be in good shape. It is not good design to have to
make the changes in two places, but when we implemented this we could
not find a way to do the class doc string interpolation after the
class was defined, but we still wanted to use the autogenerated docs
where possible (eg in methods that handle artists like the plotting
methods) since the auto-generated stuff is more likely to remain
current.Maybe an entry in the developer's guide is warranted....
Thanks for the detailed explanation. I'm tagging the message so I can remember
to include it in the developers guide. Now that I understand it, it wasn't
too difficult to reformat the output into a ReST table. Onwards!
Darren
On Friday 23 May 2008 7:54:27 pm John Hunter wrote:
On Fri, May 23, 2008 at 6:14 PM, Darren Dale <darren.dale@...143...> > wrote
I made some pretty good progress today. I found the source of that error that
was causing sphinx to fail without a helpfull message, there was a *********
in the contour documentation. pyplot_api is about halfway converted, there
are only 60 warnings reported by sphinx for pyplot.
I just realized, though, that I should probably be striving to conform with
the standard that the numpy and scipy folks put together:
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines and
http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py . Any comments? I
think I have been relying too heavily on tables for the keyword arguments.
Darren
On Saturday 31 May 2008 4:14:39 pm Darren Dale wrote:
On Saturday 31 May 2008 12:36:11 pm John Hunter wrote:
> On Sat, May 31, 2008 at 9:19 AM, Darren Dale <darren.dale@...143...> > > wrote:
> > I'll be working on converting docstrings to rest this weekend. Should
> > any of this be done on the branch? Or should we just focus on the
> > trunk?
>
> As far as I am concerned, the documentation effort is for the trunk.I would really prefer to concentrate on the trunk. There's enough work as
it is.
Hey folks,
I'm super excited about this, so I decided to give it a quick test run
with current trunk SVN. Running ./make.py in the doc/ directory
worked for a while, and then stalled at:
Sphinx v0.3, building latex
trying to load pickled env... done
building [latex]: all documents
updating environment: 0 added, 0 changed, 0 removed
processing Matplotlib.tex... index users/index users/pyplot_tutorial
users/mathtext users/navigation_toolbar users/customizing
users/artists users/event_handling faq/index faq/installing_faq
faq/troubleshooting_faq faq/howto_faq devel/index devel/coding_guide
devel/documenting_mpl devel/add_new_projection api/index
api/artist_api api/pyplot_api
resolving references...
writing... Exception occurred:
File "/home/fperez/usr/local/lib/python2.5/site-packages/Sphinx-0.3-py2.5.egg/sphinx/latexwriter.py",
line 479, in visit_entry
raise NotImplementedError('Column or row spanning cells are '
NotImplementedError: Column or row spanning cells are not implemented.
The full traceback has been saved in /tmp/sphinx-err-l_Oadi.log, if
you want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sphinx-dev@...605... Thanks!
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
! I can't find file `Matplotlib.tex'.
<*> Matplotlib.tex
Please type another input file name:
I don't know if you are so in the middle of things that you'd rather
not get bug reports on this for a while. If that's the case I'll wait
until the dust settles a bit.
In any case, many thanks for pushing this doc effort forward! The
overall usability of the combined tools, in a few months, is going to
really be massively improved thanks to all this common focus on
sphinx-based docs.
Cheers,
f