matplotlib-users Mailing List for matplotlib (Page 2)

I've poked around the docs and archives, for a clue to this, but if it's
there I didn't recognize it.

version:  0.62
WinXP
default backend:  TkAgg
interactive  (with ipython)

On computer A I have version 0.54 installed.  There I can create a plot and
say
savefig('plot.eps')
and get a good eps file.

On computer B I have version 0.62 installed.  There I can create a plot and
say
savefig('plot.eps')
with different results: ghostscript chokes.

In the case of computer A, the eps file contains
/NewCenturySchlbk-Roman findfont
while in the case of computer B, the file contains instead
/BitstreamVeraSerif-Roman findfont

both have TTFPATH=c:\windows\fonts

it's *possible* (I don't remember exactly) that I installed 0.61 from a
windows installer, and 0.54 from setup.py.

afaik, the .matplotlibrc are the same (at least in the font section)
computer B contains a file .ttffile.cache, while computer A does not have
this file
Removing it from B doesn't make any difference.

any idea ... ?

-gary

Hi,

> I thing the crash and the shear effect are both part of the same bug
> that arose from a floating point error in converting figure units to
> width and height.  I believe this is a simple fix.  I was able to
> replicate both of the buggy behaviors on my winxp box, and the
> following change fixed both.  Perhaps you and Heiko can test on your
> respective scripts and let me know.

I can confirm that this fix works for me too. Thanks, that's a big help!

 > Know if I can just figure out why there is the irritating flicker on
 > resizes in win32...

The flicker doesn't seem so bad to me, to be honest. It seemed worse 
because I was using embedding_in_wx4 (which has an extra EVT_PAINT redraw).

Mark

John Hunter wrote:

>Thanks for the bug reports,
>
>I thing the crash and the shear effect are both part of the same bug
>that arose from a floating point error in converting figure units to
>width and height.  I believe this is a simple fix.  I was able to
>replicate both of the buggy behaviors on my winxp box, and the
>following change fixed both.  Perhaps you and Heiko can test on your
>respective scripts and let me know.
>
>On site-packages/matplotlib/backends/backend_wxagg.py, replace
>FigureCanvasWXAgg.draw with
>
>    def draw(self):
>        """
>        Render the figure using agg
>        """
>        DEBUG_MSG("draw()", 1, self)
>
>        FigureCanvasAgg.draw(self)
>        s = self.tostring_rgb()  
>        w = int(self.renderer.width)
>        h = int(self.renderer.height)
>        image = wxEmptyImage(w,h)
>        image.SetData(s)
>        self.bitmap = image.ConvertToBitmap()
>        self.gui_repaint()
>
>Let me know!
>
>Know if I can just figure out why there is the irritating flicker on
>resizes in win32....
>
>JDH        
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>  
>
Hello John,

I tested the fix and the problem seems to be gone. I will continue the 
testing and will let you know in case I will find anything else.

Thank you for your fast response and for the great library..

Heiko

>>>>> "Mark" == Mark Howson <ao...@ds...> writes:

    Mark> BTW, the embedding_in_wx4 example (among others) exhibits
    Mark> the same problem for me. I can always reproduce it by
    Mark> launching and resizing the window from small to large,
    Mark> without ever releasing the mouse button. This usually
    Mark> crashes within 10 resizes or so, but as with your
    Mark> description it's intermittent, it can take longer. This is
    Mark> with Windows XP, Python 2.3.4, matplotlib 0.61.0, wxPython
    Mark> 2.5.2.7. It was also present in the last matplotlib and
    Mark> wxPython releases at least. I seem to remember the plain wx
    Mark> frontend also being flaky under this kind of 'abuse', but I
    Mark> can't seem to get that to break now.

    Mark> I also notice that you get a shear effect on some of the
    Mark> resizes (where the plot is drawn as a parallelogram). That's
    Mark> reproducible by shrinking the plot very small, but also
    Mark> occasionally happens at other sizes. I can't be sure whether
    Mark> the size/aspect ratio of the window causes that.

Thanks for the bug reports,

I thing the crash and the shear effect are both part of the same bug
that arose from a floating point error in converting figure units to
width and height.  I believe this is a simple fix.  I was able to
replicate both of the buggy behaviors on my winxp box, and the
following change fixed both.  Perhaps you and Heiko can test on your
respective scripts and let me know.

On site-packages/matplotlib/backends/backend_wxagg.py, replace
FigureCanvasWXAgg.draw with

    def draw(self):
        """
        Render the figure using agg
        """
        DEBUG_MSG("draw()", 1, self)

        FigureCanvasAgg.draw(self)
        s = self.tostring_rgb()  
        w = int(self.renderer.width)
        h = int(self.renderer.height)
        image = wxEmptyImage(w,h)
        image.SetData(s)
        self.bitmap = image.ConvertToBitmap()
        self.gui_repaint()

Let me know!

Know if I can just figure out why there is the irritating flicker on
resizes in win32....

JDH        

Hi,

> I'm getting access violations while resizing the window/splitters of the 
> attached script. The problem is intermittant.

BTW, the embedding_in_wx4 example (among others) exhibits the same 
problem for me. I can always reproduce it by launching and resizing the 
window from small to large, without ever releasing the mouse button. 
This usually crashes within 10 resizes or so, but as with your 
description it's intermittent, it can take longer. This is with Windows 
XP, Python 2.3.4, matplotlib 0.61.0, wxPython 2.5.2.7. It was also 
present in the last matplotlib and wxPython releases at least. I seem to 
remember the plain wx frontend also being flaky under this kind of 
'abuse', but I can't seem to get that to break now.

I also notice that you get a shear effect on some of the resizes (where 
the plot is drawn as a parallelogram). That's reproducible by shrinking 
the plot very small, but also occasionally happens at other sizes. I 
can't be sure whether the size/aspect ratio of the window causes that.

Hello,

I'm getting access violations while resizing the window/splitters of the 
attached script. The problem is intermittant.

Windows XP
Python 2.3.3
matplotlib 0.61.00 (.matplotlibrc from examples)
wxPython *2.5.2.7

Any idea what's going on?

Heiko

*

Hi everyone,

sorry for the cross post to those of you who are on all these lists, but since 
this will affect ipython's future quite a bit, I want a significant heads-up 
to be seen by all potentially affected.

1. PyGTK & matplotlib
---------------------

Thanks to Antoon Pardon and John Hunter, ipython has nearly ready full support 
for interactive matplotlib with all backends.  In this process, we've also 
added GTK threading support, so you can now use ipython for pygtk development.

This code is now in IPython's CVS, and the matplotlib features require 
matplotlib CVS (for matplotlib use only; matplotlib has NOT become a general 
ipython requirement).  So those of you willing to bleed a little can use it, 
and now is your opportunity to let us know of any problems you find.

Our solution is simpler, but more limited in scope, than scipy's gui_thread. 
However it currently does NOT work with the WX backends, only with Tk and GTK 
(-AGG or not).  Help from any WX guru is welcome, the place to look is at the 
end of IPython/Shell.py.  I hope that we can find, at least in our more 
limited context, a working solution for WX which doesn't require all the 
complexity of gui_thread.

In order to use this, do an 'ipython -upgrade' after a cvs update; this will 
get the necessary support files into ~/.ipython.  You will then need to use 
the new threading options; copying from the docs:

  -gthread, -mpthread: these are special options, only one of which can be
  given, and which can ONLY be given as the FIRST option passed to IPython
  (they will have no effect in any other position).

  If -gthread is given, IPython starts running a separate thread for GTK
  operation, so that pyGTK-based programs can open GUIs without blocking
  IPython.

  The -mpthread option adds special support for the matplotlib library
  (http://matplotlib.sourceforge.net), allowing interactive usage of the GTK
  and WX backends.  This also modifies the @run command to correctly execute
  any matplotlib-based script which calls show() at the end, without blocking.

The most convenient way to use this is the new pylab profile, which should be 
invoked as follows (aliasing this in your shell may be a good idea):

	$ ipython -mpthread -p pylab

pylab will honor your choice of matplotlib backend, though currently it will 
revert (with a warning) WX to TkAgg, since WX is broken.  This will go away 
once we figure out the WX problems.


2. IPython's future
-------------------

Once this support for matplotlib is working to satisfaction, it will mean the 
end of the line for any more feature-related changes to ipython for quite a 
while.  Once this is reasonably shaken (I hope with at most one more release 
beyond 0.6.3, which will officially include this), I plan on beginning the 
long-awaited internal cleanup of ipython.

Given my very limited time, this will mean essentially ZERO new features on 
ipython for quite a while.  It will also mean that the new ipython will:

- require python 2.3: I want to deprecate as much redundant code as I can from 
the ipython distribution.  I'll use optparse and any other new module from the 
stdlib which can help shrink ipython.

- break backwards compatibility in many areas.  In particular, the ipythonrc 
files will become true python files.

- the internal class structure of ipython will drastically change.  If you 
have code which uses ipython via IPython.Shell, you should be fine, as I'll 
try to keep that API stable.  If you've been poking your dirty fingers into 
iplib or ipmaker directly, expect things to break badly, and don't even think 
about complaining :)

