Re: [matplotlib-devel] Checked in major reorganization of __init__.py
I just tried to commit a rename of 'rcdefaults.py' to 'rcsetup.py', but I got an error: - ...$ svn commit -m"renamed rcdefaults.py to rccsetup.py to avoid conflict" Sendingmatplotlib/__init__.py Deleting matplotlib/rcdefaults.py Adding matplotlib/rcsetup.py svn: Commit failed (details follow): svn: COPY of rcsetup.py: 403 Forbidden (https://svn.sourceforge.net) - If anybody knows what the reason for this might be, please let me know... Greetings, Norbert Eric Firing wrote: > Norbert Nemec wrote: > >> Hmm - let me think We already have >> rc >> rcParams >> rc_params >> rcdefaults >> rcParamDefaults >> defaultParams >> in the main module of maplotlib >> >> How about calling the new module 'rcdefaultparams.py', simply to make >> the confusion complete and because I really feel that no other name >> would fit the current "naming scheme" better... ;-) >> > > Yes, it is confusing, there are too many similar names. I suspect some > are used infrequently enough that we could change them without too much > pain. > > But the new module is really two things: 1) rc utilities (mainly > validation facilities) and 2) a set of default values. If these are > kept together the module could be called "rc_init.py" because everything > is mainly used for rc initialization, although there are things still in > mpl's __init__.py that are also part of the rc initialization. Or it > could be called "rc_utils.py" or "rcsetup.py". I would prefer any of > these to rcdefaultparams.py. > > Furthermore, even after factoring out the rc things as you have done the > mpl namespace is badly cluttered with things like checkdep_dvipng, > (which is actually part of the rc validation, so maybe it should be in > your new module) so still more refactoring and/or renaming might be in > order. I can imagine a class being used to good effect to organize the > whole business of rc handling. > > One more miscellaneous thought: shouldn't mpl.rc() be using the > validation functions instead of simply stuffing inputs into rcParams? > > I suppose this brings us back to the old "traits, properties, or > neither" question. But incremental improvements such as the one you > have made are still helpful. > > Eric > >> Greetings, >> Norbert >> >> >> >> John Hunter wrote: >> >>> On 6/30/07, Norbert Nemec <[EMAIL PROTECTED]> wrote: >>> >>> Hi there, I just checked in some major reorganization work in __init__.py The main intention was to move the list of option defaults to a separate file 'rcdefaults.py' that could be imported from setup.py to access the settings with minimal dependencies on the remaining code. >>> I haven't tested this but I did take a brief look at it and I think >>> your cleaning and organizing is useful. I think we have a naming >>> problem though -- this __init__ module defines an rcdefaults function, >>> which is likely to cause confusion with the new rcdefaults module. >>> Eg, >>> >>> >from matplotlib import rcdefaults >>> >>> will be ambiguous. You may want to consider a new name. >>> >>> DH >>> >>> - >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> ___ >>> Matplotlib-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >>> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.
Re: [matplotlib-devel] Memory leaks
Eric Firing wrote: Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of results: tkagg is best, with only slow memory growth and a constant number of python objects; qtagg grows by 2.2k per loop, with no increase in python object count; wx (which is built on gtk) consumes 3.5k per loop, with an increasing object count; gtk consumes 1.8k per loop with an increasing object count. All runs are on stock ubuntu feisty python 2.5. Thanks for these results. Unfortunately, I'm seeing different results here. [dagnabbit!] None of them have an increasing object count for me, which leads me to suspect there's some version difference between your environment and mine that isn't being accounted for. Gtk[Agg|Cairo] -- 1.3k per loop. Wx[Agg] -- 0.010k per loop QtAgg -- 2.3k per loop (which is in the same ballpark as your result) Qt4Agg -- 1.4k per loop (which seems to be in the same ballpark as Darren Dale's result) TkAgg -- 0.29k per loop I don't know if the size of memory per loop is directly comparable between your environment and mine, but certainly the shape of the curve, and whether the number of Python objects is growing is very relevant. I made some more commits to SVN on 07/03/07 necessary for recent versions of gtk+ and qt. Did you (by any chance) not get those patches? It would also be interesting to know which versions of the toolkits you have, as they are probably different from mine. Is it safe to assume that they are all the stock Ubuntu feisty packages? In any case, I have updated memleak_gui.py to display the relevant toolkit versions. I've also attached a script to display the toolkit versions. Its output on my machine is: # pygtk version: (2, 10, 4), gtk version: (2, 10, 9) # PyQt4 version: 4.2, Qt version 40300 # pyqt version: 3.17.2, qt version: 30303 # wxPython version: 2.8.4.0 # Tkinter version: $Revision: 50704 $, Tk version: 8.4, Tcl version: 8.4 Cheers, Mike toolkit_versions.py Description: application/python # columns are: iteration, OS memory (k), number of python objects # 0 963056145 10 966556145 20 966456145 30 968056145 40 969256145 50 970656145 60 972156145 70 973456145 80 974756145 90 976156145 100 977456145 110 978856145 120 980256145 130 981556145 140 982956145 150 984256145 160 985556145 170 987056145 180 988356145 190 989656145 200 991156145 210 992356145 220 993756145 230 995156145 240 996456145 250 997856145 260 999256145 2701000656145 2801001956145 2901003256145 3001004756145 3101005956145 3201007356145 3301008656145 3401010156145 3501011356145 3601012756145 3701014056145 3801015556145 3901016756145 4001018156145 4101019456145 4201020956145 4301022356145 4401023656145 4501024956145 4601026256145 4701027656145 4801028956145 4901030356145 5001031756145 5101033156145 5201034356145 5301035856145 5401037156145 5501038556145 5601039956145 5701041156145 5801042556145 5901043856145 6001045256145 6101046556145 6201047956145 6301049256145 6401050656145 6501051956145 6601053356145 6701054656145 6801056056145 6901057456145 7001058756145 7101060256145 7201061556145 7301062856145 7401064156145 7501065556145 7601066856145 7701068256145 7801069656145 7901071056145 8001072256145 8101073856145 8201075156145 8301076556145 8401077856145 8501079356145 8601080556145 8701081956145 8801083356145 8901084656145 9001086056145 9101087356145 9201088856145 9301090056145 9401091456145 9501092756145 9601094156145 9701095556145 9801096856145 9901098156145 10001099556145 10101100956145 10201102356145 10301103656145 10401104956145 10501106356145 10601107756145 10701109056145 10801110556145 1090756145 11001113156145 11101114456145 11201115856145 11301117156145 11401118556145 11501119856145 11601121256145 11701122556145 11801123956145 11901125256145 12001126656145 12101127956145 12201129456145 12301130756145 12401132056145 12501133456145 12601134756145
Re: [matplotlib-devel] [Matplotlib-users] Matplotlib plotting performance
On 7/5/07, Tom Denniston <[EMAIL PROTECTED]> wrote: > Oops that was the TKAgg profile results. These are the WxAgg results > attached. Sorry about that. > > On 7/5/07, Tom Denniston <[EMAIL PROTECTED]> wrote: > > I've been trying to profile and speed up an app that uses matplotlib. > > I tried to write an example using simple pylab commands to reproduce > > the slowness. What I found was I could get a huge speedup just > > avoiding unnecessary redraws. I'm down now to passable behavior. > > Plotting 6 series in two windows takes about one and a quarter > > seconds. I would like to improve this further, however, if it is > > possible which is why I am posting. What is your hold state? In your test function you may want to make sure you are not repeatedly adding data to the same figure. Eg p1.plot(something, hold=False) repeated calls to plot where hold is True can cause significant slowing... In mpl hold is True by default and in matlab it is False by default but you can set the default as an Axes property or in your rc file. JDH - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Subsetting fonts in Postscript
[I've been discussing this off-list with John Hunter, and I thought I'd summarize that conversation in case anyone else on this list has any thoughts or suggestions.] I've started working on the problem of reducing Postscript output file sizes by saving out only the glyphs that are used in the figure. There are (at least) two alternative approaches: 1. Subset the Truetype font into another Truetype font and embed it as we do now. This could theoretically be done with fonttools/ttx. Writing out .ttf files looks to be rather complex, and there's a lot of griping about the format itself to be found on the 'net. John also mentioned that he'd prefer not to add the requirement of fonttools to the mix from past experience. 2. Convert the Truetype font to a Type 3 font (which is basically a set of standard Postscript commands). There is a small C application (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3 that looks to work quite well. Some modifications would have to be made to actually subset the font and to integrate with Python etc., but it's fairly straightforward code, and the licensing is amenable to including it in the matplotlib source tree. Clearly, I'm leaning toward option #2, but thought I'd open it to the crowd to see if there are any other options or opinions on the matter. The plan is to make the choice of the existing or new behavior be an option, with the default TBD. Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On 7/5/07, Eric Firing <[EMAIL PROTECTED]> wrote: > > The plan is to make the choice of the existing or new behavior be an > > option, with the default TBD. > > Is there any reason *not* to do the subsetting? There was some original confusion in a potential loss of quality in truetype/type2 conversions, because of quartic vs cubic spline approximations in the two specifications. When we were concerned that some users may be hit by a loss-of-quality in conversion, we considered making the conversion and subsetting optional. Michael later clarifed that the loss (which happens only in corner cases) would occur in the type3->truetype conversion, and not in the truetype->type3 case we are interested in because type3 uses quartic and truetype uses cubic. Unless there is a good reason to make it optional, I would like to make it as simple as possible and simply do the conversion and embedding every time. This will make support and debugging easier. JDH - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Michael Droettboom wrote: > [I've been discussing this off-list with John Hunter, and I thought I'd > summarize that conversation in case anyone else on this list has any > thoughts or suggestions.] > > I've started working on the problem of reducing Postscript output file > sizes by saving out only the glyphs that are used in the figure. There > are (at least) two alternative approaches: > > 1. Subset the Truetype font into another Truetype font and embed it as > we do now. This could theoretically be done with fonttools/ttx. > Writing out .ttf files looks to be rather complex, and there's a lot of > griping about the format itself to be found on the 'net. John also > mentioned that he'd prefer not to add the requirement of fonttools to > the mix from past experience. > > 2. Convert the Truetype font to a Type 3 font (which is basically a set > of standard Postscript commands). There is a small C application > (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3 > that looks to work quite well. Some modifications would have to be made > to actually subset the font and to integrate with Python etc., but it's > fairly straightforward code, and the licensing is amenable to including > it in the matplotlib source tree. > > Clearly, I'm leaning toward option #2, but thought I'd open it to the > crowd to see if there are any other options or opinions on the matter. I'm very glad to hear that you are working on this, and option #2 sounds good to me. Is the potential advantage of #1 better ultimate rendering quality? Or smaller file size? It looks like fonttools has been untouched since 2002, correct? > > The plan is to make the choice of the existing or new behavior be an > option, with the default TBD. Is there any reason *not* to do the subsetting? Eric > > Cheers, > Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Eric Firing wrote: > Michael Droettboom wrote: >> 1. Subset the Truetype font into another Truetype font and embed it >> as we do now. This could theoretically be done with fonttools/ttx. >> Writing out .ttf files looks to be rather complex, and there's a lot >> of griping about the format itself to be found on the 'net. John >> also mentioned that he'd prefer not to add the requirement of >> fonttools to the mix from past experience. >> >> 2. Convert the Truetype font to a Type 3 font (which is basically a >> set of standard Postscript commands). There is a small C application >> (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type >> 3 that looks to work quite well. Some modifications would have to be >> made to actually subset the font and to integrate with Python etc., >> but it's fairly straightforward code, and the licensing is amenable >> to including it in the matplotlib source tree. >> >> Clearly, I'm leaning toward option #2, but thought I'd open it to the >> crowd to see if there are any other options or opinions on the matter. > > I'm very glad to hear that you are working on this, and option #2 > sounds good to me. Is the potential advantage of #1 better ultimate > rendering quality? Or smaller file size? Potentially on both counts. Hinting will not be converted, and since TT and PS have slightly different rendering models, there is the potential for rounding error etc. (though I don't know how real of a problem that is.) Also, Type 3 is an ASCII format, so if the file weren't subsetted, the size would certainly be larger. So a lot depends on the ratio of glyphs in the original font to glyphs in the figure, obviously. Of course, we could have an "auto" mode, where whichever is ultimately smaller is written out. > > It looks like fonttools has been untouched since 2002, correct? I wasn't able to find anything newer either. > >> >> The plan is to make the choice of the existing or new behavior be an >> option, with the default TBD. > > Is there any reason *not* to do the subsetting? If hinting is a requirement, yes, if the PS file is to be used on a lo-res printer or screen. Somewhat of a side case, maybe. Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Yes -- the global wxapp variable was removed (a very good thing). I just committed a patch to fix this crash (r3460) Cheers, Mike Christopher Barker wrote: > Eric Firing wrote: > >> I just updated from svn and tried to rerun the wx test, but ran into an >> error: >> >> [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python >> wxapp.Yield() >> NameError: global name 'wxapp' is not defined >> > > I think I just saw a note that Ken had committed a patch that a user had > provided that kept the wx back-end from re-starting an event loop if > there was one already running -- maybe that has something to do with > this bug? > > -Chris > > > > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On 7/5/07, Carl Worth <[EMAIL PROTECTED]> wrote: > You might take a look at what kind of PostScript and PDF output you > get from cairo right now, (since cairo has many different kinds of > font subsetting, (type3, type42 and others), and it's regularly being > tested on as many PostScript and PDF viewers as possible). > > I don't know if there's anything special about the PostScript output > you're currently producing that wouldn't make it acceptable to use > cairo's PostScript output directly. But even if you just want code, > it's inside cairo under the LGPL. Hey Carl, I looked at cairo when we first started with the postscript backend, but in the bad old days it was just a raster dump. I understand it has come a long way since. mpl's postscript backend supports latex expressions in PS output, which requires a fair amount of complex trickery in the postscript backend, though we we could probably do it with embedded rasters in cairo. The postscript backend is also standalone with no dependencies other than mpl and numpy, and adding cairo to the mix might be a bit difficult for across platforms for some users (though this appears to have gotten a lot better too). LGPL means we cannot reuse the code. While I like the idea of using cairo for both raster and vector outputs in principle because it offloads a lot of work onto a large and well supported project, it would probably take a fair amount of work to get all of mpl's functionality into the cairo backend (I don't know this since I have not tested the backend for some time, but does it support, for example unicode_demo, mathtext_demo, usetex, and image_demo ?). JDH - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Will this (whichever method is chosen) work for PDF too? Just wondering, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Eric Firing wrote: > I just updated from svn and tried to rerun the wx test, but ran into an > error: > > [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python > wxapp.Yield() > NameError: global name 'wxapp' is not defined I think I just saw a note that Ken had committed a patch that a user had provided that kept the wx back-end from re-starting an event loop if there was one already running -- maybe that has something to do with this bug? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thu, 05 Jul 2007 07:37:21 -1000, Eric Firing wrote: > > 2. Convert the Truetype font to a Type 3 font (which is basically a set > > of standard Postscript commands). There is a small C application > > (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3 > > that looks to work quite well. Some modifications would have to be made > > to actually subset the font and to integrate with Python etc., but it's > > fairly straightforward code, and the licensing is amenable to including > > it in the matplotlib source tree. > > > > Clearly, I'm leaning toward option #2, but thought I'd open it to the > > crowd to see if there are any other options or opinions on the matter. You might take a look at what kind of PostScript and PDF output you get from cairo right now, (since cairo has many different kinds of font subsetting, (type3, type42 and others), and it's regularly being tested on as many PostScript and PDF viewers as possible). I don't know if there's anything special about the PostScript output you're currently producing that wouldn't make it acceptable to use cairo's PostScript output directly. But even if you just want code, it's inside cairo under the LGPL. -Carl pgpfoIOVymvfH.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Carl Worth wrote: > You might take a look at what kind of PostScript and PDF output you > get from cairo right now, (since cairo has many different kinds of > font subsetting, (type3, type42 and others), and it's regularly being > tested on as many PostScript and PDF viewers as possible). > Thanks for the tip. Indeed, using the unicode_test.py example (which probably has a greater than average amount of text in it), the file sizes are (with the size of the font section is parentheses): backend_ps.py: 135763 (127211) cairo: 49102 (39669) Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 8552) > I don't know if there's anything special about the PostScript output > you're currently producing that wouldn't make it acceptable to use > cairo's PostScript output directly. But even if you just want code, > it's inside cairo under the LGPL. > It may be worthwhile to look at Cairo's font subsetting code if it's determined that the Python Postscript backend has other advantages. I'm sure people who've been here longer than I have can better speak to those pros and cons. Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Michael Droettboom wrote: > Carl Worth wrote: > >> You might take a look at what kind of PostScript and PDF output you >> get from cairo right now, (since cairo has many different kinds of >> font subsetting, (type3, type42 and others), and it's regularly being >> tested on as many PostScript and PDF viewers as possible). >> >> > Thanks for the tip. Indeed, using the unicode_test.py example (which > probably has a greater than average amount of text in it), the file > sizes are (with the size of the font section is parentheses): > > backend_ps.py: 135763 (127211) > cairo: 49102 (39669) > > Interestingly, the non-font part is slightly larger for Cairo (9433 vs. > 8552) > Though, I should add, there is a bug in Cairo output with unicode_demo.py: The y-axis label reads "stream-vera/VeraSe.ttf"... Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Mike, New exception: [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python ../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > ~/temp/memleak_wx_0705.asc Traceback (most recent call last): File "../matplotlib_units/unit/memleak_gui.py", line 58, in pylab.close(fig) File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", line 742, in close _pylab_helpers.Gcf.destroy(manager.num) File "/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", line 28, in destroy figManager.destroy() File "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1405, in destroy self.frame.Destroy() File "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1364, in Destroy wxapp.Yield() AttributeError: 'listiterator' object has no attribute 'Yield' Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > It may be worthwhile to look at Cairo's font subsetting code if it's > determined that the Python Postscript backend has other advantages. I'm > sure people who've been here longer than I have can better speak to > those pros and cons. Unfortunately, because it is LGPL, I don't think we can in good conscience look at the code, because doing so probably violates the spirit of the LGPL which says you can link with it but not reuse the code in a non GPL/LGPL program. Others may have a different interpretation, and if look but don't copy is OK under the LGPL as it is journalism (read and summarize with citation but don't plagiarize) then its fine by me but that's not my current understanding. JDH - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Interesting. I don't get that, but I do get some random segfaults (I got lucky the first time I tested). I'm awfully surprised that wx.GetApp() would return an iterator, as you are getting, so maybe it's corruption of some sort? Reverting to revision 3441 on backend_wx.py does resolve this issue for me, so it is related to removing the wxapp global variable. While I like the idea of removing global variables, that was problematic, since when the wxapp variable is dereferenced, the whole wx.App is destructed, (hence, I believe the segfaults). Since I didn't want to just put the wxapp global variable back in, I assigned it to the figure that creates it, therefore stick around as long as the figure does. (Is that the correct thing for its lifetime?) Anyway, it seems to fix memleak_gui.py for me. Ken and Tim will probably want to check that I didn't cause more mainloops to start than necessary in the process. Also, I'm a little puzzled by this code in show() in backend_wx.py: wxapp = wx.GetApp() if wxapp is not None: # wxPython 2.4 has no wx.App.IsMainLoopRunning() method imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False) if imlr(): wxapp.MainLoop() If I'm reading this correctly, shouldn't it be "if not imlr()"? If it is correct, maybe it needs a comment as to why mainloops should be started if a mainloop is already running. Cheers, Mike Eric Firing wrote: > Mike, > > New exception: > > [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python > ../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > > ~/temp/memleak_wx_0705.asc > Traceback (most recent call last): > File "../matplotlib_units/unit/memleak_gui.py", line 58, in > pylab.close(fig) > File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", > line 742, in close > _pylab_helpers.Gcf.destroy(manager.num) > File > "/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", > line 28, in destroy > figManager.destroy() > File > "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", > line 1405, in destroy > self.frame.Destroy() > File > "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", > line 1364, in Destroy > wxapp.Yield() > AttributeError: 'listiterator' object has no attribute 'Yield' > > > Eric > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
John Hunter wrote: > On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > >> It may be worthwhile to look at Cairo's font subsetting code if it's >> determined that the Python Postscript backend has other advantages. I'm >> sure people who've been here longer than I have can better speak to >> those pros and cons. > > Unfortunately, because it is LGPL, I don't think we can in good > conscience look at the code, because doing so probably violates the > spirit of the LGPL which says you can link with it but not reuse the > code in a non GPL/LGPL program. Others may have a different > interpretation, and if look but don't copy is OK under the LGPL as it > is journalism (read and summarize with citation but don't plagiarize) > then its fine by me but that's not my current understanding. Agreed. I haven't looked at it the Cairo source yet, so you can still consider me "untainted" in that regard. My earlier comment was mainly out of licensing confusion. ;) Do you agree that it is still an open question whether it's better to spend time improving the matplotib PS backend, or to fix (if possible) the issues with matplotlib's Cairo integration? It does ultimately come down to a tradeoff: an additional dependency vs. extra maintenance burden. Maybe it would be a good start to enumerate the Cairo backend's current shortcomings. (So far I've seen some minor text bugs, and math rendering is raster dumps.) Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Michael Droettboom wrote: Interesting. I don't get that, but I do get some random segfaults (I got lucky the first time I tested). I'm awfully surprised that wx.GetApp() would return an iterator, as you are getting, so maybe it's corruption of some sort? Reverting to revision 3441 on backend_wx.py does resolve this issue for me, so it is related to removing the wxapp global variable. While I [...] Works for me now, and the result is attached. Object count is still climbing. Eric # columns are: iteration, OS memory (k), number of python objects # 01884975791 101884975831 201884975871 301884975911 401893075951 501893075991 601903876031 701903876071 801903876111 901903876151 1001912476191 1101912476231 1201923576271 1301923576311 1401931676351 1501931676391 1601941776431 1701941776471 1801941776511 1901951376551 2001951376591 2101951376631 2201961276671 2301961276711 2401961276751 2501971076791 2601971076831 2701971076871 2801980076911 2901980076951 3001980076991 3101989377031 3201989377071 3301989377111 3401997877151 3501997877191 3602008877231 3702008877271 3802008877311 3902019277351 4002019277391 4102019277431 4202019277471 4302027477511 4402027477551 4502037477591 4602037477631 4702037477671 4802048477711 4902048477751 5002048477791 5102058877831 5202058877871 5302058877911 5402058877951 5502068377991 5602068378031 5702068378071 5802076378111 5902079678151 6002086178191 6102096178231 6202096178271 6302096178311 6402106078351 6502106078391 6602106078431 6702115678471 6802115678511 6902115678551 7002125478591 7102125478631 7202125478671 7302135378711 7402135378751 7502135378791 7602144278831 7702144278871 7802144278911 7902152878951 8002152878991 8102163879031 8202163879071 8302163879111 8402163879151 8502173379191 8602173379231 8702173379271 8802182079311 8902182079351 9002193179391 9102193179431 9202193179471 9302193179511 9402201579551 9502201579591 9602212679631 9702212679671 9802212679711 9902212679751 10002220779791 10102220779831 10202229879871 10302229879911 10402233579951 10502240179991 10602250380031 10702250380071 10802250380111 10902260180151 11002260180191 11102260180231 11202269980271 11302269980311 11402269980351 11502279880391 11602279880431 11702279880471 11802289780511 11902289780551 12002289780591 12102299580631 12202299580671 12302299580711 12402308680751 12502308680791 12602308680831 12702318080871 12802318080911 12902328380951 13002328380991 13102328381031 13202328381071 1330233668 13402336681151 13502347581191 13602347581231 13702347581271 13802347581311 13902355281351 14002355281391 14102364381431 14202364381471 14302359581511 14402370081551 14502380881591 14602380881631 14702380881671 14802378781711 14902385281751 15002395181791 15102404881831 15202404881871 15302404881911 15402414681951 15502414681991 15602414682031 15702424782071 15802424782111 15902424782151 16002434482191 16102434482231 16202434482271 16302444282311 16402444282351 16502444282391 16602454282431 16702454282471 16802454282511 16902463982551 17002463982591 17102463982631 17202473882671 17302473882711 17402473882751 17502483782791 17602483782831 17702483782871 17802493582911 17902493582951 18002493582991 18102502583031 18202502583071 18302502583111 18402511883151 18502511883191 18602510483231 18702517083271 18802528183311 18902528183351 19002528183391 19102538583431 192025385
Re: [matplotlib-devel] Memory leaks
Interesting... When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step. If that doesn't make it immediately obvious, I'll try this on my Ubuntu box at home and see if I can reproduce what you're seeing. Cheers, Mike Eric Firing wrote: Michael Droettboom wrote: Interesting. I don't get that, but I do get some random segfaults (I got lucky the first time I tested). I'm awfully surprised that wx.GetApp() would return an iterator, as you are getting, so maybe it's corruption of some sort? Reverting to revision 3441 on backend_wx.py does resolve this issue for me, so it is related to removing the wxapp global variable. While I [...] Works for me now, and the result is attached. Object count is still climbing. Eric # columns are: iteration, OS memory (k), number of python objects # 01884975791 101884975831 201884975871 301884975911 401893075951 501893075991 601903876031 701903876071 801903876111 901903876151 1001912476191 1101912476231 1201923576271 1301923576311 1401931676351 1501931676391 1601941776431 1701941776471 1801941776511 1901951376551 2001951376591 2101951376631 2201961276671 2301961276711 2401961276751 2501971076791 2601971076831 2701971076871 2801980076911 2901980076951 3001980076991 3101989377031 3201989377071 3301989377111 3401997877151 3501997877191 3602008877231 3702008877271 3802008877311 3902019277351 4002019277391 4102019277431 4202019277471 4302027477511 4402027477551 4502037477591 4602037477631 4702037477671 4802048477711 4902048477751 5002048477791 5102058877831 5202058877871 5302058877911 5402058877951 5502068377991 5602068378031 5702068378071 5802076378111 5902079678151 6002086178191 6102096178231 6202096178271 6302096178311 6402106078351 6502106078391 6602106078431 6702115678471 6802115678511 6902115678551 7002125478591 7102125478631 7202125478671 7302135378711 7402135378751 7502135378791 7602144278831 7702144278871 7802144278911 7902152878951 8002152878991 8102163879031 8202163879071 8302163879111 8402163879151 8502173379191 8602173379231 8702173379271 8802182079311 8902182079351 9002193179391 9102193179431 9202193179471 9302193179511 9402201579551 9502201579591 9602212679631 9702212679671 9802212679711 9902212679751 10002220779791 10102220779831 10202229879871 10302229879911 10402233579951 10502240179991 10602250380031 10702250380071 10802250380111 10902260180151 11002260180191 11102260180231 11202269980271 11302269980311 11402269980351 11502279880391 11602279880431 11702279880471 11802289780511 11902289780551 12002289780591 12102299580631 12202299580671 12302299580711 12402308680751 12502308680791 12602308680831 12702318080871 12802318080911 12902328380951 13002328380991 13102328381031 13202328381071 1330233668 13402336681151 13502347581191 13602347581231 13702347581271 13802347581311 13902355281351 14002355281391 14102364381431 14202364381471 14302359581511 14402370081551 14502380881591 14602380881631 14702380881671 14802378781711 14902385281751 15002395181791 15102404881831 15202404881871 15302404881911 15402414681951 15502414681991 15602414682031 15702424782071 15802424782111 15902424782151 16002434482191 16102434482231 16202434482271 16302444282311 16402444282351 16502444282391 1660
Re: [matplotlib-devel] Subsetting fonts in Postscript
On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Do you agree that it is still an open question whether it's better to > spend time improving the matplotib PS backend, or to fix (if possible) > the issues with matplotlib's Cairo integration? It does ultimately come > down to a tradeoff: an additional dependency vs. extra maintenance The postscript backend as it stands is in good shape, and is full featured (Darren can tell you how much work he has put into supporting and enhancing the latex support). The last major issue with it is the font size issue, and with your help a solution is on the horizon. So it is definitely a good use of time to fix this last bit. It doesn't sound like your "option 2" is a ton of work, but correct me if I'm wrong. While I would love to see cairo become a full featured backend, and for there to be additional GUI support like tkcairo, wxcairo, etc, we are a lot farther from that goal than we are to getting the font sizes down in the existing postscript backend. And I like the fact the mpl is completely BSD-ish -- relying on a core component which is LGPL would be a step back in my book, though having it as an option would be great. http://www.scipy.org/License_Compatibility > burden. Maybe it would be a good start to enumerate the Cairo backend's > current shortcomings. As a start, you might try adding cairo to the list of backends in examples/backend_driver.py and see if everything passes, and take a look at the generated images, eg compared to those of Agg, and see if you identify any other discrepancies. Steve Chaplin who wrote the cairo backend can also elaborate. > (So far I've seen some minor text bugs, and math > rendering is raster dumps.) Do you mean mathtext or usetex? - The former is mpl's own math layout using the cm*.ttf files, and should work like any other text in the file. The latter uses tex and dvipng rasters (at least in agg), but I don't think it is supported in cairo. So I am not sure where these rasters are coming from, unless cairo is converting all text to rasters. JDH - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
John Hunter wrote: > On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > >> Do you agree that it is still an open question whether it's better to >> spend time improving the matplotib PS backend, or to fix (if possible) >> the issues with matplotlib's Cairo integration? It does ultimately come >> down to a tradeoff: an additional dependency vs. extra maintenance > > The postscript backend as it stands is in good shape, and is full > featured (Darren can tell you how much work he has put into supporting > and enhancing the latex support). The last major issue with it is the > font size issue, and with your help a solution is on the horizon. So > it is definitely a good use of time to fix this last bit. It doesn't > sound like your "option 2" is a ton of work, but correct me if I'm > wrong. No, not a ton of work. And this context is helpful. > > While I would love to see cairo become a full featured backend, and > for there to be additional GUI support like tkcairo, wxcairo, etc, we > are a lot farther from that goal than we are to getting the font sizes > down in the existing postscript backend. And I like the fact the mpl > is completely BSD-ish -- relying on a core component which is LGPL > would be a step back in my book, though having it as an option would > be great. > > http://www.scipy.org/License_Compatibility Agreed. > Do you mean mathtext or usetex? - The former is mpl's own math layout > using the cm*.ttf files, and should work like any other text in the > file. The latter uses tex and dvipng rasters (at least in agg), but I > don't think it is supported in cairo. So I am not sure where these > rasters are coming from, unless cairo is converting all text to > rasters. mathtext_demo.py -- It originally looked like the math text was rasterized, but the tick labels are not. On closer inspection, it seems all the text is rasterized. The fonts are not rasterized when using the Cairo backend with unicode_demo.py. Haven't looked into that any deeper... Cheers, Mike - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thursday 05 July 2007 03:46:13 pm John Hunter wrote: > On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > Do you agree that it is still an open question whether it's better to > > spend time improving the matplotib PS backend, or to fix (if possible) > > the issues with matplotlib's Cairo integration? It does ultimately come > > down to a tradeoff: an additional dependency vs. extra maintenance > > The postscript backend as it stands is in good shape, and is full > featured (Darren can tell you how much work he has put into supporting > and enhancing the latex support). The last major issue with it is the > font size issue, and with your help a solution is on the horizon. So > it is definitely a good use of time to fix this last bit. It doesn't > sound like your "option 2" is a ton of work, but correct me if I'm > wrong. It was a fair amount of work figuring out how to support latex. Jouni started work on a dvi parser, see dviread.py in matplotlib/lib/matplotlib, which could greatly simplify the gymnastics we currently use to support latex in ps output. If dviread were to be further developed, latex could also be used in conjunction with the pdf backend (Jouni's reason for starting dviread), the svg backend, and I guess it would work with cairo as well. But making dviread robust will probably take more work than options 1 or 2, so it is probably best to pursue one of those options for now. > While I would love to see cairo become a full featured backend, and > for there to be additional GUI support like tkcairo, wxcairo, etc, we > are a lot farther from that goal than we are to getting the font sizes > down in the existing postscript backend. And I like the fact the mpl > is completely BSD-ish -- relying on a core component which is LGPL > would be a step back in my book, though having it as an option would > be great. Why can't we all just get along? > Do you mean mathtext or usetex? - The former is mpl's own math layout > using the cm*.ttf files, and should work like any other text in the > file. The latter uses tex and dvipng rasters (at least in agg), but I > don't think it is supported in cairo. So I am not sure where these > rasters are coming from, unless cairo is converting all text to > rasters. I think he is right, gtkcairo converts mathtext to rasters. usetex is not support in gtkcairo. Darren - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Michael Droettboom wrote: > Interesting... > > When you get a chance, would you mind running the attached script? This > is how I was finding object leaks before. It takes a single commandline > argument that is the number of iterations. Can you send me the outputs > from 1 and 2 iterations? That way we should be able to see what type of > object is being leaked, which is a good first step. [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1 75891 76010 *** *** uncollectable list: [] [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2 GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded. GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded. 75891 76014 *** *** uncollectable list: [] Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Michael Droettboom wrote: > Interesting... > > When you get a chance, would you mind running the attached script? This > is how I was finding object leaks before. It takes a single commandline > argument that is the number of iterations. Can you send me the outputs > from 1 and 2 iterations? That way we should be able to see what type of > object is being leaked, which is a good first step. And here is the result of the script modified for gtk: [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1 55352 55417 *** *** *** *** *** *** *** *** *** *** *** *** uncollectable list: [] [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2 55352 55421 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** uncollectable list: [] Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote: > > Interesting. I don't get that, but I do get some random segfaults (I > got lucky the first time I tested). It looks like wxPython doesn't retain a reference to the wxApp PyObj for you: [EMAIL PROTECTED]:~/Projects/matplotlib-svn$ pythonw Python 2.4.4 (#1, Oct 18 2006, 10:34:39) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx >>> app = wx.PySimpleApp() >>> del app >>> wx.GetApp() Segmentation fault > I'm awfully surprised that wx.GetApp() would return an iterator, as > you > are getting, so maybe it's corruption of some sort? My guess is that Eric got lucky and ob_type was pointing to the listiterator's C type instance. > Since I didn't want to just put the wxapp global variable back in, > I assigned it to the figure that creates it, therefore stick around > as long as the figure does. (Is that the correct thing for its > lifetime?) I don't think this will work if you create two figures, destroy the first one, and then create another figure. Once created, the wxApp needs to exist for the life of the python process. I'll go ahead an put the global variable back in. > Also, I'm a little puzzled by this code in show() in backend_wx.py: > > wxapp = wx.GetApp() > if wxapp is not None: > # wxPython 2.4 has no wx.App.IsMainLoopRunning() method > imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False) > if imlr(): > wxapp.MainLoop() > > If I'm reading this correctly, shouldn't it be "if not imlr()"? Yes, it should be. I'll try to code with my eyes open from now on. :-/ Ken - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Yep. Nothing obvious. I'll have to have a look on Ubuntu and see if that makes a difference. Cheers, Mike Eric Firing wrote: > Michael Droettboom wrote: >> Interesting... >> >> When you get a chance, would you mind running the attached script? >> This is how I was finding object leaks before. It takes a single >> commandline argument that is the number of iterations. Can you send >> me the outputs from 1 and 2 iterations? That way we should be able >> to see what type of object is being leaked, which is a good first step. > > [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1 > 75891 76010 > *** > *** > > uncollectable list: [] > > [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2 > GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer > Dell424 could not be loaded. > GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m > could not be loaded. > 75891 76014 > *** > *** > > uncollectable list: [] > > > Eric > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
That is at least something to go by. ;) Thanks, Mike Eric Firing wrote: > Michael Droettboom wrote: >> Interesting... >> >> When you get a chance, would you mind running the attached script? >> This is how I was finding object leaks before. It takes a single >> commandline argument that is the number of iterations. Can you send >> me the outputs from 1 and 2 iterations? That way we should be able >> to see what type of object is being leaked, which is a good first step. > > And here is the result of the script modified for gtk: > > [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1 > 55352 55417 > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > > uncollectable list: [] > > [EMAIL PROTECTED]:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2 > 55352 55421 > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > *** > > uncollectable list: [] > > Eric > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Ken McIvor wrote: > On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote: >> >> Interesting. I don't get that, but I do get some random segfaults (I >> got lucky the first time I tested). > > It looks like wxPython doesn't retain a reference to the wxApp PyObj for > you: > > [EMAIL PROTECTED]:~/Projects/matplotlib-svn$ pythonw > Python 2.4.4 (#1, Oct 18 2006, 10:34:39) > [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import wx > >>> app = wx.PySimpleApp() > >>> del app > >>> wx.GetApp() > Segmentation fault This qualifies as a wx bug, doesn't it? If wx doesn't retain the reference, then instead of a segfault shouldn't it raise an exception? Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
On Jul 5, 2007, at 3:48 PM, Eric Firing wrote: > > This qualifies as a wx bug, doesn't it? I believe so. I'll file it. > If wx doesn't retain the reference, then instead of a segfault > shouldn't it raise an exception? I'd expect wx.GetApp() to work like the rest of wxPython and always return the wx.App instance. This has been fixed in revision 3463. Ken - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
Ken McIvor wrote: >> This qualifies as a wx bug, doesn't it? > I believe so. I'll file it. I agree - a segfault is ALWAYS a bug. >> If wx doesn't retain the reference, then instead of a segfault >> shouldn't it raise an exception? > > I'd expect wx.GetApp() to work like the rest of wxPython and always > return the wx.App instance. If a wx.App has not been created, it returns None: >>> import wx >>> wx.GetApp() >>> a = wx.GetApp() >>> print a None Which is probably what it should do if the wxApp() has been deleted. In any case, you can only create one wxApp per program instance, and it can not be destroyed and re-started, so keeping a global instance around is probably the way to go. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thu, 5 Jul 2007 13:26:22 -0500, "John Hunter" wrote: > On 7/5/07, Carl Worth <[EMAIL PROTECTED]> wrote: > > I don't know if there's anything special about the PostScript output > > you're currently producing that wouldn't make it acceptable to use > > cairo's PostScript output directly. But even if you just want code, > > it's inside cairo under the LGPL. > > I looked at cairo when we first started with the postscript backend, > but in the bad old days it was just a raster dump. I understand it > has come a long way since. Yes, it's definitely a _lot_ better than that now. As of any recent release of cairo, (1.4.x), you will probably get all-vector output for the kinds of things I would expect matplotlib to do. If you do hit something that requires a raster-based fallback in cairo, (translucence or similar), the current releases of cairo do still compute the fallback by doing full-page rasterization. But there's a patch already put together, (by the expert Adrian Johnson), that makes cairo do rasterization for only the minimal necessary region, (so expect that in cairo 1.6 in the future). > mpl's postscript backend supports latex expressions in PS output, > which requires a fair amount of complex trickery in the postscript > backend, though we we could probably do it with embedded rasters in > cairo. Embedding latex expressions is really cool. If you do try something like this with cairo and find that you wish cairo would do something that it can't, then please let me know. > The postscript backend is also standalone with no dependencies > other than mpl and numpy, and adding cairo to the mix might be a bit > difficult for across platforms for some users (though this appears to > have gotten a lot better too). Yes, cairo should work extremely well across platforms, (and particularly the "generic" backends like the image, PDF, PostScript, and SVG backends). The only outstanding platform-specific issues are in display-device-specific backends such as in cairo's quartz backend, (but even it does work extremely well---just not quite perfectly---and the mozilla people are working hard to complete it). > LGPL means we cannot reuse the code. That's your choice of course. As far as type3 goes, there's really nothing special there. It would be just as easy (or easier) to just read the PostScript language reference and implement things directly as compared to reading cairo's code. That's all I did to write it originally, and it's not hard at all. Now, some of the other font subsetting work in cairo is a bit more sophisticated. Adrian Johnson has done most of that, so he would probably be the person you would need to ask if you would like the code to be made available under a more liberal licence than the LGPL, (or the Mozilla Public License as cairo is currently made available under either of those). > While I like the idea of using cairo for both raster and vector > outputs in principle because it offloads a lot of work onto a large > and well supported project, it would probably take a fair amount of > work to get all of mpl's functionality into the cairo backend (I don't > know this since I have not tested the backend for some time, but does > it support, for example unicode_demo, mathtext_demo, usetex, and > image_demo ?). It doesn't look to me like there's a lot of missing work. Here are the results from unicode_demo: http://www.cworth.org/matplotlib/ To summarize, all of the PNG, PostScript, PDF, and SVG output looks fine from the cairo backend. Meanwhile, the PDF backend, (as of 0.87.7) seems to generate broken output for the accented characters, and the SVG backend doesn't position/scale the text correctly. Cairo's PDF and PostScript output is smaller than matplotlib's native output, (factor of 2.75), while cairo's SVG output is a fair amount larger than matplotlib's, (factor of 11), since it's embedding all of the text glyphs, (which could be either good or bad depending on what you really want). I didn't seem to have any usetex demo installed with the Debian 0.87.7 package of python-matplotlib-doc, and with both mathtext_demo and image_demo I got the following inscrutable error messages: /usr/lib/python2.4/site-packages/matplotlib/backends/backend_cairo.py:329: UserWarning: cairo with Numeric support is required for _draw_mathtext() /usr/lib/python2.4/site-packages/matplotlib/backends/backend_cairo.py:162: UserWarning: cairo with Numeric support is required for draw_image() Does anybody know what that could mean? I have no idea what "cairo with Numeric support" is. Is it perhaps something specific to the pycairo python bindings of cairo? -Carl pgpZ2aFDbzUty.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it no
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thu, 5 Jul 2007 14:46:13 -0500, "John Hunter" wrote: > The postscript backend as it stands is in good shape, and is full > featured (Darren can tell you how much work he has put into supporting > and enhancing the latex support). The last major issue with it is the > font size issue, and with your help a solution is on the horizon. So > it is definitely a good use of time to fix this last bit. It doesn't > sound like your "option 2" is a ton of work, but correct me if I'm > wrong. For what it's worth, I think I'd be inclined to agree with you there. If your existing code is working just fine, then switching to cairo is just more work. But if you do start having to do any serious maintenance, then you might want to reconsider. > http://www.scipy.org/License_Compatibility Thanks, John, for sharing this essay. Please allow me to respond to a few points: In my experience, the benefits of collaborating with the private sector are real, whereas the fear that some private company will "steal" your product and sell it in a proprietary application leaving you with nothing is not. In my experience, there is real harm that can come when proprietary modifications to a license made available under a permissive license are not contributed back. An extremely clear case is that of the X Window System which went through a period of several independent software vendors trying to out-compete each other on their own proprietary modifications to the system, (resulting in the near death of the system altogether). I've had some discussions with Jim Gettys about that process and how the MIT license for X has played out over the years. You argue that a project most needs the extra users provided by a permissive license during its formative years until it reaches critical mass and the network effects kick in. Jim actually argues the point differently and says that the extra protections of the GPL are most necessary during the formative period, but not at all needed once the project reaches critical mass. So I've heard him express that he wishes there were a way to allow a project to grow under the GPL and then change to something like the MIT license once it reaches critical mass. There is a lot of GPL code in the world, and it is a constant reality in the development of matplotlib that when we want to reuse some algorithm, we have to go on a hunt for a non-GPL version. So that's a cost that you need to weigh against the decision to not be able to accept any GPL code into your project. But I think the fact that there _is_ a lot of GPL code in the world is a strong argument against your original thesis that a license more permissible than the GPL is necessary to bootstrap a free software project to critical mass. There _is_ a lot of GPL code, which means there _are_ a lot of users of that code, and a lot of those users are businesses that don't have a problem using, (and modifying, and contributing back to), GPL code. There are two unpalatable options. 1) Go with GPL and lose the mind-share of the private sector 2) Forgo GPL code and retain the contribution of the private sector. You've chosen (2) along with a decision to try to campaign authors of GPL code to relicense their code as BSD/MIT (ish) whenever you want to use it. I would guess you'll find that quite difficult in many cases, (I don't agree that the GPL is most often chosen without intention just because it is "famous"). I think an easier route to take path (2) is to use the LGPL for your library, and then only have to convince authors to re-license the subset of their GPL application code as LGPL that you're actually interested in incorporating into your library. I would predict that you will be more successful at that more often than convincing people to relicense GPL to BSD/MIT (ish). You only bring the LGPL up at the end of your essay as almost an afterthought and dismiss it with a very vague, "but many companies are still loath to use it out of legal concerns". Do you have actual evidence to point to for that? It would be simpler if there were direct experiments we could run to measure some of these things, but there aren't, (and conditions do continue to change). My experience with the cairo project suggests that we've been able to achieve a very successful library implementation, (with plenty of "corporate" contribution), with an LGPL (and MPL) license. This is a very tough decision because their is a lot of very high quality software that is GPL and we need to use it; Network effects are strong---when they're good, don't fight them. :-) And I've even been annoyed enough with having to get code relicensed from GPL to LGPL+MPL for use in cairo that I'm thinking the next library I invent might be simply GPL from the beginning. Which brings me to my final point. I think it's very interesting (and worthwhile) to debate license decisions like th
Re: [matplotlib-devel] Subsetting fonts in Postscript
Carl, I have made a few changes in svn to facilitate testing cairo with backend_driver (and to fix a bug that turned up), and I will do a bit more on this later today or tomorrow. The result of a quick pass through the backend_driver test with png output is quite encouraging, though. There are some bugs in string placement, image handling, and clipping, but most things work, including mathtext. Default fonts seem to be different. Eric Carl Worth wrote: > On Thu, 5 Jul 2007 13:26:22 -0500, "John Hunter" wrote: >> On 7/5/07, Carl Worth <[EMAIL PROTECTED]> wrote: >>> I don't know if there's anything special about the PostScript output >>> you're currently producing that wouldn't make it acceptable to use >>> cairo's PostScript output directly. But even if you just want code, >>> it's inside cairo under the LGPL. >> I looked at cairo when we first started with the postscript backend, >> but in the bad old days it was just a raster dump. I understand it >> has come a long way since. [...] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
On Thu, 05 Jul 2007 13:22:11 -1000, Eric Firing wrote:
> I have made a few changes in svn to facilitate testing cairo with
> backend_driver (and to fix a bug that turned up), and I will do a bit
> more on this later today or tomorrow.
Cool. I've started downloading all the matplotlib source history with
git-svn, so once that's done I'll take a look. Hopefully it's obvious
how to run through the cairo backend with the test suite---otherwise
I'll ask.
> The result of a quick pass
> through the backend_driver test with png output is quite encouraging,
> though. There are some bugs in string placement, image handling, and
> clipping, but most things work, including mathtext. Default fonts seem
> to be different.
If there's anything I can do to help I'll do what I can---let me know.
Oh, and I meant to say that it's a bit annoying that
savefig("somefile") doesn't work with the cairo backend. My
understanding is that this is supposed to automatically select the
correct file extension based on the backend type, (with the implicit
assumption that any given backend only supports one backend type).
That seems like a useful way of using savefig, and I don't think it's
correct to break it just because cairo supports multiple file types.
My suggestion would be to make it default to .png if no additional
information is provided, and then to also add some sort of pseudo
backends so that the other cairo-supported file types could easily be
obtained with this same savefig call. For example something like:
python myscript.py -dCairoPDF
What do you think? Would that be simple to implement?
-Carl
PS. I'd be more inclined to name the backends things like cairo-pdf
than CairoPDF but it seems that the latter better fits the existing
convention for matplotlib backend naming.
pgpkwqB6ms90i.pgp
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Carl Worth wrote:
> On Thu, 05 Jul 2007 13:22:11 -1000, Eric Firing wrote:
>> I have made a few changes in svn to facilitate testing cairo with
>> backend_driver (and to fix a bug that turned up), and I will do a bit
>> more on this later today or tomorrow.
>
> Cool. I've started downloading all the matplotlib source history with
> git-svn, so once that's done I'll take a look. Hopefully it's obvious
> how to run through the cairo backend with the test suite---otherwise
> I'll ask.
>
>> The result of a quick pass
>> through the backend_driver test with png output is quite encouraging,
>> though. There are some bugs in string placement, image handling, and
>> clipping, but most things work, including mathtext. Default fonts seem
>> to be different.
>
> If there's anything I can do to help I'll do what I can---let me know.
Thanks. One place to start would be with the string placement. If you
compare png output from Cairo vs Agg, I think you will find that strings
are being positioned differently, sometimes very subtly, sometimes
(especially for plot title) by quite a bit. If you can figure out where
the differences are coming from, we can decide whether changes are
needed in Cairo, in one or more of the other backends, or both. (I
think SVG also positions strings quite differently; I think ps
positioning is much closer to Agg.)
>
> Oh, and I meant to say that it's a bit annoying that
> savefig("somefile") doesn't work with the cairo backend. My
> understanding is that this is supposed to automatically select the
> correct file extension based on the backend type, (with the implicit
> assumption that any given backend only supports one backend type).
>
> That seems like a useful way of using savefig, and I don't think it's
> correct to break it just because cairo supports multiple file types.
>
> My suggestion would be to make it default to .png if no additional
> information is provided, and then to also add some sort of pseudo
Yes, I was looking at making that the default.
> backends so that the other cairo-supported file types could easily be
> obtained with this same savefig call. For example something like:
>
> python myscript.py -dCairoPDF
>
> What do you think? Would that be simple to implement?
I think it would be easy. It might be done most easily and consistently
via the rc mechanism. Figure.savefig already has a kwarg for it, so it
would be a matter of having that kwarg default to the rc setting. For
the backend specification I would suggest "-dCairo.pdf" etc, which is
mnemonic and easy to parse.
Eric
>
> -Carl
>
> PS. I'd be more inclined to name the backends things like cairo-pdf
> than CairoPDF but it seems that the latter better fits the existing
> convention for matplotlib backend naming.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Checked in major reorganization of __init__.py
Norbert, I just did the rename, and it worked: [EMAIL PROTECTED]:~/programs/py/mpl/matplotlib_units$ svn move lib/matplotlib/rcdefaults.py lib/matplotlib/rcsetup.py A lib/matplotlib/rcsetup.py D lib/matplotlib/rcdefaults.py [EMAIL PROTECTED]:~/programs/py/mpl/matplotlib_units$ svn status ? CXX.new ? svn-commit.2.tmp ? test.png ? svn-commit.tmp ? unit/legend_unit.png ? lib/svn-commit.tmp D lib/matplotlib/rcdefaults.py A + lib/matplotlib/rcsetup.py ? examples/units/basic_units.pyc [EMAIL PROTECTED]:~/programs/py/mpl/matplotlib_units$ svn commit Zed V1.0.3 by Sandro Serafini (c) 1997/98 Loading /home/efiring/.zedxrc... Reading /home/efiring/myzed.cfg... Resuming /home/efiring/.zedxrc... Deleting lib/matplotlib/rcdefaults.py Adding lib/matplotlib/rcsetup.py Committed revision 3465. I also changed __init__.py to import rcsetup in a revision that followed by about 2 minutes--so I hope no one did an svn update during that interval. I have no idea what cause your svn commit failure. Eric Norbert Nemec wrote: > I just tried to commit a rename of 'rcdefaults.py' to 'rcsetup.py', but > I got an error: > > - > ...$ svn commit -m"renamed rcdefaults.py to rccsetup.py to avoid conflict" > Sendingmatplotlib/__init__.py > Deleting matplotlib/rcdefaults.py > Adding matplotlib/rcsetup.py > svn: Commit failed (details follow): > svn: COPY of rcsetup.py: 403 Forbidden (https://svn.sourceforge.net) > - > > If anybody knows what the reason for this might be, please let me know... > > Greetings, > Norbert > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subsetting fonts in Postscript
Carl Worth wrote: > On Thu, 05 Jul 2007 13:22:11 -1000, Eric Firing wrote: [...] > > My suggestion would be to make it default to .png if no additional > information is provided, and then to also add some sort of pseudo > backends so that the other cairo-supported file types could easily be > obtained with this same savefig call. For example something like: > > python myscript.py -dCairoPDF > > What do you think? Would that be simple to implement? It's done, except that it is '-dCairo.pdf'. Also, examples/backend_driver.py now supports case-insensitive specifation of backends, and the same form of cairo specification. See docstring at the top. I found that the cairo backend writes ps files but not eps--it enlists backend_ps for eps files. Does pycairo not have a way to specify eps rather than ps output? Eric > > -Carl > > PS. I'd be more inclined to name the backends things like cairo-pdf > than CairoPDF but it seems that the latter better fits the existing > convention for matplotlib backend naming. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
