matplotlib-users Mailing List for matplotlib

Hi,
 so here is some quick but working example. I added there are 2-3 functions (unused)
as a bonus, you can easily call them from the main function using same API
(except the piechart). I hope this shows what I lack in matplotlib - a general API
so that I could easily switch form scatter plot to piechart or barchart without altering
much the function arguments. Messing with return objects line2D, PathCollection, Rectangle
is awkward and I would like to stay away from matplotlib's internals. ;) Some can be sliced,
so not, you will see in the code.
 This eatmem.py will take easily all your memory. Drawing 300000 dots is not feasible
with 16GB of RAM. While the example is for sure inefficient in many places generating the data
in python does not eat RAM. That happens afterwards.
I would really like to hear whether matplotlib could be adjusted instead. ;) I already mentioned
in this thread that it is awkward to pre-create colors before passing all data to a drawing
function. I think we could all save a lot if matplotlib could dynamically fetch colors
on the fly from user-created generator, same for legends descriptions. I think my example
code shows the inefficient approach here. Would I have more time I would randomize a bit
more the sublist of each series so that the numbers in legends would be more variable
but that is a cosmetic issue.
 Probably due to my ignorance you will see that figures with legends have different font
sizes, axes are rescaled and the figure. Of course I wanted to have the drawing same via both
approaches but failed badly. The files/figures with legends should be just accompanied by the
legend "table" underneath but the drawing itself should be same. Maybe an issue with DPI settings
but not only.
 I placed some comments in the code, please don't take them in person. ;) Of course
I am glad for the existing work and am happy to contribute my crap. I am fine if you rewamp
this ugly code into matplotlib testsuite, provide similar function (the API mentioned above)
so that I could use your code directly. That would be great. I just tried to show multiple
issues at once, notably that is why I included those unused functions. You will for sure find
a way to use them.
 Regarding the "unnecessary" del() calls etc., I think I have to use keep some, Ben, because
the function is not always left soon enough. I could drop some, you are right, but for some
I don't think so. Matplotlib cannot recycle the memory until me (upstream) deletes the reference
so ... go and test this lousy code. Now you have a testcase. ;) Same with the gc.collect() calls.
Actually, the main loop with 10 iteration is there just to show why I always want to clear
a figure when entering a function and while leaving it as well. It happened too many times that
I drawed over an old figure, and this was posted also few times on this list by others. That is
a weird behavior in my opinion. We, users, are just forced to use too low-level functions.
So, have fun eating your memory! :))
Martin

Hi,
On Fri, Oct 11, 2013 at 9:29 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> On Thu, Oct 3, 2013 at 1:33 PM, Matthew Brett <mat...@gm...> wrote:
>> Hi,
>>
>> On Thu, Oct 3, 2013 at 1:29 PM, Russell E. Owen <ro...@uw...> wrote:
>>> In article
>>> <CAH6Pt5q=Z_m...@ma...>,
>>> Matthew Brett <mat...@gm...>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Thu, Oct 3, 2013 at 5:59 AM, Michael Droettboom
>>>> <md...@st...> wrote:
>>>> > Matthew Terry, as part of his Mac testing project, has done a great deal of
>>>> > reconnaissance on this.
>>>> >
>>>> > https://github.com/matplotlib/mpl_mac_testing
>>>> >
>>>> > I know he was looking into statically linking some of the C dependencies
>>>> > (freetype, libpng etc.) as a way to make the installer more robust to
>>>> > different environments.
>>>>
>>>> Thanks - that looks like a useful testing grid.
>>>>
>>>> Are there any near-term plans for something like a .dmg or .mpkg or
>>>> .pkg installer?
>>>
>>> Building a binary installer with statically linked libraries is not
>>> terribly hard (see
>>> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
>>> l>). There are two problem:
>>> - As of 1.3.0 mpl does not include python-dateutil, pytz or six (for
>>> good reasons) and that makes it harder to make a really usable binary
>>> installer. This interacts with the next problem:
>>> - For unknown reasons running the 1.3.0 installer breaks existing
>>> installations of python-dateutil if those packages were installed using
>>> an older mpl binary installer.
>>>
>>> The missing packages can be added to the binary installer after it is
>>> produced by bdist_mpkg by post-processing the mpkg. That would take care
>>> of the second issue for most users (who would use the default
>>> installation and get everything). I have not had time to deal with that.
>>> Thus I never uploaded an official binary installer for 1.3.0 and stopped
>>> providing them. Matthew Terry has taken over that task.
>>
>> Aha - yes - postprocessing the mpkg would be pretty easy.
>>
>> So - I guess I should just build the installer myself and post it for
>> testing? Is that the best way forward?
>
> OK - after a lot of blood, sweat and tears:
>
> http://nipy.bic.berkeley.edu/practical_neuroimaging/matplotlib-1.3.1-py2.7-macosx10.6.mpkg.zip
>
> - a standalone binary installer for matplotlib 1.3.1, including:
>
> tornado
> pyparsing
> python-dateutil
> pytz
> six
>
> Please do test.
>
> It imports on my machines (10.6, 10.7 * 2, 10.8), I am just running the tests.
>
> I'm building from a waf build that should be replicable:
>
> https://github.com/matthew-brett/mpl-osx-binaries
>
> On a 10.6 and a 10.8 machine I get a couple of test errors, log attached:
>
> ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
> ERROR: matplotlib.tests.test_backend_pgf.test_mixedmode
>
> One (clean) 10.7 passes, another 10.7 machine gives the same errors as
> above plus 2 ghostscript errors.
python3.3 installer, same errors as 2.7 for OSX 10.8:
http://nipy.bic.berkeley.edu/practical_neuroimaging/matplotlib-1.3.1-py3.3-macosx10.6.mpkg.zip
I've attached the log this time (for 2.7, it's similar for 3.3)
Best,
Matthew

