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 renam
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
ER
Michael Droettboom wrote:
> Even if my Postscript is to spec, it's not terribly useful if it crashes
> a very popular tool ;)
>
> I'm curious -- does the file fail if you set "ps.fonttype: 42" in your
> matplotlibrc? That would at least rule out anything non-font in the file.
Aha! You may be
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:
Execu
[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 cont
Michael Droettboom wrote:
> Eric Firing wrote:
>> I second that! I greatly appreciate your contributions, first in
>> chasing down memory leaks and now in reducing file sizes by embedding
>> fonts.
> It's been fun.
Mike,
Good--what's next? You're
Mike,
The attached file masked_interior.py illustrates masking failure in a
very simple case; you can see masking working in the plot on the left,
where a contour intersects the masked region, but when that contour
level is removed the masked region is getting filled in.
The file contourf_de
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 unfortunate;
John Hunter wrote:
> On 7/12/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> It looks like that the backend API isn't really set up to do compound
>> paths. The PolygonCollection class appears to be just a list of simple
>> polygons, rather than something that could be used for compound pa
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 *nee
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 probl
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 gra
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 m
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
>> head
Carl Worth wrote:
> On Thu, 12 Jul 2007 11:35:25 -1000, Eric Firing wrote:
>> Carl Worth wrote:
>>
[...]
> Later, you said...
>
>> Aha! Cairo ps output is full of "initclip" commands, so it can't be
>> converted to eps without substantial reworki
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 plottin
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 of recursive imp
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 g
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
Christopher Barker wrote:
> John Hunter wrote:
[...]
> I do wish that:
>
import matplotlib as mpl
import mpl.artist
> Traceback (most recent call last):
>File "", line 1, in
> ImportError: No module named mpl.artist
>
> worked.
The way I have it working now (on my machine, not in
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
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 -- h
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
John Hunter wrote:
> On 7/15/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> \> docstring still blathers on about pylab functions, however; I suspect we
>> should change this to something more unique and helpful, such as a
>> directory of matplotlib submodules and/or an
Michael Droettboom wrote:
> Darren Dale wrote:
>> If not, should we use
>> u'\xd7' or '×' in the actual sources (the latter requiring the file's
>> encoding to be declared at the beginning of the file, like: # -*- coding:
>> utf-8 -*-)?
> In an ideal world, I would prefer the latter, but we woul
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 min
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 "_tmp_unicode_de
Darren Dale wrote:
[...]
> Why do we need a single namespace? It seems unadvisable. There is additional
> overhead with namespace lookups: running numpy.arange(10) a million times
> takes 15% longer than arange(10). I would have thought it best to do more
> of "from w import x, y, z"
I have in
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 vali
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
Robert Kern wrote:
[...]
> We've split up the main "enthought" package such that Traits can be installed
> separately as "enthoguht.traits". I think we'd prefer depending on it
> externally
> now that we've spent so much effort to make that feasible.
When do you expect to make a release?
Eric
-
Bryce Hendrix wrote:
> John, you're trying to check out the code from Trac, not svn :) Try this
> URL
>
> https://svn.enthought.com/svn/enthought/branches/enthought.traits_2.0
I just did this. There is still an authentication problem, but manually
accepting the cert makes it work.
The 2.0 bra
Norbert,
In addition to the problem that numerix was supposed to retain support
for Numeric and numarray for the time being, for external use, there is
the problem that all examples are currently broken.
Please let me know if you are still online (I know it is very late in
Germany); otherwise
wo to prevent confusion and surprises.
Thanks, and I'm sorry for my excessive and erroneous earlier reaction.
Eric
Eric Firing wrote:
> Norbert,
>
> In addition to the problem that numerix was supposed to retain support
> for Numeric and numarray for the time being, for externa
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 numeri
Darren Dale wrote:
[...]
>> The point is that although users will have to *have* numpy, they will
>> not yet have to convert all their other packages to numpy; if they have
>> extension packages built on numarray, for example, and accessed via code
>> using matplotlib.numerix, everything will still
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.
> [...]
>
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
Nils,
I just committed 3582 which reverted numerix to 3573, so please try
again. It works for me now.
Eric
Nils Wagner wrote:
> Hi,
>
> I cannot install matplotlib from latest svn.
> error: package directory 'lib/matplotlib/numerix/mlab' does not exist
>
> Nils
try something else.
Eric
Nils Wagner wrote:
> Eric Firing wrote:
>> Nils,
>>
>> I just committed 3582 which reverted numerix to 3573, so please try
>> again. It works for me now.
>>
>> Eric
>>
>>
>> Nils Wagner wrote:
>>> Hi,
>>&g
Nils,
Two more commits, now at 3584, and I think I have it straightened out.
I hope so. I'm going offline for 8 hours or so, so if it is not
fixed now either someone else will have to do it, or it will have to wait.
Eric
Nils Wagner wrote:
> Eric Firing wrote:
>> Nils
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' Some of my grids are large, and I
>> on
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 shadi
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 al
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 (
Stefan van der Walt wrote:
> Thanks for applying the patch, Eric. I should also mention that there
> are two other problems that my patch didn't solve:
Thank you for your patch, and for pointing out the additional problems.
>
> In agg_resize.py:
>
> Traceback (most recent call last):
> File
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 * sema
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
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 premat
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
> s
Darren Dale wrote:
[...]
>
> I'll start working on an option in svn-mpl to turn the new system on and wrap
> it in an rcParams-like object. Then maybe we can convince a few devs to try
> using the new system for a while.
I will be happy to take a look and try it out. It certainly sounds like
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/
> __ini
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 ol
John Hunter wrote:
> On 7/26/07, Darren Dale <[EMAIL PROTECTED]> wrote:
>>> where Math is a wrapper object that signals to "text" that its contents
>>> are to be passed to the mathtext interpreter.
>> I would like to voice my opinion against this idea. I think the backward
>> imcompatibility will b
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 re
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 set
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 ti
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 paramete
not like to see mpl become a library that is painfully sluggish
to start up; it is already too slow for my liking, with font setup being
a major contributor.
Eric
Darren Dale wrote:
On Monday 30 July 2007 07:10:01 pm Eric Firing wrote:
Darren Dale wrote:
I just committed changes in
Fernando,
Here is some more information about profiling that others may find useful:
1) The profile module reports times that are much longer than normal; I
don't know to what extent the relative times are still correct; my
impression is that they do still give a decent idea of where the
bottl
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 vers
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 me
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 ml
you see is what you get. It is pretty tedious, though, 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
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 ni
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
Michael Droettboom wrote:
[...]
> All this raises a much larger question of whether we want to replace
> font_manager.py with something like fontconfig. There don't appear to
> be Python wrappers for it, but it would eliminate a number of issues
> with font_manager.py : a) it would look up fonts i
Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
>
> For the C library you say "man strcpy" or "man erf" and it tells you
> what include file to use to get the definition (function prototype). In
> python you only get the help after you've already imported. But it was
> and still is reasonable to have a
Christopher Barker wrote:
> Ryan May wrote:
>>> I for one will be happy to change my code; numerical stuff in
>>> numpy, plotting stuff in pylab (or pyplot?), though some things
>>> like linspace() may be hard to loose; that's really an mlab
>>> function and I can import mlab.
>
> I'm a big namesp
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,
wit
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'
Brandon,
I could add that method very easily, but do we really need it? Is there
a compelling use case? You can always access the title directly as an
attribute of the axes instance. xlabel and ylabel are other things for
which there is a setter but not a getter. This dates from before my
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
Michael Droettboom wrote:
> My suspicion from looking at the code was that a great deal of time
was spent statting all the font files at start up. FontManager.__init__
goes through all the files in the cache to determine if they still exist
and refreshes the cache if it finds one missing. Your patc
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, rig
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 se
don't 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
ml
>
> We're trying to see if it would 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 h
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
ut you want to keep the array dimensions unchanged. In the case
of a line plot or step plot, 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
doc. The patch as well as an example code and its
> output are attached.
>
> Please note that the example actually call ax.step directly instead of
> using the pylab interface; I guess this has to be added (boilerplate.py?)
Yes, I can take care of that. No problem.
Eric
>
&g
Manuel Metz wrote:
> Hello,
> I have attached a patch that adds the ability to draw upper/lower limits
> indicators for errorbars. New keyword args had to be introduced to the
> errorbar command, and I also had to add new plot styles. I chose
> 'y','Y','z' and 'Z' as new linestyles for arrowhead
Mike,
After a quick test, I am puzzled: running "backend_driver.py Template"
takes 0.49 minutes on my machine before and after this change, so the
dedenting time must have been less than I thought.
Eric
[EMAIL PROTECTED] wrote:
> Revision: 3744
> http://matplotlib.svn.sourceforge.net/
Mike,
Thank you, that's wonderful! I knew dedent was a major speed problem,
but I couldn't think of how to speed it up, and to my eye keeping the
docstrings properly indented in the code makes a *huge* difference in
readability.
Eric
[EMAIL PROTECTED] wrote:
> Revision: 3744
> http
Manuel,
Sorry for the delay in looking at your patch.
I am not familiar with this type of plot, as opposed to ordinary
errorbars. What is it used for? What is the meaning of the upper and
lower limits?
The errorbar docstring will need to be modified to explain the new
kwargs. Additional co
Darren,
There is an inconsistency between mpl-data/matplotlib.conf and
config/mplconfig.py. The former has [[math]] under [text], but the
latter is based on a separate [mathtext]. It would be trivial to
resolve the inconsistency, but I don't know which way it should be
resolved, so I will le
Michael Droettboom wrote:
> lib/matplotlib/mpl-data/matplotlibrc is generated at build time by
> interpolating some fields in matplotlibrc.template.
>
> Since it always get changed, it always shows up as a modified file by
> svn status. This is only a minor annoyance when working on the trunk.
The Axes.panx() method and several others contain calls to
_send_xlim_event() and similar methods. These methods don't seem to be
defined anywhere.
Eric
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. M
John Hunter wrote:
> On 9/9/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>> The Axes.panx() method and several others contain calls to
>> _send_xlim_event() and similar methods. These methods don't seem to be
>> defined anywhere.
>
> These methods (panx, zoomx
The pylab namespace has gradually gotten messier and messier, with all
sorts of things dumped into it. A number of people have asked for a
smaller module that would contain only the state-machine plotting part
of pylab--that is, the figure, show, plot, contour, etc. sorts of
functions. The na
John Hunter wrote:
> On 9/9/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>> The Axes.panx() method and several others contain calls to
>> _send_xlim_event() and similar methods. These methods don't seem to be
>> defined anywhere.
>
> These methods (panx, zoomx
Darren Dale wrote:
[...]
>
> Could MANIFEST also be removed? I think it is generated from MANIFEST.in.
It is, but it is not clear to me when or how this occurs. Does
distutils do it? MANIFEST seems to have special significance, but I
don't know anything about it beyond that.
Eric
--
John et al.,
"Agg 2.5 will ship with a libsigc++ license that will allow us to treat
the code as MIT X11 unless the code is pulled out, allowing Antigrain to
be used internally for Silverlight and allowing them to license
Antigrain for other customers."
I found the above quote on this page: ht
Bill Baxter wrote:
>
> On 9/24/07, *Eric Firing* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> John et al.,
>
> "Agg 2.5 will ship with a libsigc++ license that will allow us to treat
> the code as MIT X11 unless the code is p
Leon Barrett wrote:
> I found a bug in the Axes3D code for making 3D plots. I created a simple
> patch to fix it. I then submitted a bug to the tracker more than a week
> ago. However, it seems to have gone unnoticed, so I am sending this
> information to the mailing list, which seems to be more
James,
I see that you have implemented a strategy change in axes.py for
inverted axes, with corresponding additions to the API. I don't have
strong opinions about the strategy. Keeping track of orientation via a
flag is reasonable, although I'm not positive it is better, given that
it compli
Ted Drain wrote:
> John,
> I think keeping the existing API is probably a good idea. What about
> something like this:
>
> - Keep xlim and viewlim as they are.
>
> - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < x2.
>
> - Add set_xbound(x1,x2) that takes x1 then calls s
Ted Drain wrote:
> John,
> I think that the problem isn't doing the inversion - it's keeping it.
> Calling set_xlim() to invert is fine - but it never seems to stay that
> way. There is a lot of code (resizing, autoscaling, labelling, etc)
> that has a tendency to flip the axis back to it's 'u
601 - 700 of 1085 matches
Mail list logo
