matplotlib-devel Mailing List for matplotlib (Page 2)

Hi,
After switching over from the MacOSX backend to the GTKAgg backend, I 
started notice a big change in drawing behavior.
Now I know that MacOSX is interactive all the time by [mis]design, so I 
wasn't surprised that I would have to add draw() commands when 
isinteractive()==False; however, when using the non-pyplot commands, 
i.e. ax.plot() rather than plot(), I must use draw() to render the new 
Line2D even when isinteractive()==True. This doesn't seem correct 
behavior to me. A lot of drawing just can't be done by the pyplot 
functions. You have to go to the axes functions.
On another, but related topic, I use ipython -pylab, and generally 
develop by using the `run -i file.py` syntax. I have found what I think 
is a bug where if I have a file that consists of:
cat >> file.py <<EOF
print isinteractive()
EOF
and I do
In [1]: isinteractive()
Out[1]: True
In [2]: run -i file.py
False
which means I either have to do ion() or draw() each time even for 
pyplot commands. Is this a bug in ipython or matplotlib?
M

On 05/20/2011 11:48 AM, Benjamin Root wrote:
> Some other ideas I have had is to include a link to the glossary page in
> the page header next to "docs", and maybe the FAQ, as well? I also want
> to expand the glossary page, and comb through the docstrings to
> incorporate more ":term:" usage. However, I probably want to hold off
> on those ideas for the master branch.
Ben,
There is a tradeoff involved in adding more directives like ":term:" 
(which I was not even aware of): they make the html more clickable but 
they clutter the plain text. Even for html, having too many links can 
be distracting and reduce readability. So, use with caution. If it is 
easy to find the glossary, then I am not sure there is any net advantage 
in using "term" directives.
Eric

On 05/20/2011 11:48 AM, Benjamin Root wrote:
>
>
> I have made a few more small changes, and I have an additional change
> that I have not committed yet. The table of contents for the examples
> page has every single example titled as something like "animation
> example code:". This is repeatitive and distracting. In the same
> spirit of removing "matplotlib" from the titles of the api subsections,
> I wanted to do the same here. I figured out how to do that without
> changing the actual titles of the subsections.
>
> So, my question is, do we want that? If so, I can push up the change to
Yes!
> my pull request. I still have to do some merge work apparently, but
> otherwise, I think I am done with the major changes to the v1.0.x docs.
> Is there anything else we want to fix before I merge this pull request?
Sounds to me like this is a good time to merge it.
>
> Some other ideas I have had is to include a link to the glossary page in
> the page header next to "docs", and maybe the FAQ, as well? I also want
Glossary? I didn't even know there was one, so putting in a prominent 
link to it sounds like a good idea. I think that putting a FAQ link up 
front is also a good idea; maybe it will help remind us to keep 
expanding the FAQ when we keep seeing the same question on the mailing list.
> to expand the glossary page, and comb through the docstrings to
> incorporate more ":term:" usage. However, I probably want to hold off
> on those ideas for the master branch.
>
> Let me know what you all think of the docs!
I have not yet tried to build from your branch, but based on 
descriptions and discussions, it should be a substantial improvement. Go 
ahead and push when you feel ready. Thank you for all the work.
Eric
> Ben Root
>

On Thu, May 19, 2011 at 6:27 PM, Benjamin Root <ben...@ou...> wrote:
> On Mon, May 16, 2011 at 5:28 PM, Benjamin Root <ben...@ou...> wrote:
>
>> On Monday, May 16, 2011, John Hunter <jd...@gm...> wrote:
>> >
>> >
>> > On Mon, May 16, 2011 at 2:52 PM, Eric Firing <ef...@ha...>
>> wrote:
>> >
>> >
>> >
>> > I had no idea this would open such a big can of worms! The strategy
>> > question here is, what do we want to include in the html API docs?
>> >
>> > It looks like the process of setting up the sphinx API docs was never
>> > completed; the present set of modules that are included ranges from the
>> > fundamental (e.g. figure.py) to the peripheral (e.g. afm.py), but I
>> > doubt that text.py, for example, was deliberately excluded.
>> >
>> > I don't see any major disadvantage to including all modules. It might
>> > make sense to present them in categories, though, instead of dumping
>> > them all into a single alphabetical list.
>> >
>> > Perhaps Mike and John will have sage advice.
>> >
>> >
>> > Not all of the doc strings have been converted to rest. Back when I was
>> actively working on the docs, I would add a module to the API table of
>> contents when I had at least done a first pass at converting the docs to
>> rest. This isn't a requirement, but it helps explain why some modules and
>> not others are in the list.
>> >
>>
>> Well, I will take a look at what is currently converted and see if any
>> of those can get added.
>>
>> Ben Root
>>
>
> Ok, on my pull request, I have made a number of commits. In particular, I
> have ReST-ified widgets.py (although there are still some more things to do
> in it). I have added a widgets api file to the api docs, and also renamed
> the headers for each api file so that the "matplotlib" part didn't show up
> repeatedly in the ToC.
>
> There are still plenty of odds and ends that can be done. I want to clean
> up the examples page so that the "matplotlib: " string doesn't show up for
> every entry as well. Furthermore, the widgets module has some docstrings
> that seems like the author got distracted halfway through writing it and
> never came back. I marked those docstrings with FIXME comments.
>
> Let me know what you all think!
>
> Ben Root
>
>
I have made a few more small changes, and I have an additional change that I
have not committed yet. The table of contents for the examples page has
every single example titled as something like "animation example code:".
This is repeatitive and distracting. In the same spirit of removing
"matplotlib" from the titles of the api subsections, I wanted to do the same
here. I figured out how to do that without changing the actual titles of
the subsections.
So, my question is, do we want that? If so, I can push up the change to my
pull request. I still have to do some merge work apparently, but otherwise,
I think I am done with the major changes to the v1.0.x docs. Is there
anything else we want to fix before I merge this pull request?
Some other ideas I have had is to include a link to the glossary page in the
page header next to "docs", and maybe the FAQ, as well? I also want to
expand the glossary page, and comb through the docstrings to incorporate
more ":term:" usage. However, I probably want to hold off on those ideas
for the master branch.
Let me know what you all think of the docs!
Ben Root

Hi All,
I'm trying to track down a sporadic Fatal python error in a
complicated data analysis program I'm writing. Quick explanation: I
have a qt gui that launches a python task-manager thread. That thread
creates a multiprocessing.Pool, and iterates through a list of data in
an hdf5 file, passing each item of data to Pool.apply_async. A
callback takes the result and updates an entry in the hdf5 file, and
appends an item to a queue. The qt gui uses a qtimer to check the
queue once a second. If the queue is not empty, it reads the hdf5 file
and updates an imshow image. I can click a pixel in the image, which
plots the spectrum and fit associated with that pixel. I can then
click a qt button to switch between lin and log scales in the spectrum
plot. If the taskmanager thread is running, changing between lin and
log scales can pretty reliably cause a crash (especially on Fedora
14):
python: /builddir/build/BUILD/Python-2.7/Modules/gcmodule.c:311:
update_refs: Assertion `gc->gc.gc_refs != 0' failed.
Aborted (core dumped)
That's not a lot of information to go on, and I'm drawing on a ton of
extension modules in my program: numpy, h5py, qt, matplotlib, pymca.
We've also been able to get the program to crash on mac:
Exception AttributeError: "'BboxTransformTo' object has no attribute
'data'" in <function remove at 0x128752410> ignored
Traceback (most recent call last):
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_qt4agg.py",
line 83, in paintEvent
 FigureCanvasAgg.draw(self)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_agg.py",
line 394, in draw
 self.figure.draw(self.renderer)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/figure.py",
line 798, in draw
 func(*args)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/axes.py",
line 1946, in draw
 a.draw(renderer)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/legend.py",
line 430, in draw
 self._legend_box.draw(renderer)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/offsetbox.py",
line 240, in draw
 c.draw(renderer)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/offsetbox.py",
line 240, in draw
 c.draw(renderer)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/offsetbox.py",
line 240, in draw
 c.draw(renderer)
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/offsetbox.py",
line 239, in draw
 c.set_offset((px+ox, py+oy))
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/offsetbox.py",
line 460, in set_offset
 self.offset_transform.clear()
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/transforms.py",
line 1549, in clear
 self.invalidate()
 File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/transforms.py",
line 124, in invalidate
 stack.extend(root._parents.keys())
AttributeError: 'list' object has no attribute 'keys'
Fatal Python error: GC object already tracked
Abort trap
All access to hdf5 is protected with a thread lock, and I have made
some fairly stressful scripts testing h5py/threading/multiprocessing
and haven't been able to produce a crash.
Does anyone have suggestions on how I can try to track down this
problem? These GC reports are not giving me much to go on, how can I
determine to which extension module these objects with bad reference
counts belong?
Thanks, and sorry for the long and obscure post.
Darren

In legend.__init__ the exception message doesn't match the condition
that raises it. I think it should say "numpoints must be > 0". I'm
using matplotlib version 0.99.3.
Example:
#----------------------------
import matplotlib.pyplot as plt
ax = plt.subplot(1,1,1)
ax.plot(1.1, 2.2, label='foo')
ax.legend(numpoints=0)
#----------------------------
# ValueError: numpoints must be >= 0; it was 0
Steve

On Mon, May 16, 2011 at 5:28 PM, Benjamin Root <ben...@ou...> wrote:
> On Monday, May 16, 2011, John Hunter <jd...@gm...> wrote:
> >
> >
> > On Mon, May 16, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote:
> >
> >
> >
> > I had no idea this would open such a big can of worms! The strategy
> > question here is, what do we want to include in the html API docs?
> >
> > It looks like the process of setting up the sphinx API docs was never
> > completed; the present set of modules that are included ranges from the
> > fundamental (e.g. figure.py) to the peripheral (e.g. afm.py), but I
> > doubt that text.py, for example, was deliberately excluded.
> >
> > I don't see any major disadvantage to including all modules. It might
> > make sense to present them in categories, though, instead of dumping
> > them all into a single alphabetical list.
> >
> > Perhaps Mike and John will have sage advice.
> >
> >
> > Not all of the doc strings have been converted to rest. Back when I was
> actively working on the docs, I would add a module to the API table of
> contents when I had at least done a first pass at converting the docs to
> rest. This isn't a requirement, but it helps explain why some modules and
> not others are in the list.
> >
>
> Well, I will take a look at what is currently converted and see if any
> of those can get added.
>
> Ben Root
>
Ok, on my pull request, I have made a number of commits. In particular, I
have ReST-ified widgets.py (although there are still some more things to do
in it). I have added a widgets api file to the api docs, and also renamed
the headers for each api file so that the "matplotlib" part didn't show up
repeatedly in the ToC.
There are still plenty of odds and ends that can be done. I want to clean
up the examples page so that the "matplotlib: " string doesn't show up for
every entry as well. Furthermore, the widgets module has some docstrings
that seems like the author got distracted halfway through writing it and
never came back. I marked those docstrings with FIXME comments.
Let me know what you all think!
Ben Root

On Thu, May 19, 2011 at 1:42 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Thu, May 19, 2011 at 1:16 PM, Benjamin Root <ben...@ou...> wrote:
>
>> I have come across a slight oddity while working on the docs today. I
>> wanted to make some small changes to the ReST docs for the examples section,
>> but then I noticed that my docs/examples directory had the new animation
>> examples and a directory for "old_animations". Figuring that this could not
>> be correct, I checked on github, and for branch v1.0.x, there is no
>> "docs/examples" directory. Is this directory created and its contents
>> filled whenever I run setup.py? The modification time for the folder seems
>> to indicate that.
>>
>
> This is created and built by the doc builder, so it is when you run make.py
> from the doc dir, not when you run setup.py from the src dir.
>
> Check doc/sphinxext/gen_rst.py and doc/sphinxext/gen_gallery.py
>
> If you run
>
>
> > python make.py clean
>
> from the doc dir, it should clean it up.
>
> JDH
>
Ah, that makes sense, although the mod time for my directory doesn't...
maybe the setup.py is somehow touching that directory?
Anyway, when I cleaned up the docs with the above command, it removed
doc/pyplots/tex_demo.png, which appears to have been under version control.
I guess this is a mistake in either the version control, or the cleanup
script (which left behind other png files in the same directory).
Ben Root

On Thu, May 19, 2011 at 1:16 PM, Benjamin Root <ben...@ou...> wrote:
> I have come across a slight oddity while working on the docs today. I
> wanted to make some small changes to the ReST docs for the examples section,
> but then I noticed that my docs/examples directory had the new animation
> examples and a directory for "old_animations". Figuring that this could not
> be correct, I checked on github, and for branch v1.0.x, there is no
> "docs/examples" directory. Is this directory created and its contents
> filled whenever I run setup.py? The modification time for the folder seems
> to indicate that.
>
This is created and built by the doc builder, so it is when you run make.py
from the doc dir, not when you run setup.py from the src dir.
Check doc/sphinxext/gen_rst.py and doc/sphinxext/gen_gallery.py
If you run
 > python make.py clean
from the doc dir, it should clean it up.
JDH

I have come across a slight oddity while working on the docs today. I
wanted to make some small changes to the ReST docs for the examples section,
but then I noticed that my docs/examples directory had the new animation
examples and a directory for "old_animations". Figuring that this could not
be correct, I checked on github, and for branch v1.0.x, there is no
"docs/examples" directory. Is this directory created and its contents
filled whenever I run setup.py? The modification time for the folder seems
to indicate that.
Thanks,
Ben Root

On 05/18/2011 11:45 AM, Darren Dale wrote:
>>
>> I suspect the anomalies have not resulted from forced pushes, but from
>> local pulls and merges followed by innocuous pushes. So the key is
>> understanding how to ensure one's local branches have the desired
>> history before pushing to github. (And making sure one is pushing from
>> the correct source to the correct destination. Trying first with
>> --dry-run can help.)
>
> Before pushing, I also recommend inspecting the history graph, either
> with "gitk --all" or "git log --oneline --graph --all". I try to
> remember to make sure the history graph looks the way I expect it
> should before I push anywhere.
QGit is another alternative.
Eric

On Wed, May 18, 2011 at 3:22 PM, Eric Firing <ef...@ha...> wrote:
> On 05/18/2011 08:47 AM, Benjamin Root wrote:
>>
>>
>> On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gd...@mr...
>> <mailto:gd...@mr...>> wrote:
>>
>>   On 18/05/2011 5:14 AM, Eric Firing wrote:
>>   > 3) We don't have to always push sets of changes from an original pull
>>   > request to upstream; they can be consolidated using any of a
>>   variety of
>>   > methods to form a new local feature branch with the same net
>>   effect but
>>   > fewer commits (maybe only one), and then that can be merged (which
>>   > should be fast-forward, no merge commit) and pushed to upstream.
>>    This
>>   > takes a little more work than simply accepting (merging) a pull
>>   request
>>   > as-is, but in many cases it may be worth it because it can yield a
>>   > cleaner history. Similarly, if someone is developing a feature
>>   branch
>>   > on github, and the net effect is correct but the branch has
>>   intermediate
>>   > commits that distract from the net result, then a good practice
>>   would be
>>   > for that person to consolidate the changes into a new feature branch
>>   > with a cleaner history, close the pull request on the old one and
>>   open a
>>   > new request for the polished branch.
>>   >
>>   I believe this script more or less automates the process:
>>   https://github.com/jeresig/pulley
>>
>>   Gerald.
>>
>>
>> Don't know if this was a mistake or not, but I see that commit e7f1e83
>> (the one to fix a clipping issue when a patch's line width is 1 but
>> there is no color) seems to have been merged back into itself...
>> somehow... in commit 0c886b8. I have seen things like this before, and
>> I never quite understood how they happen. Plus, do we want to get that
>> patch merged down to master?
>
> Yes, it needs to get merged to master; but no, I don't think anything
> was "merged back into itself"; instead, it is just a case where a
> fast-forward with no merge commit would have left a simpler history--one
> commit instead of two.
>
> Merging from v1.0.x to master doesn't have to be done after every change
> to v1.0.x, but it shouldn't be left undone for very long. A few days
> ago I wasted a chunk of time thrashing around on master because of a bug
> that had been fixed on 1.0.x but was not yet merged into master--and I
> had not thought to check their relative states. The bug had actually
> been introduced to master via a recent change merged from 1.0.x.
>
> We are experiencing some bumps on the git/github learning curve, but not
> nearly enough to make me pine for svn.
>
>>
>> I think we definitely need to see what sort of controls we can put in
>> place to prevent mix-ups in the future. One thing I did like about SVN
>> was that it was next to impossible to change the history. Meanwhile,
>> with git, it becomes possible. Is there some way we can disallow forced
>> pushes, maybe? Just a thought...
>>
>
> I suspect the anomalies have not resulted from forced pushes, but from
> local pulls and merges followed by innocuous pushes. So the key is
> understanding how to ensure one's local branches have the desired
> history before pushing to github. (And making sure one is pushing from
> the correct source to the correct destination. Trying first with
> --dry-run can help.)
Before pushing, I also recommend inspecting the history graph, either
with "gitk --all" or "git log --oneline --graph --all". I try to
remember to make sure the history graph looks the way I expect it
should before I push anywhere.

On 05/18/2011 08:47 AM, Benjamin Root wrote:
>
>
> On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gd...@mr...
> <mailto:gd...@mr...>> wrote:
>
> On 18/05/2011 5:14 AM, Eric Firing wrote:
> > 3) We don't have to always push sets of changes from an original pull
> > request to upstream; they can be consolidated using any of a
> variety of
> > methods to form a new local feature branch with the same net
> effect but
> > fewer commits (maybe only one), and then that can be merged (which
> > should be fast-forward, no merge commit) and pushed to upstream.
> This
> > takes a little more work than simply accepting (merging) a pull
> request
> > as-is, but in many cases it may be worth it because it can yield a
> > cleaner history. Similarly, if someone is developing a feature
> branch
> > on github, and the net effect is correct but the branch has
> intermediate
> > commits that distract from the net result, then a good practice
> would be
> > for that person to consolidate the changes into a new feature branch
> > with a cleaner history, close the pull request on the old one and
> open a
> > new request for the polished branch.
> >
> I believe this script more or less automates the process:
> https://github.com/jeresig/pulley
>
> Gerald.
>
>
> Don't know if this was a mistake or not, but I see that commit e7f1e83
> (the one to fix a clipping issue when a patch's line width is 1 but
> there is no color) seems to have been merged back into itself...
> somehow... in commit 0c886b8. I have seen things like this before, and
> I never quite understood how they happen. Plus, do we want to get that
> patch merged down to master?
Yes, it needs to get merged to master; but no, I don't think anything 
was "merged back into itself"; instead, it is just a case where a 
fast-forward with no merge commit would have left a simpler history--one 
commit instead of two.
Merging from v1.0.x to master doesn't have to be done after every change 
to v1.0.x, but it shouldn't be left undone for very long. A few days 
ago I wasted a chunk of time thrashing around on master because of a bug 
that had been fixed on 1.0.x but was not yet merged into master--and I 
had not thought to check their relative states. The bug had actually 
been introduced to master via a recent change merged from 1.0.x.
We are experiencing some bumps on the git/github learning curve, but not 
nearly enough to make me pine for svn.
>
> I think we definitely need to see what sort of controls we can put in
> place to prevent mix-ups in the future. One thing I did like about SVN
> was that it was next to impossible to change the history. Meanwhile,
> with git, it becomes possible. Is there some way we can disallow forced
> pushes, maybe? Just a thought...
>
I suspect the anomalies have not resulted from forced pushes, but from 
local pulls and merges followed by innocuous pushes. So the key is 
understanding how to ensure one's local branches have the desired 
history before pushing to github. (And making sure one is pushing from 
the correct source to the correct destination. Trying first with 
--dry-run can help.)
Eric
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 2011年5月18日 13:47:04 -0500, Benjamin Root wrote:
[clip]
> Don't know if this was a mistake or not, but I see that commit e7f1e83
> (the one to fix a clipping issue when a patch's line width is 1 but
> there is no color) seems to have been merged back into itself...
> somehow... in commit 0c886b8. I have seen things like this before, and
> I never quite understood how they happen.
"git merge --no-ff" most likely, as it always creates a separate
merge commit, even if the branch in question has only a single commit.
[clip]
> I think we definitely need to see what sort of controls we can put in
> place to prevent mix-ups in the future. One thing I did like about SVN
> was that it was next to impossible to change the history. Meanwhile,
> with git, it becomes possible. 
> Is there some way we can disallow forced pushes, maybe? Just a thought...
Disabling forced pushes will not help against what occurred here,
at least as far I understand, because the "additional" commits in the
pull requests come from valid merges done after the pull request branched.
The only difference to SVN here is that Git actually tracks the merge
history...
... and, apparently, the Github UI (but not Git itself) gets confused
in some cases as to what's new in a branch.
-- 
Pauli Virtanen

On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gd...@mr...> wrote:
> On 18/05/2011 5:14 AM, Eric Firing wrote:
> > 3) We don't have to always push sets of changes from an original pull
> > request to upstream; they can be consolidated using any of a variety of
> > methods to form a new local feature branch with the same net effect but
> > fewer commits (maybe only one), and then that can be merged (which
> > should be fast-forward, no merge commit) and pushed to upstream. This
> > takes a little more work than simply accepting (merging) a pull request
> > as-is, but in many cases it may be worth it because it can yield a
> > cleaner history. Similarly, if someone is developing a feature branch
> > on github, and the net effect is correct but the branch has intermediate
> > commits that distract from the net result, then a good practice would be
> > for that person to consolidate the changes into a new feature branch
> > with a cleaner history, close the pull request on the old one and open a
> > new request for the polished branch.
> >
> I believe this script more or less automates the process:
> https://github.com/jeresig/pulley
>
> Gerald.
>
>
Don't know if this was a mistake or not, but I see that commit e7f1e83 (the
one to fix a clipping issue when a patch's line width is 1 but there is no
color) seems to have been merged back into itself... somehow... in commit
0c886b8. I have seen things like this before, and I never quite understood
how they happen. Plus, do we want to get that patch merged down to master?
I think we definitely need to see what sort of controls we can put in place
to prevent mix-ups in the future. One thing I did like about SVN was that
it was next to impossible to change the history. Meanwhile, with git, it
becomes possible. Is there some way we can disallow forced pushes, maybe?
Just a thought...
Ben Root

Dear all,
When making plots, you want an log transfer of axis, but there are data
whose value is zero, at this time matplotlib prompts "Cannot take log of
nonpositive value",
but in most cases maybe you just want to check if the log axis make the plot
more nice-looking. So is it possible just change the function to make it
accept zero value
when making log transfer and set the the zero value on the log-transfered
plot remain as zero? By this way we don't have to change the zero value in
the data to a very small
value just for realizing the axis log transfer?
My matplotlib version is 0.91.2, Maybe in the new versions this has already
been done?
much thanks,
Chao
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 77 30
Portable Phone (Mobil phone) : (33) 07 60 54 23 71
************************************************************************************

On 18/05/2011 5:14 AM, Eric Firing wrote:
> 3) We don't have to always push sets of changes from an original pull
> request to upstream; they can be consolidated using any of a variety of
> methods to form a new local feature branch with the same net effect but
> fewer commits (maybe only one), and then that can be merged (which
> should be fast-forward, no merge commit) and pushed to upstream. This
> takes a little more work than simply accepting (merging) a pull request
> as-is, but in many cases it may be worth it because it can yield a
> cleaner history. Similarly, if someone is developing a feature branch
> on github, and the net effect is correct but the branch has intermediate
> commits that distract from the net result, then a good practice would be
> for that person to consolidate the changes into a new feature branch
> with a cleaner history, close the pull request on the old one and open a
> new request for the polished branch.
>
I believe this script more or less automates the process: 
https://github.com/jeresig/pulley
Gerald.

On 2011年5月17日 16:14:53 -0400, Michael Droettboom wrote:
> Darned if I know what I did differently that time. (I'm sure I hit
> git's "misunderstanding" feature again).
> 
> It only seems to have affected 2 or 3 of the pull requests -- I suspect
> rebasing those branches off of the current master would fix the problem,
> but maybe there's an easier way.
Looks like some Github quirk:
 git log master..scottza/fix-autofmt_xdate-twinx
shows only four commits.
The merges done after 2011年02月19日 seem to have connected a chunk of
previously unconnected 0_91_maint history to master.

On 05/17/2011 10:14 AM, Michael Droettboom wrote:
> Darned if I know what I did differently that time. (I'm sure I hit
> git's "misunderstanding" feature again).
>
> It only seems to have affected 2 or 3 of the pull requests -- I suspect
> rebasing those branches off of the current master would fix the problem,
> but maybe there's an easier way.
Mike,
First, regarding the pull requests, I think that in some cases it is not 
a problem because they are being closed (rejected or superseded), and in 
any case, it is easy to handle them locally and then ensure a clean 
changeset to be pushed up to the main repo. So they look terrible in 
the github web view, but no real damage is done to the information in 
the branches they represent when one pulls those branches and works with 
them locally.
Second, I think the problems came from one or two exceptions to 
recommended git practice (this is coming from a git non-expert, so take 
with a grain of salt; git experts, please chime in and correct me as 
needed), which appear to be of two types: one is pulling from "origin" 
when you intended to pull from "upstream":
* | | commit 14406a68c039dc6578730f23955bf34d34008a08
|\ \ \ Merge: fdf5fae 132f967
| | | | Author: Michael Droettboom <md...@gm...>
| | | | Date: Fri May 6 15:25:01 2011 -0400
| | | |
| | | | Merge remote branch 'origin/v1.0.x'
(this is the one that deleted scads of files, which you replaced in the 
subsequent commit)
and the other is merging from origin or upstream into a feature branch:
| | * | commit 668ef6d826eff5eb4aac6251e1ddd9ac713616e5
| | |\ \ Merge: de18d9a 53f8139
| | |/ / Author: Michael Droettboom <md...@gm...>
| |/| | Date: Thu May 12 11:43:48 2011 -0400
| | | |
| | | | Merge remote branch 'upstream/v1.0.x' into gtk_crash
My understanding is that:
1) merges should always be from a feature branch into v1.0.x or master 
(and from v1.0.x into master, not the reverse); this can be done by 
updating local copies of v1.0.x etc from upstream, merging from the 
feature branch, and then pushing to upstream.
2) If a feature branch is local only (no one else has it) then it can be 
rebased so that merging it into v1.0.x etc. does not involve a merge 
commit; but if the feature branch has been published on github, then it 
should not be rebased.
3) We don't have to always push sets of changes from an original pull 
request to upstream; they can be consolidated using any of a variety of 
methods to form a new local feature branch with the same net effect but 
fewer commits (maybe only one), and then that can be merged (which 
should be fast-forward, no merge commit) and pushed to upstream. This 
takes a little more work than simply accepting (merging) a pull request 
as-is, but in many cases it may be worth it because it can yield a 
cleaner history. Similarly, if someone is developing a feature branch 
on github, and the net effect is correct but the branch has intermediate 
commits that distract from the net result, then a good practice would be 
for that person to consolidate the changes into a new feature branch 
with a cleaner history, close the pull request on the old one and open a 
new request for the polished branch.
Regarding your 14406a commit: if I understand correctly, a better 
recovery method would have been to use
git reset --hard HEAD^
to simply back up the branch pointer by one.
The bad commit would still be in your local tree, but it would be 
un-named (that is, it would have no branch name) and would not go 
anywhere else.
Eric
>
> Mike
>
> On 05/17/2011 03:16 PM, Eric Firing wrote:
>> I suspect that the series of May 6 commits ending with
>> a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such
>> a way that some (but not all) older pull requests on github like this one
>>
>> https://github.com/matplotlib/matplotlib/pull/1
>>
>> are showing hundreds of commits and diffs.
>>
>> Eric

Darned if I know what I did differently that time. (I'm sure I hit 
git's "misunderstanding" feature again).
It only seems to have affected 2 or 3 of the pull requests -- I suspect 
rebasing those branches off of the current master would fix the problem, 
but maybe there's an easier way.
Mike
On 05/17/2011 03:16 PM, Eric Firing wrote:
> I suspect that the series of May 6 commits ending with
> a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such
> a way that some (but not all) older pull requests on github like this one
>
> https://github.com/matplotlib/matplotlib/pull/1
>
> are showing hundreds of commits and diffs.
>
> Eric
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

I suspect that the series of May 6 commits ending with 
a50874b711983cba505ecdb2801c4996eccf3812 has tangled the history in such 
a way that some (but not all) older pull requests on github like this one
https://github.com/matplotlib/matplotlib/pull/1
are showing hundreds of commits and diffs.
Eric

On Monday, May 16, 2011, John Hunter <jd...@gm...> wrote:
>
>
> On Mon, May 16, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote:
>
>
>
> I had no idea this would open such a big can of worms! The strategy
> question here is, what do we want to include in the html API docs?
>
> It looks like the process of setting up the sphinx API docs was never
> completed; the present set of modules that are included ranges from the
> fundamental (e.g. figure.py) to the peripheral (e.g. afm.py), but I
> doubt that text.py, for example, was deliberately excluded.
>
> I don't see any major disadvantage to including all modules. It might
> make sense to present them in categories, though, instead of dumping
> them all into a single alphabetical list.
>
> Perhaps Mike and John will have sage advice.
>
>
> Not all of the doc strings have been converted to rest. Back when I was actively working on the docs, I would add a module to the API table of contents when I had at least done a first pass at converting the docs to rest. This isn't a requirement, but it helps explain why some modules and not others are in the list.
>
Well, I will take a look at what is currently converted and see if any
of those can get added.
Ben Root

On Monday, May 16, 2011, Eric Firing <ef...@ha...> wrote:
> On 05/16/2011 09:32 AM, Benjamin Root wrote:
>>
>>
>> On Mon, May 16, 2011 at 2:08 PM, Benjamin Root <ben...@ou...
>> <mailto:ben...@ou...>> wrote:
>>
>>
>>
>>   On Mon, May 16, 2011 at 1:35 PM, Eric Firing <ef...@ha...
>>   <mailto:ef...@ha...>> wrote:
>>
>>     On 05/16/2011 06:56 AM, Benjamin Root wrote:
>>     >
>>     >
>>     > On Tue, May 10, 2011 at 12:53 PM, John Hunter
>>     <jd...@gm... <mailto:jd...@gm...>
>>     > <mailto:jd...@gm... <mailto:jd...@gm...>>> wrote:
>>     >
>>     >
>>     >
>>     >   On Tue, May 10, 2011 at 12:48 PM, Benjamin Root
>>     <ben...@ou... <mailto:ben...@ou...>
>>     > <mailto:ben...@ou... <mailto:ben...@ou...>>> wrote:
>>     >
>>     >
>>     >
>>     >
>>     >     The one thing I am confused about is what file to
>>     edit for the
>>     >     main page. I must be very dense because I just
>>     simply can not
>>     >     figure out where the main page is generated from. I
>>     have been
>>     >     meaning to fix some things on the front page for a
>>     while now,
>>     >     but have been too afraid to ask.
>>     >
>>     >
>>     >   see doc/_templates/*.html
>>     >
>>     >   After you have integrated the pull request into the 1.0.x
>>     branch
>>     >   (which is what I build the website from) I'll build and
>>     push it to
>>     >   the sf site.
>>     >
>>     >
>>     > Sorry it took so long. I have made those immediate fixes and
>>     pushed
>>     > them up to my pull request. If there are any other doc fixes
>>     we want to
>>     > make, now would be a good time to do it.
>>
>>     Ben,
>>
>>     Would you add widget.py to the autogenerated API docs, please,
>>     unless
>>     there is some reason for it to be excluded? I happened to
>>     notice that
>>     it is missing; I haven't checked for other missing modules.
>>
>>     Thank you.
>>
>>     Eric
>>
>>
>>   No problem. Having a quick view through the docs, here is what I
>>   see as missing. Maybe some of these don't need to be included?
>>
>>
>>   bezier.py
>>   blocking_input.py
>>   contour.py
>>   finance.py
>>   fontconfig_pattern.py
>>   hatch.py
>>   image.py
>>   legend.py
>>   lines.py
>>   mpl.py
>>   offsetbox.py
>>   patches.py
>>   patheffects.py
>>   pylab.py
>>   pyparsing.py
>>   quiver.py
>>   scale.py
>>   table.py
>>   texmanager.py
>>   textpath.py
>>   text.py
>>   tight_bbox.py
>>   transforms.py
>>   widgets.py
>>
>>   Some of these might not be "modules" per se, I was just doing a
>>   quick comparison of what rst docs we have and what we have in
>>   lib/matplotlib. Note, we are also missing api docs for backends
>>   "cairo", "cocoaagg", "emf", "fltkagg", "gdk", "gtkcairo", "gtk",
>>   "macosx", "mixed", "ps", "qt4", "qtagg", "qt", "svg", "tkagg", and
>>   "wx". Again, some of these might be redundant, I am just noticing
>>   differences between the available rst docs and the listed modules.
>>
>>   Also, I noticed that nxutils_api.rst is pretty much useless. Should
>> Aha!
>
> So, part of the problem here is that the contents list for "The
> Matplotlib API" is full of names like "matplotlib_axes", which is a
> module, and "matplotlib_artists", which documents a hierarchy of modules
> inheriting from Artist--but by no means all such modules, since others,
> like collections, stand alone. First, having all those "matplotlib_"
> prefixes is distracting and makes it harder to find the information.
Agreed.
> Second, the overall hierarchy is very inconsistent, with big categories
> ("artists") alongside details ("gridspec").
>
Agreed. I think we can greatly benefit from embracing categories and
other organizational concepts here and elsewhere such as the gallery
and large classes like axes. Are there good markup approaches we can
take to tag some docstrings to help sphinx organize things like this?
However, for the v1.0.x docs, I think the goal should be to get
whatever is missing filled in. Then merge that up to master (and add
animation_api docs). It would be in master where I think structural
changes to the docs should go.
I will have more time available Wednesday to work on this and I also
anticipate doing some of my wishlist work on mplot3d next week.
Ben Root

On 05/16/2011 09:32 AM, Benjamin Root wrote:
>
>
> On Mon, May 16, 2011 at 2:08 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>
>
> On Mon, May 16, 2011 at 1:35 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 05/16/2011 06:56 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 10, 2011 at 12:53 PM, John Hunter
> <jd...@gm... <mailto:jd...@gm...>
> > <mailto:jd...@gm... <mailto:jd...@gm...>>> wrote:
> >
> >
> >
> > On Tue, May 10, 2011 at 12:48 PM, Benjamin Root
> <ben...@ou... <mailto:ben...@ou...>
> > <mailto:ben...@ou... <mailto:ben...@ou...>>> wrote:
> >
> >
> >
> >
> > The one thing I am confused about is what file to
> edit for the
> > main page. I must be very dense because I just
> simply can not
> > figure out where the main page is generated from. I
> have been
> > meaning to fix some things on the front page for a
> while now,
> > but have been too afraid to ask.
> >
> >
> > see doc/_templates/*.html
> >
> > After you have integrated the pull request into the 1.0.x
> branch
> > (which is what I build the website from) I'll build and
> push it to
> > the sf site.
> >
> >
> > Sorry it took so long. I have made those immediate fixes and
> pushed
> > them up to my pull request. If there are any other doc fixes
> we want to
> > make, now would be a good time to do it.
>
> Ben,
>
> Would you add widget.py to the autogenerated API docs, please,
> unless
> there is some reason for it to be excluded? I happened to
> notice that
> it is missing; I haven't checked for other missing modules.
>
> Thank you.
>
> Eric
>
>
> No problem. Having a quick view through the docs, here is what I
> see as missing. Maybe some of these don't need to be included?
>
>
> bezier.py
> blocking_input.py
> contour.py
> finance.py
> fontconfig_pattern.py
> hatch.py
> image.py
> legend.py
> lines.py
> mpl.py
> offsetbox.py
> patches.py
> patheffects.py
> pylab.py
> pyparsing.py
> quiver.py
> scale.py
> table.py
> texmanager.py
> textpath.py
> text.py
> tight_bbox.py
> transforms.py
> widgets.py
>
> Some of these might not be "modules" per se, I was just doing a
> quick comparison of what rst docs we have and what we have in
> lib/matplotlib. Note, we are also missing api docs for backends
> "cairo", "cocoaagg", "emf", "fltkagg", "gdk", "gtkcairo", "gtk",
> "macosx", "mixed", "ps", "qt4", "qtagg", "qt", "svg", "tkagg", and
> "wx". Again, some of these might be redundant, I am just noticing
> differences between the available rst docs and the listed modules.
>
> Also, I noticed that nxutils_api.rst is pretty much useless. Should
> I fix that?
>
> Ben Root
>
>
>
> Corrections....
>
> fontconfig_pattern is included in font_manager_api.rst
> legend, lines, patches and text are included in artist_api.rst.
> However, legend is not included for the inheritance diagram.
Aha!
So, part of the problem here is that the contents list for "The 
Matplotlib API" is full of names like "matplotlib_axes", which is a 
module, and "matplotlib_artists", which documents a hierarchy of modules 
inheriting from Artist--but by no means all such modules, since others, 
like collections, stand alone. First, having all those "matplotlib_" 
prefixes is distracting and makes it harder to find the information. 
Second, the overall hierarchy is very inconsistent, with big categories 
("artists") alongside details ("gridspec").
>
> Also, 'spines' is listed as 'spine'. I don't know if that impacts
> anything, but I am a stickler for consistency. Should this be fixed?
Yes.
Eric
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, May 16, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote:
>
> I had no idea this would open such a big can of worms! The strategy
> question here is, what do we want to include in the html API docs?
>
> It looks like the process of setting up the sphinx API docs was never
> completed; the present set of modules that are included ranges from the
> fundamental (e.g. figure.py) to the peripheral (e.g. afm.py), but I
> doubt that text.py, for example, was deliberately excluded.
>
> I don't see any major disadvantage to including all modules. It might
> make sense to present them in categories, though, instead of dumping
> them all into a single alphabetical list.
>
> Perhaps Mike and John will have sage advice.
>
Not all of the doc strings have been converted to rest. Back when I was
actively working on the docs, I would add a module to the API table of
contents when I had at least done a first pass at converting the docs to
rest. This isn't a requirement, but it helps explain why some modules and
not others are in the list.