Hopefully once this is over, it will mean having a much cleaner ipython, with 
an easy path for including it into GUI shells (such as pycrust), and a sane 
internal code structure.  As the new design shakes down, we'll eventually have 
an ipython 1.0 at last ;)

Because of these changes coming down the pipe, if you have any further patches 
or changes for the current ipython which you'd like to see included, please 
send them NOW to me.  Once I shift gears to the cleanup project, I'll 
unfortunately have to drop most changes not going in that direction, simply 
for lack of time.

I'd like to thank everybody who has contributed to ipython's development so 
far, and to encourage others to join in.  The cleanup should not be too hard, 
and it will open the door for having ipython as the interactive core for very 
high quality python-based environments in the future.

Best regards,

f

Hallo John,

John Hunter wrote:

> Hi Karl, thanks for the report.  Darren Dale noted this problem and
> posted a patch to fix it.  If you have CVS access, it should be fixed
> there.  

Thanks a lot. I tried Darrens fix and it works perfectly now.

Kalle.

>>>>> "Karl-Heinz" == Karl-Heinz Glahe <gl...@kh...> writes:

    Karl-Heinz> Hallo, it seems to me that the scaling of the Y-axis
    Karl-Heinz> gets wrong if the y-values are below 1e-4. (Release
    Karl-Heinz> 0.61.0, OS=Windows 2000 SP4, Python 2.3.4, actual
    Karl-Heinz> wxPython Release) The previous release did not show
    Karl-Heinz> this behavior.

Hi Karl, thanks for the report.  Darren Dale noted this problem and
posted a patch to fix it.  If you have CVS access, it should be fixed
there.  Otherwise, please search the mailing list archives for recent
posts by Darren and you should find the fix.

If his patch (or CVS) does not fix your problem, please let me know.

JDH

Hallo,

it seems to me that the scaling of the Y-axis gets wrong if the
y-values are below 1e-4. (Release 0.61.0, OS=Windows 2000 SP4, Python 
2.3.4, actual wxPython Release)
The previous release did not show this behavior.

Example Code:

import wx
import matplotlib
matplotlib.use('WXAgg')
#with TK it is the same...

from matplotlib.matlab import *

t1 = arange(0.0, 5.0, 0.1)

figure(1)
subplot(211)
plot(t2, cos(2*pi*t2), 'r')
grid(1)
ylabel('As expected')
title('Y-axis scaling OK')

subplot(212)
plot(t2, 1e-4*cos(2*pi*t2), 'r')
ylabel('A lot of zeros')
title('Y-axis scaling wrong, should be 1e-4')
grid(1)
show()

Here you can find a screenshot (about 50 kByte) at

http://home.arcor.de/glahe/Screenshot.jpg



Best regards,

Kalle.

>>>>> "Thomas" == Thomas Barket <tho...@ya...> writes:

    Thomas> John, Tks again for your help.  I thought that you were
    Thomas> running that script in plain old ipython.  I didn't
    Thomas> realize ipython-gtk was different from ipython.  After
    Thomas> reading your last message, I downloaded and began using
    Thomas> ipython 0.6.2 for python 2.3.  I thought ipython-gtk was
    Thomas> some linux variant of ipython (im on windows xp).  I
    Thomas> appreciate now that it is a different animal entirely.  My
    Thomas> mix-up on that.  Sorry for the confusion.

    Thomas> There is no mention of ipython-gtk or pyint-gtk on the
    Thomas> ipython.scipy.org web site.  Is there any documentation
    Thomas> yet that I can see, perhaps tucked away in a cvs branch
    Thomas> somewhere?

    Thomas> I have enough to get going now.

No you don't!  ipython 0.6.2 *will not work* with interactive
matplotlib/gtk.  

ipython-gtk is not mentioned on the ipython site because it is not in
the main release yet.  It is only in CVS (and requires matplotlib CVS
as well) and is not yet fully functional.  That is why I recommended
to use pyint-gtk.py and included it in my email, which was written by
Fernando as an ipython-gtk prototyping script.  pyint-gtk.py will work
with the current matplotlib/gtk and requires no extra packages.

Keep your eyes on this list in the next few weeks for a fully
functional, integrated, ipython-gtk.

Sorry for the complexity - you're just coming into an area that is
being actively developed and changing almost daily.

JDH

John,

Tks again for your help.   I thought that you were running that script in
plain old ipython.  I didn't realize ipython-gtk was different from ipython.
After reading your last message, I downloaded and began using ipython 0.6.2
for python 2.3.  I thought ipython-gtk was some linux variant of ipython (im
on windows xp).  I appreciate now that it is a different animal entirely.
My mix-up on that.  Sorry for the confusion.

There is no mention of ipython-gtk or pyint-gtk on the ipython.scipy.org web
site.  Is there any documentation yet that I can see, perhaps tucked away in
a cvs branch somewhere?

I have enough to get going now.

Tks again,

Tom


-----Original Message-----
From: John Hunter [mailto:jdh...@ac...] 
Sent: Friday, August 20, 2004 8:36 AM
To: Thomas Barket
Cc: mat...@li...
Subject: Re: [Matplotlib-users] Requesting advice on multi-threaded
matplotlib session + grids displaying data

>>>>> "Thomas" == Thomas Barket <tho...@ya...> writes:

    Thomas> John, That makes sense.  Tks vm.

    Thomas> I am still confused on what approach needs to be taken to
    Thomas> get the data grids to be *interactive* from the python
    Thomas> command prompt.  It seems to me that such interactivity
    Thomas> requires threading (ie, creating any new data grid gui
    Thomas> window in its own thread).  Is that correct, or is there
    Thomas> some other way to do it?

OK, I appreciate that it's confusing.  It's not an easy subject.  I suggest
you give http://matplotlib.sourceforge.net/interactive.html
and http://matplotlib.sourceforge.net/faq.html#SHOW another reading because
your comments below indicate you haven't fully digested that material.  I
take full responsibility for this, however, because I wrote the docs!

I'll elaborate somewhat.

First a reminder which I think you already understand: matplotlib has an
interactive mode and a non-interactive mode.  You want to use the
interactive mode, set 'interactive : True' in your rc file.  In interactive
mode do not call show, ever.  OK.

Your real problem is how to start the mainloop vis-a-vis threading.
The answer is (for gtk/gtkagg), use a custom python shell for pygtk.
The idea here is that the custom shell starts the mainloop for you.
When you import matplotlib with interactive on from one of these shells, the
mainloop is already started in a separate thread, and you can issue plot
commands and get immediate responses without losing control of the prompt.
Of course, you can launch other gtk windows and widgets too.

There are a variety of python shells out there for pygtk, but I strongly
recommend you start with Fernando Perez's pyint-gtk.py.  
If you notice in my last post to you, I wrote

  > Here is an example using Fernando's ipython-gtk
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  > hunter:~/python/examples/pygtk> python ~/tmp/ip/ipython-gtk.py
  > Python 2.3.2 (#1, Oct 13 2003, 11:33:15)
  > [GCC 3.3.1] on linux2
  > Type "copyright", "credits" or "license" for more information.
  > (MatplotlibShell)

  > 1 >>> from matplotlib.numerix import rand
  > 2 >>> from array_to_grid import view_array
  > 3 >>> view_array( rand(20,10))
  > Out[3]: <ArrayView object (GtkWindow) at 0x4136db94>

I would have emphasized that but I wrongly assumed you knew you needed a
threaded GTK shell.  I guess I've been doing this too long :-)

pyint-gtk.py is just a temporary proof-of-concept to lay the groundwork for
ipython-gtk, which will be a full featured ipython shell with gtk/matplotlib
support.  If you haven't checked out ipython, you should, as it's *very
nice* for interactive work.
Nonetheless, the current release of ipython doesn't support gtk/matplotlib,
and pyint-gtk.py is as good as the standard shell.
Plus we need testers, because the guts of this shell will become the guts of
ipython-gtk.

If you start it with 

  > python pyint-gtk.py -mplot 

it will not only start the gtk mainloop but will import all of matplotlib,
so if the first command you type is

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

a plot will pop up.  And you can import and use the view_array code I posted
before as well.

I'll include the src for pyint-gtk.py here, as it is short

Hope this helps,
JDH

#!/usr/bin/env python
"""Multithreaded interactive interpreter with GTK and Matplotlib support.

Usage:

  pyint-gtk.py -> starts shell with gtk thread running separately

  pyint-gtk.py -mplot [filename] -> initializes matplotlib, optionally
running
  the named file.  The shell starts after the file is executed.

Threading code inspired by:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, by Brian
McErlean and John Finlay.

Matplotlib support taken from interactive.py in the matplotlib distribution.

Also borrows liberally from code.py in the Python standard library."""

__author__ = "Fernando Perez <Fer...@co...>"

import sys
import code
import threading

import pygtk
pygtk.require("2.0")
import gtk

try:
    import readline
except ImportError:
    has_readline = False
else:
    has_readline = True

class MTConsole(code.InteractiveConsole):
    """Simple multi-threaded shell"""

    def __init__(self,on_kill=None,*args,**kw):
        code.InteractiveConsole.__init__(self,*args,**kw)
        self.code_to_run = None
        self.ready = threading.Condition()
        self._kill = False
        if on_kill is None:
            on_kill = []
        # Check that all things to kill are callable:
        for _ in on_kill:
            if not callable(_):
                raise TypeError,'on_kill must be a list of callables'
        self.on_kill = on_kill
        # Set up tab-completer
        if has_readline:
            import rlcompleter
            try:  # this form only works with python 2.3
                self.completer = rlcompleter.Completer(self.locals)
            except: # simpler for py2.2
                self.completer = rlcompleter.Completer()
                
            readline.set_completer(self.completer.complete)
            # Use tab for completions
            readline.parse_and_bind('tab: complete')
            # This forces readline to automatically print the above list
when tab
            # completion is set to 'complete'.
            readline.parse_and_bind('set show-all-if-ambiguous on')
            # Bindings for incremental searches in the history. These
searches
            # use the string typed so far on the command line and search
            # anything in the previous input history containing them.
            readline.parse_and_bind('"\C-r": reverse-search-history')
            readline.parse_and_bind('"\C-s": forward-search-history')

    def runsource(self, source, filename="<input>", symbol="single"):
        """Compile and run some source in the interpreter.

        Arguments are as for compile_command().

        One several things can happen:

        1) The input is incorrect; compile_command() raised an
        exception (SyntaxError or OverflowError).  A syntax traceback
        will be printed by calling the showsyntaxerror() method.

        2) The input is incomplete, and more input is required;
        compile_command() returned None.  Nothing happens.

        3) The input is complete; compile_command() returned a code
        object.  The code is executed by calling self.runcode() (which
        also handles run-time exceptions, except for SystemExit).

        The return value is True in case 2, False in the other cases (unless
        an exception is raised).  The return value can be used to
        decide whether to use sys.ps1 or sys.ps2 to prompt the next
        line.
        """
        try:
            code = self.compile(source, filename, symbol)
        except (OverflowError, SyntaxError, ValueError):
            # Case 1
            self.showsyntaxerror(filename)
            return False

        if code is None:
            # Case 2
            return True

        # Case 3
        # Store code in self, so the execution thread can handle it
        self.ready.acquire()
        self.code_to_run = code
        self.ready.wait()  # Wait until processed in timeout interval
        self.ready.release()

        return False

    def runcode(self):
        """Execute a code object.

        When an exception occurs, self.showtraceback() is called to display
a
        traceback."""

        self.ready.acquire()
        if self._kill:
            print 'Closing threads...',
            sys.stdout.flush()
            for tokill in self.on_kill:
                tokill()
            print 'Done.'

        if self.code_to_run is not None:
            self.ready.notify()
            code.InteractiveConsole.runcode(self,self.code_to_run)

        self.code_to_run = None
        self.ready.release()
        return True

    def kill (self):
        """Kill the thread, returning when it has been shut down."""
        self.ready.acquire()
        self._kill = True
        self.ready.release()

class GTKInterpreter(threading.Thread):
    """Run a gtk mainloop() in a separate thread.
    Python commands can be passed to the thread where they will be executed.
    This is implemented by periodically checking for passed code using a
    GTK timeout callback.
    """
    TIMEOUT = 100 # Milisecond interval between timeouts.
    
    def __init__(self,banner=None):
        threading.Thread.__init__(self)
        self.banner = banner
        self.shell = MTConsole(on_kill=[gtk.mainquit])

    def run(self):
        self.pre_interact()
        self.shell.interact(self.banner)
        self.shell.kill()

    def mainloop(self):
        self.start()
        gtk.timeout_add(self.TIMEOUT, self.shell.runcode)
        try:
            if gtk.gtk_version[0] >= 2:
                gtk.threads_init()
        except AttributeError:
            pass
        gtk.mainloop()
        self.join()

    def pre_interact(self):
        """This method should be overridden by subclasses.

        It gets called right before interact(), but after the thread starts.
        Typically used to push initialization code into the interpreter"""
        
        pass

class MatplotLibInterpreter(GTKInterpreter):
    """Threaded interpreter with matplotlib support."""

    def __init__(self,banner=None):
        banner = """\nWelcome to matplotlib, a matlab-like python
environment.
    help(matlab)   -> help on matlab compatible commands from matplotlib.
    help(plotting) -> help on plotting commands.
    """
        GTKInterpreter.__init__(self,banner)
        
    def pre_interact(self):
        """Initialize matplotlib before user interaction begins"""

        push = self.shell.push
        # Code to execute in user's namespace
        lines = ["import matplotlib",
                 "matplotlib.use('GTKAgg')",
                 "matplotlib.interactive(1)",
                 "import matplotlib.matlab as matlab",
                 "from matplotlib.matlab import *"]

        map(push,lines)
        
        

        # Execute file if given.
        if len(sys.argv)>1:
            import matplotlib
            matplotlib.interactive(0) # turn off interaction
            fname = sys.argv[1]
            try:
                inFile = file(fname, 'r')
            except IOError:
                print '*** ERROR *** Could not read file <%s>' % fname
            else:
                print '*** Executing file <%s>:' % fname
                for line in inFile:
                    if line.lstrip().find('show()')==0: continue
                    print '>>', line,
                    push(line)
                inFile.close()
            matplotlib.interactive(1)   # turn on interaction

if __name__ == '__main__':
    # Quick sys.argv hack to extract the option and leave filenames in
sys.argv.
    # For real option handling, use optparse or getopt.
    if len(sys.argv) > 1 and sys.argv[1]=='-mplot':
        sys.argv = [sys.argv[0]]+sys.argv[2:]
        MatplotLibInterpreter().mainloop()
    else:
        GTKInterpreter().mainloop()

>>>>> "Thomas" == Thomas Barket <tho...@ya...> writes:

    Thomas> John, That makes sense.  Tks vm.

    Thomas> I am still confused on what approach needs to be taken to
    Thomas> get the data grids to be *interactive* from the python
    Thomas> command prompt.  It seems to me that such interactivity
    Thomas> requires threading (ie, creating any new data grid gui
    Thomas> window in its own thread).  Is that correct, or is there
    Thomas> some other way to do it?

OK, I appreciate that it's confusing.  It's not an easy subject.  I
suggest you give http://matplotlib.sourceforge.net/interactive.html
and http://matplotlib.sourceforge.net/faq.html#SHOW another reading
because your comments below indicate you haven't fully digested that
material.  I take full responsibility for this, however, because I
wrote the docs!

I'll elaborate somewhat.

First a reminder which I think you already understand: matplotlib has
an interactive mode and a non-interactive mode.  You want to use the
interactive mode, set 'interactive : True' in your rc file.  In
interactive mode do not call show, ever.  OK.

Your real problem is how to start the mainloop vis-a-vis threading.
The answer is (for gtk/gtkagg), use a custom python shell for pygtk.
The idea here is that the custom shell starts the mainloop for you.
When you import matplotlib with interactive on from one of these
shells, the mainloop is already started in a separate thread, and you
can issue plot commands and get immediate responses without losing
control of the prompt.  Of course, you can launch other gtk windows
and widgets too.

There are a variety of python shells out there for pygtk, but I
strongly recommend you start with Fernando Perez's pyint-gtk.py.  
If you notice in my last post to you, I wrote

  > Here is an example using Fernando's ipython-gtk
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  > hunter:~/python/examples/pygtk> python ~/tmp/ip/ipython-gtk.py
  > Python 2.3.2 (#1, Oct 13 2003, 11:33:15)
  > [GCC 3.3.1] on linux2
  > Type "copyright", "credits" or "license" for more information.
  > (MatplotlibShell)

  > 1 >>> from matplotlib.numerix import rand
  > 2 >>> from array_to_grid import view_array
  > 3 >>> view_array( rand(20,10))
  > Out[3]: <ArrayView object (GtkWindow) at 0x4136db94>

I would have emphasized that but I wrongly assumed you knew you needed
a threaded GTK shell.  I guess I've been doing this too long :-)

pyint-gtk.py is just a temporary proof-of-concept to lay the
groundwork for ipython-gtk, which will be a full featured ipython
shell with gtk/matplotlib support.  If you haven't checked out
ipython, you should, as it's *very nice* for interactive work.
Nonetheless, the current release of ipython doesn't support
gtk/matplotlib, and pyint-gtk.py is as good as the standard shell.
Plus we need testers, because the guts of this shell will become the
guts of ipython-gtk.

If you start it with 

  > python pyint-gtk.py -mplot 

it will not only start the gtk mainloop but will import all of
matplotlib, so if the first command you type is

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

a plot will pop up.  And you can import and use the view_array code I
posted before as well.

I'll include the src for pyint-gtk.py here, as it is short

Hope this helps,
JDH

#!/usr/bin/env python
"""Multithreaded interactive interpreter with GTK and Matplotlib support.

Usage:

  pyint-gtk.py -> starts shell with gtk thread running separately

  pyint-gtk.py -mplot [filename] -> initializes matplotlib, optionally running
  the named file.  The shell starts after the file is executed.

Threading code inspired by:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, by Brian
McErlean and John Finlay.

Matplotlib support taken from interactive.py in the matplotlib distribution.

Also borrows liberally from code.py in the Python standard library."""

__author__ = "Fernando Perez <Fer...@co...>"

import sys
import code
import threading

import pygtk
pygtk.require("2.0")
import gtk

try:
    import readline
except ImportError:
    has_readline = False
else:
    has_readline = True

class MTConsole(code.InteractiveConsole):
    """Simple multi-threaded shell"""

    def __init__(self,on_kill=None,*args,**kw):
        code.InteractiveConsole.__init__(self,*args,**kw)
        self.code_to_run = None
        self.ready = threading.Condition()
        self._kill = False
        if on_kill is None:
            on_kill = []
        # Check that all things to kill are callable:
        for _ in on_kill:
            if not callable(_):
                raise TypeError,'on_kill must be a list of callables'
        self.on_kill = on_kill
        # Set up tab-completer
        if has_readline:
            import rlcompleter
            try:  # this form only works with python 2.3
                self.completer = rlcompleter.Completer(self.locals)
            except: # simpler for py2.2
                self.completer = rlcompleter.Completer()
                
            readline.set_completer(self.completer.complete)
            # Use tab for completions
            readline.parse_and_bind('tab: complete')
            # This forces readline to automatically print the above list when tab
            # completion is set to 'complete'.
            readline.parse_and_bind('set show-all-if-ambiguous on')
            # Bindings for incremental searches in the history. These searches
            # use the string typed so far on the command line and search
            # anything in the previous input history containing them.
            readline.parse_and_bind('"\C-r": reverse-search-history')
            readline.parse_and_bind('"\C-s": forward-search-history')

    def runsource(self, source, filename="<input>", symbol="single"):
        """Compile and run some source in the interpreter.

        Arguments are as for compile_command().

        One several things can happen:

        1) The input is incorrect; compile_command() raised an
        exception (SyntaxError or OverflowError).  A syntax traceback
        will be printed by calling the showsyntaxerror() method.

        2) The input is incomplete, and more input is required;
        compile_command() returned None.  Nothing happens.

        3) The input is complete; compile_command() returned a code
        object.  The code is executed by calling self.runcode() (which
        also handles run-time exceptions, except for SystemExit).

        The return value is True in case 2, False in the other cases (unless
        an exception is raised).  The return value can be used to
        decide whether to use sys.ps1 or sys.ps2 to prompt the next
        line.
        """
        try:
            code = self.compile(source, filename, symbol)
        except (OverflowError, SyntaxError, ValueError):
            # Case 1
            self.showsyntaxerror(filename)
            return False

        if code is None:
            # Case 2
            return True

        # Case 3
        # Store code in self, so the execution thread can handle it
        self.ready.acquire()
        self.code_to_run = code
        self.ready.wait()  # Wait until processed in timeout interval
        self.ready.release()

        return False

    def runcode(self):
        """Execute a code object.

        When an exception occurs, self.showtraceback() is called to display a
        traceback."""

        self.ready.acquire()
        if self._kill:
            print 'Closing threads...',
            sys.stdout.flush()
            for tokill in self.on_kill:
                tokill()
            print 'Done.'

        if self.code_to_run is not None:
            self.ready.notify()
            code.InteractiveConsole.runcode(self,self.code_to_run)

        self.code_to_run = None
        self.ready.release()
        return True

    def kill (self):
        """Kill the thread, returning when it has been shut down."""
        self.ready.acquire()
        self._kill = True
        self.ready.release()

class GTKInterpreter(threading.Thread):
    """Run a gtk mainloop() in a separate thread.
    Python commands can be passed to the thread where they will be executed.
    This is implemented by periodically checking for passed code using a
    GTK timeout callback.
    """
    TIMEOUT = 100 # Milisecond interval between timeouts.
    
    def __init__(self,banner=None):
        threading.Thread.__init__(self)
        self.banner = banner
        self.shell = MTConsole(on_kill=[gtk.mainquit])

    def run(self):
        self.pre_interact()
        self.shell.interact(self.banner)
        self.shell.kill()

    def mainloop(self):
        self.start()
        gtk.timeout_add(self.TIMEOUT, self.shell.runcode)
        try:
            if gtk.gtk_version[0] >= 2:
                gtk.threads_init()
        except AttributeError:
            pass
        gtk.mainloop()
        self.join()

    def pre_interact(self):
        """This method should be overridden by subclasses.

        It gets called right before interact(), but after the thread starts.
        Typically used to push initialization code into the interpreter"""
        
        pass

class MatplotLibInterpreter(GTKInterpreter):
    """Threaded interpreter with matplotlib support."""

    def __init__(self,banner=None):
        banner = """\nWelcome to matplotlib, a matlab-like python environment.
    help(matlab)   -> help on matlab compatible commands from matplotlib.
    help(plotting) -> help on plotting commands.
    """
        GTKInterpreter.__init__(self,banner)
        
    def pre_interact(self):
        """Initialize matplotlib before user interaction begins"""

        push = self.shell.push
        # Code to execute in user's namespace
        lines = ["import matplotlib",
                 "matplotlib.use('GTKAgg')",
                 "matplotlib.interactive(1)",
                 "import matplotlib.matlab as matlab",
                 "from matplotlib.matlab import *"]

        map(push,lines)
        
        

        # Execute file if given.
        if len(sys.argv)>1:
            import matplotlib
            matplotlib.interactive(0) # turn off interaction
            fname = sys.argv[1]
            try:
                inFile = file(fname, 'r')
            except IOError:
                print '*** ERROR *** Could not read file <%s>' % fname
            else:
                print '*** Executing file <%s>:' % fname
                for line in inFile:
                    if line.lstrip().find('show()')==0: continue
                    print '>>', line,
                    push(line)
                inFile.close()
            matplotlib.interactive(1)   # turn on interaction

if __name__ == '__main__':
    # Quick sys.argv hack to extract the option and leave filenames in sys.argv.
    # For real option handling, use optparse or getopt.
    if len(sys.argv) > 1 and sys.argv[1]=='-mplot':
        sys.argv = [sys.argv[0]]+sys.argv[2:]
        MatplotLibInterpreter().mainloop()
    else:
        GTKInterpreter().mainloop()

John,

That makes sense.  Tks vm.  

I am still confused on what approach needs to be taken to get the data grids
to be *interactive* from the python command prompt.  It seems to me that
such interactivity requires threading (ie, creating any new data grid gui
window in its own thread).  Is that correct, or is there some other way to
do it?

In fact, with the example below, in order to get it to work, I needed to add
a couple of lines to call the mainloop:

>>> from matplotlib.numerix import rand
>>> from array_to_grid import view_array
>>> view_array( rand(20,10))
<ArrayView object (GtkWindow) at 0x1136eb8>
>>> import gtk
>>> gtk.main()

After I call gtk.main(), I then lose all ability to interact with the python
command prompt :-(.  This gui mainloop concept is something I am a little
confused on.  I understand why one has to call such a mainloop for a gui: so
the gui window can be alerted by the os that some kind of event has been
fired, like a mouse click, so it can respond in the appropriate manner.  But
I don't want to create an application that takes over the mainloop.  I am
not writing a window-driven application.  I want to continue to interact
with the python command prompt (and hopefully be able to interact with any
launched gui windows from it).  So I suppose I have to figure out how to get
such mainloops to run in separate threads (or is "process" the correct word
here???) in order to have access to the python command prompt (and possibly
even create more data grids!).  Is that correct?  Im also a little confused
bc I have read statements like "all graphics commands should be handled in a
single thread."  The "Thinking in Tkinter" web site
(http://www.ferg.org/thinking_in_tkinter/index.html) says:

          Note that you should not run these programs under IDLE.   
          IDLE is itself a Tkinter application, with its own 
          "mainloop" that will conflict with the mainloop in these 
          programs. If you really want to view and run these 
          programs using IDLE, then -- for each program -- you
          should comment out the "mainloop" statement in the 
          program before running it.

That kind of warning sounds a little depressing.  Is it not possible to
(somewhat easily) launch various gui windows, like a data grid, in their own
threads (processes?) and still have control of the python command prompt and
be able to interact with such gui windows?

Any pointers anyone can give me to learn more about launching interactive
gui widgets from the python command prompt and maintaining interactivity
with the python command prompt would be greatly appreciated.  

Many thanks once again.

Sincerely,

Tom

 
-----Original Message-----
From: John Hunter [mailto:jdh...@ac...] 
Sent: Wednesday, August 18, 2004 1:31 PM
To: Thomas Barket
Cc: mat...@li...
Subject: Re: [Matplotlib-users] Requesting advice on multi-threaded
matplotlib session + grids displaying data

>>>>> "Thomas" == Thomas Barket <tho...@ya...> writes:

    Thomas> Btw, what does "TkAgg sets interactive mode to True when
    Thomas> you issue the show command" mean exactly?

It means that if you are using tkagg and issue show, it launches the
interactive interpreter (python shell)

    Thomas> Wx has such a grid widget which can be used for
    Thomas> displaying/editing data, which is what I was hoping to
    Thomas> use.  However, I am not sure if one should mix different
    Thomas> gui's.  Iow, if I use tkagg or gtk as my interactive
    Thomas> matplotlib gui, can I also display and interact with
    Thomas> wxpython grid widgets in the same script smoothly?  Am I
    Thomas> asking for trouble having the same script display
    Thomas> interactive matplotlib charts using one gui type and then
    Thomas> display these grid widgets using another gui type?  Or
    Thomas> should I just stick with one gui type throughout the
    Thomas> entire script so that the interactive matplotlib charts
    Thomas> use say gtk and the same script also uses gtk for its grid
    Thomas> widgets?

OK, now I see better where you are coming from.  You have a deluge of data
coming back from the prompt in the interactive shell and are looking for a
better way to deal with it.  This is really beyond the scope of matplotlib
since it is a plotting library and your question goes more to interacting
with data.  See ipython for solutions to facilitate better interaction with
data.

I can give you a couple of pointers though.

If you save the return value of a plot as a named variable, the output will
be suppressed.  Then you can use array slicing to only show a portion of it.


  1 >>> n, bins, patches = hist(randn(10000), 100) # no output printed
  2 >>> n[:5]  # look at your data in slices using indexing
  Out[2]: [1,1,2,5,3,]

ipython has additional features to automatically suppress really large
arrays

  1 >>> rand(100,100)
  Out[1]: array (100,100) , type = d, has 10000 elements

On to your question about mixing GUIs.  Don't do it.  You will explode.

If you want to display your data in a wx grid, you could use the wxagg
matplotlib backend and write some functions to display the data in a wx
grid.  Eg, if you are working in a shell that supports wx interactive work
(pycrust), you could write a function to display any array or vector in a wx
grid and then call that function interactively.  Fernando is working on an
interactive shell (mentioned
previously) that supports matplotlib/gtk.  Once he gets the kinks worked
out, he plans to support matplotlib/wx as well.

If you want to work in gtk (eg matplotlib/gtkagg) the equivalent to a wx
grid is a treeview/liststore.  You can write functions to pipe arrays into
grids and then display them by calling that function interactively.  Here is
an example using Fernando's ipython-gtk

  hunter:~/python/examples/pygtk> python ~/tmp/ip/ipython-gtk.py
  Extra content at the end of the document
  Python 2.3.2 (#1, Oct 13 2003, 11:33:15)
  [GCC 3.3.1] on linux2
  Type "copyright", "credits" or "license" for more information.
  (MatplotlibShell)

  1 >>> from matplotlib.numerix import rand
  2 >>> from array_to_grid import view_array
  3 >>> view_array( rand(20,10))
  Out[3]: <ArrayView object (GtkWindow) at 0x4136db94>

And this is the screenshot -
http://nitace.bsd.uchicago.edu:8080/files/share/Screenshot-Ipython-gtk.py.pn
g

While it would be possible for us to write functions in matplotlib that
would implement view_array (or something like it) for each of the GUI
backends, allowing you to call this function for tk, wx or gtk, it's really
beyond the scope of matplotlib (we're busy enough trying to plot!).  It's
more in the domain of a matlab / mathematica like integrated scientific
computing environment, another topic near and dear to Fernando's heart.

Here is the code array_to_grid.py - you can do a lot more with treeviews and
liststores, eg make a proper editable spreadsheet interface with scroll bars
in both x and y directions, but this will get you started

'Display an array as a treeview'

import pygtk
pygtk.require('2.0')
import gobject
import gtk
from gtk import gdk

def view_array(X):
    'instantiate an ArrayView instance and show it'
    grid = ArrayView(X)
    grid.show_all()
    return grid
    
class ArrayView(gtk.Window):

    def __init__(self, X):
        gtk.Window.__init__(self)

        self.numRows, self.numCols = X.shape
        self.data = X

        self.set_title('Array display')
        self.set_border_width(8)

        vbox = gtk.VBox(False, 8)
        self.add(vbox)

        sw = gtk.ScrolledWindow()
        sw.set_shadow_type(gtk.SHADOW_ETCHED_IN)
        sw.set_policy(gtk.POLICY_NEVER,
                      gtk.POLICY_AUTOMATIC)
        vbox.pack_start(sw, True, True)

        model = self.create_model()

        self.treeview = gtk.TreeView(model)
        self.treeview.set_rules_hint(True)


        sw.add(self.treeview)

        self.add_columns()

        self.set_default_size(640, 480)

        self.add_events(gdk.BUTTON_PRESS_MASK |
                       gdk.KEY_PRESS_MASK|
                       gdk.KEY_RELEASE_MASK)


    def add_columns(self):
        model = self.treeview.get_model()
        renderer = gtk.CellRendererText()

        for i in range(self.numCols):
            column = gtk.TreeViewColumn('%d'%i, gtk.CellRendererText(),
text=i)
            self.treeview.append_column(column)

    def create_model(self):
        types = [gobject.TYPE_DOUBLE]*self.numCols
        store = gtk.ListStore(*types)

        for row in self.data:
            iter = store.append()
            pairs = []
            for i, num in enumerate(row): pairs.extend((i, num))

            store.set(iter, *pairs)
        return store

                                     
if __name__=='__main__':
    from matplotlib.numerix import rand
    view_array(rand(10,10))
    gtk.main()

John Hunter wrote:

> Yes, and along those lines for the GTK shell, we should use
> rcParams['backend'] to detect GTK versus GTKAgg and use whichever is
> in the rc file in the call to matplotlib.use.

Ok.  I may take a first stab at this in a day or two, but no promises.

> good.  As for problems with wx, I can't really say until we try.

I can :(  I just tried, and the new code (which doesn't lock up gv), will 
never start if the backend chosen is WX.  But it may be a matter of thread 
conflicts or something, since pygtk calls are still being made.  Let's get 
Tk*/Gtk* working first, with a well-localized set of thread calls only when 
needed.  With a clean enough base, putting the WX code in the right place 
should be reasonably easy.  Perhaps Andrew (who wanted to hack matplotlib a 
bit) might help along in LA.

Cheers,

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:


    >> push = self.shell.push # Code to execute in user's namespace
    >> lines = ["import matplotlib",
    ---> "matplotlib.use('GTKAgg')",
    >> "matplotlib.interactive(1)", "import matplotlib.matlab as
    >> matlab", "from matplotlib.matlab import *"] You might make the
    >> additional caveat in the docs about honoring rc settings that
    >> the default backend is overridden.

    Fernando> Well, actually I think we should honor the user's rc
    Fernando> choice, don't you?  In fact, the ipython version does
    Fernando> this, so the equivalent here would be just to comment
    Fernando> out the line you highlighted.

Yes, and along those lines for the GTK shell, we should use
rcParams['backend'] to detect GTK versus GTKAgg and use whichever is
in the rc file in the call to matplotlib.use.


    Fernando> Cool.  I'll integrate Antoon's and your fixes into the
    Fernando> 'real' (read ipython-based) code, and we'll play with
    Fernando> that a bit.  Do you foresee any problems with the WX
    Fernando> backend?  Right now I have global pygtk calls, but I
    Fernando> suppose those should be done only by the matplotlib
    Fernando> shell class IF Gtk is the chosen backend.  

Relocating the pygtk calls into the backend dependent section sounds
good.  As for problems with wx, I can't really say until we try.

Thanks!
JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
>     Fernando> ps. John, I think we almost have this nailed :)
> 
> Don't tempt the fates -- I got an X11 freeze.  But I think I fixed it.

Hey, I said _almost_ :)

>     def pre_interact(self):
>         """Initialize matplotlib before user interaction begins"""
> 
> --->    import matplotlib.matlab
> 
> I don't think you want this, especially not here.  Remember that all
> the matplotlib.use and matplotlib.interactive calls should be made
> *before* importing matplotlib.matlab (which is when the actual backend
> is imported)

Noted.

>         push = self.shell.push
>         # Code to execute in user's namespace
>         lines = ["import matplotlib",
> --->             "matplotlib.use('GTKAgg')",
>                  "matplotlib.interactive(1)",
>                  "import matplotlib.matlab as matlab",
>                  "from matplotlib.matlab import *"]
>    
> You might make the additional caveat in the docs about honoring rc
> settings that the default backend is overridden.

Well, actually I think we should honor the user's rc choice, don't you?  In 
fact, the ipython version does this, so the equivalent here would be just to 
comment out the line you highlighted.

> 
>         map(push,lines)
> 
>         # turn off rendering until end of script
> --->     matplotlib.matlab.interactive = 0
> 
> I'm pretty sure you mean matplotlib.interactive(0) -- ie, it's a
> function, not a variable, and it isn't in the matlab interface module.
> And don't you want to turn off interaction only if they load a file,
> and then turn it back on?  Ie,
[...]

Ok. In fact, in the ipython-based version you and I have floated, this was 
alreadey fixed (by you).  But I'll double-check as soon as I can get that done 
(probably this evening).  I asked the pygtk crowd for help with the simpler 
pyint-gtk, which did NOT have our recent work, because it made it much easier 
for them to test without asking them to download CVS ipython.


> But with these changes, it works great!  Here is my modified version

Cool.  I'll integrate Antoon's and your fixes into the 'real' (read 
ipython-based) code, and we'll play with that a bit.  Do you foresee any 
problems with the WX backend?  Right now I have global pygtk calls, but I 
suppose those should be done only by the matplotlib shell class IF Gtk is the 
chosen backend.  That part of the design needs a bit of polishing, and I may 
have to leave it til we meet at scipy'04.  I still have to put my talks 
together for the meeting, so my hacking time will be very limited for the next 
two weeks.

But we _are_ close :)

Best,

f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> thanks to Antoon Pardon from the pygtk mailing list, 

I told you those guys were brainy :-)

    Fernando> ps. John, I think we almost have this nailed :)

Don't tempt the fates -- I got an X11 freeze.  But I think I fixed it.

    def pre_interact(self):
        """Initialize matplotlib before user interaction begins"""

--->    import matplotlib.matlab

I don't think you want this, especially not here.  Remember that all
the matplotlib.use and matplotlib.interactive calls should be made
*before* importing matplotlib.matlab (which is when the actual backend
is imported)

        push = self.shell.push
        # Code to execute in user's namespace
        lines = ["import matplotlib",
--->             "matplotlib.use('GTKAgg')",
                 "matplotlib.interactive(1)",
                 "import matplotlib.matlab as matlab",
                 "from matplotlib.matlab import *"]
   
You might make the additional caveat in the docs about honoring rc
settings that the default backend is overridden.

        map(push,lines)

        # turn off rendering until end of script
--->     matplotlib.matlab.interactive = 0

I'm pretty sure you mean matplotlib.interactive(0) -- ie, it's a
function, not a variable, and it isn't in the matlab interface module.
And don't you want to turn off interaction only if they load a file,
and then turn it back on?  Ie,

        # Execute file if given.
        if len(sys.argv)>1:
--->        import matplotlib
--->        matplotlib.interactive(0) # turn off interaction
            fname = sys.argv[1]
            try:
                inFile = file(fname, 'r')
            except IOError:
                print '*** ERROR *** Could not read file <%s>' % fname
            else:
                print '*** Executing file <%s>:' % fname
                for line in inFile:
                    if line.lstrip().find('show()')==0: continue
                    print '>>', line,
                    push(line)
                inFile.close()
--->        matplotlib.interactive(1)   # turn on interaction


But with these changes, it works great!  Here is my modified version

#!/usr/bin/env python
"""Multithreaded interactive interpreter with GTK and Matplotlib support.

Usage:

  pyint-gtk.py -> starts shell with gtk thread running separately

  pyint-gtk.py -mplot [filename] -> initializes matplotlib, optionally running
  the named file.  The shell starts after the file is executed.

Threading code inspired by:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, by Brian
McErlean and John Finlay.

Matplotlib support taken from interactive.py in the matplotlib distribution.

Also borrows liberally from code.py in the Python standard library."""

__author__ = "Fernando Perez <Fer...@co...>"

import sys
import code
import threading

import pygtk
pygtk.require("2.0")
import gtk

try:
    import readline
except ImportError:
    has_readline = False
else:
    has_readline = True

class MTConsole(code.InteractiveConsole):
    """Simple multi-threaded shell"""

    def __init__(self,on_kill=None,*args,**kw):
        code.InteractiveConsole.__init__(self,*args,**kw)
        self.code_to_run = None
        self.ready = threading.Condition()
        self._kill = False
        if on_kill is None:
            on_kill = []
        # Check that all things to kill are callable:
        for _ in on_kill:
            if not callable(_):
                raise TypeError,'on_kill must be a list of callables'
        self.on_kill = on_kill
        # Set up tab-completer
        if has_readline:
            import rlcompleter
            try:  # this form only works with python 2.3
                self.completer = rlcompleter.Completer(self.locals)
            except: # simpler for py2.2
                self.completer = rlcompleter.Completer()
                
            readline.set_completer(self.completer.complete)
            # Use tab for completions
            readline.parse_and_bind('tab: complete')
            # This forces readline to automatically print the above list when tab
            # completion is set to 'complete'.
            readline.parse_and_bind('set show-all-if-ambiguous on')
            # Bindings for incremental searches in the history. These searches
            # use the string typed so far on the command line and search
            # anything in the previous input history containing them.
            readline.parse_and_bind('"\C-r": reverse-search-history')
            readline.parse_and_bind('"\C-s": forward-search-history')

    def runsource(self, source, filename="<input>", symbol="single"):
        """Compile and run some source in the interpreter.

        Arguments are as for compile_command().

        One several things can happen:

        1) The input is incorrect; compile_command() raised an
        exception (SyntaxError or OverflowError).  A syntax traceback
        will be printed by calling the showsyntaxerror() method.

        2) The input is incomplete, and more input is required;
        compile_command() returned None.  Nothing happens.

        3) The input is complete; compile_command() returned a code
        object.  The code is executed by calling self.runcode() (which
        also handles run-time exceptions, except for SystemExit).

        The return value is True in case 2, False in the other cases (unless
        an exception is raised).  The return value can be used to
        decide whether to use sys.ps1 or sys.ps2 to prompt the next
        line.
        """
        try:
            code = self.compile(source, filename, symbol)
        except (OverflowError, SyntaxError, ValueError):
            # Case 1
            self.showsyntaxerror(filename)
            return False

        if code is None:
            # Case 2
            return True

        # Case 3
        # Store code in self, so the execution thread can handle it
        self.ready.acquire()
        self.code_to_run = code
        self.ready.wait()  # Wait until processed in timeout interval
        self.ready.release()

        return False

    def runcode(self):
        """Execute a code object.

        When an exception occurs, self.showtraceback() is called to display a
        traceback."""

        self.ready.acquire()
        if self._kill:
            print 'Closing threads...',
            sys.stdout.flush()
            for tokill in self.on_kill:
                tokill()
            print 'Done.'

        if self.code_to_run is not None:
            self.ready.notify()
            code.InteractiveConsole.runcode(self,self.code_to_run)

        self.code_to_run = None
        self.ready.release()
        return True

    def kill (self):
        """Kill the thread, returning when it has been shut down."""
        self.ready.acquire()
        self._kill = True
        self.ready.release()

class GTKInterpreter(threading.Thread):
    """Run a gtk mainloop() in a separate thread.
    Python commands can be passed to the thread where they will be executed.
    This is implemented by periodically checking for passed code using a
    GTK timeout callback.
    """
    TIMEOUT = 100 # Milisecond interval between timeouts.
    
    def __init__(self,banner=None):
        threading.Thread.__init__(self)
        self.banner = banner
        self.shell = MTConsole(on_kill=[gtk.mainquit])

    def run(self):
        self.pre_interact()
        self.shell.interact(self.banner)
        self.shell.kill()

    def mainloop(self):
        self.start()
        gtk.timeout_add(self.TIMEOUT, self.shell.runcode)
        try:
            if gtk.gtk_version[0] >= 2:
                gtk.threads_init()
        except AttributeError:
            pass
        gtk.mainloop()
        self.join()

    def pre_interact(self):
        """This method should be overridden by subclasses.

        It gets called right before interact(), but after the thread starts.
        Typically used to push initialization code into the interpreter"""
        
        pass

class MatplotLibInterpreter(GTKInterpreter):
    """Threaded interpreter with matplotlib support."""

    def __init__(self,banner=None):
        banner = """\nWelcome to matplotlib, a matlab-like python environment.
    help(matlab)   -> help on matlab compatible commands from matplotlib.
    help(plotting) -> help on plotting commands.
    """
        GTKInterpreter.__init__(self,banner)
        
    def pre_interact(self):
        """Initialize matplotlib before user interaction begins"""

        push = self.shell.push
        # Code to execute in user's namespace
        lines = ["import matplotlib",
                 "matplotlib.use('GTKAgg')",
                 "matplotlib.interactive(1)",
                 "import matplotlib.matlab as matlab",
                 "from matplotlib.matlab import *"]

        map(push,lines)
        
        

        # Execute file if given.
        if len(sys.argv)>1:
            import matplotlib
            matplotlib.interactive(0) # turn off interaction
            fname = sys.argv[1]
            try:
                inFile = file(fname, 'r')
            except IOError:
                print '*** ERROR *** Could not read file <%s>' % fname
            else:
                print '*** Executing file <%s>:' % fname
                for line in inFile:
                    if line.lstrip().find('show()')==0: continue
                    print '>>', line,
                    push(line)
                inFile.close()
            matplotlib.interactive(1)   # turn on interaction

if __name__ == '__main__':
    # Quick sys.argv hack to extract the option and leave filenames in sys.argv.
    # For real option handling, use optparse or getopt.
    if len(sys.argv) > 1 and sys.argv[1]=='-mplot':
        sys.argv = [sys.argv[0]]+sys.argv[2:]
        MatplotLibInterpreter().mainloop()
    else:
        GTKInterpreter().mainloop()

Hi all,

thanks to Antoon Pardon from the pygtk mailing list, I now have what appears 
to be a fully working interactive python console for gtk/matplotlib usage, 
which does NOT lock up when things like os.system('gv foo.eps &') are emitted.

I've attached it here, and it would be great if people could take it for a 
spin and let me know how it works.  Just make it executable and run

./pyint-gtk.py -mplot

and it preloads matplotlib for you, honoring your .matplotlibrc settings 
(except that it forces matplotlib to interactive mode).

If this resists a few days of testing, I'll port the mods Anton made to the 
real ipython.

Best regards,

f.

ps. John, I think we almost have this nailed :)

>>>>> "Jon" == Jon Wright <wr...@es...> writes:

    Jon> Hi all, Is there a trick hidden somewhere for autoscaling one
    Jon> axis only? I am frequently plotting data which has a series
    Jon> of narrow peaks and a large dynamic range. After zooming on
    Jon> the x-axis to the region of interest, I'd like to have an
    Jon> option to make the y axis rescale for the data in that range

Just to make sure you know, with the new toolbar2 (matplotlib-0.61)
you can selectively scale the yaxis interactively by pressing the
pan/zoom button, and clicking and dragging your right mouse button
over the y axis while holding down the 'y' key.  Ditto for pan with
the left button.

    Jon> only. Having flailed around in the source I have the feeling
    Jon> that this is possible, but I haven't quite fathomed out how
    Jon> to do it (I'm using matplotlib for an interactive plot
    Jon> embedded in a tk application). Essentially I want the
    Jon> appropriate magic spell to give me a bounding box in y for
    Jon> the current x axis limits. The things I tried so far always
    Jon> seem to give the bounding box for all the data points,
    Jon> including the ones which are not currently being plotted on
    Jon> the x range. Sorry if I've missed something obvious!

No you're not missing anything.  I can give you an idea of how to hack
this though.  The autoscaling is controlled by a tick locator, found
in matplotlib.tickers.  There are a number of locators which derive
from the Locator base class.  You can access the major tick locator of
a given axis with, for example

    locator = ax.yaxis.get_major_locator()

The locator has a method to compute the view limits

  vmin, vmax = locator.autoscale()

It uses a _transforms.Interval instance under the hood to get the data
limits dmin, dmax which gives the min and max range for your data on
that axis.  Of course, this is the min and max for all the y data, not
just the data in the current xrange, which is your problem.

In order to solve this, your need to: 1) compute the data limits in
the current viewport, 2) set the limited data lim on the axis interval
instance, 3) use it to get the new autoscale limits, and 4) reset the
old data lim interval instance back to its original setting.  Assuming
you know the y data lim in the xrange of interest (more on that later)
you would do (untested but should work barring an obvious screw up)

  interval = ax.yaxis.get_data_interval()
  savemin, savemax = interval.get_bounds()
  dmin, dmax = # compute the y data limits in this xrange as below
  interval.set_bounds(dmin, dmax)

  # the locator has a ref to the interval and so sees your changes
  ax.set_ylim(locator.autoscale())  # autoscale returns (vmin, vmax)
  
  # now reset the original data lim
  interval.set_bounds(savemin, savemax)

The only remaining thing is to get the ydata in xrange.  This depends
on the kind of data you plotted, but let's assume it is from 'plot'
and thus your data are stored in Line2D instances.  With a single line
(eg returned by the call) 'line, = plot(x,y)' (note the comma for
tuple unpacking) you can do

  import matplotlib.numerix as nx
  xmin, xmax = ax.get_xlim()
  xdata  = line.get_xdata()
  ydata  = line.get_xdata()
  ind = nx.nonzero(mx.logical_and(nx.greater_equal(xdata, xmin)
                                  nx.less_equal(xdata, xmax)))
  y = nx.take(ydata, ind)
  dmin, dmax = min(y), max(y)
  
  # and now set the data lim in the interval instance as indicated
  # above

Now that's the process for a single line.  For multiple lines, all you
need to do is keep a running total of all the data to get the min/max
of all the lines.  The function ax.get_lines() will return all the
data lines matplotlib uses.  If you have scatters, pcolors and other
kinds of plots which may use collections and other data structures,
then more work would be needed still.  However, you may have direct
access to your data, in which case you can just use that to extract
the ydata in the range.

BTW, there has been some discussion on the devel list recently about a
plugin feature to support easy customization and extension of the
toolbar.  This kind of thing is a perfect candidate for that, because
you could create a plugin for 'autoscale y in the current xrange' and
we could place it in a contrib plugin dir that others could add to
their toolbar when they want.

