matplotlib-users Mailing List for matplotlib (Page 1432)

Hi,
I installed matlibplot without any problems but when I tried to try it I 
got that error with the import:
 >>> from matplotlib.matlab import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "matplotlib/matlab.py", line 133, in ?
    from axes import Axes
  File "matplotlib/axes.py", line 9, in ?
    from artist import Artist
  File "matplotlib/artist.py", line 4, in ?
    from transforms import identity_transform
  File "matplotlib/transforms.py", line 180, in ?
    from _transforms import Value, Point, Bbox, Affine
ImportError: No module named _transforms
 >>> from matplotlib.matlab import *
 >>> plot([1,2,3,4])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'plot' is not defined

It is weird because it is working the second time I try the same import 
but as you can see, it seems that "plot" is not recognized after all.

Thanks,
Mathieu

>
>
>
>I'm trying to generate dynamic images, using CGI, with matplotlib.  I'd like to have a CGI script return the images directly, instead of having to use savefig() first to write them to a file.
>
>Is there a way to do this?
>
>  
>
Technically yes.
When you are using the GD backend you can simply savefig to a stdout 
stream (ie. via savefig(sys.stdout)).

As of version 0.53 you could not do this (meaning write to a stream) 
directly with the Agg backend. matplotlib wants a file name, but you 
can't simply give it /dev/stdout (at least on a *nix) because it appends 
an extension.

So the bottom line is that if you're using GD then you're good to go. 
With Agg, you can either write to file and then read that in your CGI 
script, or modify the code that handles the writing - at one point 
(~v0.50) I did that for GD before it became part of the distro.

Perhaps John can comment on whether he foresees adding write-to-stream 
functionality with Agg.

-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

On Wed, 2004-05-26 at 13:09, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
>     Todd> This turned out to be really easy so now canvas.draw
>     Todd> triggers a blit and functions more like the other backends.
>     Todd> It's in CVS.  I also found an extraneous draw() so
>     Todd> performance should be better, perhaps 2x.
> 
> Yep, I'm getting about 20fps on my system now.  Much improved.
> 
> Gary, I'm uploading a zip file which has the new matplotlib python
> code.  AFAIK, all the changes were made at the python level (right
> Todd?) 

Yes, the changes were pure Python and limited to backend_tkagg.py.

Todd

> so you should just be able to unzip this in your site-packages
> dir to try the new code.  Let me know if it works, and what kind of
> performance you are getting now.
> 
> http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.zip
> 
> JDH
> 
-- 
Todd Miller <jm...@st...>

Hi,

I'm trying to generate dynamic images, using CGI, with matplotlib.  I'd =
like to have a CGI script return the images directly, instead of having =
to use savefig() first to write them to a file.

Is there a way to do this?


Trevor

Hi,

I'm trying to generate dynamic images, using CGI, with matplotlib.  I'd =
like to have a CGI script return the images directly, instead of having =
to use savefig() first to write them to a file.

Is there a way to do this?


Trevor

>>>>> "Todd" == Todd Miller <jm...@st...> writes:

    Todd> This turned out to be really easy so now canvas.draw
    Todd> triggers a blit and functions more like the other backends.
    Todd> It's in CVS.  I also found an extraneous draw() so
    Todd> performance should be better, perhaps 2x.

Yep, I'm getting about 20fps on my system now.  Much improved.

Gary, I'm uploading a zip file which has the new matplotlib python
code.  AFAIK, all the changes were made at the python level (right
Todd?) so you should just be able to unzip this in your site-packages
dir to try the new code.  Let me know if it works, and what kind of
performance you are getting now.

http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.zip

JDH

Matt Newville wrote:

>Perry Greenfield wrote:
>
>  
>
>>We are trying to have setup.py handle X11-based Tkinter on Mac OS X
>>(to date that is the only Tkinter we use). Does anyone out there
>>use Tkagg with the Aqua-based Tkinter on Mac OS X? We are unclear
>>as to whether the Aqua version is really useful yet.
>>    
>>

It's been a little while since I've gotten down-and-dirty on OS X, but 
as of a year or so ago, I was continually frustrated with Tkinter on OS 
X because of apparent weird little bugs, but I never felt sufficiently 
on top of Tkinter to really believe they were bugs with Tkinter or with 
me.  Anyhow, I switched to wx, and have never been happier.  It looks 
great on Aqua, is totally cross-platform, and XRCed rocks!

>TkAgg with Aqua-based Tkinter works for me on Mac OS X.  (That's
>with matplotlib 0.54 -- I haven't tried the latest CVS with fixes
>for dynamic updates, but am happy to hear it will be faster!). 
>
>The Aqua-based Tkinter is not great, and I would be perfectly happy
>using X11-based Tkinter.  I simply installed the Tkinter with the
>MacPython and its PackageManager.  Is X11-based Tkinter available in
>such a package, or does it require a source build??  A source build
>would be OK with me, but might make it difficult to distribute apps.
>  
>
Fink sticks to the X environment, so I'm 99% sure that if you install 
their Tkinter it'll run on X11.  I think this probably means installing 
Python from fink, too. So you'd have 2 Pythons: Apple's and fink's (in 
/sw/bin/python, I guess).  If you want to distribute apps as a packaged 
.dmg that someone can just download and run on an OS X system, the fink 
route seems a little, uh, challenging.

Good luck!
Andrew

Perry Greenfield wrote:

> We are trying to have setup.py handle X11-based Tkinter on Mac OS X
> (to date that is the only Tkinter we use). Does anyone out there
> use Tkagg with the Aqua-based Tkinter on Mac OS X? We are unclear
> as to whether the Aqua version is really useful yet.

TkAgg with Aqua-based Tkinter works for me on Mac OS X.  (That's
with matplotlib 0.54 -- I haven't tried the latest CVS with fixes
for dynamic updates, but am happy to hear it will be faster!). 

The Aqua-based Tkinter is not great, and I would be perfectly happy
using X11-based Tkinter.  I simply installed the Tkinter with the
MacPython and its PackageManager.  Is X11-based Tkinter available in
such a package, or does it require a source build??  A source build
would be OK with me, but might make it difficult to distribute apps.

--Matt Newville <newville @ cars.uchicago.edu>

We are trying to have setup.py handle X11-based Tkinter on Mac OS X
(to date that is the only Tkinter we use). Does anyone out there
use Tkagg with the Aqua-based Tkinter on Mac OS X? We are unclear
as to whether the Aqua version is really useful yet.

Thanks, Perry Greenfield

>>>>> "matthew" == matthew arnison <ma...@ca...> writes:

    matthew> The call to tick_right() seems to produce different
    matthew> behaviour in 0.54.  Instead of moving the tick labels to
    matthew> the right of the plot, it instead now moves the labels to
    matthew> just inside the left side of the plot. This it to the
    matthew> right of where they were, but not nearly as useful as the
    matthew> original behaviour. :)

    matthew> See the attached screenshot generated from two_scales.py

Hi Matthew, these are my favorite bug fixes - just a single character
change!  In matplotlib.axis.YAxis._get_text2 (on or around line 311),
change

        t =  Text(x=0, y=loc,

to

        t =  Text(x=1, y=loc,

Should cure what ails you.

    matthew> Otherwise, congratulations on another excellent
    matthew> matplotlib release!

Thanks!  Not without a few roadbumps along the way....

JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:

    Peter> Hi: The following script:

    Peter> #!/usr/bin/env python from matplotlib.matlab import *

    Peter> figure(1) plot([0],[0]) show()

Thanks, Peter, for alerting me to this problem.  I'm now adding this
script and several other instances of plotting constants in a variety
of guises to the unit testing scripts.  I think the following fix will
work for you.  Replace matplotlib.axes.Axes.add_line with

    def add_line(self, l):
        "Add a line to the list of plot lines"
        self._set_artist_props(l)
        
        xdata = l.get_xdata()
        ydata = l.get_ydata()
        if l.get_transform() != self.transData:
            xys = self._get_verts_in_data_coords(
                l.get_transform(), zip(xdata, ydata))
            self.update_datalim(xys)
        else:
            # the data are already using the data coord system - no
            # transforms necessary
            minx, maxx = min(xdata), max(xdata)
            miny, maxy = min(ydata), max(ydata)
            if minx==maxx:
                minx -= 1
                maxx += 1

            if miny==maxy:
                miny -= 1
                maxy += 1
                
            corners = ( (minx, miny), (maxx, maxy) )

            self.update_datalim(corners)

        l.set_clip_box(self.bbox)
        self._lines.append(l)

Passes my tests...

JDH

The call to tick_right() seems to produce different behaviour in 0.54. 

Instead of moving the tick labels to the right of the plot, it instead 
now moves the labels to just inside the left side of the plot. This it to 
the right of where they were, but not nearly as useful as the original 
behaviour. :)

See the attached screenshot generated from two_scales.py

Otherwise, congratulations on another excellent matplotlib release!

Cheers,
Matthew.

Inline responses follow ...

----- Original Message -----
> If you open up a DOS command shell and run
>   from matplotlib.matlab import *
>   plot([1,2,3])
>   show()
> with 
>   c:> python myscript.py -dGTKAgg
> what happens?

The hard drive grinds away for a couple of seconds, then I get an Invalid Page Fault dialog with Python in the title bar. When I close the dialog, the DOS prompt returns, so it's not crashing the DOS window. No other windows appear in this sequence.

> When you run from windows explorer and get a traceback,
> you often lose the DOS window that provides the required information.
> So it's best to debug from a command shell, though admittedly most of
> the windows shells suck.

Agreed. I use cygwin when I need a shell usually, although for the above test I used a standard windows command shell.

> This is intentional.  Since Tkinter doesn't have a mainloop, we switch
> python to interactive mode after TkAgg finishes it's business and the
> Tk window remains open until the python shell is closed.

Oh. Thanks for explaining.

> I would be surprised if it's win98 specific.  I haven't seen any
> problems so far that were specific to just one windows OS.  They're
> basically all the same as far as I can see, Microsoft just keeps
> shrinkwrapping them and recharging you for them :-)  I have win98 at
> home so I'll try and test a version there.

It'll be interesting to see if it's specific to my system which is always a possibility.

Thanks John.
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Hi:

The following script:

#!/usr/bin/env python
from matplotlib.matlab import *

figure(1)
plot([0],[0])
show()


gives this traceback:

Traceback (most recent call last):
  File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in callback
    self.draw()
  File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 42, in draw
    agg.draw()
  File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 299, in draw
    self.figure.draw(self.renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/figure.py", line 
128, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/axes.py", line 603, 
in draw
    self.xaxis.draw(renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 463, 
in draw
    tick.draw(renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 130, 
in draw
    if self.label1On: self.label1.draw(renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/text.py", line 202, 
in draw
    ismath=self.is_math_text())
  File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 203, in draw_text
    self._renderer.draw_text(
OverflowError: float too large to convert

If I remember correctly, there was a similar issue when 0.53 came out.


-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

On Tue, 2004-05-25 at 17:11, Todd Miller wrote:
> On Tue, 2004-05-25 at 11:13, John Hunter wrote:
> > >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> > 
> >     Todd> I tried porting anim.py to TkAgg this morning and got it
> >     Todd> basically working.  There are two things that might account
> >     Todd> for the trouble you've been having:
> > 
> >     Todd> 1.  With TkAgg, at least for now, you have to call the
> >     Todd> figure manager show() method with each cycle rather than the
> >     Todd> canvas draw() method.
> > 
> > Would it be possible to reorganize tkagg so that a call to canvas.draw
> > also triggers a blit so that the interface could be more consistent
> > across backends?
> 
> I've been on leave a lot today but I'll take a look at this either this
> evening or tomorrow morning.
> 
This turned out to be really easy so now canvas.draw triggers a blit and
functions more like the other backends.  It's in CVS.  I also found an
extraneous draw() so performance should be better, perhaps 2x.

Cheers,
Todd

On Tue, 2004-05-25 at 11:13, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
>     Todd> I tried porting anim.py to TkAgg this morning and got it
>     Todd> basically working.  There are two things that might account
>     Todd> for the trouble you've been having:
> 
>     Todd> 1.  With TkAgg, at least for now, you have to call the
>     Todd> figure manager show() method with each cycle rather than the
>     Todd> canvas draw() method.
> 
> Would it be possible to reorganize tkagg so that a call to canvas.draw
> also triggers a blit so that the interface could be more consistent
> across backends?

I've been on leave a lot today but I'll take a look at this either this
evening or tomorrow morning.

Todd

> Gary: did Todd's example help you enough to speed you on your way?
>
> JDH
>

Well...   I might say "yes", but you did put that word "speed" in there   :)

If I run his code, it updates 1.5 frame per second.  If I change the two
calls to

manager.canvas._tkcanvas.after(100, updatefig)

to

manager.canvas._tkcanvas.after(1, updatefig)

there is no difference in the speed.
FWIW, I'm on an 850MHz WinXP.  IIRC, I get the same performance under linux
on the same machine.

You got five frames per second?  When you say you improved performance
"without text" do you mean that you didn't label the axes?

Aside: I see that he calls show() in each iteration, yet John says show()
should only be called once per script.  Todd seems
to be on top of this, so I'll take his word as good.  Todd uses a figure
manager.  I can copy that code, but I don't know what I'm doing with it.  I
don't know what a figure manager does.

Finally, I'm not sure what he meant by "re-registering the handler with each
cycle".  Does this mean call ....after()  ?

Oh ... one last thing, and maybe this  is somehow relevant ... Todd's
program crashes on exit with message:

>>> invalid command name "18438384callit"
    while executing
"18438384callit"
    ("after" script)

...after which I'm dumped into python (interactive prompt).

-gary

>>>>> "Todd" == Todd Miller <jm...@st...> writes:

    Todd> I tried porting anim.py to TkAgg this morning and got it
    Todd> basically working.  There are two things that might account
    Todd> for the trouble you've been having:

    Todd> 1.  With TkAgg, at least for now, you have to call the
    Todd> figure manager show() method with each cycle rather than the
    Todd> canvas draw() method.

Would it be possible to reorganize tkagg so that a call to canvas.draw
also triggers a blit so that the interface could be more consistent
across backends?

    Todd> 2.  The Tk timed event system requires re-registering the
    Todd> handler with each cycle.

Or you can do something like this

  def updatefig(*args):
      updatefig.count += 1
      lines[0].set_ydata(X[:,updatefig.count%60])
      manager.show()
      return updatefig.count
  updatefig.count=-1

  while 1:
      cnt = updatefig()
      if cnt==100: break
    
    Todd> Performance was better than I thought it would be but still
    Todd> kinda slow.

I profiled this because it was slower than I expected.  Turns out that
there is a huge performance hit in the changes I made to Text to
handle arbitrary rotations (a lot of time spent in Matrix getitem,
multiply, etc...).  With text I could get only 5 frames per second;
w/o text I get 13 fps.  The good news is that it will be easy to
optimize away most of the text based performance hit using more
efficient matrix operations and caching.

This can likely be improved further by using collections for drawing
markers in the line class.

Gary: did Todd's example help you enough to speed you on your way?

JDH

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:

    Gary> Hi John, I probably didn't make it clear, but TkAgg has
    Gary> problems too.  Here's what I know: Under 0.53.1 TkAgg and
    Gary> GTKAgg both worked fine, both when running the script
    Gary> directly from Windows Explorer in which case file
    Gary> association cause python to fire up in a DOS shell, and when
    Gary> running it from within SciTE or IDLE things are fine
    Gary> too. 0.54 has changed something.

Well, it's changed a lot.  The big dollar question is which of these
changes are causing these problems :-)

    Gary>  I tried grabbing and
    Gary> running a few examples from CVS as well as my own previously
    Gary> working examples. They behave consistently - GTKAgg no
    Gary> longer works at all

I need clarification here.  What does it mean "no longer works at
all".  If you open up a DOS command shell and run

  from matplotlib.matlab import *
  plot([1,2,3])
  show()

with 

  c:> python myscript.py -dGTKAgg

what happens?  When you run from windows explorer and get a traceback,
you often lose the DOS window that provides the required information.
So it's best to debug from a command shell, though admittedly most of
the windows shells suck.

    Gary>  and TkAgg works but only if I run it from DOS with a
    Gary> -dTkAgg option.  It may be a GUI conflict but it has only
    Gary> started to conflict with 0.54.  removing show() or replacing
    Gary> it with show(mainloop=False) seem to make no difference to
    Gary> the behaviour running TkAgg from SciTE.  

show(mainloop=False) would only be expected to have any effect with
GTK*, but I understand that it's not helping in that case either.

    Gary> I do notice that
    Gary> the python >>> prompt comes up in any DOS windows when
    Gary> running with the -dTkAgg option after the Tk plot window
    Gary> displays. Closing the window then leaves the python prompt
    Gary> and I have to ^Z it to shut it down. It's like it thinks it
    Gary> should be running in interactive mode, although 'interactive
    Gary> : False' is set in my .matplotlibrc This seems abnormal to
    Gary> me.

This is intentional.  Since Tkinter doesn't have a mainloop, we switch
python to interactive mode after TkAgg finishes it's business and the
Tk window remains open until the python shell is closed.

    Gary> In my original post I asked if anyone else had success or
    Gary> problems in Win98 and since noone replied, maybe we can
    Gary> assume that I'm one of the rare users who's still using
    Gary> it. Therefore, as much as I (and probably you) would like to
    Gary> get to the bottom of what's happening, it's probably Win98
    Gary> specific and therefore, can probably wait; at least until
    Gary> after my upcoming exams are over and I get a chance to

I would be surprised if it's win98 specific.  I haven't seen any
problems so far that were specific to just one windows OS.  They're
basically all the same as far as I can see, Microsoft just keeps
shrinkwrapping them and recharging you for them :-)  I have win98 at
home so I'll try and test a version there.

    Gary> really look into it some more. So I might go quiet for a few
    Gary> weeks unless you want me to try anything quick and specific.
    Gary> Finally, I hope you didn't lose the ecolor changes I made to
    Gary> errorbars and they might make it into a future version :-)

No, I missed them the first time but when cleaning out my inbox found
them and made an entry on the TODO list, so they'll get merged soon
enough.  Thanks.

If you could try the command shell test with GTKAgg that I asked for
above, that would be great.

JDH

Hi John,
I probably didn't make it clear, but TkAgg has problems too.
Here's what I know:
Under 0.53.1 TkAgg and GTKAgg both worked fine, both when running the script directly from Windows Explorer in which case file association cause python to fire up in a DOS shell, and when running it from within SciTE or IDLE things are fine too. 0.54 has changed something. I tried grabbing and running a few examples from CVS as well as my own previously working examples. They behave consistently - GTKAgg no longer works at all and TkAgg works but only if I run it from DOS with a -dTkAgg option.
It may be a GUI conflict but it has only started to conflict with 0.54.
removing show() or replacing it with show(mainloop=False) seem to make no difference to the behaviour running TkAgg from SciTE.
I do notice that the python >>> prompt comes up in any DOS windows when running with the -dTkAgg option after the Tk plot window displays. Closing the window then leaves the python prompt and I have to ^Z it to shut it down. It's like it thinks it should be running in interactive mode, although 'interactive  : False' is set in my .matplotlibrc
This seems abnormal to me.

In my original post I asked if anyone else had success or problems in Win98 and since noone replied, maybe we can assume that I'm one of the rare users who's still using it. Therefore, as much as I (and probably you) would like to get to the bottom of what's happening, it's probably Win98 specific and therefore, can probably wait; at least until after my upcoming exams are over and I get a chance to really look into it some more. So I might go quiet for a few weeks unless you want me to try anything quick and specific.
Finally, I hope you didn't lose the ecolor changes I made to errorbars and they might make it into a future version :-)

regards,
Gary
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

On Sat, 2004-05-22 at 23:01, Gary Pajer wrote:
> > I've been trying to figure out how to do an dynamic update in TkAgg
> without
> > success.  Anyone have any pointers?
> > I'm trying to recreate the functionality of the Pmw.Blt stripchart.
> >
> > -gary
> >
> 
> I guess I should be a little more specific.    The part I'm having trouble
> with is the dynamic update.  As a step along the way, I've got a gui with a
> button that just replots some data slightly altered from the original.
> 
> If I use FigureCanvasTkAgg.show (schematically speaking) it will replot, but
> just once. That is, my button's callback routine contains a loop that tries
> to change the data (via set_ydata followed by ....show()) several times in a
> row.  If I click the button, the data updates, but only once.  I click it
> again, it the data updates once.  I remove the loop, the data updates once.
> This strikes me as odd.  How should the graphics window know or care if I'm
> in a python loop or not?
> 
> I'm thinking that a well-placed  call to
> canvas.get_tk_widget.update_idletasks()  should do the job, but that hasn't
> worked for me either.
> 
> Aside:  having played with anim.py I'm concerned about speed.  It seems that
> the speed of anim.py is limited by my system, not by the call to
> gtk.timeout_add().  I might be back asking about a solution that runs faster
> ... perhaps a lower level solution.  (Pmw.Blt works fast enough.)  Hmm... I
> just tried anim.py again, and it won't run.  I've just upgraded to 0.54.
> Odd ... it opens a Tk window.  I'll try that again later after I reboot.
> I'm on WinXP.
> 
> Comment:  I don't have a handle at all on how the graphics system is
> organized.  For example, what is a figure manager?  When do I use it?  I
> don't seem to need it, but there it is, and some of the examples use it.
> Looking through the docstrings I find myself going in circles.  Maybe I'm
> digging too deeply for my own good.  Maybe you developer types might add to
> your to-do list a description of the stucture of the graphics system.
> 
> thanks again,
> gary
> 
> btw, for every task other than animation, matplotlib is the bomb.  great
> job.
> 

I tried porting anim.py to TkAgg this morning and got it basically
working.  There are two things that might account for the trouble you've
been having:

1.  With TkAgg, at least for now,  you have to call the figure manager
show() method with each cycle rather than the canvas draw() method.

2.  The Tk timed event system requires re-registering the handler with
each cycle.

Performance was better than I thought it would be but still kinda slow.

Hope this helps,
Todd


Todd Miller <jm...@st...>

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
    Gary> I guess I should be a little more specific.  The part I'm
    Gary> having trouble with is the dynamic update.  As a step along
    Gary> the way, I've got a gui with a button that just replots some
    Gary> data slightly altered from the original.

    Gary> If I use FigureCanvasTkAgg.show (schematically speaking) it
    Gary> will replot, but just once. That is, my button's callback
    Gary> routine contains a loop that tries to change the data (via
    Gary> set_ydata followed by ....show()) several times in a row.
    Gary> If I click the button, the data updates, but only once.  I
    Gary> click it again, it the data updates once.  I remove the
    Gary> loop, the data updates once.  This strikes me as odd.  How
    Gary> should the graphics window know or care if I'm in a python
    Gary> loop or not?

99% of the time, should only call show once per script -
http://matplotlib.sourceforge.net/faq.html#SHOW.  If you want to
update the plot after changing some data, you should draw
canvas.draw(), as in examples/dynamic_demo.py.  If you are still
having troubles after trying this, send me an attached script and I'll
take a look.

    Gary> I'm thinking that a well-placed call to
    Gary> canvas.get_tk_widget.update_idletasks() should do the job,
    Gary> but that hasn't worked for me either.

    Gary> Aside: having played with anim.py I'm concerned about speed.
    Gary> It seems that the speed of anim.py is limited by my system,
    Gary> not by the call to gtk.timeout_add().  I might be back
    Gary> asking about a solution that runs faster ... perhaps a lower
    Gary> level solution.  (Pmw.Blt works fast enough.)  Hmm... I just
    Gary> tried anim.py again, and it won't run.  I've just upgraded
    Gary> to 0.54.  Odd ... it opens a Tk window.  I'll try that again
    Gary> later after I reboot.  I'm on WinXP.

I am also interested in improving performance here.  My goal is to
extend agg canvas so that portions of the canvas can be updated, eg a
vertical stip, to support things like strip charts.  We have a project
at the hospital that I'm working on where we'd like to write a simple
AD data collection framework using matplotlib for the display, so I've
been mulling over the kinds of changes that need to be made.  Do you
know now what kinds of updates you need to make?  Eg, do you have
lines and you know you only need to update the screen for xlim between
points a and b?

    Gary> Comment: I don't have a handle at all on how the graphics
    Gary> system is organized.  For example, what is a figure manager?
    Gary> When do I use it?  I don't seem to need it, but there it is,
    Gary> and some of the examples use it.  Looking through the
    Gary> docstrings I find myself going in circles.  Maybe I'm
    Gary> digging too deeply for my own good.  Maybe you developer
    Gary> types might add to your to-do list a description of the
    Gary> stucture of the graphics system.

It's absolutely a need and it's on my mental list of things to do.
There have been so many other areas that have required work and I
haven't made the time to generate adequate documentation.  For the
near term I'd like to concentrate on getting all the install problems
ironed out and getting some documentation going.

    Gary> btw, for every task other than animation, matplotlib is the
    Gary> bomb.  great job.

Thanks!
JDH

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:

    Gary> Hi John, I've now retraced my steps and discovered that
    Gary> GTKAgg exhibits the crashing problem but TkAgg seems to
    Gary> exhibit a different but maybe related problem.

    Gary> I uninstalled 0.53.1 again and confirmed that the old
    Gary> \site-packages\matplotlib directory was removed.  I'm trying
    Gary> the matplotlib-0.54.win32-py2.3.exe version with Numeric and
    Gary> the only .matplotlibrc setting changed being backend :
    Gary> GTKAgg

    >>>> import matplotlib
    Gary> returns without complaint but
    >>>> import matplotlib.matlab
    Gary> generates a pythonw illegal operation dialog with "PYTHONW
    Gary> caused an invalid page fault" etc. and causes IDLE generates
    Gary> a "================================ RESTART
    Gary> ================================" line.

It looks like GUI conflict: GTK versus Idle Tk.  This would explain
why TkAgg works but GTKAgg fails.  Try running several of the examples
from the examples dir (not in an IDE but from the shell) with -dGTKAgg
and -dTkAgg and see if you have any troubles.  If they work fine, at
least we'll have narrowed your trouble down to a GUI conflict.  I
don't think you can expect GTK or GTKAgg to work from within IDLE.

Some of these issues are discussed on
http://matplotlib.sourceforge.net/faq.html#SHOW and
http://matplotlib.sourceforge.net/interactive.html

    Gary> However, there are problems. For example, I tried running a
    Gary> previously working plot script from SciTE and it now
    Gary> generates an abnormal program termination MSVC++ Runtime
    Gary> library error from pythonw.exe prior to a page fault.  This
    Gary> time, python generates something: Fatal Python error:
    Gary> PyEval_RestoreThread: NULL tstate
    >> Process failed to respond; forcing abrupt termination...

I believe SciTE is a GTK based IDE, so you may not want to issue
"show" since this can get you into mainloop conflicts or threading
problems.  I'm not 100% sure what happens when you call gtk.mainloop
twice from the same program, which is effectively what I think you be
doing if you called show from within scite.

