matplotlib-users Mailing List for matplotlib (Page 11)

Is it possible to have nested subplots?

I would like to have 2 rows....with the top row having two columns and
the bottom row having one column.

For the bottom plot, I'd like to be able to choose between the following:
  1) The size of the bottom plot expands to fill the entire horizontal space.
  2) The size of the bottom plot is unchanged (same as the other two
plots) and is simply centered in the bottom row.

x  x
  x

Thanks.

Lars,

I  don't think you can do much about this using the interactive tool, so 
your options are:

1) position all axes explicitly, or

2) use colorbar kwargs to get a more pleasing arrangement.  The relevant 
kwargs are:

             fraction    = 0.15; fraction of original axes to use for 
colorbar
             pad         = 0.05 if vertical, 0.15 if horizontal; fraction
                                   of original axes between colorbar and
                                   new image axes
             shrink      = 1.0; fraction by which to shrink the colorbar
             aspect      = 20; ratio of long to short dimensions


Eric

Lars Friedrich wrote:
> Hello,
> 
> I would like to have multiple image plots in a figure. Each plot should 
> have its own colorbar. I tried the following:
> 
> **********************************
> a = N.array(((1,2,3), (4,5,6)))
> 
> P.figure(0)
> P.subplot(1,2,1)
> P.imshow(a)
> P.colorbar()
> 
> P.subplot(1,2,2)
> P.imshow(a)
> P.colorbar()
> ************************************
> 
> The two images display and have their own colorbar, each. However, the 
> placement is not optimal. (see attached 'colorbar1.png') But when I try 
> to use the "Configure subplot parameters" feature in the interactive 
> figure window, only the image plots are affected and the colorbars stay 
> as they are. When I hit the reset button in the "configure subplots" 
> dialogue, the figure looks different from the way it looked, when it was 
> generated (see attached 'colorbar2.png'). Do I have to do all the 
> placement on my own by using axes.set_position or is there a more 
> comfortable way using the subplot syntax?
> 
> Thanks
> Lars
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Mike,

    Updating to 0.91.1 fixed it.  Python's memory usage was climbing in 
excess of 1 GB when running this script before (eventually crashing) -- 
now it hovers nicely around 60MB and completes with no problems.  Excellent!

Thanks,

--Jordan

Michael Droettboom wrote:

> You can try running the garbage collector after each savefig.  
> ("import gc" and then call "gc.collect()").  If you are using a GUI 
> backend, you may want to try using the "raw" Agg backend instead -- 
> there are fewer moving parts that way.
>
> There have been a number of memory leaks that have been fixed since 
> 0.90.1.  You may want to try 0.91 or a SVN checkout to see if that 
> fixes your problem.
>
> There is additional information about memory leaks in the FAQ.  I 
> don't know if any are relevant to your particular situation:
>
> http://matplotlib.sourceforge.net/faq.html#LEAKS
>
> If none of the above helps, please send a complete but short script 
> that reproduces the error (basing it on memleak_gui.py or 
> memleak_hawaii.py is even more helpful), and one of the developers can 
> look into it.
>
> Cheers,
> Mike
>
> Jordan Atlas wrote:
>
>> Hi all,
>>
>>     I've noticed that when I save my figures using savefig the memory 
>> is not immediately released.  For example, in pseudocode,
>>
>> times = get_times()
>> for var_id in var_list:
>>     Plotting.figure()
>>     var_values = get_values(var_id)
>>     pylab.plot(times, values)
>>     Plotting.savefig(var+'.png', dpi=150)
>>     Plotting.close()
>>
>> This pseudo code loops over a list of variables, gets their values, 
>> and saves a plot for each one.  The variable list has hundreds of 
>> items.  If I run the code like this, the memory usage grows very 
>> quickly until python crashes.  If I comment out the savefig line, or 
>> shorten the list of variables, the code completes without error.
>>
>> Can anyone suggest how I might write this differently so that I can 
>> process the long list of variables and save the figures?  Is there 
>> any way to force the program to release memory once the figures are 
>> saved?
>>
>> I'm using matplotlib 0.90.1 and python 2.4 on windows XP.
>>
>> Thank you,
>>
>> --Jordan Atlas
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> SF.Net email is sponsored by: The Future of Linux Business White Paper
>> from Novell.  From the desktop to the data center, Linux is going
>> mainstream.  Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

