Folks,
We had some minor confusion with a merge a few weeks back, which
pulled much of the master branch into the v1.0.x maintenance branch. I
created a new v1.0.x-maint branch that rolled back all of the changes
from that point on, and cherry-picked all of the changes that were
actually intended for the v1.0.x branch.
Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
repository (though I'll keep a local copy for a few weeks as a backup,
just in case).
If you have any changes that branched from v1.0.x after May 6 2011,
please contact me off list so we can correctly apply those changes on
top of v1.0.x-maint.
Darren
There might be a missing commit. I just noticed that a bunch of .py source files are missing in doc/mpl_toolkits/axes_grid/figures/. This might require cherry-picking a50874b711983cba505e which was the commit that Michael used to restore some of the mistakes of the commits on May 6th.
I will leave it up to Darren to figure out exactly what would be the correct course of action.
Ben Root
P.S. : As an interesting aside to what caused me to find this mistake…
My docs were still not building correctly, although now that the v1.0.x branch is fixed, it didn’t have the multiprocessing trick that is in master. Therefore, when the error occurred, a message was able to be printed to my screen, which allows me to trace it down.
What happens is that eventually, the python debugger is fired off by sphinx. If possible, it would probably be wise to disable this behavior as it makes no sense for doc-building. What triggers the startup of pdb is that the copying of simple_axes_divider2.py fails at line 403 of plot_directive.py, in _plot_directive(). This failure, however, is actually not the first error, as the first one gets swallowed by a try…finally statement at line 230, in run_code() of the same file.
Because of the removal of the .py files as noted above, I only had .pyc files in that directory, which lead to the build system thinking that there was content to build. I see these assumptions as being problematic, and should probably be rethought in the future.
···
On Thu, Jun 2, 2011 at 6:46 PM, Darren Dale <dsdale24@…149…> wrote:
Folks,
We had some minor confusion with a merge a few weeks back, which
pulled much of the master branch into the v1.0.x maintenance branch. I
created a new v1.0.x-maint branch that rolled back all of the changes
from that point on, and cherry-picked all of the changes that were
actually intended for the v1.0.x branch.
Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
repository (though I’ll keep a local copy for a few weeks as a backup,
just in case).
If you have any changes that branched from v1.0.x after May 6 2011,
please contact me off list so we can correctly apply those changes on
top of v1.0.x-maint.
Darren
Thanks, it should be fixed now.
···
On Fri, Jun 3, 2011 at 1:21 PM, Benjamin Root <ben.root@...553...> wrote:
On Thu, Jun 2, 2011 at 6:46 PM, Darren Dale <dsdale24@...149...> wrote:
Folks,
We had some minor confusion with a merge a few weeks back, which
pulled much of the master branch into the v1.0.x maintenance branch. I
created a new v1.0.x-maint branch that rolled back all of the changes
from that point on, and cherry-picked all of the changes that were
actually intended for the v1.0.x branch.
Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
repository (though I'll keep a local copy for a few weeks as a backup,
just in case).
If you have any changes that branched from v1.0.x after May 6 2011,
please contact me off list so we can correctly apply those changes on
top of v1.0.x-maint.
Darren
There might be a missing commit. I just noticed that a bunch of .py source
files are missing in doc/mpl_toolkits/axes_grid/figures/. This might
require cherry-picking a50874b711983cba505e which was the commit that
Michael used to restore some of the mistakes of the commits on May 6th.
I will leave it up to Darren to figure out exactly what would be the correct
course of action.
P.S. : As an interesting aside to what caused me to find this mistake...
My docs were still not building correctly, although now that the v1.0.x
branch is fixed, it didn't have the multiprocessing trick that is in
master. Therefore, when the error occurred, a message was able to be
printed to my screen, which allows me to trace it down.
What happens is that eventually, the python debugger is fired off by
sphinx. If possible, it would probably be wise to disable this behavior
Ben,
So this part of the problem sounds like a bad design in sphinx, correct? Do you know whether it is present in the current version of sphinx? If so, you might send the sphinx people a bug report. My suspicion is that the triggering of pdb was intended to be temporary (or at least optional), but got left in the sphinx code by mistake--if that is indeed where the fault lies.
Eric
···
On 06/03/2011 07:21 AM, Benjamin Root wrote:
as it makes no sense for doc-building. What triggers the startup of pdb
is that the copying of simple_axes_divider2.py fails at line 403 of
plot_directive.py, in _plot_directive(). This failure, however, is
actually not the first error, as the first one gets swallowed by a
try...finally statement at line 230, in run_code() of the same file.
Because of the removal of the .py files as noted above, I only had .pyc
files in that directory, which lead to the build system thinking that
there was content to build. I see these assumptions as being
problematic, and should probably be rethought in the future.
I will investigate that further. Currently I am using v1.0.1 of sphinx. After the current round of docs are tested and pushed up, I will take a deeper look.
By the way, whoever is the one to push the docs up to sourceforge, you can now do so from the v1.0.x-maint branch. I have built it on my computer and all of my own changes appear correct. I couldn’t test everything (my LaTeX setup isn’t quite right), but everything I intended to change appears to be there.
Ben Root
···
On Fri, Jun 3, 2011 at 1:52 PM, Eric Firing <efiring@…706…29…> wrote:
On 06/03/2011 07:21 AM, Benjamin Root wrote:
P.S. : As an interesting aside to what caused me to find this mistake…
My docs were still not building correctly, although now that the v1.0.x
branch is fixed, it didn’t have the multiprocessing trick that is in
master. Therefore, when the error occurred, a message was able to be
printed to my screen, which allows me to trace it down.
What happens is that eventually, the python debugger is fired off by
sphinx. If possible, it would probably be wise to disable this behavior
Ben,
So this part of the problem sounds like a bad design in sphinx, correct?
Do you know whether it is present in the current version of sphinx?
If so, you might send the sphinx people a bug report. My suspicion is
that the triggering of pdb was intended to be temporary (or at least
optional), but got left in the sphinx code by mistake–if that is indeed
where the fault lies.
Eric
I just pushed the doc build from the maint branch up to sf. Take it for a test drive. Thanks for pushing through on the doc fix patch.
JDH
···
On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben.root@…553…> wrote:
By the way, whoever is the one to push the docs up to sourceforge, you can now do so from the v1.0.x-maint branch. I have built it on my computer and all of my own changes appear correct. I couldn’t test everything (my LaTeX setup isn’t quite right), but everything I intended to change appears to be there.
No problem, glad to be of service. The pages look fine so far (although I want to see if I can get it to be more friendly to people with smaller screens such as an EeePC). There will be some additional work I will put in to improve the docs for the 1.1.0 release. If anybody has a wishlist or complaints about the current docs, just let me know.
I have also tried building the docs from master after merging, and the debugger problem happened again using the latest from sphinx. I will look into it further to see if I can turn that “feature” off.
Ben Root
···
On Fri, Jun 3, 2011 at 6:15 PM, John Hunter <jdh2358@…149…> wrote:
On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben.root@…553…> wrote:
By the way, whoever is the one to push the docs up to sourceforge, you can now do so from the v1.0.x-maint branch. I have built it on my computer and all of my own changes appear correct. I couldn’t test everything (my LaTeX setup isn’t quite right), but everything I intended to change appears to be there.
I just pushed the doc build from the maint branch up to sf. Take it for a test drive. Thanks for pushing through on the doc fix patch.
JDH
Looks like it is a feature, not a bug. sphinx-build has a command-line option “-P” which fires off pdb whenever there is an unhandled exception. Removing that keeps the pdb from firing off, but this still doesn’t solve our problem. The multiprocessing pool does not exit out and the process still hangs.
Right now, I am trying to figure out why the --small option to make.py is causing an unhandled exception in master with the latest sphinx. It seems like bad command-line parsing by sphinx.
Ben Root
···
On Sat, Jun 4, 2011 at 11:09 AM, Benjamin Root <ben.root@…552…553…> wrote:
On Fri, Jun 3, 2011 at 6:15 PM, John Hunter <jdh2358@…149…> wrote:
On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben.root@…553…> wrote:
By the way, whoever is the one to push the docs up to sourceforge, you can now do so from the v1.0.x-maint branch. I have built it on my computer and all of my own changes appear correct. I couldn’t test everything (my LaTeX setup isn’t quite right), but everything I intended to change appears to be there.
I just pushed the doc build from the maint branch up to sf. Take it for a test drive. Thanks for pushing through on the doc fix patch.
JDH
No problem, glad to be of service. The pages look fine so far (although I want to see if I can get it to be more friendly to people with smaller screens such as an EeePC). There will be some additional work I will put in to improve the docs for the 1.1.0 release. If anybody has a wishlist or complaints about the current docs, just let me know.
I have also tried building the docs from master after merging, and the debugger problem happened again using the latest from sphinx. I will look into it further to see if I can turn that “feature” off.
Ben Root
Sorry for the delayed reply -- I've been on vacation.
Thanks so much for untangling this mess. It looks great.
Mike
···
On 06/02/2011 07:46 PM, Darren Dale wrote:
Folks,
We had some minor confusion with a merge a few weeks back, which
pulled much of the master branch into the v1.0.x maintenance branch. I
created a new v1.0.x-maint branch that rolled back all of the changes
from that point on, and cherry-picked all of the changes that were
actually intended for the v1.0.x branch.
Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
repository (though I'll keep a local copy for a few weeks as a backup,
just in case).
If you have any changes that branched from v1.0.x after May 6 2011,
please contact me off list so we can correctly apply those changes on
top of v1.0.x-maint.
Darren
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA