matplotlib-devel Mailing List for matplotlib (Page 3)

On 7/20/10 8:06 PM, Fernando Perez wrote:
> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter<jd...@gm...>  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 rNNNN if you
> wanted).
>    
We could also make a meta repository that uses git submodules (somewhat 
akin to svn externals). Each commit in a repo that links to submodules 
specifies a specific revision of the submodule repo, so this meta 
repository would be a fairly natural way of linking across several 
repositories at specific revisions. That being said, a convention to 
simply use the standard git tags would also work fine, and wouldn't 
require people to learn git submodules. So, it's really a question of 
sticking to a convention (that has a lesser learning curve) or using a 
new set of commands that would more or less do exactly what we want, but 
would have to be learned. I'm agnostic on the issue.


>> * 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
>> (mat...@gm... 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).
>    
I went ahead and switched our github.com/matplotlib account into an 
organization when github announced organization support a few weeks ago. 
Just now I added the jdh2358 and fperez users into the matplotlib 
owner's team.

(And I'm trying to re-emerge, I promise...)


>> * porting the buildbot to work w/ github commits
>>      
I should be able to handle that fairly easily. I do it for my other 
projects. (Bigger on my buildbot priority list is stopping the annoying 
occasional config directory multi-process conflict.


>> * related: porting the trunkdocs build to work with github commits
>>      
As this is run by the buildbot, it should be taken care of with the above.


For me, the main remaining issue is how do we want to pull the svn repo 
into git? Right now, the unofficial git repo at 
github.com/astraw/matplotlib is too big for my likes because it has a 
lot of stuff besides the matplotlib source code and its history. Before 
moving to an official git repository, I think we should prune down the 
main repository to just the source code files, their history, and no 
binary files. But then that leaves the question of what to do with the 
binary files.

-Andrew

On Tue, Jul 20, 2010 at 7:43 PM, John Hunter <jd...@gm...> 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 rNNNN 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
> (mat...@gm... 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

> 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
(mat...@gm... 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

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

On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> I've been keeping more or less up on the .11 development ipython,
> under Ubuntu 9.10 (10.4 when I get around to it...).  For each of the
> backends I do the following in an interactive session that starts with
> no profile or -pylab or anything::
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('whateverbackend')
>
> from matplotlib.pyplot import scatter,show
> from numpy.random import randn
>
> %gui -a whateverguiname

Aha!

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.

Eric

>
> scatter(*randn(2,100))
> show()
>
> that "%gui" bit is the new trick in ipython .11 that you use to
> initiate the event loop, so that the --pylab flag is superfluous. I
> try it both with, and without that line.  Below are my results for the
> various backends:
>
> *wx:
> w/o %gui: nothing appears until show(),  show() correctly blocks until
> the window closes.
> w/ %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
>
> *qt4:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(),  show() does NOT block.
>
> *gtk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
> w/ %gui: identical behavior
>
> *tk:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
>
>
> So it seems the interactive case of using the %gui magic works in all
> cases for interactive mode, but show is still not consistent in
> ipython .11 ...
>
> On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing<ef...@ha...>  wrote:
>> All,
>>
>> John noticed that my changes to show() prior to 1.0 had broken a use
>> case with tkagg and ipython -pylab, so I fixed that yesterday in
>> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
>> refactoring to try to make show() behavior more understandable across
>> backends, and easier to modify if necessary.  Specifically, we need to
>> work with the ipython people to make sure the ipython 0.11 refactoring
>> of interactive support works as intended.  I haven't done any testing
>> with the development version of 0.11 yet.
>>
>> At present, all interactive backends start a blocking mainloop only if
>> ipython has not attached a _needmain flag to show(), and if mpl is not
>> in interactive mode.
>>
>> Under all script and ipython conditions, multiple calls to show in a
>> session or script are permitted.
>>
>> All interactive backends behave the same when run with ipython -pylab,
>> version 0.10: show is non-blocking, regardless of whether it is executed
>> on the command line (completely unnecessary) or is found in a script.
>>
>> Under raw ipython (no -pylab or other threading flags provided), with
>> mpl in non-interactive mode, all backends behave the same: show() is
>> needed and blocks, but may be called multiple times.  With mpl in
>> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
>> qt4agg behave the same as in -pylab mode, so there so no longer any real
>> need for the special threading modes; but wx* and qtagg do not behave in
>> a useful way, so they still need the special threading.
>>
>> All of the above is based on quick tests with my own system, ubuntu
>> 10.04.  I expect it will be the same for other supported systems, with
>> the exception that behavior in raw ipython mode, with mpl in interactive
>> mode, may not work with some earlier versions of gui toolkits--but I
>> suspect we will not actually encounter this for supported versions.
>>
>> I have not built or tested anything under Windows or OS X.  For the
>> latter, testing of the macosx backend is needed.  I expect cocoaagg to
>> behave differently than the others, but no differently than it did
>> before my changes.
>>
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> I've been keeping more or less up on the .11 development ipython,
> under Ubuntu 9.10 (10.4 when I get around to it...).  For each of the
> backends I do the following in an interactive session that starts with
> no profile or -pylab or anything::
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('whateverbackend')
>
> from matplotlib.pyplot import scatter,show
> from numpy.random import randn
>
> %gui -a whateverguiname
>
> scatter(*randn(2,100))
> show()
>
> that "%gui" bit is the new trick in ipython .11 that you use to
> initiate the event loop, so that the --pylab flag is superfluous. I
> try it both with, and without that line.  Below are my results for the
> various backends:
>
> *wx:
> w/o %gui: nothing appears until show(),  show() correctly blocks until
> the window closes.
> w/ %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
>
> *qt4:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(),  show() does NOT block.
>
> *gtk:
> w/o %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
> w/ %gui: identical behavior
>
> *tk:
> w/o %gui: the window appears on the call to scatter(), show()  blocks
> until the window closes.
> w/ %gui: the window appears on the call to scatter(), show() blocks
> until the window closes, and continues to block until ctrl-c is
> pressed in the ipython interpreter.
>
>
> So it seems the interactive case of using the %gui magic works in all
> cases for interactive mode, but show is still not consistent in
> ipython .11 ...

Erik,

Thanks for the testing.  I was also starting to test with ipython 0.11 
yesterday, and had reached the opposite conclusion--but I was using a 
different procedure.  So I will track down the difference.  My results 
were quite different...

Please verify: were you using the latest mpl from svn?

Eric

>
> On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing<ef...@ha...>  wrote:
>> All,
>>
>> John noticed that my changes to show() prior to 1.0 had broken a use
>> case with tkagg and ipython -pylab, so I fixed that yesterday in
>> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
>> refactoring to try to make show() behavior more understandable across
>> backends, and easier to modify if necessary.  Specifically, we need to
>> work with the ipython people to make sure the ipython 0.11 refactoring
>> of interactive support works as intended.  I haven't done any testing
>> with the development version of 0.11 yet.
>>
>> At present, all interactive backends start a blocking mainloop only if
>> ipython has not attached a _needmain flag to show(), and if mpl is not
>> in interactive mode.
>>
>> Under all script and ipython conditions, multiple calls to show in a
>> session or script are permitted.
>>
>> All interactive backends behave the same when run with ipython -pylab,
>> version 0.10: show is non-blocking, regardless of whether it is executed
>> on the command line (completely unnecessary) or is found in a script.
>>
>> Under raw ipython (no -pylab or other threading flags provided), with
>> mpl in non-interactive mode, all backends behave the same: show() is
>> needed and blocks, but may be called multiple times.  With mpl in
>> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
>> qt4agg behave the same as in -pylab mode, so there so no longer any real
>> need for the special threading modes; but wx* and qtagg do not behave in
>> a useful way, so they still need the special threading.
>>
>> All of the above is based on quick tests with my own system, ubuntu
>> 10.04.  I expect it will be the same for other supported systems, with
>> the exception that behavior in raw ipython mode, with mpl in interactive
>> mode, may not work with some earlier versions of gui toolkits--but I
>> suspect we will not actually encounter this for supported versions.
>>
>> I have not built or tested anything under Windows or OS X.  For the
>> latter, testing of the macosx backend is needed.  I expect cocoaagg to
>> behave differently than the others, but no differently than it did
>> before my changes.
>>
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

On 07/19/2010 11:10 AM, Sandro Tosi wrote:
> Hello,
> you know this question might seems strange, but I'd like to avoid some
> examples to be built when creating documentation.
>
> Those examples are the one using mpl.cbook.get_sample_data() to
> retrieve data files from the remote svn. In Debian we are not allowed
> to prepare a package that downloads "stuff" from the web, so I have to
> avoid this.

Good policy!

>
> The fastest solution I see is to actually exclude them from the list
> of the examples to build (but still install them, for users to use),
> but I didn't understand how :)
>
> Another solution would be for you to ship those datafile into the
> released tarball, so that it's all consistent and then point the
> example to those files, but how? if you find this in some way
> unacceptable, I can also download those files separately and add them
> when preparing the Debian package, but I have to find a way to tell
> get_sample_data() to point to that location...
>
> ...and so I'm asking you: what would you feel to be the best solution?

I think we should include any necessary data, and also eliminate the 
downloading from the examples run by the standard backend_driver.  The 
caching doesn't seem to work right, and there are long timeouts.  This 
was a problem for me recently when I was out on a ship, working on mpl 
on a computer without a live internet connection.

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.

Eric

>
> Thanks in advance for your help and suggestions,

Hello,
you know this question might seems strange, but I'd like to avoid some
examples to be built when creating documentation.

Those examples are the one using mpl.cbook.get_sample_data() to
retrieve data files from the remote svn. In Debian we are not allowed
to prepare a package that downloads "stuff" from the web, so I have to
avoid this.

The fastest solution I see is to actually exclude them from the list
of the examples to build (but still install them, for users to use),
but I didn't understand how :)

Another solution would be for you to ship those datafile into the
released tarball, so that it's all consistent and then point the
example to those files, but how? if you find this in some way
unacceptable, I can also download those files separately and add them
when preparing the Debian package, but I have to find a way to tell
get_sample_data() to point to that location...

...and so I'm asking you: what would you feel to be the best solution?

Thanks in advance for your help and suggestions,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...).  For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::

import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')

from matplotlib.pyplot import scatter,show
from numpy.random import randn

%gui -a whateverguiname

scatter(*randn(2,100))
show()

that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line.  Below are my results for the
various backends:

*wx:
w/o %gui: nothing appears until show(),  show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show()  blocks
until the window closes.

*qt4:
w/o %gui: the window appears on the call to scatter(), show()  blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(),  show() does NOT block.

*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior

*tk:
w/o %gui: the window appears on the call to scatter(), show()  blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.


So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...

On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing <ef...@ha...> wrote:
> All,
>
> John noticed that my changes to show() prior to 1.0 had broken a use
> case with tkagg and ipython -pylab, so I fixed that yesterday in
> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
> refactoring to try to make show() behavior more understandable across
> backends, and easier to modify if necessary.  Specifically, we need to
> work with the ipython people to make sure the ipython 0.11 refactoring
> of interactive support works as intended.  I haven't done any testing
> with the development version of 0.11 yet.
>
> At present, all interactive backends start a blocking mainloop only if
> ipython has not attached a _needmain flag to show(), and if mpl is not
> in interactive mode.
>
> Under all script and ipython conditions, multiple calls to show in a
> session or script are permitted.
>
> All interactive backends behave the same when run with ipython -pylab,
> version 0.10: show is non-blocking, regardless of whether it is executed
> on the command line (completely unnecessary) or is found in a script.
>
> Under raw ipython (no -pylab or other threading flags provided), with
> mpl in non-interactive mode, all backends behave the same: show() is
> needed and blocks, but may be called multiple times.  With mpl in
> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
> qt4agg behave the same as in -pylab mode, so there so no longer any real
> need for the special threading modes; but wx* and qtagg do not behave in
> a useful way, so they still need the special threading.
>
> All of the above is based on quick tests with my own system, ubuntu
> 10.04.  I expect it will be the same for other supported systems, with
> the exception that behavior in raw ipython mode, with mpl in interactive
> mode, may not work with some earlier versions of gui toolkits--but I
> suspect we will not actually encounter this for supported versions.
>
> I have not built or tested anything under Windows or OS X.  For the
> latter, testing of the macosx backend is needed.  I expect cocoaagg to
> behave differently than the others, but no differently than it did
> before my changes.
>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Sun, Jul 18, 2010 at 6:16 PM, Benjamin Root <ben...@ou...> wrote:
> A few corrections.  First, I wrong, it is unusual.  The second axes that I
> noticed in a 2d case came from a colorbar being added.  Second, in the 3d
> case, it was the Axes3DSubplot object being added twice, not the regular
> object like I originally said.
>
> The cause of this is due to the Axes3D initializer adding itself to the
> figure object being passed in.  This initializer is called when
> add_subplot() is called, so add_subplot also adds the axes when it is
> finished making it.  For normal projections, the initializer does not add
> itself to the axes.
>
> Removing the add_axes in the Axes3D initializer would "solve" the issue
> outright, however, there are plenty of legacy code where Axes3D is called
> with a figure passed in in order to create the axes, and this would break
> that use pattern.

I think the fact that add_axes will just blindly add a duplicate axes
is a bug. So why not have add_axes do something like the following:

if ax not in axes_list:
  axes_list.append(ax)
  <more stuff>

Anyone see anything wrong with this approach?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 16, 2010 at 10:21 AM, Ryan Wagner <Rya...@ro...> wrote:
> (Michael Droettboom)
>
>>> The display at the bottom that says "Cursor at: X, Y" is in pixels, not
>>> in
>
>>> data units. ?It would be great if this could display data units, though
>
>>> being general enough to support custom scales (eg. log) and projections
>>> (eg.
>
>>> polar) may be tricky without making a round-trip to the server.
>
>
>
> (Simon Ratcliffe)
>
>>As you mentioned, the trick is in giving the client some view on how
>
>>pixels should map to data values without fetching these for each mouse
>
>>movement. For simple cartesian plots this is probably pretty
>
>>straightforward. It is something we need to get working for our
>
>>internal use so it should get solved at some stage.
>
>
>
> I have accomplished this in one of my applications as follows:
>
>
>
> Axes =figure.get_axes()
>
> #The transform used in this axis is Composite Generic Transform, so get the
> two affine transformation matricies
>
> MatrixA  = axes[0].transData.inverted()._a.get_matrix()
>
> MatrixB  = axes[0].transData.inverted()._b.get_matrix()
[...]
> The simple affine transformation can be accomplished by leaving off the
> MatrixB part. Non affine will probably be similar to the above followed by a
> log or exponential operation.

The other option, which would be somewhat less accurate but would
avoid reimplementing every projection in javascript, would be to build
a mesh (e.g., a grid) over the client's viewport region, sample the
value of the projection at each point on the grid, send that to the
client, and then let the client do linear interpolation to estimate
points in between grid points.

-- Nathaniel

I noticed some odd behavior when trying to set ticks on 3d plots made
using mplot3d.Axes3D ... specifically, if you tries to access any of
the 3D axes and change the ticks, it would result in a plot all
squashed to one side (indicating some sort of projection problem).
After a bit of digging, I discovered the source of the problem:
axis.XAxis, the base of the 3D Axis class, calls set_view_interval,
which is not overridden in mplot3d.axis3d.Axis, causing the wrong
interval to get the range assigned when ticks were added.  So the
solution was to implement set_view_interval on the 3D Axis.  That fix
is attached as a diff against the current svn in mpl3d-ticks-fix.diff
.  Now setting ticks seems to work just fine, so I've included another
diff that additionally implements set_?ticks3d and get_?ticks3d
methods for Axes3D - that's attached as
mpl3d-ticks-fix-add-methods.diff .

-- 
Erik Tollerud

On Sun, Jul 18, 2010 at 3:35 PM, Benjamin Root <ben...@ou...> wrote:

> On Sun, Jul 18, 2010 at 1:40 PM, Benjamin Root <ben...@ou...> wrote:
>
>> On Sun, Jul 18, 2010 at 12:05 PM, Benjamin Root <ben...@ou...> wrote:
>>
>>>
>>>
>>> On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva <js...@fc...>wrote:
>>>
>>>> On 07/18/2010 04:58 AM, H Mike Duan wrote:
>>>> > Hi,
>>>> >
>>>> > There seems to be a problem in how 3D surfaces and lines are rendered
>>>> > in mplot3d. The following is a simple script that plots a yellow
>>>> > sphere, a blue wireframe on the surface of the sphere, and a red
>>>> > wireframe outside the sphere. The semi-transparent yellow sphere is
>>>> > rendered beautifully. The blue wireframe can only be seen with certain
>>>> > viewing angles. The red wireframe is seen all the time, but its part
>>>> > that is supposedly behind the sphere appears in front of the sphere.
>>>> > Did I do something wrong or is it a bug of mplot3d? I am using
>>>> > matplotlib 1.0.0 on Mac OS X 10.6. Thanks!
>>>> >
>>>> > -Mike
>>>>
>>>> Additionally the presented example (after adding a plt.show()) will give
>>>> the appended traceback if the sphere is panned around. That won't happen
>>>> if the line
>>>>
>>>> ax = fig.gca(projection='3d')
>>>>
>>>> is replaced with:
>>>>
>>>> ax = Axes3D(fig)
>>>>
>>>> Latest mpl svn (r8565), OS: Debian testing.
>>>>
>>>> Regards,
>>>> João Luís
>>>>
>>>>
>>>>
>>>> Traceback (most recent call last):
>>>>   File
>>>>
>>>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py",
>>>> line 253, in button_release_event
>>>>     FigureCanvasBase.button_release_event(self, x, y, event.button,
>>>> guiEvent=event)
>>>>   File
>>>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>>>> line 1603, in button_release_event
>>>>     self.callbacks.process(s, event)
>>>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
>>>> line 262, in process
>>>>     proxy(*args, **kwargs)
>>>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
>>>> line 188, in __call__
>>>>     return mtd(*args, **kwargs)
>>>>   File
>>>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>>>> line 2575, in release_pan
>>>>     a.end_pan()
>>>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py",
>>>> line 2788, in end_pan
>>>>     del self._pan_start
>>>> AttributeError: _pan_start
>>>>
>>>>
>>>>
>>> Joao,
>>>
>>> Yes, there is a known issue with objects not properly rendering when
>>> viewed at certain angles.  How to go about solving this seems to be a
>>> difficult one to figure out.
>>>
>>> Also, thanks for pointing out the difference between calling gca() and
>>> creating the Axes3D object directly.  I am not sure exactly why there would
>>> be a difference, but I will look into it right away.
>>>
>>> Ben Root
>>>
>>
>> Ok, it appears that the .add_subplot() or .gca() approach to creating 3D
>> axes appears to be adding the axes twice to the figure's canvas.  Therefore,
>> while the callback to press_pan() is connected only once, the function loops
>> over all the axes in the figure, and connecting end_pan() twice.
>>
>> The end_pan() function deletes _pan_start, so the second subsequent call
>> is trying to delete something that doesn't exist, thereby causing the
>> traceback.
>>
>> So, now the question remains, why is the Axes3D object added twice to the
>> figure?
>>
>> Ben Root
>>
>
> Further investigation reveals that this actually isn't all that unusual.
> If one were to do the same thing, but for a 2d plot, one would find that a
> figure's self.axes list would contain a SubplotAxes object, and a regular
> Axes object.  However, in our 3d case, it appears that instead of the
> SubplotAxes object being placed, the regular object is being placed instead.
>
> Hmmm, curiouser, and curiouser...
>
> Ben Root
>


A few corrections.  First, I wrong, it is unusual.  The second axes that I
noticed in a 2d case came from a colorbar being added.  Second, in the 3d
case, it was the Axes3DSubplot object being added twice, not the regular
object like I originally said.

The cause of this is due to the Axes3D initializer adding itself to the
figure object being passed in.  This initializer is called when
add_subplot() is called, so add_subplot also adds the axes when it is
finished making it.  For normal projections, the initializer does not add
itself to the axes.

Removing the add_axes in the Axes3D initializer would "solve" the issue
outright, however, there are plenty of legacy code where Axes3D is called
with a figure passed in in order to create the axes, and this would break
that use pattern.

Not exactly sure how to proceed here.

Ben Root

On Sun, Jul 18, 2010 at 3:33 PM, H Mike Duan <h.m...@gm...> wrote:

> Ben,
>
> > Yes, there is a known issue with objects not properly rendering when
> viewed
> > at certain angles.  How to go about solving this seems to be a difficult
> one
> > to figure out.
>
> I think the problem is that mplot3d can't reliably determine which
> parts of the surfaces or lines are in front and which are behind. This
> is especially clear in the test example where the yellow sphere
> doesn't cover parts of the red wire frame. The issue that some objects
> can only be seen at certain angles is likely to be a consequence of
> this bug.
>
> I want to use mplot3d to visualize my simulations. Is it your opinion
> that this bug can't be fixed in a short term? If so, I'll have to
> explore other options. Thanks!
>
> -Mike
>

My guess is yes, this can not be fixed in a short term, but I am very new to
mplot3d, so I don't know for sure.

Ben

On Sun, Jul 18, 2010 at 1:40 PM, Benjamin Root <ben...@ou...> wrote:

> On Sun, Jul 18, 2010 at 12:05 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva <js...@fc...> wrote:
>>
>>> On 07/18/2010 04:58 AM, H Mike Duan wrote:
>>> > Hi,
>>> >
>>> > There seems to be a problem in how 3D surfaces and lines are rendered
>>> > in mplot3d. The following is a simple script that plots a yellow
>>> > sphere, a blue wireframe on the surface of the sphere, and a red
>>> > wireframe outside the sphere. The semi-transparent yellow sphere is
>>> > rendered beautifully. The blue wireframe can only be seen with certain
>>> > viewing angles. The red wireframe is seen all the time, but its part
>>> > that is supposedly behind the sphere appears in front of the sphere.
>>> > Did I do something wrong or is it a bug of mplot3d? I am using
>>> > matplotlib 1.0.0 on Mac OS X 10.6. Thanks!
>>> >
>>> > -Mike
>>>
>>> Additionally the presented example (after adding a plt.show()) will give
>>> the appended traceback if the sphere is panned around. That won't happen
>>> if the line
>>>
>>> ax = fig.gca(projection='3d')
>>>
>>> is replaced with:
>>>
>>> ax = Axes3D(fig)
>>>
>>> Latest mpl svn (r8565), OS: Debian testing.
>>>
>>> Regards,
>>> João Luís
>>>
>>>
>>>
>>> Traceback (most recent call last):
>>>   File
>>>
>>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py",
>>> line 253, in button_release_event
>>>     FigureCanvasBase.button_release_event(self, x, y, event.button,
>>> guiEvent=event)
>>>   File
>>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>>> line 1603, in button_release_event
>>>     self.callbacks.process(s, event)
>>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
>>> line 262, in process
>>>     proxy(*args, **kwargs)
>>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
>>> line 188, in __call__
>>>     return mtd(*args, **kwargs)
>>>   File
>>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>>> line 2575, in release_pan
>>>     a.end_pan()
>>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py",
>>> line 2788, in end_pan
>>>     del self._pan_start
>>> AttributeError: _pan_start
>>>
>>>
>>>
>> Joao,
>>
>> Yes, there is a known issue with objects not properly rendering when
>> viewed at certain angles.  How to go about solving this seems to be a
>> difficult one to figure out.
>>
>> Also, thanks for pointing out the difference between calling gca() and
>> creating the Axes3D object directly.  I am not sure exactly why there would
>> be a difference, but I will look into it right away.
>>
>> Ben Root
>>
>
> Ok, it appears that the .add_subplot() or .gca() approach to creating 3D
> axes appears to be adding the axes twice to the figure's canvas.  Therefore,
> while the callback to press_pan() is connected only once, the function loops
> over all the axes in the figure, and connecting end_pan() twice.
>
> The end_pan() function deletes _pan_start, so the second subsequent call is
> trying to delete something that doesn't exist, thereby causing the
> traceback.
>
> So, now the question remains, why is the Axes3D object added twice to the
> figure?
>
> Ben Root
>

Further investigation reveals that this actually isn't all that unusual.  If
one were to do the same thing, but for a 2d plot, one would find that a
figure's self.axes list would contain a SubplotAxes object, and a regular
Axes object.  However, in our 3d case, it appears that instead of the
SubplotAxes object being placed, the regular object is being placed instead.

Hmmm, curiouser, and curiouser...

Ben Root

Ben,

> Yes, there is a known issue with objects not properly rendering when viewed
> at certain angles.  How to go about solving this seems to be a difficult one
> to figure out.

I think the problem is that mplot3d can't reliably determine which
parts of the surfaces or lines are in front and which are behind. This
is especially clear in the test example where the yellow sphere
doesn't cover parts of the red wire frame. The issue that some objects
can only be seen at certain angles is likely to be a consequence of
this bug.

I want to use mplot3d to visualize my simulations. Is it your opinion
that this bug can't be fixed in a short term? If so, I'll have to
explore other options. Thanks!

-Mike