matplotlib-users Mailing List for matplotlib (Page 101)

On 10/10/2013 09:47 AM, Martin MOKREJŠ wrote:
> Benjamin Root wrote:
>>
>>
>> On Thu, Oct 10, 2013 at 9:05 AM, Martin MOKREJŠ <mmo...@gm... <mailto:mmo...@gm...>> wrote:
>>
>>      Hi,
>>        rendering some of my charts takes almost 50GB of RAM. I believe below is a stracktrace
>>      of one such situation when it already took 15GB. Would somebody comments on what is
>>      matplotlib doing at the very moment? Why the recursion?
>>
>>        The charts had to have 262422 data points in a 2D scatter plot, each point has assigned
>>      its own color. They are in batches so that there are 153 distinct colors but nevertheless,
>>      I assigned to each data point a color value. There are 153 legend items also (one color
>>      won't be used).
>>
>>      ^CTraceback (most recent call last):
>>      ...
>>          _figure.savefig(filename, dpi=100)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1421, in savefig
>>          self.canvas.print_figure(*args, **kwargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2220, in print_figure
>>          **kwargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 505, in print_png
>>          FigureCanvasAgg.draw(self)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 451, in draw
>>          self.figure.draw(self.renderer)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>          draw(artist, renderer, *args, **kwargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1034, in draw
>>          func(*args)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>          draw(artist, renderer, *args, **kwargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086, in draw
>>          a.draw(renderer)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>          draw(artist, renderer, *args, **kwargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 718, in draw
>>          return Collection.draw(self, renderer)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>          draw(artist, renderer, *args, **kwargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 276, in draw
>>          offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 551, in get_edgecolor
>>          return self._edgecolors
>>      KeyboardInterrupt
>>      ^CError in atexit._run_exitfuncs:
>>      Traceback (most recent call last):
>>        File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>>          func(*targs, **kargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>>          gc.collect()
>>      KeyboardInterrupt
>>      Error in sys.exitfunc:
>>      Traceback (most recent call last):
>>        File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>>          func(*targs, **kargs)
>>        File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>>          gc.collect()
>>      KeyboardInterrupt
>>
>>      ^C
>>
>>
>>      Clues what is the code doing? I use mpl-1.3.0.
>>      Thank you,
>>      Martin
>>
>>
>> Unfortunately, that stacktrace isn't very useful. There is no recursion there, but rather the perfectly normal drawing of the figure object that has a child axes, which has child collections which have child artist objects.
>>
>> Without the accompanying code, it would be difficult to determine where the memory hog is.
> Could there be places where gc.collect() could be introduced? Are there places where matplotlib
> could del() unnecessary objects right away? I think the problem is with huge lists or pythonic
> dicts. I could save 10GB of RAM when I converted one python dict to a bsddb3 file having just
> 10MB on disk. I speculate matplotlib in that code keeps the data in some huge list or more likely
> a dict and that is the same issue.
>
> Are you sure you cannot see where a problem is? It happens (is visible) only with huge number of
> dots, of course.

Matplotlib generally keeps data in Numpy arrays, not lists or 
dictionaries (though given that matplotlib predates Numpy, there are 
some corner cases we've found recently where arrays are converted to 
lists and back unintentionally).

As Ben said, the traceback looks quite normal -- and it doesn't show 
what any of the values are.  If you can provide us with a script that 
reproduces this, that's the only way we can really plug in and see what 
might be going wrong.  It doesn't have to have anything proprietary, 
such as your data.  You can even start with one of the existing 
examples, if that helps.

Mike

>                     _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com

Michael Droettboom wrote:
> Can you provide a complete, standalone example that reproduces the 
> problem. Otherwise all I can do is guess.
> 
> The usual culprit is forgetting to close figures after you're done with 
> them.

Thanks, I learned that through matplotlib-1.3.0 give spit over me a warning message some weeks
ago. Yes, i do call _figure.clear() and pylab.clf()  but only after the savefig() returns, which
is not the case here. Also use gc.collect() a lot through the code, especially before and after
I draw every figure. That is not enough here.





from itertools import izip, imap, ifilter
import pylab
import matplotlib
# Force matplotlib not to use any X-windows backend.
matplotlib.use('Agg')
import pylab

F = pylab.gcf()

# convert the view of numpy array to tuple
# http://matplotlib.1069221.n5.nabble.com/RendererAgg-int-width-int-height-dpi-debug-False-ValueError-width-and-height-must-each-be-below-32768-td27756.html
DefaultSize = tuple(F.get_size_inches())



def draw_hist2d_plot(filename, mydata_x, mydata_y, colors, title_data, xlabel_data, ylabel_data, legends, legend_loc='upper right', legend_bbox_to_anchor=(1.0, 1.0), legend_ncol=None, xmin=None, xmax=None, ymin=None, ymax=None, fontsize=10, legend_fontsize=8, dpi=100, tight_layout=False, legend_inside=False, objsize=0.1):
    # hist2d(x, y, bins = None, range=None, weights=None, cmin=None, cmax=None **kwargs)

    if len(mydata_x) != len(mydata_y):
        raise ValueError, "%s: len(mydata_x) != len(mydata_y): %s != %s" % (filename, len(mydata_x), len(mydata_y))

    if colors and len(mydata_x) != len(colors):
        sys.stderr.write("Warning: draw_hist2d_plot(): %s: len(mydata_x) != len(colors): %s != %s.\n" % (filename, len(mydata_x), len(colors)))

    if colors and legends and len(colors) != len(legends):
        sys.stderr.write("Warning: draw_hist2d_plot(): %s, len(colors) != len(legends): %s != %s.\n" % (filename, len(colors), len(legends)))

    if mydata_x and mydata_y and filename:
        if legends:
            if not legend_ncol:
                _subfigs, _ax1_num, _ax2_num, _legend_ncol = get_ncol(legends, fontsize=legend_fontsize)
            else:
                _subfigs, _ax1_num, _ax2_num, _legend_ncol = 3, 213, 313, legend_ncol
        else:
            _subfigs, _ax1_num, _legend_ncol = 3, 313, 0

        set_my_pylab_defaults()
        pylab.clf()
        _figure = pylab.figure()
        _figure.clear()
        _figure.set_tight_layout(True)
        gc.collect()

        if legends:
            # do not crash on too tall figures
            if 8.4 * _subfigs < 200:
                _figure.set_size_inches(11.2, 8.4 * (_subfigs + 1))
            else:
                # _figure.set_size_inches() silently accepts a large value but later on _figure.savefig() crashes with:
                # ValueError: width and height must each be below 32768
                _figure.set_size_inches(11.2, 200)
                sys.stderr.write("Warning: draw_hist2d_plot(): Wanted to set %s figure height to %s but is too high, forcing %s instead. You will likely get an incomplete image.\n" % (filename, 8.4 * _subfigs, 200))
            if myoptions.debug > 5: print "Debug: draw_hist2d_plot(): Changed %s figure size to: %s" % (filename, str(_figure.get_size_inches()))
            _ax1 = _figure.add_subplot(_ax1_num)
            _ax2 = _figure.add_subplot(_ax2_num)
        else:
            _figure.set_size_inches(11.2, 8.4 * 2)
            _ax1 = _figure.gca()
        if myoptions.debug > 5: print "Debug: draw_hist2d_plot(): Changed %s figure size to: %s" % (filename, str(_figure.get_size_inches()))

        _series = []
        #for _x, _y, _c, _l in izip(mydata_x, mydata_y, colors, legends):
        for _x, _y, _c in izip(mydata_x, mydata_y, colors):
            # _Line2D = _ax1.plot(_x, _y) # returns Line2D object
            _my_PathCollection = _ax1.scatter(_x, _y, color=_c, s=objsize) # , label=_l) # returns PathCollection object
            _series.append(_my_PathCollection)

        if legends:
            #for _x, _y, _c, _l in izip(mydata_x, mydata_y, colors, legends):
            for _x, _y, _c in izip(mydata_x, mydata_y, colors):
                _my_PathCollection = _ax1.scatter(_x, _y, color=_c, s=objsize) # , label=_l)
                _series.append(_my_PathCollection)

            _ax2.legend(_series, legends, loc='upper left', bbox_to_anchor=(0,0,1,1), borderaxespad=0., ncol=_legend_ncol, mode='expand', fontsize=legend_fontsize)
            _ax2.set_frame_on(False)
            _ax2.tick_params(bottom='off', left='off', right='off', top='off')
            pylab.setp(_ax2.get_yticklabels(), visible=False)
            pylab.setp(_ax2.get_xticklabels(), visible=False)
        else:
            for _x, _y, _c in izip(mydata_x, mydata_y, colors):
                _ax1.scatter(_x, _y, color=_c, s=objsize) #, marker='^') # keeps eating memory in:
                #
                #     draw_hist2d_plot(filename, _data_xrow, _data_yrow, _my_colors, _title, _xlabel, _ylabel, [], xmin=None, xmax=None, ymin=None, ymax=None, fontsize=10, dpi=100)
                #  File "/blah.py", line 14080, in draw_hist2d_plot
                #     _ax1.scatter(_x, _y, color=_c, s=objsize) #, marker='^')
                #  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 6247, in scatter
                #     self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)
                #  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 1685, in _process_unit_info
                #     self.xaxis.update_units(xdata)
                #  File "/usr/lib64/python2.7/site-packages/matplotlib/axis.py", line 1332, in update_units
                #     converter = munits.registry.get_converter(data)

            # pylab.subplots_adjust(left = (5/25.4)/_figure.xsize, bottom = (4/25.4)/_figure.ysize, right = 1 - (1/25.4)/_figure.xsize, top = 1 - (3/25.4)/_figure.ysize)

        _ax1.set_xlabel(xlabel_data, fontsize=fontsize)
        _ax1.set_ylabel(ylabel_data, fontsize=fontsize)
        _ax1.set_xmargin(0.05)
        _ax1.set_ymargin(0.05)
        _ax1.set_autoscale_on(False)


        set_limits(_ax1, xmin, xmax, ymin, ymax)

        if fontsize == 10:
            _ax1.set_title('\n'.join(wrap(title_data, 100)), fontsize=fontsize+2)
        elif fontsize == 12:
            _ax1.set_title('\n'.join(wrap(title_data, 90)), fontsize=fontsize+2)
        else:
            _ax1.set_title('\n'.join(wrap(title_data, 100)), fontsize=fontsize+2)

        if legends:
            _figure.savefig(filename, dpi=100) #, bbox_inches='tight')
            del(_my_PathCollection)
            del(_ax2)
        else:
            _figure.savefig(filename, dpi=100)

        del(_series)
        del(_ax1)
        _figure.clear()
        del(_figure)
        pylab.clf()
        pylab.close()
        # pylab.rcdefaults()

        gc.collect()



That's the whole function. I used to suspect _ax1.scatter() in the past but probably
only because I hit the memory problems earlier. That is worked around now by using
on disk bsddb3 file or gdbm somewhere upstream. This particular function is nevertheless
fed with just a huge list numbers, and that is not the issue in itself.

I would be glad if I could tell matplotlib: Here you have 100 colors, use them for all data
as you wish, just spread them evenly over the whole dataset so that first 1/100th of the data
gets the first color, second 1/100th of the data gets the second color, and so on. Optionally,
if you would like to say: use the 100 colors in cycles for all data points, just loop through
the colors as long as you need some. In both scenarios, I could have avoided the two for loops
in the above code and necessity to generate those objects. Same for legend stuff.

Martin

> 
> Mike
> 
> On 10/10/2013 09:05 AM, Martin MOKREJŠ wrote:
>> Hi,
>>    rendering some of my charts takes almost 50GB of RAM. I believe below is a stracktrace
>> of one such situation when it already took 15GB. Would somebody comments on what is
>> matplotlib doing at the very moment? Why the recursion?
>>
>>    The charts had to have 262422 data points in a 2D scatter plot, each point has assigned
>> its own color. They are in batches so that there are 153 distinct colors but nevertheless,
>> I assigned to each data point a color value. There are 153 legend items also (one color
>> won't be used).
>>
>> ^CTraceback (most recent call last):
>> ...
>>      _figure.savefig(filename, dpi=100)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1421, in savefig
>>      self.canvas.print_figure(*args, **kwargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2220, in print_figure
>>      **kwargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 505, in print_png
>>      FigureCanvasAgg.draw(self)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 451, in draw
>>      self.figure.draw(self.renderer)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>      draw(artist, renderer, *args, **kwargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1034, in draw
>>      func(*args)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>      draw(artist, renderer, *args, **kwargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086, in draw
>>      a.draw(renderer)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>      draw(artist, renderer, *args, **kwargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 718, in draw
>>      return Collection.draw(self, renderer)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>>      draw(artist, renderer, *args, **kwargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 276, in draw
>>      offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 551, in get_edgecolor
>>      return self._edgecolors
>> KeyboardInterrupt
>> ^CError in atexit._run_exitfuncs:
>> Traceback (most recent call last):
>>    File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>>      func(*targs, **kargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>>      gc.collect()
>> KeyboardInterrupt
>> Error in sys.exitfunc:
>> Traceback (most recent call last):
>>    File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>>      func(*targs, **kargs)
>>    File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>>      gc.collect()
>> KeyboardInterrupt
>>
>> ^C
>>
>>
>> Clues what is the code doing? I use mpl-1.3.0.
>> Thank you,
>> Martin
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
Martin Mokrejs, Ph.D.
Bioinformatics
Donovalska 1658
149 00 Prague
Czech Republic
http://www.iresite.org
http://www.iresite.org/~mmokrejs

On Thu, Oct 10, 2013 at 9:47 AM, Martin MOKREJŠ <mmo...@gm...> wrote:

> Benjamin Root wrote:
> >
> >
> >
> > On Thu, Oct 10, 2013 at 9:05 AM, Martin MOKREJŠ <mmo...@gm...<mailto:
> mmo...@gm...>> wrote:
> >
> >     Hi,
> >       rendering some of my charts takes almost 50GB of RAM. I believe
> below is a stracktrace
> >     of one such situation when it already took 15GB. Would somebody
> comments on what is
> >     matplotlib doing at the very moment? Why the recursion?
> >
> >       The charts had to have 262422 data points in a 2D scatter plot,
> each point has assigned
> >     its own color. They are in batches so that there are 153 distinct
> colors but nevertheless,
> >     I assigned to each data point a color value. There are 153 legend
> items also (one color
> >     won't be used).
> >
> >     ^CTraceback (most recent call last):
> >     ...
> >         _figure.savefig(filename, dpi=100)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py",
> line 1421, in savefig
> >         self.canvas.print_figure(*args, **kwargs)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line
> 2220, in print_figure
> >         **kwargs)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py",
> line 505, in print_png
> >         FigureCanvasAgg.draw(self)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py",
> line 451, in draw
> >         self.figure.draw(self.renderer)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
> >         draw(artist, renderer, *args, **kwargs)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py",
> line 1034, in draw
> >         func(*args)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
> >         draw(artist, renderer, *args, **kwargs)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line
> 2086, in draw
> >         a.draw(renderer)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
> >         draw(artist, renderer, *args, **kwargs)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 718,
> in draw
> >         return Collection.draw(self, renderer)
> >       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
> >         draw(artist, renderer, *args, **kwargs)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 276,
> in draw
> >         offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 551,
> in get_edgecolor
> >         return self._edgecolors
> >     KeyboardInterrupt
> >     ^CError in atexit._run_exitfuncs:
> >     Traceback (most recent call last):
> >       File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
> >         func(*targs, **kargs)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90,
> in destroy_all
> >         gc.collect()
> >     KeyboardInterrupt
> >     Error in sys.exitfunc:
> >     Traceback (most recent call last):
> >       File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
> >         func(*targs, **kargs)
> >       File
> "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90,
> in destroy_all
> >         gc.collect()
> >     KeyboardInterrupt
> >
> >     ^C
> >
> >
> >     Clues what is the code doing? I use mpl-1.3.0.
> >     Thank you,
> >     Martin
> >
> >
> > Unfortunately, that stacktrace isn't very useful. There is no recursion
> there, but rather the perfectly normal drawing of the figure object that
> has a child axes, which has child collections which have child artist
> objects.
> >
> > Without the accompanying code, it would be difficult to determine where
> the memory hog is.
>
> Could there be places where gc.collect() could be introduced? Are there
> places where matplotlib
> could del() unnecessary objects right away? I think the problem is with
> huge lists or pythonic
> dicts. I could save 10GB of RAM when I converted one python dict to a
> bsddb3 file having just
> 10MB on disk. I speculate matplotlib in that code keeps the data in some
> huge list or more likely
> a dict and that is the same issue.
>
> Are you sure you cannot see where a problem is? It happens (is visible)
> only with huge number of
> dots, of course.
>
>
I am not going to claim that matplotlib is the most lean graphing library
out there, and we already do know where we can make continued improvements,
but the symptom you are describing (50 GB for a couple hundred thousand
scatter points) is just unheard of for matplotlib. Without a simple,
concise, complete code example to demonstrate your problem, we can only
hazard guesses. For all I know, you might be "appending" to numpy arrays in
a loop prior to plotting, which would eat up significant amount of memory
without it being the fault of matplotlib.

As far as I am aware, we don't do very large dictionaries, so I am doubtful
that is the issue either.

As a side note, I have typically found that situations where del()
significantly improved memory usage were typically situations where I was
"doing it wrong" in the first place and a simple refactor of the code
improved memory and (sometimes) speed, with an added benefit of improved
readability.  I have even seen situations where calling del() in the wrong
places (say, for a list created at the beginning of the loop) actually hurt
performance because python couldn't recycle that chunk of memory.

Give us a code example that reproduces your problem, and then we can start
doing some more serious debugging.

Ben Root





> Thanks,
> Martin
>

Benjamin Root wrote:
> 
> 
> 
> On Thu, Oct 10, 2013 at 9:05 AM, Martin MOKREJŠ <mmo...@gm... <mailto:mmo...@gm...>> wrote:
> 
>     Hi,
>       rendering some of my charts takes almost 50GB of RAM. I believe below is a stracktrace
>     of one such situation when it already took 15GB. Would somebody comments on what is
>     matplotlib doing at the very moment? Why the recursion?
> 
>       The charts had to have 262422 data points in a 2D scatter plot, each point has assigned
>     its own color. They are in batches so that there are 153 distinct colors but nevertheless,
>     I assigned to each data point a color value. There are 153 legend items also (one color
>     won't be used).
> 
>     ^CTraceback (most recent call last):
>     ...
>         _figure.savefig(filename, dpi=100)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1421, in savefig
>         self.canvas.print_figure(*args, **kwargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2220, in print_figure
>         **kwargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 505, in print_png
>         FigureCanvasAgg.draw(self)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 451, in draw
>         self.figure.draw(self.renderer)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>         draw(artist, renderer, *args, **kwargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1034, in draw
>         func(*args)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>         draw(artist, renderer, *args, **kwargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086, in draw
>         a.draw(renderer)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>         draw(artist, renderer, *args, **kwargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 718, in draw
>         return Collection.draw(self, renderer)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>         draw(artist, renderer, *args, **kwargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 276, in draw
>         offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
>       File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 551, in get_edgecolor
>         return self._edgecolors
>     KeyboardInterrupt
>     ^CError in atexit._run_exitfuncs:
>     Traceback (most recent call last):
>       File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>         func(*targs, **kargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>         gc.collect()
>     KeyboardInterrupt
>     Error in sys.exitfunc:
>     Traceback (most recent call last):
>       File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>         func(*targs, **kargs)
>       File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>         gc.collect()
>     KeyboardInterrupt
> 
>     ^C
> 
> 
>     Clues what is the code doing? I use mpl-1.3.0.
>     Thank you,
>     Martin
> 
> 
> Unfortunately, that stacktrace isn't very useful. There is no recursion there, but rather the perfectly normal drawing of the figure object that has a child axes, which has child collections which have child artist objects.
> 
> Without the accompanying code, it would be difficult to determine where the memory hog is.

Could there be places where gc.collect() could be introduced? Are there places where matplotlib
could del() unnecessary objects right away? I think the problem is with huge lists or pythonic
dicts. I could save 10GB of RAM when I converted one python dict to a bsddb3 file having just
10MB on disk. I speculate matplotlib in that code keeps the data in some huge list or more likely
a dict and that is the same issue.

Are you sure you cannot see where a problem is? It happens (is visible) only with huge number of
dots, of course.

Thanks,
Martin

Can you provide a complete, standalone example that reproduces the 
problem. Otherwise all I can do is guess.

The usual culprit is forgetting to close figures after you're done with 
them.

Mike

On 10/10/2013 09:05 AM, Martin MOKREJŠ wrote:
> Hi,
>    rendering some of my charts takes almost 50GB of RAM. I believe below is a stracktrace
> of one such situation when it already took 15GB. Would somebody comments on what is
> matplotlib doing at the very moment? Why the recursion?
>
>    The charts had to have 262422 data points in a 2D scatter plot, each point has assigned
> its own color. They are in batches so that there are 153 distinct colors but nevertheless,
> I assigned to each data point a color value. There are 153 legend items also (one color
> won't be used).
>
> ^CTraceback (most recent call last):
> ...
>      _figure.savefig(filename, dpi=100)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1421, in savefig
>      self.canvas.print_figure(*args, **kwargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2220, in print_figure
>      **kwargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 505, in print_png
>      FigureCanvasAgg.draw(self)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 451, in draw
>      self.figure.draw(self.renderer)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>      draw(artist, renderer, *args, **kwargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1034, in draw
>      func(*args)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>      draw(artist, renderer, *args, **kwargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086, in draw
>      a.draw(renderer)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>      draw(artist, renderer, *args, **kwargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 718, in draw
>      return Collection.draw(self, renderer)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
>      draw(artist, renderer, *args, **kwargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 276, in draw
>      offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
>    File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 551, in get_edgecolor
>      return self._edgecolors
> KeyboardInterrupt
> ^CError in atexit._run_exitfuncs:
> Traceback (most recent call last):
>    File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>      func(*targs, **kargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>      gc.collect()
> KeyboardInterrupt
> Error in sys.exitfunc:
> Traceback (most recent call last):
>    File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>      func(*targs, **kargs)
>    File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
>      gc.collect()
> KeyboardInterrupt
>
> ^C
>
>
> Clues what is the code doing? I use mpl-1.3.0.
> Thank you,
> Martin
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

On Thu, Oct 10, 2013 at 9:05 AM, Martin MOKREJŠ <mmo...@gm...> wrote:

> Hi,
>   rendering some of my charts takes almost 50GB of RAM. I believe below is
> a stracktrace
> of one such situation when it already took 15GB. Would somebody comments
> on what is
> matplotlib doing at the very moment? Why the recursion?
>
>   The charts had to have 262422 data points in a 2D scatter plot, each
> point has assigned
> its own color. They are in batches so that there are 153 distinct colors
> but nevertheless,
> I assigned to each data point a color value. There are 153 legend items
> also (one color
> won't be used).
>
> ^CTraceback (most recent call last):
> ...
>     _figure.savefig(filename, dpi=100)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line
> 1421, in savefig
>     self.canvas.print_figure(*args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py",
> line 2220, in print_figure
>     **kwargs)
>   File
> "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py",
> line 505, in print_png
>     FigureCanvasAgg.draw(self)
>   File
> "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py",
> line 451, in draw
>     self.figure.draw(self.renderer)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54,
> in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line
> 1034, in draw
>     func(*args)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54,
> in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086,
> in draw
>     a.draw(renderer)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54,
> in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py",
> line 718, in draw
>     return Collection.draw(self, renderer)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54,
> in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py",
> line 276, in draw
>     offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
>   File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py",
> line 551, in get_edgecolor
>     return self._edgecolors
> KeyboardInterrupt
> ^CError in atexit._run_exitfuncs:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>     func(*targs, **kargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py",
> line 90, in destroy_all
>     gc.collect()
> KeyboardInterrupt
> Error in sys.exitfunc:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
>     func(*targs, **kargs)
>   File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py",
> line 90, in destroy_all
>     gc.collect()
> KeyboardInterrupt
>
> ^C
>
>
> Clues what is the code doing? I use mpl-1.3.0.
> Thank you,
> Martin
>
>
Unfortunately, that stacktrace isn't very useful. There is no recursion
there, but rather the perfectly normal drawing of the figure object that
has a child axes, which has child collections which have child artist
objects.

Without the accompanying code, it would be difficult to determine where the
memory hog is.

Ben Root

Hi,
  rendering some of my charts takes almost 50GB of RAM. I believe below is a stracktrace
of one such situation when it already took 15GB. Would somebody comments on what is
matplotlib doing at the very moment? Why the recursion?

  The charts had to have 262422 data points in a 2D scatter plot, each point has assigned
its own color. They are in batches so that there are 153 distinct colors but nevertheless,
I assigned to each data point a color value. There are 153 legend items also (one color
won't be used).

^CTraceback (most recent call last):
...
    _figure.savefig(filename, dpi=100)
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1421, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2220, in print_figure
    **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 505, in print_png
    FigureCanvasAgg.draw(self)
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 451, in draw
    self.figure.draw(self.renderer)
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1034, in draw
    func(*args)
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086, in draw
    a.draw(renderer)
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 718, in draw
    return Collection.draw(self, renderer)
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 276, in draw
    offsets, transOffset, self.get_facecolor(), self.get_edgecolor(),
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 551, in get_edgecolor
    return self._edgecolors
KeyboardInterrupt
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
    gc.collect()
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/_pylab_helpers.py", line 90, in destroy_all
    gc.collect()
KeyboardInterrupt

^C


Clues what is the code doing? I use mpl-1.3.0.
Thank you,
Martin

On Thu, Oct 3, 2013 at 1:05 PM, dilpreet singh <gig...@gm...> wrote:

> Hi
>
> I am plotting a scatter plot where y axis has a log scale but in the graph
> the y axis always starts from 10 to the power -1 . I tried setting the
> limit with set_ylim() but i am not sure what value to give within this
> method since its a log scale . Is there a way i can start y axis from 10 to
> the power -0.25  .
>
>
> Thanks
> Dilpreet
>
>
The values for set_ylim() and set_xlim() are the raw data values. So, if
you want to start from 10**-0.25, you do:

ax.set_ylim(bottom=10**-0.25)

Do note that once you set the limits, the auto-detection of the limits turn
off. So, it is best to issue these sorts of commands after you finish
plotting all the data.
I hope that helps!
Ben Root



>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi Michael,

so finally how it goes? I may use something similar, do you finally make it?

cheers,

Chao



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/way-to-copy-an-axes-object-into-different-figures-tp41623p42203.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi, 

I have an issue using latex in my plot file. Below are my information.

1. Operating system: Max OS X version 10.7.5
uname -a 
Darwin pyramid.phys.northwestern.edu 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

2. matplotlib version: 1.3.0

3. Obtain matplotlib from EPD.
Python 2.7.3 | 64-bit | (default, Aug  8 2013, 05:37:06) 
IPython 0.13.1 -- An enhanced Interactive Python.

4. Here is my matplotlibrc file, I don't have any special customizations


5. The python script that demonstrate the problem can behttp://matplotlib.org/examples/pylab_examples/tex_demo.html


6. The debugging output from matplotlib is


7. I did not compile matplotlib myself.

Bests, Hao

Sun, 6 Oct 2013 15:41:07 -0500 Tony Yu <ts...@gm...>:

> The return value for streamplot is a bit hacked together. Its just a
> simple object containing a line collection and an arrow collection.
> Instead of passing the set of collections, just pass one of the
> collections to the colorbar. For example:
> 
>     sset = grid[i].streamplot(XPTS, YPTS, zx, zy, color=zr)
>     grid.cbar_axes[i].colorbar(sset.lines)
> 
> Does that work for you?

works like a charm - thank you!

best regards,
Yoshi

On Thu, Sep 26, 2013 at 10:37 AM, Yoshi Rokuko <yo...@ro...> wrote:

> Hey,
>
> I'm trying to plot streamplots into an axesgrid object with something
> like:
>
> fig = pl.figure(1, (13, 20))
> grid = AxesGrid(fig, 111,
>                 nrows_ncols = (3, 2),
>                 axes_pad = 0.6,
>                 cbar_location = 'top',
>                 cbar_mode = 'each',
>                 cbar_size = '2%',
>                 cbar_pad = '1%',
>                )
> [...]
>     norm = mpl.colors.LogNorm(vmin=1, vmax=5000)
>     im = grid[i].streamplot(XPTS, YPTS, zx, zy,
>                             color=zr,
>                             arrowsize=.001,
>                             norm=norm)
>     grid.cbar_axes[i].colorbar(im)
> [...]
>
> and then it failes with:
>
> Traceback (most recent call last):
>   File "./results.py", line 96, in <module>
>     grid.cbar_axes[i].colorbar(im)
>   File
> "/usr/lib/python2.7/site-packages/mpl_toolkits/axes_grid1/axes_grid.py",
> line 85, in colorbar cb = Colorbar(self, mappable,
> orientation=orientation, **kwargs) File
> "/usr/lib/python2.7/site-packages/mpl_toolkits/axes_grid1/colorbar.py",
> line 706, in __init__ mappable.autoscale_None() # Ensure
> mappable.norm.vmin, vmax AttributeError: 'StreamplotSet' object has no
> attribute 'autoscale_None'
>
> can't I use streamplots in axesgrid? If I comment out the colorbar for
> the streamplot colors it works ...
> Is this a bug? Is there a right way to do it? Is there a work around?
>

Hi Yoshi,

The return value for streamplot is a bit hacked together. Its just a simple
object containing a line collection and an arrow collection. Instead of
passing the set of collections, just pass one of the collections to the
colorbar. For example:

    sset = grid[i].streamplot(XPTS, YPTS, zx, zy, color=zr)
    grid.cbar_axes[i].colorbar(sset.lines)

Does that work for you?

Best,
-Tony


>
> Many thanks in advance!
>
> Regards, Yoshi

Thank you Mike, Werner and Benjamin for the good, and very fast, support.

Kind regards,
Antonio



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-installation-with-Python-x-y-tp42149p42178.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi,

On Thu, Oct 3, 2013 at 1:29 PM, Russell E. Owen <ro...@uw...> wrote:
> In article
> <CAH...@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?

Cheers,

Matthew

In article 
<CAH...@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.

I did put an unofficial binary installer for 1.3.0 here:
<http://www.astro.washington.edu/users/rowen/python/>
just be prepared to reinstall python-dateutil after you use it.

-- Russell

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?

Cheers,

Matthew

Hi

I am plotting a scatter plot where y axis has a log scale but in the graph
the y axis always starts from 10 to the power -1 . I tried setting the
limit with set_ylim() but i am not sure what value to give within this
method since its a log scale . Is there a way i can start y axis from 10 to
the power -0.25  .


Thanks
Dilpreet

Hi,

I would like to make Patch class (a compass) and be able to set its size in
points and its position finally interpeted in data coordinates once the
patch is added add to axes.
I tried start from a mix of existing patch classes (Patch, Polygon,
Shadow), but they all deal with transforms in a different way.

So, how to code it in a proper way ?

Thank for your help.

-- 
Stephane Raynaud

On Thu, Oct 3, 2013 at 9:22 AM, ajdcds <aj...@ho...> wrote:

> Benjamin, thank you very much for the tip!
>
> If I do
>
> import matplotlib
> matplotlib.use("TkAgg")
>
> This is only valid for the current script that is running, the matplotlibrc
> remains the same, right?
>
>
Yes, that is correct.

Benjamin, thank you very much for the tip!

If I do

import matplotlib
matplotlib.use("TkAgg")

This is only valid for the current script that is running, the matplotlibrc
remains the same, right?



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-installation-with-Python-x-y-tp42149p42170.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Thu, Oct 3, 2013 at 6:35 AM, ajdcds <aj...@ho...> wrote:

> Sorry, of course it does not work, the import is incorrect!
>
> It should be
>
> import matplotlib as plt
> plt.rcParams['backend'] = 'TkAgg'
>
> or simply
> import matplotlib
> matplotlib.rcParams['backend'] = 'TkAgg'
>
>
Errr... no, don't do "import matplotlib as plt". That is just confusing.

To change backends, do the following:

import matplotlib
matplotlib.use("TkAgg")

Because backends are loaded upon import of matplotlib, changing the rcParam
after importing matplotlib is too late. You force a switch of the backend
via the "use()" function.

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.

Mike

On 10/02/2013 04:15 PM, Matthew Brett wrote:
> Hi,
>
> Anything I can do to help get a binary installer for OSX?
>
> If I wanted to build one myself - is there a good place to start
> looking to understand the problems?
>
> Cheers,
>
> Matthew
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Sorry, of course it does not work, the import is incorrect!

It should be

import matplotlib as plt 
plt.rcParams['backend'] = 'TkAgg' 

or simply 
import matplotlib
matplotlib.rcParams['backend'] = 'TkAgg' 




--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-installation-with-Python-x-y-tp42149p42167.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

We were able to find the difference when installing Matplotlib via
Python(x,y) or as a separate package.
The difference is on paramater /backend/ on /matplotlibrc/ file.
/Python(x,y)-2.6.6.2.exe/ set the parameter to *Qt4Agg*
/matplotlib-1.0.1.win32-py2.6.exe/ sets the parameter to *TKAgg*

if backend : TKAgg
then the error
/  File
"C:\Python26\lib\site-packages\matplotlib\backends\qt4_editor\formlayout.py",
line 51, in <module>
    raise ImportError, "Warning: formlayout requires PyQt4 >v4.3"
ImportError: Warning: formlayout requires PyQt4 >v4.3/ 
Does not appear anymore.

Now looking how to use TKAgg without changing the matplotlibrc.
I've tried:

import matplotlib.pyplot as plt
plt.rcParams['backend'] = 'TkAgg'

But doesn't see to work.

Any suggestions?



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-installation-with-Python-x-y-tp42149p42166.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi,

On 03/10/2013 09:31, ajdcds wrote:
> If doing
>
> c:\Python26\python.exe file.py
>
> Then the error is on import private files, stated on my first post as
> /import <something>/
I didn't see a response from you on this:

c:\Python26\python.exe

from PyQt4.QtGui import QFormLayout

Does this give an import error?

If above does not give an import error can you try:

c:\Python26\python.exe 
folder_with_matplot_examples/user_interfaces/embedding_in_qt4.py

If this works then I am guessing that your 'file.py' does somehow 
manipulate the sys.path.

Werner