On Jul 15, 2008, at 6:17 PM, Andrea Gavana wrote:
Hi All,
I am helping my girlfriend in doing some plots for her thesis (!).
Normally, matplotlib puts the graph in a box, left y axis, bottom x
axis, right y axis, top x axis. What she would like to do is to remove
the right y axis and the to
Hi All,
I am helping my girlfriend in doing some plots for her thesis (!).
Normally, matplotlib puts the graph in a box, left y axis, bottom x
axis, right y axis, top x axis. What she would like to do is to remove
the right y axis and the top x axis, akin the matlab command "box off"
(if I rem
I have scatterplots on several axes that are dynamically updated, and
thus I need to keep track of each of the PolyCollection artists that
represent the scattered data. I would like to keep the same
PolyCollection object but update the positions, colors, etc. of the
symbols, possibly changing their
On Tue, Jul 15, 2008 at 10:48 AM, James K. Gruetzner <[EMAIL PROTECTED]> wrote:
> OTOH, my GTKAgg version is 2.12,0, not 2.6.0. I'm fairly sure that is where
> the problem lies, or, more likely, in GTK itself, where I have installed:
I just tested on gtk 2.12.0 and did not see the problem with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 15 July 2008 07:48:45 John Hunter wrote:
> On Tue, Jul 15, 2008 at 8:39 AM, James K. Gruetzner <[EMAIL PROTECTED]>
wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Monday 14 July 2008 21:22:31 you wrote:
> >> >>> I wo
Hi Ian,
On Tuesday 15 July 2008 10:13:02 am Ian Harry wrote:
> Thanks for helping with this problem.
>
> I have investigated further this issue and here is what I have found out:
>
> I have traced the errors themselves back to two functions in texmanager.py
> (matplotlib.texmanager), make_dvi and
Yes, it should be. I'm further puzzled that removing "del
Gcf.figs[num]" prevents the memory leak. There is some side effect that
happens when all of the figures have been closed (I think it shuts down
the GUI mainloop), that keeping at least one figure around at all times
avoids. But I have
I am puzzled. Wasn't the whole point of close() to avoid memory leaks?
Laurent
2008/7/15 Michael Droettboom <[EMAIL PROTECTED]>:
> Yes, as of r5747 twinx (well, shared axes specifically) no longer leaks.
>
> Manuel has discovered a seemingly generic leak that occurs when
> pyplot.close() is call
Hi Darren,
Thanks for helping with this problem.
I have investigated further this issue and here is what I have found out:
I have traced the errors themselves back to two functions in texmanager.py
(matplotlib.texmanager), make_dvi and make_png. Most of the errors seem to
mention 'Stale NFS file
On Tue, Jul 15, 2008 at 8:39 AM, James K. Gruetzner <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Monday 14 July 2008 21:22:31 you wrote:
>> >>> I would think that the gtk mainloop would terminate when the window
>> >>> closes (which termination should propagat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 14 July 2008 21:22:31 you wrote:
> >>> I would think that the gtk mainloop would terminate when the window
> >>> closes (which termination should propagate back up the stack), but
> >>> apparently that doesn't happen.
> >>
> >> I'm not sure I
On Tuesday 15 July 2008 09:22:10 am David Kaplan wrote:
> Hi,
>
> I guess the problem was mostly mine. To my eyes, the Bitstream Vera
> Serif doesn't look very "serif" to me (figure attached), but I am
> probably just not used to that font. Changing font.serif as suggested
> produced much more si
On Tue, Jul 15, 2008 at 2:37 AM, Angela Rivera Campos <[EMAIL PROTECTED]> wrote:
> matplotlib version 0.90.1
> numerix numpy 1.0.3
your numpy and matplotlib versions are pretty old. Any chance you can
upgrade to numpy 1.1 and matplotlib 98.1?
JDH
---
Hi,
I guess the problem was mostly mine. To my eyes, the Bitstream Vera
Serif doesn't look very "serif" to me (figure attached), but I am
probably just not used to that font. Changing font.serif as suggested
produced much more similar output. Thanks and sorry for the unnecessary
confusion.
How
I thought you said the normal text looked sans-serif. The debugging
output seems to suggest otherwise. Maybe you can send me the generated
plot as well.
The default serif font, Bitstream Vera Serif, is not an identical match
to the STIX fonts. The STIX fonts are designed to match Times. If
Yes, as of r5747 twinx (well, shared axes specifically) no longer leaks.
Manuel has discovered a seemingly generic leak that occurs when
pyplot.close() is called and running a GUI backend. I can confirm his
results with the script he last sent.
Cheers,
Mike
Manuel Metz wrote:
> John Hunter wr
Hi,
The output from using debug-annoying is attached. It all looks
relatively normal to me, but perhaps you will see something I don't. I
am thinking that the problem is the difference between Bitstream Serif
and the STIX fonts - they are just different. Perhaps you can suggest a
way to change
First of all, thank you all for the help.
> My guess is there is something triggered by a pylab
> numpy/numerix/Numeric import, but w/o kjnowing more about your
> matplotlib and other software versions is it difficult to guess.
> Could you put these lines into a test script and run them with
John Hunter wrote:
On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
I can confirm this.
Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py)
also seems to resolve the leak. But I have no idea why, so I won't
commit it just yet. I don't have mu
19 matches
Mail list logo
