matplotlib-users Mailing List for matplotlib (Page 8)

Hello, thanks for the response. I changed my matplotlibrc file from 'WxAgg' to 'Wx'. I'm still using wxpython 2.8 and matplotlib 0.90.1, and I am still getting the error that wxmsw26uh_vc.dll cannot be found. what else can I do? can I just put this file in the place that it is trying to look?
   
  thanks,
  Jeff

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Hi All,

I'm currently writing a pythonOgre version of a tsunami visualization 
tool for Geoscience Australia.  While the 3D portion is coming along 
nicely, I'm struggling a bit with formatting of time-series via 
matplotlib.  Is there anyone on the list willing to undertake a few 
hours of matplotlib consulting?  If so, please email me with your 
availability and hourly rate.

The work would require:
- checking out our Windows XP code-base via SVN
- phone call with me to discuss issues
- a few hours work over the next week tweaking our
   code and committing via SVN

Cheers,
Darran

-- 
Darran Edmundson [da...@ed...]
http://www.edmstudio.com

Hi,

mpl does not build the wxagg bridge starting from wxPython 2.8, thanks to an
upgraded system. So you can use wx directly without (much ?) loss of speed.

Matthieu

2007/11/10, Jeff Peery <jef...@ya...>:
>
> Hello,
>   I've been using wxpython 2.6 unicode version and I recently upgraded
> to 2.8 unicode version. I'm using matplotlib 0.90.1 wxAgg in my wx app
> and when I fire it up it gives me a message that it cannot find
> 'wxmsw26uh_vc.dll'. I've had this problem before and the solution was to
> install the unicode version of wxpython. But it doesn't seem to solve the
> problem with wxpython 2.8.
>
>   how do I get rid of this error?
>   thanks!
>
>   Jeff
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> -------------------------------------------------------------------------
> 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
>
>


-- 
French PhD student
Website : http://miles.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

On Saturday 10 November 2007 04:52:31 pm Michael McNeil Forbes wrote:
> On 10 Nov 2007, at 7:51 AM, Michael V. DePalatis wrote:
> ...
>
> > I recently discovered that if I import
> > pylab after importing numpy, I get tons of warnings:
> >
> > Warning: divide by zero encountered in divide
> > Warning: invalid value encountered in multiply
> > Warning: overflow encountered in long_scalars
> >
> > with the last occurring far most often (interestingly, I do not get
> > these warnings if pylab is imported before numpy). My question then is
> > two fold:
> >
> > (1) Why do I only get these warnings depending on when I import pylab?
>
> I am not sure: with the latest svn builds I get the message both
> ways.  Maybe the default error handling is different between the
> version of numpy and matplotlib you have installed.
>
> > (2) (a more general python question) How can I get these warning
> >     messages to give me *useful* information, such as where the
> > problems
> >     are happening?
>
> In numpy you can cause these to be exceptions by setting
>
> numpy.seterr("raise")
>
> Now you can see exactly where the exception happens.
>
> If you don't want to stop execution at this point, you use a
> callback.  This will pop-open the debugger at the point of error, but
> allow you to continue.
>
> def f(err,flag):
>      import pdb; pdb.set_trace()
>
> numpy.seterr("call")
> numpy.seterrcall(f)
>
> In general, with python warnings you can change them to exceptions by
> using warnings.simplefilter('error',Warning) (see http://
> docs.python.org/lib/module-warnings.html for details), however numpy
> does not seem to issue warnings, instead opting to directly print a
> message.  (Anyone know why the warnings library is not used?  Is this
> a bug that should be fixed?)

It would be better to discuss this on the numpy mailing list.

Darren

Hello, 
  I've been using wxpython 2.6 unicode version and I recently upgraded
 to 2.8 unicode version. I'm using matplotlib 0.90.1 wxAgg in my wx app
 and when I fire it up it gives me a message that it cannot find
 'wxmsw26uh_vc.dll'. I've had this problem before and the solution was to
 install the unicode version of wxpython. But it doesn't seem to solve the
 problem with wxpython 2.8. 
   
  how do I get rid of this error? 
  thanks!
   
  Jeff

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

On 10 Nov 2007, at 7:51 AM, Michael V. DePalatis wrote:
...

> I recently discovered that if I import
> pylab after importing numpy, I get tons of warnings:
>
> Warning: divide by zero encountered in divide
> Warning: invalid value encountered in multiply
> Warning: overflow encountered in long_scalars
>
> with the last occurring far most often (interestingly, I do not get
> these warnings if pylab is imported before numpy). My question then is
> two fold:
>
> (1) Why do I only get these warnings depending on when I import pylab?
>

I am not sure: with the latest svn builds I get the message both  
ways.  Maybe the default error handling is different between the  
version of numpy and matplotlib you have installed.


> (2) (a more general python question) How can I get these warning
>     messages to give me *useful* information, such as where the  
> problems
>     are happening?
>

In numpy you can cause these to be exceptions by setting

numpy.seterr("raise")

Now you can see exactly where the exception happens.

If you don't want to stop execution at this point, you use a  
callback.  This will pop-open the debugger at the point of error, but  
allow you to continue.

def f(err,flag):
     import pdb; pdb.set_trace()

numpy.seterr("call")
numpy.seterrcall(f)

In general, with python warnings you can change them to exceptions by  
using warnings.simplefilter('error',Warning) (see http:// 
docs.python.org/lib/module-warnings.html for details), however numpy  
does not seem to issue warnings, instead opting to directly print a  
message.  (Anyone know why the warnings library is not used?  Is this  
a bug that should be fixed?)

Michael.

On Nov 9, 2007 1:08 PM, Don Peterson <do...@gd...> wrote:

> 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.

For some reason, your backend is being set to GTKAgg, though this
should not be the default on windows.  If you want to use GTK, you can
install pygtk which has a win32 installer.  But more likely, you don't
want this, so you need to find your matplotlib rc file and change the
backend bariable o TkAgg (i you ant to use TkInter) or WXAgg (if you
want to use wxpython).  If you are usin the enthought tools, you may
want to consider WxAgg since many of their tools work with wx.

The easiest  way to find your matplotlib rc file is to run a simple
script that imports pylab with the --verbose-helpful flag, eg

> python myscript.py --verbose-helpful

and it will print a line telling you the path to the matplotlib rc
file.  Change the backend line from GTKAgg to the desired backend.

JDH

Hello,

I am attempting to write a small simulation to reproduce something
from a paper. However, I'm having a whale of a time getting it to
work (as far as I have been able to tell, the calculations from the
paper at least are identical to what I am trying to do, which makes
this all the more frustrating). I recently discovered that if I import
pylab after importing numpy, I get tons of warnings:

Warning: divide by zero encountered in divide
Warning: invalid value encountered in multiply
Warning: overflow encountered in long_scalars

with the last occurring far most often (interestingly, I do not get
these warnings if pylab is imported before numpy). My question then is
two fold:

(1) Why do I only get these warnings depending on when I import pylab?

(2) (a more general python question) How can I get these warning
    messages to give me *useful* information, such as where the problems
    are happening?

Thanks,

-- 
Michael V. DePalatis
Georgia Institute of Technology
School of Physics
837 State Street
Atlanta, GA 30332-0430

em vee dee at gatech dot edu
http://mike.depalatis.net

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

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.

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