Hope this helps,
JDH

  

> Hi Jean-Michel,
> 
> I spoke with with Paul Barrett (who wrote the font manager and has
> done a lot of work with fonts/text) about your problem and neither he
> nor I have any immediate insight into your problem, so I just wanted
> to let you know that we'll look into it and see if we can improve
> international / unicode support, but it may be a little while before
> we can solve this problem.
> 
> Thanks for letting us know.
> JDH

Hi JD,

That's ok, I must say that seeing the silence around my mail I 
understood that this should be the first time this kind of problem occurs!

I know that internationalization is not a simple issue so I would not be 
surprised if it is not quickly solved. Let me know if you need 
volunteers for testing.

JM. Philippe

>>>>> "Jean-Michel" == Jean-Michel Philippe <jea...@ir...> writes:

    Jean-Michel> Hi, I'm new to matplotlib which is really good job
    Jean-Michel> ;-) and I'm currently fighting against character
    Jean-Michel> encodings :-(.  Being working under win2k/western
    Jean-Michel> Europe, I finally found on the web that using a cp850
    Jean-Michel> source encoding definition was working with 'print'
    Jean-Michel> only if you also encode your strings from cp1252!
    Jean-Michel> (for us/en users: windows uses cp1252 but the console
    Jean-Michel> uses cp850, this message was written using
    Jean-Michel> iso-8859-1).  Example:

Hi Jean-Michel,

I spoke with with Paul Barrett (who wrote the font manager and has
done a lot of work with fonts/text) about your problem and neither he
nor I have any immediate insight into your problem, so I just wanted
to let you know that we'll look into it and see if we can improve
international / unicode support, but it may be a little while before
we can solve this problem.

Thanks for letting us know.
JDH

>>>>> "Sigve" == Sigve Tjora <pu...@tj...> writes:

    Sigve> Hi everyone, Is there any planned support for a Qt-backend?
    Sigve> We are using Qt in our project, and I would like to use
    Sigve> Matplot lib for plotting.

    Sigve> If there is not any support for Qt how hard would it be to
    Sigve> make it myself? Would it be best to base it on the Agg
    Sigve> backend, or should I make a native Qt backend? What is the
    Sigve> least work? Is it possible to write the whole backend in
    Sigve> Python or should I use C++ in addition?

Currently there is no QT backend, or one in the works, but it would be
nice.  It is definitely much easier to base it on the agg backend and
is in fact *strongly encouraged* as that minimizes the amount of
maintenance required.  

Using C/C++ is an optional step.  TkAgg and GTKAgg use it to get the
optimal transfer speed from the agg image to the GUI canvas.  WXAgg
and FLTKAgg do not use it, and Gregory reports great performance for
FLTKAgg.  WXAgg uses string methods to transfer the image and FLTKAgg
uses a python buffer object.  I encourage you to try and use a python
buffer object (or string method) as opposed to extension code in the
beginning since it's easier to write and maintain, it will introduce
no extra compile time dependencies, and in the event that you find it
too slow and want to write an extension to speed things up, you'll
have the pure python method to fall back on for users who can't get
the extension compiled.

matplotlib.backends.backend_template contains the basic documentation
for backend writers.  But this code does a lot more than you need,
since agg will be doing the drawing; ie you don't need to implement a
renderer or graphics context.  I recommend you give it a read through,
and then follow the lead of backend_fltkagg.  I also advise you not to
implement the classic navigation toolbar (at least not until later)
because the new toolbar design is not only better (in my opinion),
it's currently the default and most importantly, is much easier to
implement since all the work is done for you in backend bases.  You
basically need to load up some images into a toolbar and get the
signal connections right.

In the event you need a different pixel format to transfer the agg
image to the qt canvas, that will be no problem.  I will be glad to
add it for you or you can add it yourself to backend_agg.

The only thing I ask of submitters is that if you want your backend to
be included with the matplotlib distribution, please be responsible
for testing it across the major platforms the GUI should run on (eg
linux, win32, and OSX), provide some install instructions, version
dependencies, etc, for the documentation, and monitor the mailing
lists to handle questions about your backend.  In a nutshell, I need
you to maintain it.  If you don't have the time to maintain it but
want to write one anyway for your own work, I would be happy to
provide a link to it with a disclaimer that users are on their own.

Good luck if you decide to do it, and let me know if I can help.

JDH

Hi all,

Is there a trick hidden somewhere for autoscaling one axis only? I am 
frequently plotting data which has a series of narrow peaks and a large 
dynamic range. After zooming on the x-axis to the region of interest, 
I'd like to have an option to make the y axis rescale for the data in 
that range only. Having flailed around in the source I have the feeling 
that this is possible, but I haven't quite fathomed out how to do it 
(I'm using matplotlib for an interactive plot embedded in a tk 
application). Essentially I want the appropriate magic spell to give me 
a bounding box in y for the current x axis limits. The things I tried so 
far always seem to give the bounding box for all the data points, 
including the ones which are not currently being plotted on the x range. 
Sorry if I've missed something obvious!


Thanks in advance,

Jon

On Wed, 2004-08-18 at 21:45, Dominique Orban wrote:
> Great, this is doing the job nicely, thanks ! I am not very clear as to 
> what the 'subs' argument really does. In your example:
> 
>  > #full control
>  > gca().set_xscale('log',base=100,subs=[10,20,50])
>  > #Major tick every 16**i, minor tick every subs*16**i
> 
> (16 should be 100 right?).

oooouuuups, yes indeed, sorry!

>  There's a major tick at 100, 100^2, 100^3, 
> etc. And you're saying there are minor tick marks at 10*100*i ?!?

hum, not really, minor tick every array([10,20,50])*100**i (I use array
else python (and maybe some reader too familiar with python lists) may
think I mean [10,20,50] concatenated 100**i with itself...that could be
a very long list indeed ;-) )...
So minor ticks at
...0.001,0.002,0.005,0.1,0.2,0.5,10,20,50,1000,2000,5000,...

