matplotlib-users Mailing List for matplotlib

I just did a fresh install of python 2.5.1, numpy-1.0.3.1.win32-py2.5.exe,
and matplotlib-0.90.1.win32-py2.5.exe. When I try to run the following
script:

from __future__ import division
from pylab import *

plot([1,2,3])
show()

I get the following traceback:

Traceback (most recent call last):
File "a.py", line 5, in <module>
from pylab import *
File "C:\python251\Lib\site-packages\pylab.py", line 1, in <module>
from matplotlib.pylab import *
File "c:\python251\lib\site-packages\matplotlib\pylab.py", line 222, in
<modul
e>
new_figure_manager, draw_if_interactive, show = pylab_setup()
File "C:\python251\Lib\site-packages\matplotlib\backends\__init__.py",
line 24
, in pylab_setup
globals(),locals(),[backend_name])
File
"c:\python251\lib\site-packages\matplotlib\backends\backend_gtkagg.py", l
ine 10, in <module>
from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK,
FigureCan
vasGTK,\
File "C:\python251\Lib\site-packages\matplotlib\backends\backend_gtk.py",
line
6, in <module>
import gobject
ImportError: No module named gobject

--------------------------------------------------
Note: I had been using the Enthought edition of python (2.4.3 version of
python) and matplotlib and everything worked great. I then tried to
install the map addition to matplotlib and the installation failed. After
that, I started getting the import error on gobject, which I assume is
something from GTK.

Does anyone have any suggestions on how to fix this? I'm pretty helpless
right now without matplotlib, as I use it to generate graphs for a
technical document I'm writing.

Please respond to:

Don Peterson
do...@gd...

Eric Firing wrote:
> A new mpl release is coming soon.  One of the changes is that there is a 
> new matplotlib.pyplot module that has only the plotting parts of the 
> pylab interface.  The pylab module still imports from oldnumeric, so it 
> still has the old Numeric-style upper case types (Float64 instead of 
> float64, etc.), but it gets its plotting capabilities from pyplot.

My statement above is already obsolete.  We decided to move faster on 
the transition to numpy.  Pylab in svn now imports nothing from 
oldnumeric unless you edit pylab.py, changing a "False" to a "True".

Eric

> 
> The old pylab namespace was very crowded, with many ways of getting some 
> functions and modules.  Via pyplot it has been simplified somewhat. 
> This means that if it stays the way it is, some user code will 
> break--something that used to be there will be missing.
> 
> So far, no svn user has complained.  If you are concerned about possible 
> breakage of your code, however, please check now to see if there is a 
> problem.  If you can make a good argument that something I have left out 
> of pyplot (and therefore pylab) should go back in, I will be happy to 
> consider it.  But for the long run we do want to slim these things down, 
> regularize them, and deprecate the old Numeric compatibility names, 
> defaults, and functionality.  A future version of pylab may be little 
> more than
> 
> from matplotlib.pyplot import *
> from numpy import *
> 
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Nov 9, 2007 12:37 PM, John Hunter <jd...@gm...> wrote:
> On Nov 8, 2007 7:48 PM, sunzen w. <su...@gm...> wrote:
> > Mike,
> > Thank you for your suggestion.
> > I found that pan mode doesn't work as expected in page of notebook.
> > The sample code is attached.
> > Thanks for your further guidance in advance.
>
>
> Now that is a well focused question.  A little googling revealed that
> when a gtk drawing area (eg an matplotlib canvas) is placed in a gtk
> notebook, it needs to have the focus to receive key press events.
>
>   http://www.daa.com.au/pipermail/pygtk/2002-August/003190.html
>
> I had hoped it would be enough to do
>
>   canvas.grab_focus()
>
> but apparently it is not (upon testing).  But the suggestion from the
> link above to use TAB to grab the focus worked in my tests.

With a little more testing, I find if I grab the focus after showing
the window that the notebook is in, it works as expected:

        notebook = gtk.Notebook()
        win.add(notebook)

        vbox = gtk.VBox()
        fig = mplfigure.Figure(figsize=(5,4), dpi=100)
        canvas = FigureCanvas(fig)  # a gtk.DrawingArea

        vbox.pack_start(canvas)
        toolbar = NavigationToolbar(canvas, win)
        vbox.pack_start(toolbar, False, False)

        notebook.insert_page(vbox, gtk.Label('Graph'))

        win.show_all()

        # need to get the focus in a notebook to handle keypress
        # events
        canvas.grab_focus()

On Nov 8, 2007 7:48 PM, sunzen w. <su...@gm...> wrote:
> Mike,
> Thank you for your suggestion.
> I found that pan mode doesn't work as expected in page of notebook.
> The sample code is attached.
> Thanks for your further guidance in advance.


Now that is a well focused question.  A little googling revealed that
when a gtk drawing area (eg an matplotlib canvas) is placed in a gtk
notebook, it needs to have the focus to receive key press events.

  http://www.daa.com.au/pipermail/pygtk/2002-August/003190.html

I had hoped it would be enough to do

  canvas.grab_focus()

but apparently it is not (upon testing).  But the suggestion from the
link above to use TAB to grab the focus worked in my tests.

JDH

On Nov 9, 2007 8:45 AM, Darren Dale <dar...@co...> wrote:

> I think it has not been resolved. I am not so familiar with the mpl's color
> handling code, and I need to turn to "official business" for the rest of the
> day. John or Eric, do you have time to look into this? The string 'None' is
> supposedly a valid argument, but:

I committed changes to svn to add support for face and edgecolor =
'None' for Patch and derived.  This still doesn't solve the problem
comprehensively across all artists, which would probably require the
backends to support a None value for the foreground color, but this
would take a fair amount of work (eg logs of get_rgb calls in
backend_ps would have to be fixed) so for now I put on a bandaid and
added support for patches, which allows you do pass edgecolor='None'
to savefig.

I did this by setting the gc linewidth to zero if edgecolor='None',
which should be supported by all backends (in mpl linewidth=0 means no
line, different from postscript where it means the thinnest possible
line) but if you find that it isn't, let us know.

JDH

On Friday 09 November 2007 09:24:25 am Peter-Jan Randewijk wrote:
> Hi Darren, John, Eric,
>
> Has the issue regarding,  edgecolor='None', been resolved or is this
> still work in progress.
>
> I am busy with a presentation using LaTeX's Beamer class with a
> "corporate gradiented grayish background".
>
> With matplotlib and facecolor=None it almost looks nice, except for the
> white edgecolor sticking out on the left of the graph, see attached PDF.
>
> As edgecolor=None isn't working, is there another way of getting rid of
> this white edge....?

I think it has not been resolved. I am not so familiar with the mpl's color 
handling code, and I need to turn to "official business" for the rest of the 
day. John or Eric, do you have time to look into this? The string 'None' is 
supposedly a valid argument, but:

In [1]: plot([1,2])
Out[1]: [<matplotlib.lines.Line2D instance at 0x2b18a14228c0>]

In [2]: savefig('dsd.png', facecolor='None', edgecolor='None')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/home/darren/<ipython console> in <module>()

/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py in savefig(*args, 
**kwargs)
    267 def savefig(*args, **kwargs):
    268     fig = gcf()
--> 269     return fig.savefig(*args, **kwargs)
    270 if Figure.savefig.__doc__ is not None:
    271     savefig.__doc__ = dedent(Figure.savefig.__doc__)

/usr/lib64/python2.5/site-packages/matplotlib/figure.py in savefig(self, 
*args, **kwargs)
    768                 kwargs[key] = rcParams['savefig.%s'%key]
    769
--> 770         self.canvas.print_figure(*args, **kwargs)
    771
    772     def colorbar(self, mappable, cax=None, ax=None, **kw):

/usr/lib64/python2.5/site-packages/matplotlib/backend_bases.py in 
print_figure(self, filename, dpi, facecolor, edgecolor, orientation, format, 
**kwargs)
   1194                 edgecolor=edgecolor,
   1195                 orientation=orientation,
-> 1196                 **kwargs)
   1197         finally:
   1198             self.figure.dpi.set(origDPI)

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py in 
print_png(self, filename, *args, **kwargs)
    101         # Do this so we can save the resolution of figure in the PNG 
file
    102         agg = self.switch_backends(FigureCanvasAgg)
--> 103         return agg.print_png(filename, *args, **kwargs)
    104
    105 """\

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py in 
print_png(self, filename, *args, **kwargs)
    415
    416     def print_png(self, filename, *args, **kwargs):
--> 417         self.draw()
    418         self.get_renderer()._renderer.write_png(str(filename), 
self.figure.dpi.get())
    419

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py in 
draw(self)
    377
    378         self.renderer = self.get_renderer()
--> 379         self.figure.draw(self.renderer)
    380
    381     def get_renderer(self):

/usr/lib64/python2.5/site-packages/matplotlib/figure.py in draw(self, 
renderer)
    586         self.transFigure.freeze()  # eval the lazy objects
    587
--> 588         if self.frameon: self.figurePatch.draw(renderer)
    589
    590         for p in self.patches: p.draw(renderer)

/usr/lib64/python2.5/site-packages/matplotlib/patches.py in draw(self, 
renderer)
    199         #renderer.open_group('patch')
    200         gc = renderer.new_gc()
--> 201         gc.set_foreground(self._edgecolor)
    202         gc.set_linewidth(self._linewidth)
    203         gc.set_alpha(self._alpha)

/usr/lib64/python2.5/site-packages/matplotlib/backend_bases.py in 
set_foreground(self, fg, isRGB)
    617             self._rgb = fg
    618         else:
--> 619             self._rgb = colors.colorConverter.to_rgb(fg)
    620
    621     def set_graylevel(self, frac):

/usr/lib64/python2.5/site-packages/matplotlib/colors.py in to_rgb(self, arg)
    277
    278         except (KeyError, ValueError, TypeError), exc:
--> 279             raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % 
(str(arg), exc))
    280             # Error messages could be improved by handling TypeError
    281             # separately; but this should be rare and not too hard

ValueError: to_rgb: Invalid rgb arg "None"
invalid literal for float(): None

On Friday 09 November 2007 08:11:02 am Michael Droettboom wrote:
> Thanks for these patches.  (And thanks for the e-mail -- many of the
> developers, myself included, don't follow the trackers all that
> frequently.)

I agree. Its great to get patch submissions, and I dont follow the tracker as 
closely as I should. Phil Thompson submitted a patch to fix blitting and 
other bugs in the qt4 backend in 2006, and I only discovered it applied the 
changes last week!

> Martin Teichmann wrote:
> > Hi all,
> >
> > I've looked a bit into the Qt4 backend and found some oddities
> > that might be interesting to change. The Qt4 backend
> > does not use the Qt4 facilities to create a toolbar but does
> > it on its own. I changed that and filed a patch at the sourceforge
> > patch site under patch request ID 1828848 (Qt4 backend improvement).
>
> Seems reasonable.  I think it would be worth running this by the
> original developer of the Qt4 backend (I don't know who that is).

Ted Drain for Qt3, James Amundson for the first crack at porting it to Qt4, 
and myself.

> There 
> may be a reason it was done in the less straightforward way that aren't
> obvious to you or I (perhaps to ease embedding... just guessing).

I don't think we can use the QMainWindow's addToolBar for this. It creates a 
single toolbar for the entire window, but what if we want to add two 
canveses, each with its own toolbar, in a single window? I am writing an 
application that does this.

> > Working on that I also found a little bug, which I fixed in
> > patch request ID 1828813 (PyQt4 giving annoying error messages).
>
> That looks like a good idea.  I've made a few modifications to it (since
> the variable p was also used in the following "else" clause), and
> committed it in SVN r4178.

Looks like we tried to apply the QPainter patch at the same time. I added a 
comment to the CHANGELOG.

Darren

Thanks for these patches.  (And thanks for the e-mail -- many of the 
developers, myself included, don't follow the trackers all that frequently.)

Martin Teichmann wrote:
> Hi all,
> 
> I've looked a bit into the Qt4 backend and found some oddities
> that might be interesting to change. The Qt4 backend
> does not use the Qt4 facilities to create a toolbar but does
> it on its own. I changed that and filed a patch at the sourceforge
> patch site under patch request ID 1828848 (Qt4 backend improvement).

Seems reasonable.  I think it would be worth running this by the 
original developer of the Qt4 backend (I don't know who that is).  There 
may be a reason it was done in the less straightforward way that aren't 
obvious to you or I (perhaps to ease embedding... just guessing).

> Working on that I also found a little bug, which I fixed in
> patch request ID 1828813 (PyQt4 giving annoying error messages).

That looks like a good idea.  I've made a few modifications to it (since 
the variable p was also used in the following "else" clause), and 
committed it in SVN r4178.

Cheers,
Mike

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Darren Dale wrote:
> On Friday 09 November 2007 07:25:09 am Michael Droettboom wrote:
>> Darren wrote:
>> * Use the system pyparsing, if available. If not, install pyparsing like we
>> do with pytz and dateutil. matplotlib.pyparsing is gone.
>>
>> That seems like a bad idea.  In my experience, pyparsing has changed APIs
>> at even minor releases.  Worse, given the complexity of the interface, I
>> wouldn't be surprised if more subtle differences or bugs were introduced by
>> different versions.  I understand the argument for this for the bigger
>> packages, but pyparsing isn't that many lines of code, and is a single
>> file.  I don't know if the saved disk space and bandwidth is worth the
>> extra maintenance and support effort.  I would much prefer to write for a
>> single version of pyparsing that we can verify works.
> 
> OK, I'll move it back into matplotlib then.

Thanks.  Hope it isn't too much trouble to undo those changes.  (Sorry 
for the gruff e-mail.  I shouldn't e-mail before my morning coffee...)

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Friday 09 November 2007 07:25:09 am Michael Droettboom wrote:
> Darren wrote:
> * Use the system pyparsing, if available. If not, install pyparsing like we
> do with pytz and dateutil. matplotlib.pyparsing is gone.
>
> That seems like a bad idea.  In my experience, pyparsing has changed APIs
> at even minor releases.  Worse, given the complexity of the interface, I
> wouldn't be surprised if more subtle differences or bugs were introduced by
> different versions.  I understand the argument for this for the bigger
> packages, but pyparsing isn't that many lines of code, and is a single
> file.  I don't know if the saved disk space and bandwidth is worth the
> extra maintenance and support effort.  I would much prefer to write for a
> single version of pyparsing that we can verify works.

OK, I'll move it back into matplotlib then.

Darren wrote:
* Use the system pyparsing, if available. If not, install pyparsing like we do with pytz and dateutil. matplotlib.pyparsing is gone.

That seems like a bad idea.  In my experience, pyparsing has changed APIs at even minor releases.  Worse, given the complexity of the interface, I wouldn't be surprised if more subtle differences or bugs were introduced by different versions.  I understand the argument for this for the bigger packages, but pyparsing isn't that many lines of code, and is a single file.  I don't know if the saved disk space and bandwidth is worth the extra maintenance and support effort.  I would much prefer to write for a single version of pyparsing that we can verify works.

Cheers,
Mike

Hi all,

I've looked a bit into the Qt4 backend and found some oddities
that might be interesting to change. The Qt4 backend
does not use the Qt4 facilities to create a toolbar but does
it on its own. I changed that and filed a patch at the sourceforge
patch site under patch request ID 1828848 (Qt4 backend improvement).

Working on that I also found a little bug, which I fixed in
patch request ID 1828813 (PyQt4 giving annoying error messages).

Greetings,

Martin

On Friday, 9 November 2007, Eric Firing wrote:
> Greg Novak wrote:
> > Much of the data that I would like to plot lives on machines
> > other than my desktop.  I'd like to log in to the remote machine,
> > start Python, and then let Matplotlib pop up an Xwindow on my
> > desktop machine.  The problem I'm running into is that this is
> > quite painfully slow.  Even over a 100 Mbit link, screen updates
> > take several seconds.
>
> I would not have expect the problem to be so severe with that link
> speed.  I wonder whether something else is slowing down the
> transactions?

I don't have that problem. Over a 100 Mbit link the screen updates are 
about 100-200 ms, so it's not as smooth as on your own box, but 
certainly usable for interactive work. This is with the Tk backend 
but straight ssh (i.e. no compresson). So I guess it's a networking 
issue on your side.

Johann

Greg Novak wrote:
> Much of the data that I would like to plot lives on machines other
> than my desktop.  I'd like to log in to the remote machine, start
> Python, and then let Matplotlib pop up an Xwindow on my desktop
> machine.  The problem I'm running into is that this is quite painfully
> slow.  Even over a 100 Mbit link, screen updates take several seconds.

I would not have expect the problem to be so severe with that link 
speed.  I wonder whether something else is slowing down the transactions?

>  This rules out interactively playing with plots and is hard to use
> even if I just want to see the plot (not interact with it).
> 
> I've used IDL in the same way, and it's generally very fast over the
> network, seemingly because it makes plots using simple line strokes
> which Xwindows handles pretty well.  Matplotlib renders the whole plot
> and then sends the pixel data.  This results in very nice looking
> plots and fonts, but apparently slows things down.
> 
> I'm by no means suggesting any changes to Matplotlib.  Rather, I'm
> just fishing for suggestions from anyone who's in the same boat.  Do
> some backends work better than others in this situation?  Any other
> suggestions to make this work better?

Try using the gtk or wx backends; they are much faster in this use case. 
  With or without those backends, you can also try using the -C option 
to ssh to compress the data, although normally it would be only for 
slower connections.  But if you are not getting fast response with the 
gtk or wx backends, then I suspect there is a networking problem, 
probably involving a latency or lost packets.

Eric

Mike,
Thank you for your suggestion.
I found that pan mode doesn't work as expected in page of notebook.
The sample code is attached.
Thanks for your further guidance in advance.

On Nov 8, 2007 9:27 PM, Michael Droettboom <md...@st...> wrote:
 > All I can suggest is that you compare this script you provided (which
> works) to the one that's broken (your application), and try to determine
> which difference is causing it to break.  Once you've put that
> difference into a short script and we can reproduce it, we'll have a
> better idea of what the root cause might be and whether there's a
> workaround.
>
> Cheers,
> Mike
>
>
-- 
sunzen
<<freedom & enjoyment>>

Much of the data that I would like to plot lives on machines other
than my desktop.  I'd like to log in to the remote machine, start
Python, and then let Matplotlib pop up an Xwindow on my desktop
machine.  The problem I'm running into is that this is quite painfully
slow.  Even over a 100 Mbit link, screen updates take several seconds.
 This rules out interactively playing with plots and is hard to use
even if I just want to see the plot (not interact with it).

I've used IDL in the same way, and it's generally very fast over the
network, seemingly because it makes plots using simple line strokes
which Xwindows handles pretty well.  Matplotlib renders the whole plot
and then sends the pixel data.  This results in very nice looking
plots and fonts, but apparently slows things down.

I'm by no means suggesting any changes to Matplotlib.  Rather, I'm
just fishing for suggestions from anyone who's in the same boat.  Do
some backends work better than others in this situation?  Any other
suggestions to make this work better?

Thanks,
Greg