Try doing this at the end of your script (this is a GTK / GTKAgg
specific option:

show(mainloop=False)

which will realize your figures w/o starting the mainloop, and
*should* work within a program where the pygtk mainloop is already
started.  I don't know enough about scite to know if this will work or
not.  The other thing that might happen is that nothing will show at
all (if scite is not pygtk).  My guess is you will no longer get the
thread error, in which case at least we'll have learned something.

JDH

>>>>> "Jean-Luc" == Jean-Luc Menut <jea...@fr...> writes:

    Jean-Luc> Hello,
    >> You need to install freetype and make sure this library is in
    >> your basedirs path.

    Jean-Luc> I 've did it but infortunatly i have a new error message
    Jean-Luc> wich concern a library ,i mean.

Just an idea: Try replacing line 9 of CXX/Objects.hxx with

extern "C" {
#include "Python.h"
;

That is, just put the extern C thing around the inclusion of the
python.h file and let me know if that makes a difference.  If it fails
again, send along the error message from the compiler and I'll take a
second look.

JDH

Hello,

> You need to install freetype and make sure this library is in your
> basedirs path.

I 've did it but infortunatly i have a new error message wich concern a 
library ,i mean.

Thank you for your help,

Jean-Luc

here the message :

building 'matplotlib._transforms' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -Isrc -I. 
-I/home2/menut/prg/python2.3/include/python2.3 -c src/_transforms.cpp -o 
build/temp.osf1-V5.1-alpha-2.3/src/_transforms.o
In file included from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:8,
                  from CXX/Objects.hxx:9,
                  from CXX/Extensions.hxx:18,
                  from src/_transforms.h:10,
                  from src/_transforms.cpp:3:
/home2/menut/prg/python2.3/include/python2.3/pyconfig.h:840:1: warning: 
"_OSF_SOURCE" redefined
In file included from /usr/include/locale.h:49,
                  from /usr/local/include/c++/3.3.3/clocale:49,
                  from 
/usr/local/include/c++/3.3.3/alphaev67-dec-osf5.1/bits/c++locale.h:41,
                  from /usr/local/include/c++/3.3.3/iosfwd:46,
                  from /usr/local/include/c++/3.3.3/ios:44,
                  from /usr/local/include/c++/3.3.3/ostream:45,
                  from /usr/local/include/c++/3.3.3/iterator:70,
                  from /usr/local/include/c++/3.3.3/numeric:67,
                  from src/_transforms.cpp:2:
/usr/include/standards.h:206:1: warning: this is the location of the 
previous definition
In file included from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:8,
                  from CXX/Objects.hxx:9,
                  from CXX/Extensions.hxx:18,
                  from src/_transforms.h:10,
                  from src/_transforms.cpp:3:
/home2/menut/prg/python2.3/include/python2.3/pyconfig.h:847:1: warning: 
"_POSIX_C_SOURCE" redefined
In file included from /usr/include/locale.h:49,
                  from /usr/local/include/c++/3.3.3/clocale:49,
                  from 
/usr/local/include/c++/3.3.3/alphaev67-dec-osf5.1/bits/c++locale.h:41,
                  from /usr/local/include/c++/3.3.3/iosfwd:46,
                  from /usr/local/include/c++/3.3.3/ios:44,
                  from /usr/local/include/c++/3.3.3/ostream:45,
                  from /usr/local/include/c++/3.3.3/iterator:70,
                  from /usr/local/include/c++/3.3.3/numeric:67,
                  from src/_transforms.cpp:2:
/usr/include/standards.h:198:1: warning: this is the location of the 
previous definition
In file included from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:8,
                  from CXX/Objects.hxx:9,
                  from CXX/Extensions.hxx:18,
                  from src/_transforms.h:10,
                  from src/_transforms.cpp:3:
/home2/menut/prg/python2.3/include/python2.3/pyconfig.h:859:1: warning: 
"_XOPEN_SOURCE" redefined
In file included from /usr/include/locale.h:49,
                  from /usr/local/include/c++/3.3.3/clocale:49,
                  from 
/usr/local/include/c++/3.3.3/alphaev67-dec-osf5.1/bits/c++locale.h:41,
                  from /usr/local/include/c++/3.3.3/iosfwd:46,
                  from /usr/local/include/c++/3.3.3/ios:44,
                  from /usr/local/include/c++/3.3.3/ostream:45,
                  from /usr/local/include/c++/3.3.3/iterator:70,
                  from /usr/local/include/c++/3.3.3/numeric:67,
                  from src/_transforms.cpp:2:
/usr/include/standards.h:188:1: warning: this is the location of the 
previous definition
In file included from 
/home2/menut/prg/python2.3/include/python2.3/pyport.h:99,
                  from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:48,
                  from CXX/Objects.hxx:9,
                  from CXX/Extensions.hxx:18,
                  from src/_transforms.h:10,
                  from src/_transforms.cpp:3:
/usr/include/sys/time.h:71: error: 'suseconds_t' is used as a type, but 
is not
    defined as a type.
In file included from 
/home2/menut/prg/python2.3/include/python2.3/pyport.h:157,
                  from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:48,
                  from CXX/Objects.hxx:9,
                  from CXX/Extensions.hxx:18,
                  from src/_transforms.h:10,
                  from src/_transforms.cpp:3:
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/sys/stat.h:213: 
error: '
    blksize_t' is used as a type, but is not defined as a type.
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/sys/stat.h:213: 
error: '
    blkcnt_t' is used as a type, but is not defined as a type.
error: command 'gcc' failed with exit status 1