> What if you'd want tick labels [0, 1, 2, 3, 4, ...] instead of (in base 
> 2, say) [1, 2, 4, 8, 16, ...] ? 
> Is that easily done? I tried to obtain 
> it based on the example custom_ticker1.py (in the examples 
> subdirectory), but haven't been successful so far.

You mean tick labels like a linear plot, but with log ticking? (and
beware of 0, I doubt you will be able to see the 0 label in a log plot
except if you do a *LOT* of paning ;-) ;-P )
If yes, this is not yet possible, because only "major" ticks (the one
corresponding to base**i) are labeled, and what you want is labeling of
all ticks...this would be feasible when I cleanup minor/major ticking
for logscale, in the meantime I added a flag to logformatter to tell
"label all ticks" instead of "label only major ticks".
Then, to do what you want (or what I believe you want ;-) ),
simply do 
gca().set_xscale('log',base=1000,label_minor=True).

the base should be large enough so that your whole xrange is in it, and
by default minor tick will be generated every unit.
Be aware though that due to log spacing, last labels could be very close
to each other and this ain't pretty ;-) That's why I allowed full
control on minor ticks with subs, often you do want to carefully choose
which ticks you want, because you can end up with a black mes of ticks
and labels on the right of your graph if you don't...

> Thanks A LOT for the update of axes.py and ticker.py,

you're welcome,

Greg.