Hi,
On Thu, Oct 3, 2013 at 1:33 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> On Thu, Oct 3, 2013 at 1:29 PM, Russell E. Owen <ro...@uw...> wrote:
>> In article
>> <CAH6Pt5q=Z_m...@ma...>,
>> Matthew Brett <mat...@gm...>
>> wrote:
>>
>>> Hi,
>>>
>>> On Thu, Oct 3, 2013 at 5:59 AM, Michael Droettboom
>>> <md...@st...> wrote:
>>> > Matthew Terry, as part of his Mac testing project, has done a great deal of
>>> > reconnaissance on this.
>>> >
>>> > https://github.com/matplotlib/mpl_mac_testing
>>> >
>>> > I know he was looking into statically linking some of the C dependencies
>>> > (freetype, libpng etc.) as a way to make the installer more robust to
>>> > different environments.
>>>
>>> Thanks - that looks like a useful testing grid.
>>>
>>> Are there any near-term plans for something like a .dmg or .mpkg or
>>> .pkg installer?
>>
>> Building a binary installer with statically linked libraries is not
>> terribly hard (see
>> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
>> l>). There are two problem:
>> - As of 1.3.0 mpl does not include python-dateutil, pytz or six (for
>> good reasons) and that makes it harder to make a really usable binary
>> installer. This interacts with the next problem:
>> - For unknown reasons running the 1.3.0 installer breaks existing
>> installations of python-dateutil if those packages were installed using
>> an older mpl binary installer.
>>
>> The missing packages can be added to the binary installer after it is
>> produced by bdist_mpkg by post-processing the mpkg. That would take care
>> of the second issue for most users (who would use the default
>> installation and get everything). I have not had time to deal with that.
>> Thus I never uploaded an official binary installer for 1.3.0 and stopped
>> providing them. Matthew Terry has taken over that task.
>
> Aha - yes - postprocessing the mpkg would be pretty easy.
>
> So - I guess I should just build the installer myself and post it for
> testing? Is that the best way forward?
OK - after a lot of blood, sweat and tears:
http://nipy.bic.berkeley.edu/practical_neuroimaging/matplotlib-1.3.1-py2.7-macosx10.6.mpkg.zip
- a standalone binary installer for matplotlib 1.3.1, including:
tornado
pyparsing
python-dateutil
pytz
six
Please do test.
It imports on my machines (10.6, 10.7 * 2, 10.8), I am just running the tests.
I'm building from a waf build that should be replicable:
https://github.com/matthew-brett/mpl-osx-binaries
On a 10.6 and a 10.8 machine I get a couple of test errors, log attached:
ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
ERROR: matplotlib.tests.test_backend_pgf.test_mixedmode
One (clean) 10.7 passes, another 10.7 machine gives the same errors as
above plus 2 ghostscript errors.
Cheers,
Matthew