matplotlib-devel Mailing List for matplotlib

On Thu, Jul 29, 2010 at 6:17 PM, Benjamin Root <ben...@ou...> wrote:
> As a side-note, it looks like various files that have been changed due to
> svnmerge.py are still showing themselves as having their properties
> modified. Is this ok?
Yes, for some reason some of the files, like axes3d examples, are
always tagged with property changes on svn merges. It's a nuisance.
but harmless. In the handling of weights vs x, I notice in some
places we call np.array and others np.asarray. Shouldn't we be using
asarray in all of these cases, eg
Index: lib/matplotlib/axes.py
===================================================================
--- lib/matplotlib/axes.py	(revision 8606)
+++ lib/matplotlib/axes.py	(working copy)
@@ -7401,11 +7401,13 @@
 **kwargs):
 """
 call signature::
+
+ def hist(x, bins=10, range=None, normed=False, weights=None,
+ cumulative=False, bottom=None, histtype='bar', align='mid',
+ orientation='vertical', rwidth=None, log=False,
+ color=None, label=None,
+ **kwargs):
- hist(x, bins=10, range=None, normed=False, cumulative=False,
- bottom=None, histtype='bar', align='mid',
- orientation='vertical', rwidth=None, log=False, **kwargs)
-
 Compute and draw the histogram of *x*. The return value is a
 tuple (*n*, *bins*, *patches*) or ([*n0*, *n1*, ...], *bins*,
 [*patches0*, *patches1*,...]) if the input contains multiple
@@ -7567,7 +7569,7 @@
 'this looks transposed (shape is %d x %d)' % x.shape[::-1])
 else:
 # multiple hist with data of different length
- x = [np.array(xi) for xi in x]
+ x = [np.asarray(xi) for xi in x]
 nx = len(x) # number of datasets
@@ -7582,7 +7584,7 @@
 # We need to do to 'weights' what was done to 'x'
 if weights is not None:
 if isinstance(weights, np.ndarray) or not iterable(weights[0]) :
- w = np.array(weights)
+ w = np.asarray(weights)
 if w.ndim == 2:
 w = w.T
 elif w.ndim == 1:
@@ -7590,7 +7592,7 @@
 else:
 raise ValueError("weights must be 1D or 2D")
 else:
- w = [np.array(wi) for wi in weights]
+ w = [np.asarray(wi) for wi in weights]
 if len(w) != nx:
 raise ValueError('weights should have the same shape as x')

I don't think this is just an issue of "bbox_inches" option. For
example, if you create an axes of rect=[0,0,1,1] and save the figure
(w/o bbox_inches option), you will see a similar behavior.
Also, I believe that the result depends on the backends.
I think this kind of issue is quite difficult to resolve and I doubt
if this will be solved anytime soon.
Any contribution will be very much appreciated.
Regards,
-JJ
On Sat, Jul 31, 2010 at 5:48 AM, Damon McDougall
<D.M...@wa...> wrote:
> Aha! Even without the text, i.e. setting label1On = False for all the major ticks, the behaviour I see is that with bbox_inches = 'tight' and pad_inches = 0.0 I get the saved figure which includes the black border line for the bottom and left edges, but not the top and right edges. This may have something to do with it. Maybe it's an issue with the bounding box not being 'inclusive' and leaving out the end points?
>
> Regards,
> -- Damon
>
> --------------------------
> Damon McDougall
> Mathematics Institute
> University of Warwick
> Coventry
> CV4 7AL
> d.m...@wa...
>
>
>
> On 30 Jul 2010, at 20:33, Eric Firing wrote:
>
>> On 07/30/2010 06:32 AM, Damon McDougall wrote:
>>> Hmm, it seems as though tick labels get clipped on the top and on the right when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this behaviour. Is there perhaps a bug in Bbox.union that's causing this?
>>>
>>
>> Not likely. Much more likely is a problem in calculating the rendered
>> size of the text.
>>
>> Eric
>>
>>> Regards,
>>> -- Damon
>>>
>>> --------------------------
>>> Damon McDougall
>>> Mathematics Institute
>>> University of Warwick
>>> Coventry
>>> CV4 7AL
>>> d.m...@wa...
>>>
>>>
>>>
>>> On 30 Jul 2010, at 16:03, Tony S Yu wrote:
>>>
>>>>
>>>> On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm interested in fiddling around with the matplotlib source. Let's say we set up various things:
>>>>>
>>>>> from matplotlib.figure import Figure()
>>>>> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>>>>>
>>>>> fig = Figure()
>>>>> canvas = FigureCanvas(fig)
>>>>> ax = fig.add_subplot(1, 1, 1)
>>>>> fig.savefig('asd.pdf', bbox_inches='tight')
>>>>>
>>>>> I would like to know what exactly happens when bbox_inches='tight' is passed to savefig(). I've been searching in the figure.py source and nowhere can I see the bbox_inches='tight' keyword being tested for in the savefig() method. Having said that, all of the kwargs do get passed on to the canvas.print_figure() method, so I looked in the backend_pdf.py file but couldn't find a print_figure() method. Could someone point me in the right direction?
>>>>>
>>>>> Regards,
>>>>> -- Damon
>>>>
>>>> That's funny: I was just looking at bbox_inches='tight' recently. You'll find the relevant section in matplotlib.backend_bases.print_figure.
>>>>
>>>> Best,
>>>> -Tony
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>> of 1ドル Million in cash or HP Products. Visit us here for more details:
>>> http://p.sf.net/sfu/dev2dev-palm
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of 1ドル Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of 1ドル Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Aha! Even without the text, i.e. setting label1On = False for all the major ticks, the behaviour I see is that with bbox_inches = 'tight' and pad_inches = 0.0 I get the saved figure which includes the black border line for the bottom and left edges, but not the top and right edges. This may have something to do with it. Maybe it's an issue with the bounding box not being 'inclusive' and leaving out the end points?
Regards,
-- Damon
--------------------------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.m...@wa...
On 30 Jul 2010, at 20:33, Eric Firing wrote:
> On 07/30/2010 06:32 AM, Damon McDougall wrote:
>> Hmm, it seems as though tick labels get clipped on the top and on the right when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this behaviour. Is there perhaps a bug in Bbox.union that's causing this?
>> 
> 
> Not likely. Much more likely is a problem in calculating the rendered 
> size of the text.
> 
> Eric
> 
>> Regards,
>> -- Damon
>> 
>> --------------------------
>> Damon McDougall
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> CV4 7AL
>> d.m...@wa...
>> 
>> 
>> 
>> On 30 Jul 2010, at 16:03, Tony S Yu wrote:
>> 
>>> 
>>> On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm interested in fiddling around with the matplotlib source. Let's say we set up various things:
>>>> 
>>>> from matplotlib.figure import Figure()
>>>> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>>>> 
>>>> fig = Figure()
>>>> canvas = FigureCanvas(fig)
>>>> ax = fig.add_subplot(1, 1, 1)
>>>> fig.savefig('asd.pdf', bbox_inches='tight')
>>>> 
>>>> I would like to know what exactly happens when bbox_inches='tight' is passed to savefig(). I've been searching in the figure.py source and nowhere can I see the bbox_inches='tight' keyword being tested for in the savefig() method. Having said that, all of the kwargs do get passed on to the canvas.print_figure() method, so I looked in the backend_pdf.py file but couldn't find a print_figure() method. Could someone point me in the right direction?
>>>> 
>>>> Regards,
>>>> -- Damon
>>> 
>>> That's funny: I was just looking at bbox_inches='tight' recently. You'll find the relevant section in matplotlib.backend_bases.print_figure.
>>> 
>>> Best,
>>> -Tony
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of 1ドル Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of 1ドル Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 07/30/2010 06:32 AM, Damon McDougall wrote:
> Hmm, it seems as though tick labels get clipped on the top and on the right when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this behaviour. Is there perhaps a bug in Bbox.union that's causing this?
>
Not likely. Much more likely is a problem in calculating the rendered 
size of the text.
Eric
> Regards,
> -- Damon
>
> --------------------------
> Damon McDougall
> Mathematics Institute
> University of Warwick
> Coventry
> CV4 7AL
> d.m...@wa...
>
>
>
> On 30 Jul 2010, at 16:03, Tony S Yu wrote:
>
>>
>> On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
>>
>>> Hi,
>>>
>>> I'm interested in fiddling around with the matplotlib source. Let's say we set up various things:
>>>
>>> from matplotlib.figure import Figure()
>>> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>>>
>>> fig = Figure()
>>> canvas = FigureCanvas(fig)
>>> ax = fig.add_subplot(1, 1, 1)
>>> fig.savefig('asd.pdf', bbox_inches='tight')
>>>
>>> I would like to know what exactly happens when bbox_inches='tight' is passed to savefig(). I've been searching in the figure.py source and nowhere can I see the bbox_inches='tight' keyword being tested for in the savefig() method. Having said that, all of the kwargs do get passed on to the canvas.print_figure() method, so I looked in the backend_pdf.py file but couldn't find a print_figure() method. Could someone point me in the right direction?
>>>
>>> Regards,
>>> -- Damon
>>
>> That's funny: I was just looking at bbox_inches='tight' recently. You'll find the relevant section in matplotlib.backend_bases.print_figure.
>>
>> Best,
>> -Tony
>>
>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of 1ドル Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hmm, it seems as though tick labels get clipped on the top and on the right when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this behaviour. Is there perhaps a bug in Bbox.union that's causing this?
Regards,
-- Damon
--------------------------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.m...@wa...
On 30 Jul 2010, at 16:03, Tony S Yu wrote:
> 
> On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
> 
>> Hi,
>> 
>> I'm interested in fiddling around with the matplotlib source. Let's say we set up various things:
>> 
>> from matplotlib.figure import Figure()
>> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>> 
>> fig = Figure()
>> canvas = FigureCanvas(fig)
>> ax = fig.add_subplot(1, 1, 1)
>> fig.savefig('asd.pdf', bbox_inches='tight')
>> 
>> I would like to know what exactly happens when bbox_inches='tight' is passed to savefig(). I've been searching in the figure.py source and nowhere can I see the bbox_inches='tight' keyword being tested for in the savefig() method. Having said that, all of the kwargs do get passed on to the canvas.print_figure() method, so I looked in the backend_pdf.py file but couldn't find a print_figure() method. Could someone point me in the right direction?
>> 
>> Regards,
>> -- Damon
> 
> That's funny: I was just looking at bbox_inches='tight' recently. You'll find the relevant section in matplotlib.backend_bases.print_figure.
> 
> Best,
> -Tony
> 

On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
> Hi,
> 
> I'm interested in fiddling around with the matplotlib source. Let's say we set up various things:
> 
> from matplotlib.figure import Figure()
> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
> 
> fig = Figure()
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(1, 1, 1)
> fig.savefig('asd.pdf', bbox_inches='tight')
> 
> I would like to know what exactly happens when bbox_inches='tight' is passed to savefig(). I've been searching in the figure.py source and nowhere can I see the bbox_inches='tight' keyword being tested for in the savefig() method. Having said that, all of the kwargs do get passed on to the canvas.print_figure() method, so I looked in the backend_pdf.py file but couldn't find a print_figure() method. Could someone point me in the right direction?
> 
> Regards,
> -- Damon
That's funny: I was just looking at bbox_inches='tight' recently. You'll find the relevant section in matplotlib.backend_bases.print_figure.
Best,
-Tony

On Fri, Jul 30, 2010 at 9:54 AM, Damon McDougall
<D.M...@wa...>wrote:
> Hi,
>
> I'm interested in fiddling around with the matplotlib source. Let's say we
> set up various things:
>
> from matplotlib.figure import Figure()
> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>
> fig = Figure()
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(1, 1, 1)
> fig.savefig('asd.pdf', bbox_inches='tight')
>
> I would like to know what exactly happens when bbox_inches='tight' is
> passed to savefig(). I've been searching in the figure.py source and nowhere
> can I see the bbox_inches='tight' keyword being tested for in the savefig()
> method. Having said that, all of the kwargs do get passed on to the
> canvas.print_figure() method, so I looked in the backend_pdf.py file but
> couldn't find a print_figure() method. Could someone point me in the right
> direction?
>
> Regards,
> -- Damon
>
>
That is because the FigureCanvasPdf class inherits from the
FigureCanvasBase, which defines the .savefig() function. You will find that
in backend_bases.py.
I hope this helps,
Ben Root

Hi,
I'm interested in fiddling around with the matplotlib source. Let's say we set up various things:
from matplotlib.figure import Figure()
from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(1, 1, 1)
fig.savefig('asd.pdf', bbox_inches='tight')
I would like to know what exactly happens when bbox_inches='tight' is passed to savefig(). I've been searching in the figure.py source and nowhere can I see the bbox_inches='tight' keyword being tested for in the savefig() method. Having said that, all of the kwargs do get passed on to the canvas.print_figure() method, so I looked in the backend_pdf.py file but couldn't find a print_figure() method. Could someone point me in the right direction?
Regards,
-- Damon
--------------------------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.m...@wa...

On 07/29/2010 01:17 PM, Benjamin Root wrote:
> On Thu, Jul 29, 2010 at 3:39 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 07/29/2010 09:31 AM, Benjamin Root wrote:
> [...]
> >
> > Good catch, Jeff. Looking over the code, looks like both the
> input
> > data, x, and the weights get similar pre-processing done to
> ready it
> > for histogramming. It appears that a fix was made to how x
> was being
> > processed, but the same was not done to weights. I have a patch
> > that fixes the pre-processing of weights, and also adds
> comments to
> > both blocks of code to remind future developers to make sure
> changes
> > are made to both chunks of code.
> >
> > The functional part of the change was to check if the first
> element
> > of weights was an iterable or not. Before, the weights array
> as in
> > the given example would be considered 1-element weights for 3
> > datasets, rather than 3-element weights for 1 dataset.
> >
> > Ben Root
> >
> >
> > Re-pinging on my proposed patch. Also, should it go into just the
> > trunk, or should it also go into the branch?
>
> Ben,
>
> Go ahead, trunk and branch, since it is a bugfix.
>
> Thank you.
>
> Eric
>
>
> Done in r8595 and r8596.
>
> As a side-note, it looks like various files that have been changed due
> to svnmerge.py are still showing themselves as having their properties
> modified. Is this ok?
That seems to be the way svnmerge works--it almost always generates an 
alarming list of property changes.
Eric
>
> Ben Root

On Thu, Jul 29, 2010 at 3:39 PM, Eric Firing <ef...@ha...> wrote:
> On 07/29/2010 09:31 AM, Benjamin Root wrote:
> [...]
> >
> > Good catch, Jeff. Looking over the code, looks like both the input
> > data, x, and the weights get similar pre-processing done to ready it
> > for histogramming. It appears that a fix was made to how x was being
> > processed, but the same was not done to weights. I have a patch
> > that fixes the pre-processing of weights, and also adds comments to
> > both blocks of code to remind future developers to make sure changes
> > are made to both chunks of code.
> >
> > The functional part of the change was to check if the first element
> > of weights was an iterable or not. Before, the weights array as in
> > the given example would be considered 1-element weights for 3
> > datasets, rather than 3-element weights for 1 dataset.
> >
> > Ben Root
> >
> >
> > Re-pinging on my proposed patch. Also, should it go into just the
> > trunk, or should it also go into the branch?
>
> Ben,
>
> Go ahead, trunk and branch, since it is a bugfix.
>
> Thank you.
>
> Eric
>
>
Done in r8595 and r8596.
As a side-note, it looks like various files that have been changed due to
svnmerge.py are still showing themselves as having their properties
modified. Is this ok?
Ben Root

On 07/29/2010 09:31 AM, Benjamin Root wrote:
[...]
>
> Good catch, Jeff. Looking over the code, looks like both the input
> data, x, and the weights get similar pre-processing done to ready it
> for histogramming. It appears that a fix was made to how x was being
> processed, but the same was not done to weights. I have a patch
> that fixes the pre-processing of weights, and also adds comments to
> both blocks of code to remind future developers to make sure changes
> are made to both chunks of code.
>
> The functional part of the change was to check if the first element
> of weights was an iterable or not. Before, the weights array as in
> the given example would be considered 1-element weights for 3
> datasets, rather than 3-element weights for 1 dataset.
>
> Ben Root
>
>
> Re-pinging on my proposed patch. Also, should it go into just the
> trunk, or should it also go into the branch?
Ben,
Go ahead, trunk and branch, since it is a bugfix.
Thank you.
Eric
>
> Ben Root
>

On Sun, Jul 25, 2010 at 3:51 PM, Benjamin Root <ben...@ou...> wrote:
> On Tue, Jul 20, 2010 at 9:21 AM, Jeff Klukas <kl...@wi...> wrote:
>
>> 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')
>>
>>
> Good catch, Jeff. Looking over the code, looks like both the input data,
> x, and the weights get similar pre-processing done to ready it for
> histogramming. It appears that a fix was made to how x was being processed,
> but the same was not done to weights. I have a patch that fixes the
> pre-processing of weights, and also adds comments to both blocks of code to
> remind future developers to make sure changes are made to both chunks of
> code.
>
> The functional part of the change was to check if the first element of
> weights was an iterable or not. Before, the weights array as in the given
> example would be considered 1-element weights for 3 datasets, rather than
> 3-element weights for 1 dataset.
>
> Ben Root
>
>
Re-pinging on my proposed patch. Also, should it go into just the trunk, or
should it also go into the branch?
Ben Root

Hello,
On Mon, Jul 19, 2010 at 23:10, Sandro Tosi <mo...@de...> 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.
>
> 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 don't want to put pressure on this but... was there any progress? :)
It would be nice to have this somehow fixed or worked-around, so that
I can upload to debian (experimental branch) and get some testing
there. The fact doc generation requires downloading datafiles from web
it's the only thing left that holds upload of mpl.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I am trying to track down a problem in the 3D code, and I have noticed an
issue with Axes3D.add_collection3d(). It checks to see which collection
type you are passing in and will convert them to their 3D equivalent if
possible, and then calls .set_sort_zpos() afterwards. However,
.set_sort_zpos() was only defined for Poly3DCollections. Was there supposed
to be some sort of inheritance that was supposed to occur or something?
Thanks,
Ben Root

Great - if anything's unclear, I can fairly easily make a test case as
Benjamin suggested, so just let me know if that's necessary - thank!
On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> wrote:
> Hi Erik,
>
> Sorry for the delay. From just looking at the diff I would say it's a
> great addition. I'll test tomorrow and push it if it works (which I
> assume it does).
>
> Cheers,
> Reinier
>
> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> wrote:
>> Just a quick ping about this - did it get applied, or was there
>> something wrong with it? (Or am I just too impatient?)
>>
>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote:
>>> 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
>>>
>>
>>
>>
>> --
>> Erik Tollerud
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of 1ドル Million in cash or HP Products. Visit us here for more details:
>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Reinier Heeres
> Tel: +31 6 10852639
>
-- 
Erik Tollerud

On Tue, Jul 27, 2010 at 12:11 AM, David Trem <dav...@gm...> wrote:
> Just for the records, the fix now applied to the svn and
> discuss on this list under """Plot moves while using the "Zoom to
> rectangle" button""" thread also fixes the problem I reported
> earlier this year (see email below).
>
> Best Regards,
>
> David
>
> Le 20/01/10 18:01, David Trem a écrit :
> > Hi,
> >
> > I do see strange behavior when using "Zoom to rectangle"
> > on my figures embedded in gtk through glade.
> > When clicking on the figure and start drawing the rectangle,
> > the bottom axis moves up as well as the graph which screw up
> > the whole figure during the rectangle definition. When releasing
> > the mouse button the figure looks ok.
> >
> > I attach a small script together with glade file (slightly modified
> > from the matplotlib examples) that allows to reproduce the problem:
> > -> launch the script, press the "Zoom to rectangle button" and start
> > drawing the rectangle region on the graph, you will see the issue...
> > It as to be noticed that pure gtk version (without glade) does work
> > properly.
> >
> > I'm on MacOsX 10.5.8 using gtk.gtk_version (2, 18, 6)
> > and gtk.pygtk_version (2, 16, 0) with python 2.6
> >
> > Hope someone could help me solving this annoying issue.
> >
> > Regards,
> >
> > David
>
>
David,
I am glad to see that this solved your problem. Sorry for the lack of a
follow-up on your issue. I guess the solution to your problem wasn't
entirely obvious at that time. I take it that no ticket was filed for it
that we have to close?
Ben Root

Hi Erik,
Sorry for the delay. From just looking at the diff I would say it's a
great addition. I'll test tomorrow and push it if it works (which I
assume it does).
Cheers,
Reinier
On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> wrote:
> Just a quick ping about this - did it get applied, or was there
> something wrong with it? (Or am I just too impatient?)
>
> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote:
>> 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
>>
>
>
>
> --
> Erik Tollerud
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of 1ドル Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Reinier Heeres
Tel: +31 6 10852639

Just for the records, the fix now applied to the svn and
discuss on this list under """Plot moves while using the "Zoom to
rectangle" button""" thread also fixes the problem I reported
earlier this year (see email below).
Best Regards,
David
Le 20/01/10 18:01, David Trem a écrit :
> Hi,
> 
> I do see strange behavior when using "Zoom to rectangle"
> on my figures embedded in gtk through glade.
> When clicking on the figure and start drawing the rectangle,
> the bottom axis moves up as well as the graph which screw up
> the whole figure during the rectangle definition. When releasing
> the mouse button the figure looks ok.
> 
> I attach a small script together with glade file (slightly modified
> from the matplotlib examples) that allows to reproduce the problem:
> -> launch the script, press the "Zoom to rectangle button" and start
> drawing the rectangle region on the graph, you will see the issue...
> It as to be noticed that pure gtk version (without glade) does work
> properly.
> 
> I'm on MacOsX 10.5.8 using gtk.gtk_version (2, 18, 6)
> and gtk.pygtk_version (2, 16, 0) with python 2.6
> 
> Hope someone could help me solving this annoying issue.
> 
> Regards,
> 
> David

On Mon, Jul 26, 2010 at 7:55 PM, Erik Tollerud <eri...@gm...>wrote:
> Just a quick ping about this - did it get applied, or was there
> something wrong with it? (Or am I just too impatient?)
>
> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...>
> wrote:
> > 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
> >
>
>
>
Erik,
Do you have a short, simple script that demonstrates the problem so that we
can test the patch?
Ben Root

Just a quick ping about this - did it get applied, or was there
something wrong with it? (Or am I just too impatient?)
On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote:
> 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
>
-- 
Erik Tollerud

On 07/26/2010 11:13 AM, Gökhan Sever wrote:
>
>
> On Mon, Jul 26, 2010 at 4:01 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> A message to the users' list prompted me to begin a tirade about the
> default key bindings that appeared some time fairly recently--see the
> bottom of the matplotlibrc_template file. I really think that having
> these bindings enabled by default is a substantial mistake, one that
> will trip up and annoy far more users than it will help.
>
> I would like to class this as a bug, and remove default bindings from
> the maintenance branch and the trunk. Those users who want the bindings
> can then enable them via their own matplotlibrc files.
>
> Objections? Counter-arguments?
>
> Eric
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of 1ドル Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> I think, placing a global switch like keymap.enable = "no" would resolve
> this issue smoothly. The reason of putting key-bindings in the
> matplotlibrc file is to give users more freedom to create their own
> keymappings. As it is stated in that file, keybindings are easily
> nullified by assigning them to null strings.
Yes, I agree that a single setting to turn the mapping capability on or 
off would make sense. I strongly believe that by default it should be off.
Eric
>
> PS: Sorry, replying to all.
>
> --
> Gökhan

