matplotlib-devel Mailing List for matplotlib

On Mon, Nov 8, 2010 at 1:29 PM, Sandro Tosi <mo...@de...> wrote:
> What's the plan about 1.0.1? is it going to be release soon? will it
> include the sample_data dir in the released tarball, so that we can
> set examples.download = False, and examples.directory =
> "..../sample_data" inside the tarball? that would really help getting
> mpl 1.0.* into Debian.
I will try and get to the release ASAP and set the sample_data up this way...
JDH

Hi all,
On Sun, Nov 7, 2010 at 09:25, Jouni K. Seppänen <jk...@ik...> wrote:
> Jouni K. Seppänen <jk...@ik...> writes:
>
>> Benjamin Root <ben...@ou...> writes:
>>
>>>> As an Ubuntu user, I would really a mechanism
>>>> for excluding examples requiring downloaded data from being built
>>>
>>> How far did we get on that? I could have sworn we did something
>>> about the caching mechanism.
>>
>> I'll commit something simple to deal with this, since the fancier
>> plans were apparently too much.
>
> So now on the 1.0 maintenance branch (coming soon to trunk, once I'm
> done wrangling with svnmerge) you can set new rc parameters
> examples.download to False and examples.directory to the directory where
> you have a checkout of the sample data1. Then get_sample_data will only
> look in this directory and not download anything.
>
> Does this help with the Debian and Ubuntu builds?
Yes, indeed, thanks! I was in fact just working on preparing a patch
again "vanilla" 1.0.0 to be included in Debian package, but then I
realized that I have to provide those sample data, downloading them
from the internet before the build and ship them in the debian
customization of the released tarball... then I stop.
What's the plan about 1.0.1? is it going to be release soon? will it
include the sample_data dir in the released tarball, so that we can
set examples.download = False, and examples.directory =
"..../sample_data" inside the tarball? that would really help getting
mpl 1.0.* into Debian.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Should be fixed in r8778, r8779.
Mike
On 11/08/2010 11:13 AM, Michael Droettboom wrote:
> On 11/08/2010 10:34 AM, Benjamin Root wrote:
>> I have come across an odd bug in PolarAxes event handling. If one 
>> creates a polar axes, then attempts to do a zoom action (is this even 
>> allowed?), and then attempts to do a pan (is this even allowed?), 
>> errors get thrown.
> Rubber-band zooming is not allowed, but panning is. Panning mode 
> allows for zooming (sounds counter-intuitive in English, but it makes 
> more sense in the interface that way). That mode also allows for 
> dragging the r-labels.
>> Digging deeper, I noticed that the error being thrown is from 
>> "drag_zoom", which is odd because the current action should be 
>> drag_pan. Note that this bug only occurs if a zoom was attempted 
>> prior to a pan. Tracing the code execution, I can see that drag_pan 
>> does get called before drag_zoom, which leads me to suspect that the 
>> callbacks were never disconnected.
> Quite possibly. I wrote the polar panning code -- but never tested 
> this interaction with rubber-band zooming, because the latter isn't 
> supposed to do anything anyway.
>>
>> I don't have enough experience in this area to get much further. Can 
>> anybody else figure out why the interactive panning and zooming are 
>> not working for polar plots? There does appear to be code for that 
>> purpose, but nothing happens for either. Maybe it is linked to this 
>> bug? Maybe some code point is being skipped that would connect and 
>> disconnect the proper callbacks? I am not sure what is going on 
>> here. I have attached a really simple script to create a polar plot 
>> for others to test this out.
> I was able to confirm this and will look into it further.
>
> Cheers,
> Mike
>>
>> Note: I am using GTKAgg backend.
>>
>> Steps to reproduce:
>> 1. Run script
>> 2. Click on zoom button.
>> 3. Click anywhere inside the polar plot (dragging is not needed).
>> 4. Click on pan button
>> 5. Click and drag inside the polar plot.
>>
>> Ben Root
>>
>>
>> ------------------------------------------------------------------------------
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 11/08/2010 10:34 AM, Benjamin Root wrote:
> I have come across an odd bug in PolarAxes event handling. If one 
> creates a polar axes, then attempts to do a zoom action (is this even 
> allowed?), and then attempts to do a pan (is this even allowed?), 
> errors get thrown.
Rubber-band zooming is not allowed, but panning is. Panning mode allows 
for zooming (sounds counter-intuitive in English, but it makes more 
sense in the interface that way). That mode also allows for dragging 
the r-labels.
> Digging deeper, I noticed that the error being thrown is from 
> "drag_zoom", which is odd because the current action should be 
> drag_pan. Note that this bug only occurs if a zoom was attempted 
> prior to a pan. Tracing the code execution, I can see that drag_pan 
> does get called before drag_zoom, which leads me to suspect that the 
> callbacks were never disconnected.
Quite possibly. I wrote the polar panning code -- but never tested this 
interaction with rubber-band zooming, because the latter isn't supposed 
to do anything anyway.
>
> I don't have enough experience in this area to get much further. Can 
> anybody else figure out why the interactive panning and zooming are 
> not working for polar plots? There does appear to be code for that 
> purpose, but nothing happens for either. Maybe it is linked to this 
> bug? Maybe some code point is being skipped that would connect and 
> disconnect the proper callbacks? I am not sure what is going on 
> here. I have attached a really simple script to create a polar plot 
> for others to test this out.
I was able to confirm this and will look into it further.
Cheers,
Mike
>
> Note: I am using GTKAgg backend.
>
> Steps to reproduce:
> 1. Run script
> 2. Click on zoom button.
> 3. Click anywhere inside the polar plot (dragging is not needed).
> 4. Click on pan button
> 5. Click and drag inside the polar plot.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel