matplotlib-devel Mailing List for matplotlib

On Tue, Nov 9, 2010 at 3:48 PM, Eric Firing <ef...@ha...> wrote:
> On 11/09/2010 11:03 AM, John Hunter wrote:
> Based on a very superficial look, I suspect we could eliminate
> pixbuf_get_pixels_array by using the function
> http://www.pygtk.org/docs/pygtk/class-gdkpixbuf.html#function-gdk--pixbuf-new-from-data.
Nice find -- this does the trick. I was able to plug it into gdk
draw_image and draw_mathtext fairly painlessly. I've now removed all
the gtk compile time dependencies in the attached patch against svn
HEAD. Because this is a major change, I'm going to hold off
committing it to give you all a change to review and test, and I'll
test some more on a different platform when I get home. But on
solaris python2.4, I have animations with blitting in gtkagg, images
and mathtext in GTK/GDK, so this is looking pretty good so far (all of
this was segfaulting before)
Because build_gtk and build_gtkagg are no longer config options, there
is a small change in the logic in how the default backend gets set.
Now gtkagg will be set as the default backend if check_for_gtk returns
True. We may want to change this, since tkagg is a little friendlier
across shells.
JDH

On 11/09/2010 11:03 AM, John Hunter wrote:
> On Tue, Nov 9, 2010 at 2:25 PM, John Hunter<jd...@gm...> wrote:
>
>
> I'm going to proceed with removing _gtkagg.cpp in the trunk, and I
> think we should consider disabling default builds of _backend_gdk.c
> (they could be enabled by a config option if we can't find a python
> replacement for pixbuf_get_pixels_array)
>
John,
Based on a very superficial look, I suspect we could eliminate 
pixbuf_get_pixels_array by using the function 
http://www.pygtk.org/docs/pygtk/class-gdkpixbuf.html#function-gdk--pixbuf-new-from-data.
Eric

On Tue, Nov 9, 2010 at 2:25 PM, John Hunter <jd...@gm...> wrote:
> Attached also is the example code I am using to test. Strangely, the
> agg buffer seems to be updating internally but the gtk window is only
> updating when I hover my mouse over it, and then only once until I
> activate another window and then re-hover over the mpl animation
> window.
OK, this was an example of how writing the email for help solves the
problem. As soon as I described the strange updating behavior, it
triggered my memory about the expose event code in backend_gtk and
when I took a look at that I realized I need to draw to the window and
not the pixbuf as we do in _render_figure. The revised diff is
attached.
So this email now is a patch review request, and importantly, can we
get rid of all gtk extension code? There is now no need for
_gtkagg.cpp, and the only other piece is src/_backend_gdk.c which
provides pixbuf_get_pixels_array. If we could get rid of this, which
is used for images and mathtext in the GDK backend, it would be a big
win for compilation and distribution. Ideally, I would like to not
compile anything against a GUI, but so far we haven't been able to
figure out a way around TkAgg. But removing GTK compile time
dependencies would be a good start.
If you are familiar with agg and/or gtk/gdk internals, please take a
look at my updated patch. I am not double buffering as we are in
_render_figure, which seems appropriate for animation. I am actually
a little confused about why we need so many buffers in the main draw
pipeline -- we have the agg buffer, the gtk pixbuf, the gdk pixmap,
and the gdk window. Does anyone recall why we don't render directly
from the pixbuf to the window here? My guess is that it is to handle
the expose event in backend_gtk efficiently, but we should be able to
do this from the pixbuf directly to the window.... Or perhaps I'm
missing something.
I'm going to proceed with removing _gtkagg.cpp in the trunk, and I
think we should consider disabling default builds of _backend_gdk.c
(they could be enabled by a config option if we can't find a python
replacement for pixbuf_get_pixels_array)
JDH

We are getting seg faults on our Solaris platform at work when we use
the blit API in GTKAgg. This has been going on for a while, and I
don't know if it is in our pygtk version, or what. The line that is
causing the crash is in src/_gtkagg.cpp
 GdkDrawable *drawable = GDK_DRAWABLE(py_drawable->obj);
But rather than spend any more time trying to track that down, I
decided to try and remove the gtk extension code entirely, which would
be a great help for building mpl and distributing binaries. I feel
like I am close, but something is still not clicking (at least on my
platform).
I'm attaching an svn diff in case anyone has some ideas -- basically,
it removes the use of agg_to_gtk_drawable in
backend_gtkagg.FigureCanvasGTKAgg.blit and replaces it with gdk
pixmap/pixbuffer calls. If anyone has any ideas, please let me know.
Attached also is the example code I am using to test. Strangely, the
agg buffer seems to be updating internally but the gtk window is only
updating when I hover my mouse over it, and then only once until I
activate another window and then re-hover over the mpl animation
window.
Thanks for any help!
JDH

Hello developers,
I'm seeing what appears to be a bug when plotting bars next to each
other without edges. In pdf output, you can see that there is a tiny
gap in between each bar, which renders as one pixel wide no matter how
far I zoom in. It's also visible in interactive or png output:
http://www.dumpt.com/img/viewer.php?file=mc0wf07aksrzqs1h8j5k.png
You can generate the above by running a slightly modified demo:
-------------------------------------------
#!/usr/bin/env python
# a stacked bar plot with errorbars
import numpy as np
import matplotlib.pyplot as plt
N = 5
menMeans = (20, 35, 30, 35, 27)
womenMeans = (25, 32, 34, 20, 25)
menStd = (2, 3, 4, 1, 2)
womenStd = (3, 5, 2, 3, 3)
ind = np.arange(N) # the x locations for the groups
width = 1.0 # CHANGED from 0.35 in the demo
# CHANGED: adding linewidth=0 to these calls
p1 = plt.bar(ind, menMeans, width, color='r', yerr=womenStd, linewidth=0)
p2 = plt.bar(ind, womenMeans, width, color='y', linewidth=0,
 bottom=menMeans, yerr=menStd)
plt.ylabel('Scores')
plt.title('Scores by group and gender')
plt.xticks(ind+width/2., ('G1', 'G2', 'G3', 'G4', 'G5') )
plt.yticks(np.arange(0,81,10))
plt.legend( (p1[0], p2[0]), ('Men', 'Women') )
plt.show()
-------------------------------------------
Any thoughts on why there's always a tiny gap between bars?
Thanks,
Jeff
|| Jeff Klukas
|| Physics Lecturer, University of Wisconsin -- Whitewater
|| Research Assistant, University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://hep.wisc.edu/~jklukas/

On 11/08/2010 09:38 PM, Benjamin Root wrote:
>
> 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.
Right mouse button zooms the radial axis, analogously to how the right 
mouse button zooms axes in a rectilinear plot.
Mike

Hi,
On Mon, Nov 8, 2010 at 7:06 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett <mat...@gm...> wrote:
...
>> 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....
Thanks for extensions, and the pointer to the ipython directive, I had
only half remembered it, but it does look very well designed for what
I had in mind.
For the first time for a few years, I'm looking forward to writing
some tutorials...
See you,
Matthew

On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett <mat...@gm...> 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 "<ipython console>", 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<TAB>
 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.1312433 ],
 [ 0.67338089, 0.72302393],
 [ 0.7566368 , 0.07033696],
 [ 0.22591016, 0.77731835],
 [ 0.0072729 , 0.34273127]])
Another demonstration of multi-line input and output
.. ipython::
 In [106]: print x
 --------> print(x)
 jdh
 In [109]: for i in range(10):
 .....: print i
 .....:
 .....:
 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
Most of the "pseudo-decorators" can be used an options to ipython
mode. For example, to setup maptlotlib pylab but suppress the output,
you can do. When using the matplotlib ``use`` directive, it should
occur before any import of pylab. This will not show up in the
rendered docs, but the commands will be executed in the embedded
interpeter and subsequent line numbers will be incremented to reflect
the inputs::
 .. ipython::
 :suppress:
 In [144]: from pylab import *
 In [145]: ion()
.. ipython::
 :suppress:
 In [144]: from pylab import *
 In [145]: ion()
Likewise, you can set ``:doctest:`` or ``:verbatim:`` to apply these
settings to the entire block.
You can create one or more pyplot plots and insert them with the
``@savefig`` decorator.
.. ipython::
 @savefig plot_simple.png width=4in
 In [151]: plot([1,2,3]);
 # use a semicolon to suppress the output
 @savefig hist_simple.png width=4in
 In [151]: hist(np.random.randn(10000), 100);
In a subsequent session, we can update the current figure with some
text, and then resave
.. ipython::
 In [151]: ylabel('number')
 In [152]: title('normal distribution')
 @savefig hist_with_text.png
 In [153]: grid(True)

On Monday, November 8, 2010, Michael Droettboom <md...@st...> 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
> 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
>
>
>
>
>
>
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

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