On Mon, Jul 26, 2010 at 4:01 PM, Eric Firing <ef...@ha...> wrote:
> A message to the users' list prompted me to begin a tirade about the
> default key bindings that appeared some time fairly recently--see the
> bottom of the matplotlibrc_template file. I really think that having
> these bindings enabled by default is a substantial mistake, one that
> will trip up and annoy far more users than it will help.
>
> I would like to class this as a bug, and remove default bindings from
> the maintenance branch and the trunk. Those users who want the bindings
> can then enable them via their own matplotlibrc files.
>
> Objections? Counter-arguments?
>
> Eric
>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of 1ドル Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
I think, placing a global switch like keymap.enable = "no" would resolve
this issue smoothly. The reason of putting key-bindings in the matplotlibrc
file is to give users more freedom to create their own keymappings. As it is
stated in that file, keybindings are easily nullified by assigning them to
null strings.
PS: Sorry, replying to all.
-- 
Gökhan

A message to the users' list prompted me to begin a tirade about the 
default key bindings that appeared some time fairly recently--see the 
bottom of the matplotlibrc_template file. I really think that having 
these bindings enabled by default is a substantial mistake, one that 
will trip up and annoy far more users than it will help.
I would like to class this as a bug, and remove default bindings from 
the maintenance branch and the trunk. Those users who want the bindings 
can then enable them via their own matplotlibrc files.
Objections? Counter-arguments?
Eric

Hi,
I've come across two bugs with pcolormesh, one relating to the MacOSX backend, and the other relating to the linewidth argument being ignored. I've submitted tickets:
https://sourceforge.net/tracker/?func=detail&aid=3034775&group_id=80706&atid=560720
https://sourceforge.net/tracker/?func=detail&aid=3034778&group_id=80706&atid=560720
Cheers,
Tom

Please refer to the messages under "Detecting GUI mainloop running in 
IPython" on http://news.gmane.org/gmane.comp.python.ipython.devel.
At least at the moment, they are not showing up as a single thread; 
maybe it takes a little time for the thread logic to sort out the messages.
I hope that someone with better understanding than mine of gui mechanics 
will join the discussion on the ipython-dev list. The IPython people 
have been making changes, and have more in mind. This involves critical 
mpl functionality.
Eric