[matplotlib-devel] event bug in polar axes
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. 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. 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. 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 polar_plot_zoomtest.py Description: Binary data -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] event bug in polar axes
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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] event bug in polar axes
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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib 1.0.1 release schedule (again)
Hi all, On Sun, Nov 7, 2010 at 09:25, Jouni K. Seppänen wrote: > Jouni K. Seppänen writes: > >> Benjamin Root 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 data¹. 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib 1.0.1 release schedule (again)
On Mon, Nov 8, 2010 at 1:29 PM, Sandro Tosi 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] plot directive, thank you and a question
Hi,
First - thank you - it makes my heart very glad to be able to do this:
.. plot::
:include-source:
import matplotlib.pyplot as plt
plt.plot(range(10))
plt.show()
Here's my question. This is already a huge step forward for me, but
the full monty would be to be able to do:
.. testcode::
import some_module
res = some_module.use_it('a string')
.. plot::
:include-source:
plt.imshow(res)
and so on. I mean, the ability to keep the code context across the
page, both in the ..plot: and ..testcode:: and even >>> directives, so
I can build up my tutorial examples on top of the previous results.
That step would make it the perfect tool for the tutorials that I have
ready to port - and I am sure - many others.
Is that already possible? If not, how easy would it be? It if isn't
easy, can y'all give me some pointers as to how to get there?
Thanks again,
Matthew
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] event bug in polar axes
On Monday, November 8, 2010, Michael Droettboom wrote: > > > > > > > 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 > Matplotlib-devel@lists.sourceforge.net > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > Thanks, that seems to do the trick. What is it that one can do anyway with this pan/zoom mode? All I seem to be able to do is move the labeling for the radial distance. Thanks, Ben -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] plot directive, thank you and a question
On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett wrote:
> First - thank you - it makes my heart very glad to be able to do this:
>
> .. plot::
> :include-source:
>
> import matplotlib.pyplot as plt
> plt.plot(range(10))
> plt.show()
>
> Here's my question. This is already a huge step forward for me, but
> the full monty would be to be able to do:
>
> .. testcode::
>
> import some_module
> res = some_module.use_it('a string')
>
> .. plot::
> :include-source:
>
> plt.imshow(res)
>
> and so on. I mean, the ability to keep the code context across the
> page, both in the ..plot: and ..testcode:: and even >>> directives, so
> I can build up my tutorial examples on top of the previous results.
> That step would make it the perfect tool for the tutorials that I have
> ready to port - and I am sure - many others.
>
> Is that already possible? If not, how easy would it be? It if isn't
> easy, can y'all give me some pointers as to how to get there?
This is a useful feature I've wanted myself. I just contributed a
change to the plot directive in svn to support this using two new
options :context: and :nofigs:, and updated the sampledoc tutorial.
The relevant bit from the tutorial is in the link below:
http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots
Also, we have a really useful ipython directive that is stateful by
default, and includes many options for suppressing input blocks,
doctesting on output blocks, saving figures, and more. It is included
in the ipython src tree. My original proposal is at
http://matplotlib.sourceforge.net/ipymode/_build/html/proposal.html,
which I've implemented with minor changes. A real world working
example from some lecture notes I prepared recently is attached as
convolution.rst, and some notes are below. I need to get this added
to the sampledoc tutorial
=
Ipython Directive
=
The ipython directive is a stateful ipython shell for embedding in
sphinx documents. It knows about standard ipython prompts, and
extracts the input and output lines. These prompts will be renumbered
starting at ``1``. The inputs will be fed to an embedded ipython
interpreter and the outputs from that interpreter will be inserted as
well.
.. ipython::
In [136]: x = 2
In [137]: x**3
Out[137]: 8
The state from previous sessions is stored, and standard error is
trapped. At doc build time, ipython's output and std err will be
inserted, and prompts will be renumbered. So the prompt below should
be ``In [3]:`` in the rendered docs.
.. ipython::
In [138]: z = x*3 # x is recalled from previous block
In [139]: z
Out[139]: 6
In [140]: print z
> print(z)
6
In [141]: q = z[) # this is a syntax error -- we trap ipy exceptions
File "", line 1
q = z[) # this is a syntax error -- we trap ipy exceptions
^
SyntaxError: invalid syntax
The embedded interpeter supports some limited markup. For example,
you can put comments in your ipython sessions, which are reported
verbatim. There are some handy "pseudo-decorators" that let you
doctest the output. The inputs are fed to an embbedded ipython
session and the outputs from the ipython session are inserted into
your doc. If the output in your doc and in the ipython session don't
match on a doctest assertion, an error will be
.. ipython::
In [1]: x = 'hello world'
# this will raise an error if the ipython output is different
@doctest
In [2]: x.upper()
Out[2]: 'HELLO WORLD'
# some readline features cannot be supported, so we allow
# "verbatim" blocks, which are dumped in verbatim except prompts
# are continuously numbered
@verbatim
In [3]: x.st
x.startswith x.strip
Multi-line input is supported.
.. ipython::
In [130]: url = 'http://ichart.finance.yahoo.com/table.csv?s=CROX\
.: &d=9&e=22&f=2009&g=d&a=1&br=8&c=2006&ignore=.csv'
In [131]: print url.split('&')
> print(url.split('&'))
['http://ichart.finance.yahoo.com/table.csv?s=CROX', 'd=9', 'e=22',
'f=2009', 'g=d', 'a=1', 'b=8', 'c=2006', 'ignore=.csv']
In [60]: import urllib
You can do doctesting on multi-line output as well. Just be careful
when using non-deterministic inputs like random numbers in the ipython
directive, because your inputs are ruin through a live interpreter, so
if you are doctesting random output you will get an error. Here we
"seed" the random number generator for deterministic output, and we
suppress the seed line so it doesn't show up in the rendered output
.. ipython::
In [133]: import numpy.random
@suppress
In [134]: numpy.random.seed(2358)
@doctest
In [135]: np.random.rand(10,2)
Out[135]:
array([[ 0.64524308, 0.59943846],
[ 0.47102322, 0.8715456 ],
[ 0.29370834, 0.74776844],
[ 0.99539577, 0.1313423 ],
[ 0.16250302, 0.21103583],
[ 0.81626524, 0