This is apparently a configuration option of mailman that has been 
purposefully set for the matplotlib mailing lists.  I don't have strong 
opinions about this, but you may be interested in this thread:

http://sourceforge.net/mailarchive/message.php?msg_id=903323ff0708220749r82f9650i7338e63a56d6094d%40mail.gmail.com

Cheers,
Mike

massimo sandal wrote:
> Robert Dailey ha scritto:
> 
>> What are the different ways one could send an email to a mailing list?
> 
> On a related note, I *hate* that hitting "reply" uses the mail address 
> of the parent poster, instead than that of the mailing list. The scipy 
> and the gentoo mailing list (two other examples I know) behave more 
> properly. Is this a sourceforge quirk?
> 
> m.
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

You can try running the garbage collector after each savefig.  ("import 
gc" and then call "gc.collect()").  If you are using a GUI backend, you 
may want to try using the "raw" Agg backend instead -- there are fewer 
moving parts that way.

There have been a number of memory leaks that have been fixed since 
0.90.1.  You may want to try 0.91 or a SVN checkout to see if that fixes 
your problem.

There is additional information about memory leaks in the FAQ.  I don't 
know if any are relevant to your particular situation:

http://matplotlib.sourceforge.net/faq.html#LEAKS

If none of the above helps, please send a complete but short script that 
reproduces the error (basing it on memleak_gui.py or memleak_hawaii.py 
is even more helpful), and one of the developers can look into it.

Cheers,
Mike

Jordan Atlas wrote:
> Hi all,
> 
>     I've noticed that when I save my figures using savefig the memory is 
> not immediately released.  For example, in pseudocode,
> 
> times = get_times()
> for var_id in var_list:
>     Plotting.figure()
>     var_values = get_values(var_id)
>     pylab.plot(times, values)
>     Plotting.savefig(var+'.png', dpi=150)
>     Plotting.close()
> 
> This pseudo code loops over a list of variables, gets their values, and 
> saves a plot for each one.  The variable list has hundreds of items.  If 
> I run the code like this, the memory usage grows very quickly until 
> python crashes.  If I comment out the savefig line, or shorten the list 
> of variables, the code completes without error.
> 
> Can anyone suggest how I might write this differently so that I can 
> process the long list of variables and save the figures?  Is there any 
> way to force the program to release memory once the figures are saved?
> 
> I'm using matplotlib 0.90.1 and python 2.4 on windows XP.
> 
> Thank you,
> 
> --Jordan Atlas
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Robert Dailey ha scritto:

> What are the different ways one could send an email to a mailing list?

On a related note, I *hate* that hitting "reply" uses the mail address 
of the parent poster, instead than that of the mailing list. The scipy 
and the gentoo mailing list (two other examples I know) behave more 
properly. Is this a sourceforge quirk?

m.

-- 
Massimo Sandal
University of Bologna
Department of Biochemistry "G.Moruzzi"

snail mail:
Via Irnerio 48, 40126 Bologna, Italy

email:
mas...@un...

tel: +39-051-2094388
fax: +39-051-2094387

Hi all,

    I've noticed that when I save my figures using savefig the memory is 
not immediately released.  For example, in pseudocode,

times = get_times()
for var_id in var_list:
    Plotting.figure()
    var_values = get_values(var_id)
    pylab.plot(times, values)
    Plotting.savefig(var+'.png', dpi=150)
    Plotting.close()

This pseudo code loops over a list of variables, gets their values, and 
saves a plot for each one.  The variable list has hundreds of items.  If 
I run the code like this, the memory usage grows very quickly until 
python crashes.  If I comment out the savefig line, or shorten the list 
of variables, the code completes without error.

Can anyone suggest how I might write this differently so that I can 
process the long list of variables and save the figures?  Is there any 
way to force the program to release memory once the figures are saved?

I'm using matplotlib 0.90.1 and python 2.4 on windows XP.

Thank you,

--Jordan Atlas

Hey guys,

I realize this isn't the place to post this but I can't figure out a better
place. I just had a really quick question.

Sometimes I notice that mail I receive from this mailing list was never
directly (through To: or CC:) sent to the mailing list. For example, say
there's two people communicating:

fo...@bl...
fo...@bl...

Usually when foo1 sends a mail to foo2, foo2 will receive a mail like this:

To: fo...@bl...
From: fo...@bl...
CC: mat...@li...

However, in one case I found that the mail was never sent to
matplotlib-users. However, somehow the list.sourceforge.net mailing server
intercepted it and sent it to the other person via a 'bounce' email address.
How does this happen? What are the different ways one could send an email to
a mailing list?

Thanks, and again apologies for the off topic post.

I have the CocoaAgg backend specified in matplotlibrc in ~/.matplotlib/ as:

backend      : CocoaAgg

However, when I plot, matplotlib uses the TkAgg backend in spite of this.

-- 
Christopher J. Fonnesbeck
+ Fish & Wildlife Research Institute (FWC)
+ 727.235.5570

On Tuesday 04 December 2007 16:05:33 John Hunter wrote:
> On Dec 4, 2007 10:00 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:
> > Interestingly enough, the embedding_in_gtk.py script works perfectly
> > (takes less than a second to run), so I am not able to reproduce the
> > slowness!
>
> Hmm, the plot thickens.  How about embedding_in_gtk2.py -- this add the
> toolbar

This does indeed slow things down. The minimal script that reproduces this=
=20
behaviour is the following (the delay appears round about the definition of=
=20
toolbar):

import gtk
from matplotlib.axes import Subplot
from matplotlib.figure import Figure
from numpy import arange, sin, pi
from matplotlib.backends.backend_gtk import FigureCanvasGTK as FigureCanvas
from matplotlib.backends.backend_gtk import NavigationToolbar2GTK \
	as NavigationToolbar
win =3D gtk.Window()
win.connect("destroy", lambda x: gtk.main_quit())
win.set_default_size(400,300)
win.set_title("Embedding in GTK")
fig =3D Figure(figsize=3D(5,4), dpi=3D100)
canvas =3D FigureCanvas(fig)
toolbar =3D NavigationToolbar(canvas, win)
# ^ Delay appears here
win.add(toolbar)
win.show_all()
gtk.main()

On Dec 4, 2007 10:00 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:

> Interestingly enough, the embedding_in_gtk.py script works perfectly (tak=
es
> less than a second to run), so I am not able to reproduce the slowness!

Hmm, the plot thickens.  How about embedding_in_gtk2.py -- this add the too=
lbar

JDH

On Tuesday 04 December 2007 15:54:17 you wrote:
> OK, it is in the gtk figure creation code.  Get the matplotlib
> examples directory and try running examples/embedding_in_gtk.py which
> does not use pylab but instead does all the gtk stuff manually.  See
> if you can reproduce the error.  If so, slowly remove or comment out
> parts of the code until you get the minimal script which reproduces
> the slowness and then send it my way with commentary.  It looks like
> you may have something wrong with your gtk installation but it is hard
> to say.

Interestingly enough, the embedding_in_gtk.py script works perfectly (takes 
less than a second to run), so I am not able to reproduce the slowness!

Thanks!

On Dec 4, 2007 9:39 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:
> On Tuesday 04 December 2007 15:31:04 John Hunter wrote:
> > What about these scripts
> >
> > # just make a figure
> > from pylab import *
> > figure()
>
> Takes a long time.

OK, it is in the gtk figure creation code.  Get the matplotlib
examples directory and try running examples/embedding_in_gtk.py which
does not use pylab but instead does all the gtk stuff manually.  See
if you can reproduce the error.  If so, slowly remove or comment out
parts of the code until you get the minimal script which reproduces
the slowness and then send it my way with commentary.  It looks like
you may have something wrong with your gtk installation but it is hard
to say.

JDH

On Tuesday 04 December 2007 15:31:04 John Hunter wrote:
> What about these scripts
>
> # just make a figure
> from pylab import *
> figure()

Takes a long time.

> # just make a subplot
> from pylab import *
> subplot(111)

Takes a long time.

> I'm trying to narrow down where the problem is occurring and am still
> stumped as to the explanation...

I've used MPL in a few system, and it is only on this particular one that it 
has this delay! Incidentally, do you want the debug output from these two 
scripts? They essentially the same as the ones I sent before (up to backend 
GTKAgg version 2.10.1, where the output stops, and after a while, we're back 
at the command line).

Thanks,
J

On Dec 4, 2007 9:19 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:
> On Tuesday 04 December 2007 15:13:21 you wrote:
> > OK, the delay comes before draw which is an important piece of
> > information.  What happens if you run these two scripts.  Do you get
> > the delay?
> >
> > # script 1 (no plot)
> > from pylab import *
>
> No delay. Debug output stops at line  "backend GTKAgg version 2.10.1", bu=
t
> returns to prompt. I'd say this works as expected.
>
> > # script2 (no show)
> > from pylab import *
> > plot([1,2,3])

What about these scripts

# just make a figure
from pylab import *
figure()

# just make a subplot
from pylab import *
subplot(111)

I'm trying to narrow down where the problem is occurring and am still
stumped as to the explanation...

On Tuesday 04 December 2007 15:13:21 you wrote:
> OK, the delay comes before draw which is an important piece of
> information.  What happens if you run these two scripts.  Do you get
> the delay?
>
> # script 1 (no plot)
> from pylab import *

No delay. Debug output stops at line  "backend GTKAgg version 2.10.1", but 
returns to prompt. I'd say this works as expected.

> # script2 (no show)
> from pylab import *
> plot([1,2,3])

Delay. Delay on the same bit I commented on before (see the previous debug 
output). So no need to wait for the show() call to get to the error, I 
guess...

Thanks

On Tuesday 04 December 2007 14:27:21 you wrote:
> On Dec 4, 2007 8:23 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:
> > PS and Agg work fast enough, and produce meaningful PS and PNG output
> > files (as well as popping up a window with the plot)
>
> Wait a minute, if you are getting a plot window when you pass -dPS or
> -dAgg, something very odd is happening and likely points to what is
> causing your real problem.  It means some other GUI toolkit is getting
> activated and the slowness you are seeing is resulting from a conflict
> between mainloops, most likely.  If this is indeed the case, please
> run with either -dAgg or -sPS and post the full debug annoying output.

Sorry, my wrong. There's no such window when running with Agg. There was=20
another window from another session which I mistakenly thought had to do wi=
th=20
these tests. Agg and PS produce PNG and PS files respectively, with no wind=
ow=20
popping up. Apologies for that.

>  Also, post the exact script you are running....

It is in the beginning of my debug output, but I'll re-send the script and=
=20
command line:

*script (test.py):
from pylab import *
plot([1,2,3])
show()
savefig("myfig")


*command line:
python test.py -dGTKAgg --verbose-debug-annoying

Thanks,
J

On 04/12/2007, pranal shah <sha...@gm...> wrote:
> matplot lib users...
> pls unsubscribe me

Visit the list page thats append to every mail to this list.

> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Cheers

Adam

On Dec 4, 2007 8:23 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:

> PS and Agg work fast enough, and produce meaningful PS and PNG output fil=
es
> (as well as popping up a window with the plot)

Wait a minute, if you are getting a plot window when you pass -dPS or
-dAgg, something very odd is happening and likely points to what is
causing your real problem.  It means some other GUI toolkit is getting
activated and the slowness you are seeing is resulting from a conflict
between mainloops, most likely.  If this is indeed the case, please
run with either -dAgg or -sPS and post the full debug annoying output.
 Also, post the exact script you are running....

JDH

On Dec 4, 2007 8:23 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:

> PS and Agg work fast enough, and produce meaningful PS and PNG output fil=
es
> (as well as popping up a window with the plot)

Wait a minute, if you are getting a plot window when you pass -dPS or
-dAgg, something very odd is happening and likely points to what is
causing your real problem.  It means some other GUI toolkit is getting
activated and the slowness you are seeing is resulting from a conflict
between mainloops, most likely.  If this is indeed the case, please
run with either -dAgg or -sPS and post the full debug annoying output.
 Also, post the exact script you are running....

JDH

John,

On Tuesday 04 December 2007 14:07:36 you wrote:
> Two more tests.  WIll you set the debug level to
> --verbose-debug-annoying and add a savefig command to your script, eg
> savefig('myfig') with no extension (the backend will provide a default
> extension with the -d flags below).  Try running the script in three
> modes

PS and Agg work fast enough, and produce meaningful PS and PNG output files 
(as well as popping up a window with the plot). GTKAgg is the one taking a 
long time to pop up, AND results in an empty PNG file. I am attaching the 
debug output of the GTKAgg mode. (Delay occurs @ #[... DELAY....] line.

% cat test.py
from pylab import *
plot([1,2,3])
show()
savefig("myfig")
% python test.py -dGTKAgg --verbose-debug-annoying
matplotlib data path /usr/lib/python2.4/site-packages/matplotlib/mpl-data
$HOME=/home/ucfajlg
CONFIGDIR=/home/ucfajlg/.matplotlib
loaded rc 
file /usr/lib/python2.4/site-packages/matplotlib/mpl-data/matplotlibrc
matplotlib version 0.90.1
verbose.level debug-annoying
interactive is False
units is True
platform is linux2
loaded modules: 
['pylab', '_bisect', '__future__', 'copy_reg', 'sre_compile', 'distutils', 'itertools', '_sre', 'japanese.aliases', 'site', '__builtin__', '
datetime', 'distutils.re', 'matplotlib.re', 'matplotlib.tempfile', 'encodings', 'pytz.datetime', 'shutil', 'distutils.string', 'distutils.os', 'dateutil', '
matplotlib.datetime', 'posixpath', '_random', 'tempfile', 'errno', 'matplotlib.warnings', 'binascii', 'encodings.codecs', 'sre_constants', 're', 'matplotlib
.md5', 'os.path', 'pytz.sys', '_codecs', 'distutils.sysconfig', 'encodings.exceptions', 'pytz.sets', 'math', 'fcntl', 'stat', 'zipimport', 'string', 'warnin
gs', 'encodings.types', 'UserDict', 'encodings.utf_8', 'matplotlib', 'japanese', 'sys', 'japanese.aliases.encodings', 'pytz.tzinfo', 'pytz', '__main__', 'ma
tplotlib.__future__', 'codecs', 'matplotlib.sys', 'matplotlib.pytz', 'types', 'md5', 'matplotlib.dateutil', 'matplotlib.os', 'thread', 'sre', 'bisect', 'mat
plotlib.distutils', 'signal', 'distutils.errors', 'random', 'linecache', 'matplotlib.shutil', 'posix', 'encodings.aliases', 'sets', 'exceptions', 'sre_parse
', 'pytz.bisect', 'distutils.sys', 'os', 'strop']
numerix numpy 1.0.4
font search path 
['/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf', '/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/afm']
trying 
fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/cmsy10.ttf
trying 
fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/VeraSeBd.ttf
trying 
fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/cmr10.ttf
trying 
fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/cmex10.ttf
trying 
fontname /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf
loaded ttfcache file /home/ucfajlg/.matplotlib/ttffont.cache
backend GTKAgg version 2.10.1
# [.... DELAY ....]
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=640.0,                         height=480.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done
RendererAgg._get_agg_font
        findfont failed Bitstream Vera Serif, New Century Schoolbook, Century 
Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times New 
Roma
n, Times, Palatino, Charter, serif
Could not match Bitstream Vera Serif, New Century Schoolbook, Century 
Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times New 
Roman, Times
, Palatino, Charter, serif, normal, normal.  
Returning /usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg.points_to_pixels
RendererAgg.points_to_pixels
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg.points_to_pixels
RendererAgg.points_to_pixels
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg.points_to_pixels
RendererAgg.points_to_pixels
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg.points_to_pixels
RendererAgg.points_to_pixels
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg.points_to_pixels
RendererAgg.points_to_pixels
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg.points_to_pixels
RendererAgg.points_to_pixels
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg._get_agg_font
RendererAgg.draw_text
RendererAgg._get_agg_font
FigureCanvasAgg.buffer_rgba
RendererAgg.buffer_rgba
FigureCanvasAgg.print_figure
FigureCanvasAgg.draw
RendererAgg.__init__
RendererAgg.__init__ width=800.0,                         height=600.0
RendererAgg.__init__ _RendererAgg done
RendererAgg.__init__ done

matplot lib users...
pls unsubscribe me

Pranal

I have posted fresh win32 eggs and exe's on SF.  I explicitly removed
the inclusion of msvcp from distutils in numpy.  Please give them a
try and let me know if you have any more problems.  Note: I just
posted the files so it might take a while for them to propagate.

- Charlie

On Dec 3, 2007 9:47 PM, Charlie Moad <cw...@gm...> wrote:
> I'll remove the exe's from SF.  It's been a while since a release, and
> I guess I was a little rusty. ;)
>
> - Charlie
>
>
> On Dec 3, 2007 7:02 PM, John Hunter <jd...@gm...> wrote:
> >
> > On Dec 3, 2007 5:53 PM, John Hunter <jd...@gm...> wrote:
> > > On Dec 3, 2007 5:49 PM, John Hunter <jd...@gm...> wrote:
> > >
> > > > Charlie, I don't know how you handled this last time, but is there
> > > > something in setuptools you have to disable for this build?
> > >
> > > Well, here's a clue: matplotlib/__init__.py does not exist in this instal
> >
> > When I copy all the dirs from the 2.5 egg you built into
> > site-packages, I get a matplotlib with rcParams and the rest of the
> > __init__.py stuff.  Unfortunately, when I try to import pylab, I get
> > the dreaded old msvcp71.dll error.  If I recall correctly, we used to
> > hack distutils to remove the line that linked with that lib.
> >
> > JDH
> >
>

On Dec 4, 2007 3:30 AM, Lars Friedrich <lfr...@im...> wrote:
> Hello,
>
> in my matplotlibrc, I use 'backend : WXAgg'. This works fine, since I
> use a wxPython shell as an interactive shell with pylab. However,
> 'WXAgg' is not in the list of possible backends given in matplotlibrc.
> Is it save (also in the future) to use WXAgg, or should I try to switch
> to one of the other backends?

Yes, it is fully supported and safe to use.  I think it is just an
oversight that it is not listed in the choices in rc, so we'll fix
that.

On Dec 4, 2007 4:50 AM, Jos=E9 G=F3mez-Dans <jgo...@gm...> wrote:

> Thanks for your reply. I think it might well be a fonts problem. Here's t=
he
> test script, plus a comment where the big delay happens:
> % cat test.py
> from pylab import *
> plot([1,2,3])
> show()

Two more tests.  WIll you set the debug level to
--verbose-debug-annoying and add a savefig command to your script, eg
savefig('myfig') with no extension (the backend will provide a default
extension with the -d flags below).  Try running the script in three
modes

 -dPS, -dAgg and -dGTKAgg

and let us know if the lag is in all three and if not in which one(s).
 Then repost the debug output and insert a comment where the lag is
occurring.

Thanks,
JDH