Hi John, I've now retraced my steps and discovered that GTKAgg exhibits the crashing problem but TkAgg seems to exhibit a different but maybe related problem. I uninstalled 0.53.1 again and confirmed that the old \site-packages\matplotlib directory was removed. I'm trying the matplotlib-0.54.win32-py2.3.exe version with Numeric and the only .matplotlibrc setting changed being backend : GTKAgg >>> import matplotlib returns without complaint but >>> import matplotlib.matlab generates a pythonw illegal operation dialog with "PYTHONW caused an invalid page fault" etc. and causes IDLE generates a "================================ RESTART ================================" line. If I use backend : TkAgg instead >>> import matplotlib.matlab now returns without complaint However, there are problems. For example, I tried running a previously working plot script from SciTE and it now generates an abnormal program termination MSVC++ Runtime library error from pythonw.exe prior to a page fault. This time, python generates something: Fatal Python error: PyEval_RestoreThread: NULL tstate >Process failed to respond; forcing abrupt termination... let me know if there's anything else you want me to try regards, Gary ----- Original Message ----- From: John Hunter <jdh...@ac...> Date: 2004年5月23日 18:43:04 -0500 To: "Gary Ruben" <ga...@em...> Subject: Re: [Matplotlib-users] matplotlib-0.54 Win98 crash > >>>>> "Gary" == Gary Ruben <ga...@em...> writes: > > Gary> I just tried matplotlib-0.54 under Win98 with the GTKAgg > Gary> backend and it crashes python when I do import > Gary> matplotlib.matlab It doesn't seem to get far enough to > Gary> generate any helpful diagnostics I'm afraid. I've reverted > Gary> to 0.53.1 for the moment. Anyone else had success or > Gary> failure in Win98? > > Can you try flushing the old site-packages/matplotlib and reinstall? > Did you use the numarray or numeric matplotlib build? There is a > problem with the numarray build in that it was built against numarray > CVS. Hopefully we can get a new build up tomorrow. > > Do you get a segfault or a traceback? Are there any messages? > > Thanks, > JDH > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
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
>>>>> "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
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
>>>>> "Gary" == Gary Ruben <ga...@em...> writes: Gary> The hard drive grinds away for a couple of seconds, then I Gary> get an Invalid Page Fault dialog with Python in the title Gary> bar. When I close the dialog, the DOS prompt returns, so Gary> it's not crashing the DOS window. No other windows appear in Gary> this sequence. The good news is I can replicate it on my windows 98 box (and a windows ME box). I've had no troubles on XP. It is triggered by importing matplotlib.backends._gtkagg. That's all I know so far, but I should be able to figure it out from here. Thanks for the alert. JDH
>>>>> "John" == John Hunter <jdh...@ac...> writes: John> The good news is I can replicate it on my windows 98 box John> (and a windows ME box). I've had no troubles on XP. It is John> triggered by importing matplotlib.backends._gtkagg. That's John> all I know so far, but I should be able to figure it out John> from here. I rewrote _gtkagg using cxx and this seems to have fixed the problem (at least on my test systems). Flush the old, and try: http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.win32-py2.3.exe FYI, this should have your errorbar fixes in as well. Good luck! JDH
Hi John, I can confirm that 0.54.1a fixes the crashing problem - thanks! However, I tested it with a few errorbar plots and I noticed a few things. You've changed the errorbar bar-ends to use markers, but the scaling is now different and seems no longer to be settable via the capsize parameter. The autoscaling no longer works either. If I use the example: -- from matplotlib.matlab import * t = arange(0.1, 4, 0.1) s = exp(-t) e = 0.1*randn(len(s)) f = 0.1*randn(len(s)) l1 = errorbar(t, s, e, f) set(l1, 'color', 'g') show() -- a traceback is generated: Traceback (most recent call last): File "errorbar_demo.pyw", line 10, in ? set(l1, 'color', 'g') File "C:\APPS\PYTHON23\Lib\site-packages\matplotlib\matlab.py", line 1275, in set func = getattr(o,funcName) AttributeError: 'NoneType' object has no attribute 'set_color' I'm pretty sure this worked in 0.53 If you change l1 = errorbar(t, s, e, f) to l1,l2 = errorbar(t, s, e, f) you get another traceback: Traceback (most recent call last): File "errorbar_demo.pyw", line 8, in ? l1,l2 = errorbar(t, s, e, f) TypeError: unpack non-sequence This worked in 0.53 If you remove the set() call, the plot appears, but you'll see the autoscaling is wonky. I discovered these because I was trying to reproduce the plots on my python page <http://users.bigpond.net.au/gazzar/python.html> When I try to reproduce the first one, I get a traceback. If I remove the l1,e1 assignment part and the legend call, no traceback occurs. I don't understand why: The traceback produced is: Traceback (most recent call last): File "_mass_matplotlib.py", line 17, in ? l1,e1=errorbar(m, PrimeVals(t), [NegErrs(t), PosErrs(t)], fmt='r') TypeError: unpack non-sequence When I try to reproduce the second plot, the plot window appears. The scaling shown on my webpage is the autoscaling produced with 0.53 (xaxis=2->4.5, yaxis=5.?->5.32), but the autoscaling in 0.54.1a has the axis ranges of (xaxis=1->5.5, yaxis=4->6.5). Also I have to squint to see the bar-ends ;-) <- (smiley of my left eye squinting) regards and thanks for sorting out the GTKAgg stuff, Gary -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
Hi:
I was wondering whether anyone else has noticed a performance difference
between using plot_date() and plot().
Here is a dummy script:
#!/usr/bin/env python
import time
from matplotlib.dates import EpochConverter
from matplotlib.matlab import *
from matplotlib.ticker import DateFormatter, DayLocator, HourLocator
useDates=0
now=time.time()
weekAgo=now-60*60*24*7
dates=arange(weekAgo, now, 10) #Say have a point every 10 secs..
vals=dates
if useDates:
#Date plot
fmt=DateFormatter('%D')
days=DayLocator(1)
hours=HourLocator(12)
converter = EpochConverter()
ax = subplot(111)
plot_date(dates, vals, converter)
ax.xaxis.set_major_locator(days)
ax.xaxis.set_major_formatter(fmt)
ax.xaxis.set_minor_locator(hours)
#What will this do??
#ax.autoscale_view()
else:
#Regular plot
plot(dates, vals)
ylabel('Number of points: '+str(len(dates)))
xlabel('time')
grid(True)
show()
I use python2.2 running on a 3.2 PIV with 2GB or ram and when I use
regular plotting, this takes ~1sec. With plot_date() it takes ~8sec.
I really like the flexibility of the way dates are handled but this
seems to be too much of a performance hit for me to use (I ofter have
data sets of 500 000 points). So my question is whether I am perhaps
missing something trivial and not setting things up right. I cannot run
any of the date_demo scripts because don't have python2.3 so cannot test
how fast they run.
I will need to setup the x-axis labeling as dates, but now it seems it
would be faster to just update the xticslabels of a "regular" plot.
Any thoughts?
Thanks.
--
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA
>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes: Peter> Hi: I was wondering whether anyone else has noticed a Peter> performance difference between using plot_date() and Peter> plot(). Here is a dummy script: It turns out that the difference in execution times between these two cases is explained by the fact that the default plot style for plot is '-' and the default plot style for date is 'o'. Drawing a long connected line is still much faster than drawing a bunch of circles. I think if I start using collections in Line2D to draw markers we'll see a performance boost there, but until I do it it's hard to estimate how much. There is a small change I can make which is to allow converter to be None for the case in which your dates are already epoch. This will save some cycles, but is negligible compared to the arc drawing time in your example; from the profiler: 60480 7.470 0.000 7.470 0.000 backend_agg.py:117(draw_arc) 60480 0.200 0.000 0.200 0.000 dates.py:410(epoch) But if I can get the marker performance much better by using collections, then the conversion step will be worth bypassing. JDH
> > >It turns out that the difference in execution times between these two >cases is explained by the fact that the default plot style for plot is >'-' and the default plot style for date is 'o'. > > Yes.. changing the style to '-' fixes the performance issue... great! >There is a small change I can make which is to allow converter to be >None for the case in which your dates are already epoch. This will >save some cycles, > Yes.. I would certainly be for it!.. But I'm biased - all my data is already epoch.. ;) -- Peter Groszkowski Gemini Observatory Tel: +1 808 974-2509 670 N. A'ohoku Place Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA
>>>>> "Gary" == Gary Ruben <ga...@em...> writes: Gary> Hi John, I can confirm that 0.54.1a fixes the crashing Gary> problem - thanks! However, I tested it with a few errorbar Gary> plots and I noticed a few things. You've changed the Gary> errorbar bar-ends to use markers, but the scaling is now Gary> different and seems no longer to be settable via the capsize Gary> parameter. The autoscaling no longer works either. Doh! There was one major problem in that I had commented out the return in maplotlib.matlab.errorbar during debugging. This explains all your problems with working on the return lines. The body of that function should be try: ret = gca().errorbar(x, y, yerr, xerr, fmt, ecolor, capsize) except ValueError, msg: msg = raise_msg_to_str(msg) error_msg(msg) else: draw_if_interactive() return ret I don't see any problems with the capsize or autoscaling. Perhaps with this new code you can see if you are still having troubles and post an example. Sorry for the troubles, 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