matplotlib-devel Mailing List for matplotlib

Howdy,

On Tue, Jul 20, 2010 at 11:48 AM, Eric Firing <ef...@ha...> 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

On 07/20/2010 08:59 AM, Ryan May wrote:
> On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing<ef...@ha...>  wrote:
>> On 07/20/2010 08:30 AM, Darren Dale wrote:
>>> On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom<md...@st...>    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
>

On Tue, Jul 20, 2010 at 1:48 PM, Eric Firing <ef...@ha...> wrote:
> On 07/20/2010 08:30 AM, Darren Dale wrote:
>> On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom<md...@st...>  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

On 07/20/2010 08:30 AM, Darren Dale wrote:
> On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom<md...@st...>  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

On Tue, Jul 20, 2010 at 12:33 PM, Michael Droettboom <md...@st...> 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?

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]
> darren@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 '.':
> U    CHANGELOG
> U    lib/matplotlib/backends/backend_qt4.py
>
> property 'svnmerge-integrated' set on '.'
>
>
> [~/Projects/matplotlib]
> darren@waterhouse $ svn commit -F svnmerge-commit-message.txt
> Sending        .
> Sending        CHANGELOG
> Sending        doc/pyplots/README
> Sending        doc/sphinxext/gen_gallery.py
> Sending        doc/sphinxext/gen_rst.py
> Sending        examples/misc/multiprocess.py
> Sending        examples/mplot3d/contour3d_demo.py
> Sending        examples/mplot3d/contourf3d_demo.py
> Sending        examples/mplot3d/polys3d_demo.py
> Sending        examples/mplot3d/scatter3d_demo.py
> Sending        examples/mplot3d/surface3d_demo.py
> Sending        examples/mplot3d/wire3d_demo.py
> Sending        lib/matplotlib/backends/backend_qt4.py
> Sending        lib/matplotlib/sphinxext/mathmpl.py
> Sending        lib/matplotlib/sphinxext/only_directives.py
> Sending        lib/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]
> darren@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: examples/mplot3d/polys3d_demo.py
> ___________________________________________________________________
> Modified: svn:mergeinfo
>     Merged /branches/v1_0_maint/examples/mplot3d/polys3d_demo.py:r8566
>
>
> Property changes on: examples/mplot3d/wire3d_demo.py
> ___________________________________________________________________
> Modified: svn:mergeinfo
>     Merged /branches/v1_0_maint/examples/mplot3d/wire3d_demo.py:r8566
>
>
> Property changes on: examples/mplot3d/surface3d_demo.py
> ___________________________________________________________________
> Modified: svn:mergeinfo
>     Merged /branches/v1_0_maint/examples/mplot3d/surface3d_demo.py:r8566
>
>
> Property changes on: examples/mplot3d/contour3d_demo.py
> ___________________________________________________________________
> Modified: svn:mergeinfo
>     Merged /branches/v1_0_maint/examples/mplot3d/contour3d_demo.py:r8566
>
>
> Property changes on: examples/misc/multiprocess.py
> ___________________________________________________________________
> Modified: svn:mergeinfo
>     Merged /branches/v1_0_maint/examples/misc/multiprocess.py:r8566
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    

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.klukas@gmail | jeffyklukas@aim | jeffklukas@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')

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]
darren@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 '.':
U    CHANGELOG
U    lib/matplotlib/backends/backend_qt4.py

property 'svnmerge-integrated' set on '.'


[~/Projects/matplotlib]
darren@waterhouse $ svn commit -F svnmerge-commit-message.txt
Sending        .
Sending        CHANGELOG
Sending        doc/pyplots/README
Sending        doc/sphinxext/gen_gallery.py
Sending        doc/sphinxext/gen_rst.py
Sending        examples/misc/multiprocess.py
Sending        examples/mplot3d/contour3d_demo.py
Sending        examples/mplot3d/contourf3d_demo.py
Sending        examples/mplot3d/polys3d_demo.py
Sending        examples/mplot3d/scatter3d_demo.py
Sending        examples/mplot3d/surface3d_demo.py
Sending        examples/mplot3d/wire3d_demo.py
Sending        lib/matplotlib/backends/backend_qt4.py
Sending        lib/matplotlib/sphinxext/mathmpl.py
Sending        lib/matplotlib/sphinxext/only_directives.py
Sending        lib/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]
darren@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: examples/mplot3d/polys3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/polys3d_demo.py:r8566


Property changes on: examples/mplot3d/wire3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/wire3d_demo.py:r8566


Property changes on: examples/mplot3d/surface3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/surface3d_demo.py:r8566


Property changes on: examples/mplot3d/contour3d_demo.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/mplot3d/contour3d_demo.py:r8566


Property changes on: examples/misc/multiprocess.py
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/v1_0_maint/examples/misc/multiprocess.py:r8566

On Mon, Jul 19, 2010 at 5:22 PM, Eric Firing <ef...@ha...> wrote:
> It would be OK to retain some examples with live downloading, but they
> should not be required for doc generation or for basic testing of mpl.
> They don't contribute anything essential to either.

The primary motivation for the get_sample_data code arose from my
observation that the gallery had become extremely popular, and
appeared to be the way most people learned/experimented with mpl.  I
wanted some way to make it easy for a user to download and run any
example from the gallery.  One could say, "grab this tarball or
zipfile and unpack it before running this example", but getting the
relative paths right, especially on windows, is difficult for new
users.

I completely agree that we can and should support a mechanism for
users / distributors who want to circumvent the download phase.  One
could have an rc param "sampledata.localonly" that would check the mpl
config dir for a sample_data dir (which is where it looks already) and
forgo all the revision control stuff: if the file is there load it,
else raise.  Or we could support a special MPLSAMPLEDATA env var which
could point to a dir or even a tar/zip file.  Then one could get a svn
co of sample_data, zip it up when going out to sea or packaging mpl,
and configure mpl, presumably via the rc mechanism or env vars to use
the hardcopy.

JDH

Hey guys,

On Mon, Jul 19, 2010 at 4:07 PM, Eric Firing <ef...@ha...> wrote:
>
> Please leave out the -a.  It is harmful, not helpful, for mpl.  This may
> mean we need to change mpl and/or ipython, or the documentation, to
> prevent problems with the -a option; but I think you will find that if
> you leave out that option, the behavior will be more consistent and the
> need for Ctrl-C will go away.  Without %gui, there will still be an
> inconsistency between wx and the others--but that's what the %gui magic
> is for, to make wx use PyOS_InputHook like the others.

I just wanted to say thanks a LOT for this testing.  Right now we're
not quite in the gui code, but it's *very* useful for us to have this
information.  And please keep in mind that if you find out that from
the ipython side we're doing something silly/backwards regarding this,
we're more than happy to change it.  We ultimately want the gui
integration to be as painless as possible.

One extra twist to consider: we're moving to a 2-process model for
most of ipython, so that user interface and code execution live in
separate processes.  It will continue to be possible to use a
one-process ipython, but we think most users will prefer the
two-process model.  One quirk there will be that %gui now uses
PyOSInputHook to talk to the GUI event loop, but this is only called
by Python if stdin is waiting for input.  In a server process (like we
are starting to develop), there is no interactive input (the input
comes over a socket) so we'll need to worry about letting the GUI
event loop work while keeping the network event loop also responsive.

As our picture becomes clearer we'll make sure to update you folks as
well, so we can work from both ends (ipython/mpl) to ensure a good
end-user experience with minimal fuss and all relevant backends.

Cheers,

f