Hey someone said something nice about transforms!
About time, isn't it!
One thing I still don't understand: when is it necessary to bracket code
with freeze/thaw?
Eric, I haven't had a chance to try this code out but I did read
through it and it looks very nice. A small comment: fig.dpi
I added the ability to easily generate a key for quiver plots. The
function is called quiverkey(). It is illustrated in the revised
examples/quiver_demo.py. I also changed Axes.quiver and pylab.quiver to
use quiver2 if possible--that is, if it seems consistent with the
arguments that are
John Hunter wrote:
Eric == Eric Firing [EMAIL PROTECTED] writes:
Eric Based on a quick look, I think it would be easy to make
Eric LineCollection and PolyCollection accept a numerix array in
Eric place of [(x,y), (x,y), ...] for each line segment or
Eric polygon
Norbert,
Your 2790 patch seems to have completely wiped out the handling of
marker colors in the simple case N.plot(N.random.random(1000),'r.'),
as noted by Stefan Van der Walt in a message yesterday to the matplotlib
users list. I presume you are monitoring that list, and saw his message
Norbert Nemec wrote:
OK, I found the problem and committed a temporary fix. The real problem,
however is rooted a bit deeper.
First an explanation of the intended change:
It used to be that marker colors were partly automatic, but not
completely. I.e.
plot(x,y,'-or')
would set
Norbert,
I am splitting this thread because I think different issues are involved
in different parts.
In looking at your original patch, I also wondered what is the reason
for supporting 3 different ways of specifying _draw_nothing? (I had
not previously noticed that there was any such
Norbert,
The problem in r2790: I changed the default value in matplotlibrc to
'auto' and everything worked fine for me. I forgot that, of course,
anybody updating from an older version, would still have the values
'blue' and 'black' in their matplotlibrc, which would not be overridden
by
Norbert,
The core problem: The matplotlibrc file distributed with matplotlib
contains all the default values in non-commented lines. This file is
usually copied to the home-directory of any user, making it impossible
to simply change any default value in later versions. It is not possible
to
Norbert,
Either I am not understanding you correctly, or we have fundamentally
different views of the role of matplotlibrc values. The way I see it,
function args and kwargs *always* override matplotlibrc values, which in
turn *always* override built-in defaults. So in the example above, if
This is fixed now in SVN. The problem was that Numeric arrays lack a
len attribute, and hasattr(xmin, 'len') was being used to find out
whether xmin is a scalar or a length-2 array (xmin, xmax). The solution
is to do the test with iterable(xmin) instead. The bug was introduced
in 2782.
Norbert,
Your change in commenting out almost everything in matplotlibrc was a
good one, but I think it had an unintended consequence: it changed the
way everything looks because the defaults in __init__.py were not the
same as the ones in matplotlibrc. To my eye and on my machine the
Jim,
I have modified your LogNorm, added it to colors.py, made some changes
to colorbar.py, and added a stripped-down version of your pcolor_log.py
to the examples directory. If you update your mpl from svn, then I
think you will find that pcolor_log now works the way you expected it to
John,
What is your present thinking with respect to timetable and strategy for
dropping Numeric and numarray support?
Thanks.
Eric
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel
It has been quite a while since 0.87.7, and I note that the ubuntu
feisty upstream version freeze date is Feb. 8. Is it time for a new mpl
release? If it were done within the next few days, would it get into
feisty? I acknowledge that I can offer no help with the release
process, and I
John Hunter wrote:
I'm still learning how to reply-to with my new-fangled gmail. I'm
forwarding this response on to the list
-- Forwarded message --
From: John Hunter [EMAIL PROTECTED]
Date: Feb 5, 2007 9:46 AM
Subject: Re: [matplotlib-devel] release?
To: Eric Firing
Charlie Moad wrote:
Well, another option is to maintain a sub-directory structure when
creating mpl-data in the source package. The downside is that this will
introduce code changes all over the code -- for example, code that
previously asked for os.path.join( mpl.get_data_dir(), 'blah.glade'
beyond my
free bandwidth capacity.
-Andrew
Eric Firing wrote:
Darren Dale wrote:
We support setuptools, but we do not require it.
So, it sounds like setuptools is required now if one has Python 2.3.
If so, is that acceptable--is the gain worth the pain? Is there any
In response to the feature request:
Does anyone see any disadvantage to making Text.__init__ and
Text.set_text() either try to call the __str__ method, or use the str()
builtin, if passed an argument that is not a string? Maybe there is no
need to even check--just automatically use str(arg)?
John Hunter wrote:
On 3/17/07, Eric Firing [EMAIL PROTECTED] wrote:
In response to the feature request:
Does anyone see any disadvantage to making Text.__init__ and
Text.set_text() either try to call the __str__ method, or use the str()
builtin, if passed an argument that is not a string
John Hunter wrote:
If you are using mpl svn, please read this as it describes
some fairly major changes.
Mike Lusignan has been working on adding units support, and as a
consequence, partial support for working with arbitrary types in mpl.
The support is not complete yet, but it is
The coding guide recommends that any **kwargs dictionary that is passed
into a function should be copied so that the original is unaffected when
items are popped off inside the function. I noticed that this is not
done by pylab functions generated by boilerplate.py, and in fact I don't
think
In 2007, two different major memory leaks have been identified:
1) Eric Pellegrini showed that a loop over figure(); close() leaks. I
have verified that this occurs with any interactive backend, but not
with non-interactive backends. This may be the same problem that was
reported in other
I can add a couple of things to item (1) below. First, the problem
occurs only with toolbar2, not with classic or None. Second, a script
that illustrates it is attached.
Eric
Eric Firing wrote:
In 2007, two different major memory leaks have been identified:
1) Eric Pellegrini showed
John Hunter wrote:
[...]
As for your specific points:
* inside matplotlib we should just use numpy everywhere. We need to
agree on some import convention. I'm happy with 'import numpy as nx'
though this might be confusing for a while since people might confuse
it with the numerix layer.
Matthieu Brucher wrote:
Hi,
I'm trying to display a scatter plot in 3D, and it calls the 2D scatter
plot, in axes.py. This method tests for validity of the color argument
in line 3777 :
if not is_string_like(c) and iterable(c) and len(c)==len(x):
colors = None
Matthieu Brucher wrote:
I don't quite understand: what kind of c are you passing in, what is
the original code doing with it, and what should it do with it? (I find
both the original and the suggested code hard to understand, which makes
me think that neither is actually what
Revision 3237 to fix set_ticklabels seems to have a problem: it breaks
examples/mri_with_eeg.py.
Eric
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control
: switching may have some subtle consequences in
matplotlib (nothing that can't be quickly fiexed, however). What do Eric
Firing, John Hunter and the other mpl developer think ?
I think this would be a good time to make the switch. We are going to
be stripping out the Numeric and numarray support, so
John Hunter wrote:
[...]
Yes, we've often talked about using traits here and elsewhere but the
idea has languished because it has never made it to the top of
anyone's priority queue. I just added examples/rc_traits.py, which is
the example code I wrote some time ago when I was exploring how
Jeff,
Your sensible change required one other, so I have committed both in rev
3312.
Eric
Jeff Whitaker wrote:
Eric: I came across what may be a small bug in colorbar. If you pass a
list to colorbar with the 'ticks' keyword, and the list is longer than
10, you don't actually get the
There is a question that has not been addressed yet: how to handle numpy
masked arrays. There are two modules, mostly compatible: numpy.ma and
maskedarray. The latter will (I hope) become the standard
implementation; until it does, we should have an easy mechanism for
switching from one to
I have made changes in matplotlib svn to facilitate experimentation with
the maskedarray module; I hope this will speed up the process of testing
it and incorporating it into numpy as a replacement for numpy.core.ma.
mpl scripts now accept the switches --maskedarray and --ma to force the
use
John Hunter wrote:
On 6/30/07, Eric Firing [EMAIL PROTECTED] wrote:
Mike,
All this sounds like great progress--thanks! I particularly appreciate
the descriptions of what problems you found and how you found them.
John et al.: is there a maintainer for each of these backends? I think
Norbert Nemec wrote:
Hmm - let me think We already have
rc
rcParams
rc_params
rcdefaults
rcParamDefaults
defaultParams
in the main module of maplotlib
How about calling the new module 'rcdefaultparams.py', simply to make
the confusion complete and because I
Michael Droettboom wrote:
Eric Firing wrote:
So, this test is still showing problems, with similar memory
consumption in these three backends.
Not necessarily. By default, Python allocates large pools from the
operating system and then manages those pools itself (though its
PyMalloc call
Michael Droettboom wrote:
Eric Firing wrote:
I also made memleak_gui.py more flexible with arguments. For example,
here are tests with three backends, a generous number of loops, and
suppression of intermediate output:
Those changes are really helpful. I just added code to display
Michael Droettboom wrote:
Eric Firing wrote:
I just committed a change to the output formatting of memleak_gui so
that if you redirect it to a file, that file can be loaded with
pylab.load() in case you want to plot the columns. (At least this is
true if you don't use the -c option
Mike,
New exception:
[EMAIL PROTECTED]:~/programs/py/mpl/tests$ python
../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000
~/temp/memleak_wx_0705.asc
Traceback (most recent call last):
File ../matplotlib_units/unit/memleak_gui.py, line 58, in module
pylab.close(fig)
File
Michael Droettboom wrote:
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
I'm awfully surprised that wx.GetApp() would return an iterator, as you
are getting, so maybe it's corruption of some sort?
Reverting to revision 3441 on
Michael Droettboom wrote:
Interesting...
When you get a chance, would you mind running the attached script? This
is how I was finding object leaks before. It takes a single commandline
argument that is the number of iterations. Can you send me the outputs
from 1 and 2 iterations?
Michael Droettboom wrote:
Interesting...
When you get a chance, would you mind running the attached script? This
is how I was finding object leaks before. It takes a single commandline
argument that is the number of iterations. Can you send me the outputs
from 1 and 2 iterations?
Ken McIvor wrote:
On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
It looks like wxPython doesn't retain a reference to the wxApp PyObj for
you:
[EMAIL
Carl,
I have made a few changes in svn to facilitate testing cairo with
backend_driver (and to fix a bug that turned up), and I will do a bit
more on this later today or tomorrow. The result of a quick pass
through the backend_driver test with png output is quite encouraging,
though. There
Carl Worth wrote:
On Thu, 05 Jul 2007 13:22:11 -1000, Eric Firing wrote:
[...]
My suggestion would be to make it default to .png if no additional
information is provided, and then to also add some sort of pseudo
backends so that the other cairo-supported file types could easily be
obtained
:
On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
Steve,
Darren Dale raised a question offline that I think will be of general
interest to mpl devels, and that you are the person to answer:
How do you see the future of a cairo backend as a prospective
replacement for most or all
There are two conspicuous bugs in the Cairo output:
1) contour_demo.py: the image part of the figure is wrong in shape and
content. It looks like an array dimensions confusion or something like
that. Strangely, the very similar image in image_demo.py is fine.
I fixed this bug. There
John,
Have you considered Allan's version of _backend_agg.cpp (message date
was 06/27)? I just tried it, and so far, I like it. I have not found
any problems with the backend_driver.py test, and the improvement in
speed that Allan notes with the plot(rand(10)) example is
dramatic--the
Michael Droettboom wrote:
Sorry about that. I didn't notice the SVN login error the first time.
It should be in SVN now.
The default is to output Type 3 fonts (i.e. the new way).
Darren: you mean rcdefaults.py, not rcsetup.py, right? I can't find an
rcsetup.py.
Mike,
I renamed
Michael Droettboom wrote:
[...]
All should be in SVN.
Mike,
Now it compiles and runs all the demos, and displays OK at normal
resolution; but when I try to show it with gv or evince at 400%, gs crashes:
[EMAIL PROTECTED]:~/programs/py/mpl/matplotlib_units/examples$ evince
simple_plot_ps.ps
Michael Droettboom wrote:
Here's simple_plot.ps generated with the old PS backend.
Crash! Again, with 400% magnification. So now you really are off the hook.
[EMAIL PROTECTED]:~/programs/py/mpl/tests$ evince simple_plot_ps.ps
ERROR: /unknownerror in --%op_show_continue--
Operand stack:
[EMAIL PROTECTED] wrote:
John (and others),
I've made a quick change to the svg backend to cull the data, see attached
patch. I haven't tested it extensively, but it seems OK. It culls both
lines and polygons out of svg output.
Allan,
Looks good, and the basic idea should be generally
John Hunter wrote:
On 7/10/07, Michael Droettboom [EMAIL PROTECTED] wrote:
The comparison is just over the PDF files, old way (Truetype embedding)
vs. new way (Type 3 subsetting).
[...]
In any case, excellent work!
JDH
Mike,
I second that! I greatly appreciate your contributions,
Mike, John,
I sent an inquiry to stixfonts based on
http://www.stixfonts.org/swdev_geninfo.html#; I will let you know if
they come back with anything. It does look like a genuine release is in
sight. But are these fonts all based on Roman style, with serifs,
correct? That seems
John Hunter wrote:
[...]
So one reason why the backends are a bit of a kludge is because we
have tried to throw some extra stuff into the GTK drawing model as an
afterthough. We could redo all the collection stuff w/ compounds
paths.
John,
Do all the backend devices or libraries we *need*
John Hunter wrote:
On 7/12/07, Eric Firing [EMAIL PROTECTED] wrote:
John Hunter wrote:
Do all the backend devices or libraries we *need* now support compound
paths (1) at all, and (2) in a consistent enough way to solve the
contouring problem as well as to make something like polygon
Carl Worth wrote:
On Thu, 12 Jul 2007 10:31:19 -1000, Eric Firing wrote:
if only cairo would make eps files
Isn't EPS a trivially change compared to PS? Something like a modified
header and the addition of bounding-box information?
Carl,
My knowledge of graphics topics is sketchy, but yes
Carl Worth wrote:
[...]
But yeah, I also understand that there are licensing concerns.
Anything else? Are there cairo performance concerns? If so, I'd love
to hear about them so we can fix them.
Backend cairo.ps took 0.87 minutes to complete
Backend ps took 0.66 minutes to complete
So the mpl
Darren Dale wrote:
On Thursday 12 July 2007 05:11:31 pm Carl Worth wrote:
On Thu, 12 Jul 2007 10:31:19 -1000, Eric Firing wrote:
if only cairo would make eps files
Isn't EPS a trivially change compared to PS? Something like a modified
header and the addition of bounding-box information
Director of Strategic Initiatives and Business Development
American Institute of Physics
Phone: +1 516 576 2265
Fax: +1 516 576 2327
[EMAIL PROTECTED] 7/11/07 5:47 PM
Name: Eric Firing
Email: [EMAIL PROTECTED]
Comments: I am a developer for the matplotlib plotting library, led by John D.
Hunter
Tom Holroyd (NIH/NIMH) [E] wrote:
Ted Drain wrote:
I think the basic idea is that if I want to use MPL, I should import
it and go and I should not have to import a sub-module out of MPL as
the main API.
Yeah, about that, my typical usage is actually from pylab import *.
I guess I am
Eric Firing wrote:
John Hunter wrote:
On 7/13/07, Ted Drain [EMAIL PROTECTED] wrote:
I think he means that the matplotlib/__init__.py file should be
changed to that those things are imported.
but if __init__.py imports axes, and axes import matplotlib, don't we
still have the problem
Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
If I say
import matplotlib
help(matplotlib)
(This is with 0.90.0 by the way)
It basically gives me the help I'd expect for pylab. Oh, and it says
the instead of to. It's a little weird thinking of a library as the
top level with the main
John Hunter wrote:
On 7/13/07, Eric Firing [EMAIL PROTECTED] wrote:
No, it is not your installation. You have identified an area that needs
work, after we settle on a possibly new import and namespace strategy.
This is definitely something new -- help(pylab) used to display the
rather
Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
If I say
import matplotlib
help(matplotlib)
(This is with 0.90.0 by the way)
It basically gives me the help I'd expect for pylab. Oh, and it says
the instead of to. It's a little weird thinking of a library as the
top level with the main
John Hunter wrote:
On 7/16/07, Eric Firing [EMAIL PROTECTED] wrote:
I use a good old-fashioned editor called zed, written by an Italian
named Sandro Serrafini who seems to have left no trace for several
years. I have modified it slightly, and I do minimal maintenance to
keep it compiling
Darren Dale wrote:
[...]
What about rendering unicode, but keeping the mpl sources ascii only?
This sounds like the thing to do for now.
While you are at it, perhaps you can figure out how to stop unicode_demo
from generating an error:
driving unicode_demo.py
File
Darren Dale wrote:
I've been thinking a bit about rcParams and validation. It looks like values
are currently only validated when matplolibrc is read, during the call to
rc_params. What if we define a new class (RcParams), derived from dict, which
has as an attribute, a dict, called
John Hunter wrote:
[...]
Isn't there a potential problem here? The original validate funcs
support conversion from a string to a value, but you are proposing
using them here in a context where users will generally be supplying a
(possibly bogus) value, but in general not a string. So the
Darren Dale wrote:
Hi Eric,
On Thursday 19 July 2007 02:10:03 pm Eric Firing wrote:
unless John or someone else
contradicts me I request that you restore the original numerix, or
something like it, so that users' external code can still use numerix to
deal with Numeric and/or numarray code
Darren Dale wrote:
On Thursday 19 July 2007 02:26:05 pm John Hunter wrote:
On 7/19/07, Darren Dale [EMAIL PROTECTED] wrote
On Thursday 19 July 2007 01:18:21 pm John Hunter wrote:
I have not been able to install traits by following the instructions in
mtraits.py.
[...]
I encountered a
John Hunter wrote:
On 7/19/07, Eric Firing [EMAIL PROTECTED] wrote:
The instructions still say to check out traits 2.0, but Robert is
recommending that we go with traits 3. Do you really want to stick with
version 2 now?
No, I'm happy to move over. But I spent way more time getting
Rob Hetland wrote:
On Jul 20, 2007, at 9:07 AM, Paul Kienzle wrote:
On Fri, Jul 20, 2007 at 08:53:30AM -0400, Rob Hetland wrote:
Second, much of what I do involves plotting model data (on a
curvilinear grid). I generally like to use pcolor for these plots.
I *always* want shading='flat'
Stefan,
Thanks. I will apply them shortly, after a bit of checking. (There
were commits after 3584, but things look easy enough to straighten out.)
Eric
Stefan van der Walt wrote:
Hi everyone,
Some of the examples in the repository are broken. Attached is a
patch to fix them (it also
Paul Kienzle wrote:
[...]
Quadmesh has a bug in it that I would love to see squashed. Can you
look at it, or induce someone else to do so? I tried but couldn't
figure it out--it is something deep in the use of Agg. It is illustrated
by examples/quadmesh_demo.py. With masked data
John Hunter wrote:
[...]
functions or array functions here, eg math.sqrt vs numpy.sqrt? Also,
a few of your symbols clash with python builtins (min, max, abs) which
is best avoided. Finally, how would you feel about allowing these
symbols in the module namespace, but w/o the import *
Xuedong Zhang wrote:
Hi,
During the installation of the matplotlib package,
I was told that the matplotlib is trying to replace the tk.tcl file
which belongs to the tk package
Can anyone told me if this is a bug or feature
I don't know what to call it, but if it exists it is in the
John,
You are going great guns with mpl1; I am trying to get spun up on
traits, and to understand where you are going with mpl1. In general I
like what I see--as expected. Regarding the following comments: I
recognize that you are engaged in a sketching activity, and I may be
thinking
Maybe the solution is to not use checkinstall?
Eric
Xuedong Zhang wrote:
I use the command as follows:
sudo checkinstall python setup.py install --prefix /usr/local
But the problem is the same.
It seems during the python install, python access the tk module, but the
checkinstall
seems
Darren Dale wrote:
I am working on reorganizing our config system to work with Fernando's
tconfig, and I could use some advice. Currently, a lot of the configuration
code lives in __init__.py and rcsetup.py. I am thinking of a layout like
this:
matplotlib/lib/matplotlib/
__init__
Darren Dale wrote:
On Thursday 26 July 2007 10:39:22 am Tom Holroyd (NIH/NIMH) [E] wrote:
Are traits going to be a dependency that I have to download and install, or
will all the traits stuff be bundled with mpl?
That hasn't been determined yet.
Does your config system run with the old
Darren,
When I make a clean build and install, set NEWCONFIG, and try to run I
get a permission problem. It looks like the problem is that the global
matplotlib.conf is not getting generated and installed at build/install
time, but I have not investigated it.
Eric
convert!
Traceback (most
Darren,
It looks like there is a problem with the grid lines. Although the
matplotlib.conf file is specifying linestyle = ':', and False for the
axes.grid parameter, everything is coming up with solid lines (see
barh_demo.py, for example) by default. It looks like those two keys are
not
Darren Dale wrote:
I just committed changes in svn that will allow matplotlib to use the
experimental traited mplconfig module. The traited config object itself is
called mplConfig, but I wrapped it in an object called rcParams to make it
compatible with matplotlib, so we can kick the tires
Darren Dale wrote:
On Monday 30 July 2007 6:58:17 pm Eric Firing wrote:
Darren,
It looks like there is a problem with the grid lines. Although the
matplotlib.conf file is specifying linestyle = ':', and False for the
axes.grid parameter, everything is coming up with solid lines (see
Darren Dale wrote:
[...]
How about markup=TeX then?
markup is a good kwarg for this; it is descriptive and won't be
confused with anything else.
Eric
And yes, having a rcoption default seems like it could be handy.
Mike,
Thanks for fixing pycxx to remove all those warnings!
I am curious: have you looked at the most recent upstream pycxx? My
impression is that there were supposedly some changes to support python
2.5, and a couple months ago I made a feeble and unsuccessful attempt to
use the updated
I have been gradually numpifying mlab.py; I hope this is not a
duplication of effort with someone else. I have not finished yet (and
have made no commits), and it may still take a while--there are a lot of
things to change, and I am trying to do some cleaning up and
rationalization, not just
to
remain in the *pylab* namespace for a while, but I don't think it should
stay in the *mlab* namespace as well. I really don't want to add
wrappers with warnings for all these functions.
Eric
Michael Droettboom wrote:
Eric Firing wrote:
Similarly, after dealing with mlab, I would like
, and there are
lots of gotchas. For me it is a reasonable choice for C code, although
I would still gravitate towards Pyrex in most cases. For C++, I would
not know where to start. Again, that's my personal handicap.
Eric
Michael Droettboom wrote:
Eric Firing wrote:
Mike,
Thanks for fixing
Michael Droettboom wrote:
[...]
I think the small amount of support is a valid concern, particularly as
we move toward Py3k, if no one steps up to the plate to help with the
migration.
Do you have a sense of how difficult that migration would be?
I appreciate the way it fits so nicely
Christopher Barker wrote:
Eric Firing wrote:
Swig:
GvR's comments are interesting.
Do you have a pointer to those? I'd love to see them.
http://www.artima.com/weblogs/viewpost.jsp?thread=95863
(It was in Mike's original message.)
Eric
mlab.py in svn has now been changed quite a bit:
1) It uses straight numpy.
2) In many but not all cases, I tried to simplify algorithms by using
numpy capabilities. I did some testing, but beware: there may be new bugs.
3) For functions with numpy equivalents I put in deprecation warnings,
Christopher Barker wrote:
[...]
Does internal MPL code rely on mlab? if so, it needs to be part of some
core lib that is stable enough to be a MPL dependency.
Good question. With a couple of minor exceptions (which are easily
handled), the only dependency is in axes methods that I don't
Michael Droettboom wrote:
Just wanted to link up this thread with a question I posed on the cairo
mailing list.
http://lists.cairographics.org/archives/cairo/2007-August/011201.html
Cheers,
Mike
Eric Firing wrote:
Michael Droettboom wrote:
[...]
One middle ground I thought of since my first
Ted Drain wrote:
Manuel,
We do plots like this all the time. One thing we've found that's nice
to have is a keyword that controls when the increase in y happens. We
use a step style keyword that can be 'pre' (go up then right), 'post'
(go right then up), and 'mid' (right 0.5, up, right
Mike, Rob,
One of the changes I made was to cause the afmdict to be generated
automatically at the start rather than on demand. The problem you are
having seems related to afm fonts, so I suspect this is it.
What is your rcParams['pdf.use14corefonts'] setting? Please try
reversing it, and
know how to troubleshoot it beyond this.
(As a separate issue, I probably I should change font_manager.py so that
if the rcParams value below was changed since the cache was made, it
will be rebuilt with the new value.)
Eric
Rob Hetland wrote:
On Aug 14, 2007, at 1:55 PM, Eric Firing wrote
be reasonable to use Traits for the
matplotlib config description, but there seem to be performance
issues.
]
On 7/31/07, Eric Firing [EMAIL PROTECTED] wrote:
Darren,
The two cases you ran have almost identical timing, so the problem is
not in reading matplotlib.conf. Instead, it seems
Darren Dale wrote:
On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote:
On 8/16/07, Darren Dale [EMAIL PROTECTED] wrote:
On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote:
On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
On 8/16/07, Eric Firing [EMAIL PROTECTED
, you want the line to break at the missing
point to show that a point has been removed.)
Eric
Manuel
Ted Drain wrote:
At 10:36 AM 8/14/2007, Eric Firing wrote:
Ted Drain wrote:
Manuel,
We do plots like this all the time. One thing we've found that's
nice to have is a keyword
1 - 100 of 801 matches
Mail list logo
