[matplotlib-devel] question about svnmerge
I am following the instructions in the coding guide to commit a change on the maintenance branch, and merge that change into the trunk. I am getting a bunch of unexpected property changes, so I interrupted the commit. Is it ok to go ahead and let this finish?: [~/Projects/matplotlib] dar...@waterhouse $ svnmerge merge -S v1_0_maint /usr/bin/svnmerge:71: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import sys, os, getopt, re, types, tempfile, time, popen2, locale property 'svnmerge-integrated' set on '.' --- Merging r8566 into '.': UCHANGELOG Ulib/matplotlib/backends/backend_qt4.py property 'svnmerge-integrated' set on '.' [~/Projects/matplotlib] dar...@waterhouse $ svn commit -F svnmerge-commit-message.txt Sending. SendingCHANGELOG Sendingdoc/pyplots/README Sendingdoc/sphinxext/gen_gallery.py Sendingdoc/sphinxext/gen_rst.py Sendingexamples/misc/multiprocess.py Sendingexamples/mplot3d/contour3d_demo.py Sendingexamples/mplot3d/contourf3d_demo.py Sendingexamples/mplot3d/polys3d_demo.py Sendingexamples/mplot3d/scatter3d_demo.py Sendingexamples/mplot3d/surface3d_demo.py Sendingexamples/mplot3d/wire3d_demo.py Sendinglib/matplotlib/backends/backend_qt4.py Sendinglib/matplotlib/sphinxext/mathmpl.py Sendinglib/matplotlib/sphinxext/only_directives.py Sendinglib/matplotlib/sphinxext/plot_directive.py ^Csvn: Commit failed (details follow): svn: At least one property change failed; repository is unchanged svn: Caught signal [~/Projects/matplotlib] dar...@waterhouse $ svn diff Property changes on: . ___ Modified: svnmerge-integrated - /trunk/matplotlib:1-7315 /branches/mathtex:1-7263 /branches/v0_98_5_maint:1-7253 /branches/v0_91_maint:1-6428 /branches/v1_0_maint:1-8564 + /branches/mathtex:1-7263 /branches/v0_91_maint:1-6428 /branches/v0_98_5_maint:1-7253 /branches/v1_0_maint:1-8566 /trunk/matplotlib:1-7315 Modified: svn:mergeinfo Merged /branches/v1_0_maint:r8566 Index: CHANGELOG === --- CHANGELOG (revision 8566) +++ CHANGELOG (working copy) @@ -1,3 +1,5 @@ +2010-07-20 Return Qt4's default cursor when leaving the canvas - DSD + 2010-07-06 Tagging for mpl 1.0 at r8502 Property changes on: doc/sphinxext/gen_gallery.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/doc/sphinxext/gen_gallery.py:r8566 Property changes on: doc/sphinxext/gen_rst.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/doc/sphinxext/gen_rst.py:r8566 Property changes on: doc/pyplots/README ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/doc/pyplots/README:r8566 Property changes on: lib/matplotlib/sphinxext/plot_directive.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/plot_directive.py:r8566 Property changes on: lib/matplotlib/sphinxext/mathmpl.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/mathmpl.py:r8566 Property changes on: lib/matplotlib/sphinxext/only_directives.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/only_directives.py:r8566 Property changes on: lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png:r8566 Index: lib/matplotlib/backends/backend_qt4.py === --- lib/matplotlib/backends/backend_qt4.py (revision 8566) +++ lib/matplotlib/backends/backend_qt4.py (working copy) @@ -150,6 +150,7 @@ FigureCanvasBase.enter_notify_event(self, event) def leaveEvent(self, event): +QtGui.QApplication.restoreOverrideCursor() FigureCanvasBase.leave_notify_event(self, event) def mousePressEvent( self, event ): Property changes on: examples/mplot3d/contourf3d_demo.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/examples/mplot3d/contourf3d_demo.py:r8566 Property changes on: examples/mplot3d/scatter3d_demo.py ___ Modified: svn:mergeinfo Merged /branches/v1_0_maint/examples/mplot3d/scatter3d_demo.py:r8566 Property changes on: e
[matplotlib-devel] Bug in 'weights' in axes.hist
Hello,
The documentation for hist seems to indicate that you should be able
to send a list of values through the 'weights' parameter in axes.hist,
and this worked in previous versions. In 1.0, however, this produces
an error. I've attached a diff (also pasted below) that I believe
produces the expected behavior.
It can be tested with:
plt.hist([1,2,3], weights=[1,2,3])
The above fails in the development version, but works with the diff.
Could someone add this fix?
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://klukas.web.cern.ch/
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 8565)
+++ lib/matplotlib/axes.py (working copy)
@@ -7587,7 +7587,12 @@
else:
raise ValueError("weights must be 1D or 2D")
else:
-w = [np.array(wi) for wi in weights]
+try:
+weights[0][0]
+except TypeError:
+w = [np.array(weights)]
+else:
+w = [np.array(wi) for wi in weights]
if len(w) != nx:
raise ValueError('weights should have the same shape as x')
weights.diff
Description: Binary data
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
We've seen this before. It seems to have to do with files that were created after the branching. While I haven't found a solution, it's been going on a long time and seems to be benign. (And, yeah, making the leap to a DVCS would probably not be a bad "solution" to this problem.) Mike On 07/20/2010 10:14 AM, Darren Dale wrote: > I am following the instructions in the coding guide to commit a change > on the maintenance branch, and merge that change into the trunk. I am > getting a bunch of unexpected property changes, so I interrupted the > commit. Is it ok to go ahead and let this finish?: > > [~/Projects/matplotlib] > dar...@waterhouse $ svnmerge merge -S v1_0_maint > /usr/bin/svnmerge:71: DeprecationWarning: The popen2 module is > deprecated. Use the subprocess module. >import sys, os, getopt, re, types, tempfile, time, popen2, locale > property 'svnmerge-integrated' set on '.' > > --- Merging r8566 into '.': > UCHANGELOG > Ulib/matplotlib/backends/backend_qt4.py > > property 'svnmerge-integrated' set on '.' > > > [~/Projects/matplotlib] > dar...@waterhouse $ svn commit -F svnmerge-commit-message.txt > Sending. > SendingCHANGELOG > Sendingdoc/pyplots/README > Sendingdoc/sphinxext/gen_gallery.py > Sendingdoc/sphinxext/gen_rst.py > Sendingexamples/misc/multiprocess.py > Sendingexamples/mplot3d/contour3d_demo.py > Sendingexamples/mplot3d/contourf3d_demo.py > Sendingexamples/mplot3d/polys3d_demo.py > Sendingexamples/mplot3d/scatter3d_demo.py > Sendingexamples/mplot3d/surface3d_demo.py > Sendingexamples/mplot3d/wire3d_demo.py > Sendinglib/matplotlib/backends/backend_qt4.py > Sendinglib/matplotlib/sphinxext/mathmpl.py > Sendinglib/matplotlib/sphinxext/only_directives.py > Sendinglib/matplotlib/sphinxext/plot_directive.py > ^Csvn: Commit failed (details follow): > svn: At least one property change failed; repository is unchanged > svn: Caught signal > > [~/Projects/matplotlib] > dar...@waterhouse $ svn diff > > Property changes on: . > ___ > Modified: svnmerge-integrated > - /trunk/matplotlib:1-7315 /branches/mathtex:1-7263 > /branches/v0_98_5_maint:1-7253 /branches/v0_91_maint:1-6428 > /branches/v1_0_maint:1-8564 > + /branches/mathtex:1-7263 /branches/v0_91_maint:1-6428 > /branches/v0_98_5_maint:1-7253 /branches/v1_0_maint:1-8566 > /trunk/matplotlib:1-7315 > Modified: svn:mergeinfo > Merged /branches/v1_0_maint:r8566 > > Index: CHANGELOG > === > --- CHANGELOG (revision 8566) > +++ CHANGELOG (working copy) > @@ -1,3 +1,5 @@ > +2010-07-20 Return Qt4's default cursor when leaving the canvas - DSD > + > 2010-07-06 Tagging for mpl 1.0 at r8502 > > > > Property changes on: doc/sphinxext/gen_gallery.py > ___ > Modified: svn:mergeinfo > Merged /branches/v1_0_maint/doc/sphinxext/gen_gallery.py:r8566 > > > Property changes on: doc/sphinxext/gen_rst.py > ___ > Modified: svn:mergeinfo > Merged /branches/v1_0_maint/doc/sphinxext/gen_rst.py:r8566 > > > Property changes on: doc/pyplots/README > ___ > Modified: svn:mergeinfo > Merged /branches/v1_0_maint/doc/pyplots/README:r8566 > > > Property changes on: lib/matplotlib/sphinxext/plot_directive.py > ___ > Modified: svn:mergeinfo > Merged > /branches/v1_0_maint/lib/matplotlib/sphinxext/plot_directive.py:r8566 > > > Property changes on: lib/matplotlib/sphinxext/mathmpl.py > ___ > Modified: svn:mergeinfo > Merged /branches/v1_0_maint/lib/matplotlib/sphinxext/mathmpl.py:r8566 > > > Property changes on: lib/matplotlib/sphinxext/only_directives.py > ___ > Modified: svn:mergeinfo > Merged > /branches/v1_0_maint/lib/matplotlib/sphinxext/only_directives.py:r8566 > > > Property changes on: > lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png > ___ > Modified: svn:mergeinfo > Merged > /branches/v1_0_maint/lib/matplotlib/tests/baseline_images/test_spines/spines_axes_positions.png:r8566 > > Index: lib/matplotlib/backends/backend_qt4.py > === > --- lib/matplotlib/backends/backend_qt4.py (revision 8566) > +++ lib/matplotlib/backends/backend_qt4.py (working copy) > @@ -150,6 +150,7 @@ > FigureCanvasBase.enter_notify_event(self, event) > > def leaveEvent(self, event): > +QtGui.QApplication.restoreOverrideCursor()
Re: [matplotlib-devel] question about svnmerge
On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom wrote: > We've seen this before. It seems to have to do with files that were > created after the branching. While I haven't found a solution, it's > been going on a long time and seems to be benign. Ok, thanks. > (And, yeah, making the leap to a DVCS would probably not be a bad > "solution" to this problem.) I was going to ask when the transition might occur, then decided against it. When might the transition occur? -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On 07/20/2010 08:30 AM, Darren Dale wrote: > On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom wrote: >> We've seen this before. It seems to have to do with files that were >> created after the branching. While I haven't found a solution, it's >> been going on a long time and seems to be benign. > > Ok, thanks. > >> (And, yeah, making the leap to a DVCS would probably not be a bad >> "solution" to this problem.) > > I was going to ask when the transition might occur, then decided against it. > > When might the transition occur? Although I would like the transition to occur soon, it might make sense to let the numpy people do it first so that we can take maximum advantage of their systematic approach. I don't know how much of a delay that would entail, but it might provide us with a nice ready-made set of instructions, saving us from some thrashing around. If Mike or Andrew or anyone else proficient in svn and git has the time to make the jump earlier, though, I wouldn't object. I can't help much, if at all, with the transition myself, and I will need some simple recipes (very mpl-specific, like the present instructions for taming the svnmerge monster) for the git workflow. I understand the basic ideas, and work routinely with mercurial, but git will take some practice. (It is possible that I will be able to use hggit, but usually there are gotchas with such translation interfaces, and using the native system ends up being the better course of action.) Eric -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing wrote: > On 07/20/2010 08:30 AM, Darren Dale wrote: >> On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom wrote: >>> We've seen this before. It seems to have to do with files that were >>> created after the branching. While I haven't found a solution, it's >>> been going on a long time and seems to be benign. >> >> Ok, thanks. >> >>> (And, yeah, making the leap to a DVCS would probably not be a bad >>> "solution" to this problem.) >> >> I was going to ask when the transition might occur, then decided against it. >> >> When might the transition occur? > > Although I would like the transition to occur soon, it might make sense > to let the numpy people do it first so that we can take maximum > advantage of their systematic approach. I don't know how much of a > delay that would entail, but it might provide us with a nice ready-made > set of instructions, saving us from some thrashing around. > > If Mike or Andrew or anyone else proficient in svn and git has the time > to make the jump earlier, though, I wouldn't object. I can't help much, > if at all, with the transition myself, and I will need some simple > recipes (very mpl-specific, like the present instructions for taming the > svnmerge monster) for the git workflow. I understand the basic ideas, > and work routinely with mercurial, but git will take some practice. (It > is possible that I will be able to use hggit, but usually there are > gotchas with such translation interfaces, and using the native system > ends up being the better course of action.) I can't speak to what the NumPy folk are doing, but I can say that moving the trunk of one of my small subversion projects over to git was as easy as: 0) Create authors.txt to map svn committers to git committers 1) Checkout svn trunk using git-svn (which results in a git repo) 2) Push to github I was really surprised. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On 07/20/2010 08:59 AM, Ryan May wrote: > On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing wrote: >> On 07/20/2010 08:30 AM, Darren Dale wrote: >>> On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom >>> wrote: We've seen this before. It seems to have to do with files that were created after the branching. While I haven't found a solution, it's been going on a long time and seems to be benign. >>> >>> Ok, thanks. >>> (And, yeah, making the leap to a DVCS would probably not be a bad "solution" to this problem.) >>> >>> I was going to ask when the transition might occur, then decided against it. >>> >>> When might the transition occur? >> >> Although I would like the transition to occur soon, it might make sense >> to let the numpy people do it first so that we can take maximum >> advantage of their systematic approach. I don't know how much of a >> delay that would entail, but it might provide us with a nice ready-made >> set of instructions, saving us from some thrashing around. >> >> If Mike or Andrew or anyone else proficient in svn and git has the time >> to make the jump earlier, though, I wouldn't object. I can't help much, >> if at all, with the transition myself, and I will need some simple >> recipes (very mpl-specific, like the present instructions for taming the >> svnmerge monster) for the git workflow. I understand the basic ideas, >> and work routinely with mercurial, but git will take some practice. (It >> is possible that I will be able to use hggit, but usually there are >> gotchas with such translation interfaces, and using the native system >> ends up being the better course of action.) > > I can't speak to what the NumPy folk are doing, but I can say that > moving the trunk of one of my small subversion projects over to git > was as easy as: Yes, but there is a *lot* more involved in making the transition than just creating a git replica of the svn trunk. Eric > > 0) Create authors.txt to map svn committers to git committers > 1) Checkout svn trunk using git-svn (which results in a git repo) > 2) Push to github > > I was really surprised. > > Ryan > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
Howdy, On Tue, Jul 20, 2010 at 11:48 AM, Eric Firing wrote: > > Although I would like the transition to occur soon, it might make sense > to let the numpy people do it first so that we can take maximum > advantage of their systematic approach. I don't know how much of a > delay that would entail, but it might provide us with a nice ready-made > set of instructions, saving us from some thrashing around. Matthew Brett wrote a set of instructions meant to be easily re-used by any project: http://github.com/matthew-brett/gitwash Here's the one for ipython: http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html The idea is to have one workflow we agree on (for nipy and ipython, so far), but generate docs whose URLs are correct for each project, so people can copy/paste easily from the docs. Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
> Yes, but there is a *lot* more involved in making the transition than > just creating a git replica of the svn trunk. Granted, and I'm probably forgetting many of them. So it is probably a good idea for us to enumerate them here as a checklist when we do migrate. The major issues I am aware of are: * what do to about all the various subdirs of the mpl trunk (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to one tags all with a unique revision number. In git, how do we synchronize between them? Putting them all in the same tree would be monolithic and require huge checkouts. Unlike svn, in git it is difficult/impossible to check out just a subdir (eg trunk/matplotlb) and also commit to it. So we might end up having to informally synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in the CHANGELOG or release notes. * we have to port the sample_data handling. Jouni has shown that the viewvc ETags in sf and github work the same way, so this should be a minor hurdle. * organizational stuff: how do we handle the notion of the central repo? Now that github support "organizations" this should be relatively easy. Andrew and I registered a matplotlib user acct at github and created a gmail acct mplgithub as a central administrator (matplot...@gmail.com was taken, the bastards). Email me offlist if you are interested in obtaining the passwd for the github or gmail admin accts -- but you should probably coordinate with Andrew who is our point person as soon as he re-emerges. * porting the buildbot to work w/ github commits * related: porting the trunkdocs build to work with github commits * how to handle the svn tree at sf -- should it mirror the new github tree or remain stale or simply removed? Please add to the list other issues that need to be handled. Of all these, I'm only concerned philosophically with the first. The others are matters of time and work as people make the transition to the new server. The first seems like a true potential workflow impediment for those who run off svn/git HEAD and analogues. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Tue, Jul 20, 2010 at 7:43 PM, John Hunter wrote: > > The major issues I am aware of are: > > * what do to about all the various subdirs of the mpl trunk > (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to > one tags all with a unique revision number. In git, how do we > synchronize between them? Putting them all in the same tree would be > monolithic and require huge checkouts. Unlike svn, in git it is > difficult/impossible to check out just a subdir (eg trunk/matplotlb) > and also commit to it. So we might end up having to informally > synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in > the CHANGELOG or release notes. Probably using a common tag across repos would be the easiest. Any time you want a known 'sync point', you tag all the relevant repos with the same tag. It then becomes very simple to write a little script that will update checkout a bunch of repos sitting in the same parent directory (each as its own dir, of course) at a common tag. You can make up a convention for these special tags so that they are always named with a given pattern (you could even use r if you wanted). > * organizational stuff: how do we handle the notion of the central > repo? Now that github support "organizations" this should be > relatively easy. Andrew and I registered a matplotlib user acct at > github and created a gmail acct mplgithub as a central administrator > (matplot...@gmail.com was taken, the bastards). Email me offlist if > you are interested in obtaining the passwd for the github or gmail > admin accts -- but you should probably coordinate with Andrew who is > our point person as soon as he re-emerges. No need. Organizations let you designate more than one 'owner', so you can mark more than one person with full admin privileges without having to give out the password around. I recently converted the extra ipython account to an organization, added Brian Granger as a second 'owner', and that's it. You can then make as many teams and repos as you want within an organization. The github org model is fairly simple but very effective (much nicer than how launchpad uses teams). > * porting the buildbot to work w/ github commits > > * related: porting the trunkdocs build to work with github commits > > * how to handle the svn tree at sf -- should it mirror the new github > tree or remain stale or simply removed? I would freeze it during a transition period and later on make a static backup of teh repo dump somewhere for historical purposes (and just in case, disk is cheap). I would then nuke it for simplicity of administration, since on github people can still use svn if they want to track a git repo: http://github.com/blog/626-announcing-svn-support I should note that I have not used this in practice, but a quick and dirty test with the ipython repo seems to work (you just get the master git branch though): amirbar[junk]> svn checkout http://svn.github.com/ipython/ipython.git [...] amirbar[junk]> cd ipython.git/ amirbar[ipython.git]> svn info Path: . URL: http://svn.github.com/ipython/ipython.git Repository Root: http://svn.github.com/ipython/ipython.git Repository UUID: e94b1212-8258-e27c-589c-ce57b7db7bff Revision: 2611 Node Kind: directory Schedule: normal Last Changed Author: fernando.perez Last Changed Rev: 2611 > Please add to the list other issues that need to be handled. > > Of all these, I'm only concerned philosophically with the first. The > others are matters of time and work as people make the transition to > the new server. The first seems like a true potential workflow > impediment for those who run off svn/git HEAD and analogues. Others with more git expertise may suggest a different workflow, but for that the tags approach, along with a couple of simple script helpers to make creation/checkout of these tags a one-line operation, seems like it should do the job. Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
