matplotlib-devel Mailing List for matplotlib (Page 12)

Darren Dale wrote:
> I think we would rather make traits an external dependency, if it could be 
> easily installed as a separate package by a novice python user. Would it be 
> possible for http://code.enthought.com/projects/traits/ to list specific 
> instructions and links to the downloads? Or to list traits on the Python 
> Package Index?
> 
We have now scheduled resources to finish the ETS refactoring that will 
allow us to release Traits 3, which means publishing it into PyPI. The 
effort won't start until next week at the earliest though. Even though 
I'm a bit gun-shy about doing this, I'd forecast we have Traits 3.0 
officially released and on PyPI by the end of June, perhaps a week into 
July.
-- Dave

On 2008年6月09日 07:41:05 -1000
 Eric Firing <ef...@ha...> wrote:
> Nils Wagner wrote:
>> Hi Eric,
>> 
>> I have still some trouble with the following example 
>>taken from openopt
>> 
>> 
>> /usr/bin/python -i nlp_3.py
>> starting solver ipopt (license: CPL) with problem nlp3
>> [PyIPOPT] Ipopt will use Hessian approximation.
>> [PyIPOPT] nele_hess is 0
>> iter objFunVal log10(maxResidual)
>> 0 -1.640e+02 0.81
>> Traceback (most recent call last):
>> File "nlp_3.py", line 65, in ?
>> r = p.solve(solver)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 236, in solve
>> return runProbSolver(self, solvers, *args, **kwargs)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
>> line 219, in runProbSolver
>> solver(p)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/CoinOr/ipopt_oo.py", 
>> line 70, in __solver__
>> p.iterfcn(p.x0)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 57, in <lambda>
>> self.iterfcn = lambda *args: ooIter(self, *args)# 
>>this parameter is 
>> only for OpenOpt developers, not common users
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooIter.py", 
>> line 78, in ooIter
>> for df in p.graphics.drawFuncs: df(p)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooGraphics.py", 
>> line 127, in oodraw
>> if self.nSubPlots>1: pylab.subplot(self.nSubPlots, 
>>1, 1)
>> File 
>>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
>>line 
>> 519, in subplot
>> fig = gcf()
>> File 
>>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
>>line 
>> 210, in gcf
>> return figure()
>> File 
>>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
>>line 
>> 195, in figure
>> FigureClass=FigureClass,
>> File 
>> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
>> line 119, in new_figure_manager
>> frame = FigureFrameWxAgg(num, fig)
>> File 
>> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
>> line 1237, in __init__
>> self.canvas.SetInitialSize(wx.Size(fig.bbox.width, 
>>fig.bbox.height))
>> AttributeError: 'FigureCanvasWxAgg' object has no 
>>attribute 
>> 'SetInitialSize'
>> 
>> Any idea ?
> 
> No clue. When did it stop working?
> 
> efiring@manini:~/programs/py/mpl/mpl_trunk/lib/matplotlib$ 
>rgrep SetInitialSize --include '*.py' .
> ./backends/backend_wx.py: 
>self.canvas.SetInitialSize(wx.Size(fig.bbox.width, 
>fig.bbox.height))
> ./backends/backend_wx.py: 
>self.canvas.SetInitialSize(wx.Size(width, height))
> 
> I can't find anything in the code that defines 
>SetInitialSize.
> 
I didn't check the example nlp_3.py (from openopt) 
regularly. So I can't tell you when it stopped.
As a workaround I have used another backend in my
matplotlibrc
#### CONFIGURATION BEGINS HERE
# the default backend; one of GTK GTKAgg GTKCairo FltkAgg 
QtAgg TkAgg
# Agg Cairo GD GDK Paint PS PDF SVG Template
#backend : WXAgg
backend : TkAgg
 
Cheers,
 Nils

Andrew Straw wrote:
> Hi Eric,
> 
> show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
> using IPython).
Andrew,
Please try now, with r5435 or later. There is still the underlying 
puzzle to be solved before all this can be cleaned up, but I think the 
basic functionality is back.
Eric
> 
> -Andrew
> 
> Eric Firing wrote:
>> While investigating a bug pointed out by Andrew (and one that I had 
>> introduced some time ago) I found to my horror that I had also caused 
>> another bug: interactive plotting was not working with ipython -pylab. 
>> I backed out part of r5420, and that fixed the problem. This temporary 
>> fix is to restore the mixed case backend names in the interactive_bk 
>> list that is now set in rcsetup.py and imported by backends/__init__.py.
>>
>> I am baffled as to why this is needed at present; I have not been able 
>> to figure out why ipython threading seems to get confused when that list 
>> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
>> qt4agg. I don't see anywhere in either the ipython or the mpl code that 
>> should care about the case of the names in that list, now that I have 
>> ensured that comparisons against backend names in mpl (everywhere I 
>> could find them--maybe I missed on) are case-insensitive, and 
>> get_backend() returns only lower case. rcParams['backend'] can still 
>> have mixed case, however.
>>
>> Any suggestions as to what I am missing or where to look?
>>
>> Related question: I just noticed that there is also a config/rcsetup.py. 
>> Is there any reason why there has to be so much duplication (and now 
>> gradual divergence) between this and the regular rcsetup.py? Is there 
>> any reason the traits config system can't use the regular version, maybe 
>> with some changes merged in?
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

On Monday 09 June 2008 11:48:30 am John Hunter wrote:
> Those of you who have been building the docs have probably seen the
> inscrutable table warnings coming from sphinx. I just got a clue
> where these are coming from. Look at the table formatting from this
> ipython session (in case your email client doesn't handle monospace
> right, the table border at the top is not indented right. Darren,
> I'll let you take this -- somewhere in the dedent/kwarg table
> interpolation, some spacing is getting botched.
Thanks. I hadn't noticed it before, and had to blow away the build/ to see the 
error. The artist.kwdocd['Patch'] at the top of patches.py needed a blank 
line above and below the table, its fixed now.

On Mon, Jun 9, 2008 at 11:45 AM, Gregor Thalhammer
>
> If I understood it correctly, Agg (i.e., span_image_resample_*) already
> exactly behaves like you proposed. It resamples the image if the scaling is
> less than 1, otherwise it interpolates.
> I am not an Agg expert. The documentation of Agg is not very exhaustive. I
> took it from one of the demos. span_image_resample_rgba_affine seems to be
> faster than span_image_resample_rgba, but it supports affine but no
> perspective transformations. If I understood it correctly, matplotlib only
> uses image translation and scaling, not even rotation or shearing. All this
> is covered by span_image_resample_rgba_affine.
OK, all this sounds reasonable. I've committed the changes to the
trunk. Thanks for the explanation and the patch!
JDH

John Hunter schrieb:
> On Mon, Jun 9, 2008 at 10:18 AM,
>
> 
>> I attached a patch against the current svn version that adds a 'resample'
>> argument to imshow. Additionally, this patch supports a 'image.resample'
>> entry in the rc file. Setting this to false (default), the behaviour is
>> unchanged.
>> 
>
> Hi Gregor -- thanks for sending this. It's something I was aware of
> in agg but never got around to exposing. I wonder if the
> resample=True|False is the right approach. It might be nice for
> imshow to have an 'auto' mode to either resample or interpolate
> depending on the image dimensions w/ respect to the destination size.
> Ie, if we are displaying the full image into a small destination,
> 'auto' would default to resample. If we zoom in sufficiently, the
> image might be best displayed with interpolation. Is this something
> you think would be worthwhile and would you like to work on support
> for this?
> 
If I understood it correctly, Agg (i.e., span_image_resample_*) already 
exactly behaves like you proposed. It resamples the image if the scaling 
is less than 1, otherwise it interpolates.
> Also,l I notice the patch exposes span_image_resample_rgba_affine but not
> span_image_resample_rgba which takes an interpolator template
> argument. I know very little about this area, but was this a
> conscious choice or one of expediency? Can you explain the rational?
>
> 
I am not an Agg expert. The documentation of Agg is not very exhaustive. 
I took it from one of the demos. span_image_resample_rgba_affine seems 
to be faster than span_image_resample_rgba, but it supports affine but 
no perspective transformations. If I understood it correctly, matplotlib 
only uses image translation and scaling, not even rotation or shearing. 
All this is covered by span_image_resample_rgba_affine.
Gregor

Andrew Straw wrote:
> Hi Eric,
> 
> show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
> using IPython).
Sure enough. It seems that in the process of bisecting the svn versions 
to track down this problem and the original one you reported, things got 
mixed up in my directory, so that what worked on what I thought was the 
svn head was actually working on some mongrel. After a fresh checkout 
with clean build and install, I find that neither plain show nor ipython 
-pylab is working.
Back to the drawing board. I really would like to get everything 
working with complete case-insensitivity, and lower-case defaults, for 
the backend names. There is no reason one should have to remember that 
it is TkAgg, not TKAgg, but GTKAgg, not GtkAgg.
Eric
> 
> -Andrew
> 
> Eric Firing wrote:
>> While investigating a bug pointed out by Andrew (and one that I had 
>> introduced some time ago) I found to my horror that I had also caused 
>> another bug: interactive plotting was not working with ipython -pylab. 
>> I backed out part of r5420, and that fixed the problem. This temporary 
>> fix is to restore the mixed case backend names in the interactive_bk 
>> list that is now set in rcsetup.py and imported by backends/__init__.py.
>>
>> I am baffled as to why this is needed at present; I have not been able 
>> to figure out why ipython threading seems to get confused when that list 
>> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
>> qt4agg. I don't see anywhere in either the ipython or the mpl code that 
>> should care about the case of the names in that list, now that I have 
>> ensured that comparisons against backend names in mpl (everywhere I 
>> could find them--maybe I missed on) are case-insensitive, and 
>> get_backend() returns only lower case. rcParams['backend'] can still 
>> have mixed case, however.
>>
>> Any suggestions as to what I am missing or where to look?
>>
>> Related question: I just noticed that there is also a config/rcsetup.py. 
>> Is there any reason why there has to be so much duplication (and now 
>> gradual divergence) between this and the regular rcsetup.py? Is there 
>> any reason the traits config system can't use the regular version, maybe 
>> with some changes merged in?
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

On Mon, Jun 09, 2008 at 06:41:08AM -0400, Darren Dale wrote:
> I think we would rather make traits an external dependency, if it could be 
> easily installed as a separate package by a novice python user. Would it be 
> possible for http://code.enthought.com/projects/traits/ to list specific 
> instructions and links to the downloads? Or to list traits on the Python 
> Package Index?
If I get things correctly, having traits on PyPI is planned for the
version 3 release, which should happen when the guys at Enthought find
time to make it happen. However I cannot speak for them, as I am not
employed by Enthought, sitting in Austin (Yet !). I will also be very
happy the day this happens.
Gaël

On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote:
> Gael, maybe the following situation caused the trouble:
> 1) user downloads mpl source
> 2) builds matplotlib - traits now exists in the temproary build directory
> 3) installs enthought traits
> 4) installs matplotlib - traits would not have been built in this case, its 
> already installed on the system, but it still exists in the build directory 
> and gets installed anyway.
Actually, after looking at the code and thinking a bit more, I think the
problem might simply be with different version of traits installed in
different directories in the sys.path, with Python's import mechanism
picking up the MPL-installed one, rather then the user-installed one.
Tricky problems that I see more and more happenning.
But I don't have an example box to test this hypothesis, so we are still
clueless.
Cheers,
Gaël

On Monday 09 June 2008 09:52:46 am John Hunter wrote:
> On Mon, Jun 9, 2008 at 5:41 AM, Darren Dale <dar...@co...> wrote:
> > I think we would rather make traits an external dependency, if it could
> > be easily installed as a separate package by a novice python user. Would
> > it be possible for http://code.enthought.com/projects/traits/ to list
> > specific instructions and links to the downloads? Or to list traits on
> > the Python Package Index?
>
> I also agree that we should not install a modified version of traits
> in the top level namespace. Let's disable all default installs of
> enthought traits until we work this out. We only need it for the
> optional rc config and so let's require that someone manually turn it
> on in setup.cfg if they want it. In particular, let's fix this before
> the next bugfix release. If we opt to depend on traits for the new
> rc, we will either need to require and external dependency, figure out
> a way to install a completely working and compatible version, or do
> the extra work to install it inside the matplotlib namespace. I
> prefer 1 or 3, but at this point I think whether we will migrate to
> the traited rc system is an open question so disabling is the right
> solution for now.
>
> Darren, can you take care of this?
Its done.
Gael, maybe the following situation caused the trouble:
1) user downloads mpl source
2) builds matplotlib - traits now exists in the temproary build directory
3) installs enthought traits
4) installs matplotlib - traits would not have been built in this case, its 
already installed on the system, but it still exists in the build directory 
and gets installed anyway.
Seems unlikely, but who knows.

Those of you who have been building the docs have probably seen the
inscrutable table warnings coming from sphinx. I just got a clue
where these are coming from. Look at the table formatting from this
ipython session (in case your email client doesn't handle monospace
right, the table border at the top is not indented right. Darren,
I'll let you take this -- somewhere in the dedent/kwarg table
interpolation, some spacing is getting botched.
JDH
class Arrow(Patch)
 | An arrow patch
 |
 | Method resolution order:
 | Arrow
 | Patch
 | matplotlib.artist.Artist
 | __builtin__.object
 |
 | Methods defined here:
 |
 | __init__(self, x, y, dx, dy, width=1.0, **kwargs)
 | Draws an arrow, starting at (x,y), direction and length
 | given by (dx,dy) the width of the arrow is scaled by width
 |
 | Valid kwargs are:
 | =================
==============================================
 | Property Description
 | ================= ==============================================
 | alpha float
 | animated [True | False]
 | antialiased or aa [True | False]
 | clip_box a matplotlib.transform.Bbox instance
 | clip_on [True | False]
 | edgecolor or ec any matplotlib color
 | facecolor or fc any matplotlib color
 | figure a matplotlib.figure.Figure instance
 | fill [True | False]
 | hatch unknown
 | label any string
 | linewidth or lw float
 | lod [True | False]
 | transform a matplotlib.transform transformation instance
 | visible [True | False]
 | zorder any number
 | ================= ==============================================

On Mon, Jun 9, 2008 at 10:18 AM,
> I attached a patch against the current svn version that adds a 'resample'
> argument to imshow. Additionally, this patch supports a 'image.resample'
> entry in the rc file. Setting this to false (default), the behaviour is
> unchanged.
Hi Gregor -- thanks for sending this. It's something I was aware of
in agg but never got around to exposing. I wonder if the
resample=True|False is the right approach. It might be nice for
imshow to have an 'auto' mode to either resample or interpolate
depending on the image dimensions w/ respect to the destination size.
Ie, if we are displaying the full image into a small destination,
'auto' would default to resample. If we zoom in sufficiently, the
image might be best displayed with interpolation. Is this something
you think would be worthwhile and would you like to work on support
for this?
Also,l I notice the patch exposes span_image_resample_rgba_affine but not
span_image_resample_rgba which takes an interpolator template
argument. I know very little about this area, but was this a
conscious choice or one of expediency? Can you explain the rational?
JDH

Dear developers,
matplotlib offers high quality interpolation filters which give 
excellent results if you scale up an image. However, for downscaling an 
image the results are worse. Depending on the precise scaling fine 
details (e.g., thin horizontal lines, single pixel points) disappear and 
aliasing effects are visible. After studying the source and the docs for 
Agg I figured out how to improve this. Agg provides all possibilities, 
just use them.
I attached a patch against the current svn version that adds a 
'resample' argument to imshow. Additionally, this patch supports a 
'image.resample' entry in the rc file. Setting this to false (default), 
the behaviour is unchanged.
I also attached a simple test script (test_imshow.py) to show the 
difference between image display with and without resampling. To see the 
difference it might be necessary to zoom out.
Gregor Thalhammer

Hi Eric,
show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
using IPython).
-Andrew
Eric Firing wrote:
> While investigating a bug pointed out by Andrew (and one that I had 
> introduced some time ago) I found to my horror that I had also caused 
> another bug: interactive plotting was not working with ipython -pylab. 
> I backed out part of r5420, and that fixed the problem. This temporary 
> fix is to restore the mixed case backend names in the interactive_bk 
> list that is now set in rcsetup.py and imported by backends/__init__.py.
>
> I am baffled as to why this is needed at present; I have not been able 
> to figure out why ipython threading seems to get confused when that list 
> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
> qt4agg. I don't see anywhere in either the ipython or the mpl code that 
> should care about the case of the names in that list, now that I have 
> ensured that comparisons against backend names in mpl (everywhere I 
> could find them--maybe I missed on) are case-insensitive, and 
> get_backend() returns only lower case. rcParams['backend'] can still 
> have mixed case, however.
>
> Any suggestions as to what I am missing or where to look?
>
> Related question: I just noticed that there is also a config/rcsetup.py. 
> Is there any reason why there has to be so much duplication (and now 
> gradual divergence) between this and the regular rcsetup.py? Is there 
> any reason the traits config system can't use the regular version, maybe 
> with some changes merged in?
>
> Eric
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Mon, Jun 9, 2008 at 5:41 AM, Darren Dale <dar...@co...> wrote:
> I think we would rather make traits an external dependency, if it could be
> easily installed as a separate package by a novice python user. Would it be
> possible for http://code.enthought.com/projects/traits/ to list specific
> instructions and links to the downloads? Or to list traits on the Python
> Package Index?
I also agree that we should not install a modified version of traits
in the top level namespace. Let's disable all default installs of
enthought traits until we work this out. We only need it for the
optional rc config and so let's require that someone manually turn it
on in setup.cfg if they want it. In particular, let's fix this before
the next bugfix release. If we opt to depend on traits for the new
rc, we will either need to require and external dependency, figure out
a way to install a completely working and compatible version, or do
the extra work to install it inside the matplotlib namespace. I
prefer 1 or 3, but at this point I think whether we will migrate to
the traited rc system is an open question so disabling is the right
solution for now.
Darren, can you take care of this?
JDH

On Monday 09 June 2008 03:55:47 Eric Firing wrote:
> While investigating a bug pointed out by Andrew (and one that I had
> introduced some time ago) I found to my horror that I had also caused
> another bug: interactive plotting was not working with ipython -pylab.
> I backed out part of r5420, and that fixed the problem. This temporary
> fix is to restore the mixed case backend names in the interactive_bk
> list that is now set in rcsetup.py and imported by backends/__init__.py.
>
> I am baffled as to why this is needed at present; I have not been able
> to figure out why ipython threading seems to get confused when that list
> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or
> qt4agg. I don't see anywhere in either the ipython or the mpl code that
> should care about the case of the names in that list, now that I have
> ensured that comparisons against backend names in mpl (everywhere I
> could find them--maybe I missed on) are case-insensitive, and
> get_backend() returns only lower case. rcParams['backend'] can still
> have mixed case, however.
>
> Any suggestions as to what I am missing or where to look?
>
> Related question: I just noticed that there is also a config/rcsetup.py.
> Is there any reason why there has to be so much duplication (and now
> gradual divergence) between this and the regular rcsetup.py? Is there
> any reason the traits config system can't use the regular version, maybe
> with some changes merged in?
We should probably discuss the future of TConfig in mpl at some point. Its been 
a while since I looked at it, but basically I was trying to isolate that code 
so it didnt creep into mpl until we were ready. There is lots of duplication 
in config, if you want to change it to import from rcsetup, its alright with 
me.

On Monday 09 June 2008 01:27:57 Gael Varoquaux wrote:
> On Sun, Jun 08, 2008 at 06:13:24PM -0400, Darren Dale wrote:
> > Matplotlib's setup scripts are designed to avoid this problem. There are
> > three conditions under which we install traits:
> >
> > 1) Traits is not installed
> > 2) A previous version of traits is installed, but it is a version
> > installed by matplotlib. I added an "-mpl" to the end of traits
> > __version__ string so we can keep track.
> > 3) The user explicitly askes for it in setup.cfg
> >
> > So if matplotlib is overwriting traits when it should not, I want to fix
> > it. But I need more information about what is causing it, because I don't
> > see how it could happen.
>
> If Traits is installed after MPL, if I get it right, then the problem
> occurs. IIRC, this is the problem I stumbled upon once.
I don't see why that would cause a problem.
> > I tried this when I first started working with TConfig, and concluded
> > that it was not possible because there are too many places where traits
> > expects enthought to be a top level package. There were all kind of
> > errors, exceptions being raised that were not named as expected,
> > extension code that would need to be modified, so we settled on the
> > current solution.
>
> OK. You are right. In nipy I modified enthought.traits and
> enthought.etsconfig. This was not a beautiful job, I must admit. Maybe
> monkey patching sys.path is the option (it is the way eggs do it) thought
> I must admit I hate it, because it puts a lot of magic, that will
> take the user by surprise. Anyway, the criteria for monkey-patching
> sys.path must be improved, I feel.
I also considered modifying sys.patch, this solution was roundly booed.
> If I understand things correctly, the current problem can be described
> by:
>
> * User has an old version of ETS, (the one in Enthon 1.0.4, that is a
> very old one), his code needs the old version.
> * User installs a new version of MPL.
> * His code stops working.
>
> I agree that as you describe things, this should not happen. Maybe I have
> gotten wrong the order in which the user did things. I have the feeling
> things shouldn't be dependent on the order in which you do the steps
> (maybe the test for monkey-patching sys.path should not be at
> install time, but at load time).
What test? I don't follow.
> Maybe the test fails for a very old version of traits. I wanted to have a
> quick look at this code, but I can't find it after a quick scan of the
> MPL source, and I can't devote much time to this right now.
Its a short section in setupext.py (which is in the same directory a 
setup.py), the function is called check_provide_traits.
I think we would rather make traits an external dependency, if it could be 
easily installed as a separate package by a novice python user. Would it be 
possible for http://code.enthought.com/projects/traits/ to list specific 
instructions and links to the downloads? Or to list traits on the Python 
Package Index?

While investigating a bug pointed out by Andrew (and one that I had 
introduced some time ago) I found to my horror that I had also caused 
another bug: interactive plotting was not working with ipython -pylab. 
I backed out part of r5420, and that fixed the problem. This temporary 
fix is to restore the mixed case backend names in the interactive_bk 
list that is now set in rcsetup.py and imported by backends/__init__.py.
I am baffled as to why this is needed at present; I have not been able 
to figure out why ipython threading seems to get confused when that list 
has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
qt4agg. I don't see anywhere in either the ipython or the mpl code that 
should care about the case of the names in that list, now that I have 
ensured that comparisons against backend names in mpl (everywhere I 
could find them--maybe I missed on) are case-insensitive, and 
get_backend() returns only lower case. rcParams['backend'] can still 
have mixed case, however.
Any suggestions as to what I am missing or where to look?
Related question: I just noticed that there is also a config/rcsetup.py. 
 Is there any reason why there has to be so much duplication (and now 
gradual divergence) between this and the regular rcsetup.py? Is there 
any reason the traits config system can't use the regular version, maybe 
with some changes merged in?
Eric

Nils Wagner wrote:
> Hi all,
> 
> I cannot build matplotlib from svn since last Friday.
> Any idea ?
> -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -lpng -lz 
> -lstdc++ -lm -o 
> build/lib.linux-x86_64-2.5/matplotlib/_path.so
> /usr/bin/ld: cannot find -lpng
Do you have a libpng.so in /usr/lib64 or /usr/local/lib64? My 
interpretation of the error message is that the linker is not finding it.
Eric

Hi all,
I cannot build matplotlib from svn since last Friday.
Any idea ?
Nils
cc1plus: Warnung: Kommandozeilenoption 
"-Wstrict-prototypes" ist gültig für Ada/C/ObjC, aber 
nicht für C++
g++ -pthread -shared 
build/temp.linux-x86_64-2.5/agg24/src/agg_curves.o 
build/temp.linux-x86_64-2.5/agg24/src/agg_bezier_arc.o 
build/temp.linux-x86_64-2.5/agg24/src/agg_trans_affine.o 
build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_stroke.o 
build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o 
build/temp.linux-x86_64-2.5/CXX/cxxsupport.o 
build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o 
build/temp.linux-x86_64-2.5/CXX/cxxextensions.o 
build/temp.linux-x86_64-2.5/src/path.o -L/usr/local/lib 
-L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -lpng -lz 
-lstdc++ -lm -o 
build/lib.linux-x86_64-2.5/matplotlib/_path.so
/usr/bin/ld: cannot find -lpng
collect2: ld gab 1 als Ende-Status zurück
error: command 'g++' failed with exit status 1
 

On Sun, Jun 08, 2008 at 06:13:24PM -0400, Darren Dale wrote:
> Matplotlib's setup scripts are designed to avoid this problem. There are three 
> conditions under which we install traits:
> 1) Traits is not installed
> 2) A previous version of traits is installed, but it is a version installed by 
> matplotlib. I added an "-mpl" to the end of traits __version__ string so we 
> can keep track.
> 3) The user explicitly askes for it in setup.cfg
> So if matplotlib is overwriting traits when it should not, I want to fix it. 
> But I need more information about what is causing it, because I don't see how 
> it could happen.
If Traits is installed after MPL, if I get it right, then the problem
occurs. IIRC, this is the problem I stumbled upon once.
> I tried this when I first started working with TConfig, and concluded
> that it was not possible because there are too many places where traits
> expects enthought to be a top level package. There were all kind of
> errors, exceptions being raised that were not named as expected,
> extension code that would need to be modified, so we settled on the
> current solution.
OK. You are right. In nipy I modified enthought.traits and
enthought.etsconfig. This was not a beautiful job, I must admit. Maybe
monkey patching sys.path is the option (it is the way eggs do it) thought
I must admit I hate it, because it puts a lot of magic, that will
take the user by surprise. Anyway, the criteria for monkey-patching
sys.path must be improved, I feel.
If I understand things correctly, the current problem can be described
by:
 * User has an old version of ETS, (the one in Enthon 1.0.4, that is a
 very old one), his code needs the old version.
 * User installs a new version of MPL.
 * His code stops working.
I agree that as you describe things, this should not happen. Maybe I have
gotten wrong the order in which the user did things. I have the feeling
things shouldn't be dependent on the order in which you do the steps
(maybe the test for monkey-patching sys.path should not be at
install time, but at load time).
Maybe the test fails for a very old version of traits. I wanted to have a
quick look at this code, but I can't find it after a quick scan of the
MPL source, and I can't devote much time to this right now.
Cheers,
Gaël

Andrew,
Yes, and it looks like there is more to it: the draw() method doesn't 
seem to be working (or getting called at the right time) in interactive 
mode, but no exception is being raised, either. I will look into it.
Eric
Andrew Straw wrote:
> Hi (Eric?),
> 
> Re-running an older script of mine today, I notice a change of behavior
> with imshow(). The script below produces the attached 2 figures for MPL
> 0.91.3 and svn from today (labeled "0.98.0"). I believe that the
> behavior of 0.91.3 was correct -- the image is not cropped, its aspect
> ratio is maintained, and the data coordinates correspond to the pixel
> coordinates. I am also including the original image used in this example.
> 
> import matplotlib, pylab
> import Image
> 
> im = Image.open('eye_map.gif')
> im_extent = (0, im.size[0], 0, im.size[1])
> pylab.imshow(im,origin='lower',
> extent=im_extent,
> aspect='equal')
> fname = 'extent_bug_%s.png'%matplotlib.__version__
> pylab.savefig(fname)
> 
> Please let me know if I can do more. Note that I have shifted the image
> mode to an 8-bit palette for the .pngs with GIMP to save space in this
> email, but otherwise the images are exactly as emitted by MPL.
> 
> Thanks,
> Andrew
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi (Eric?),
Re-running an older script of mine today, I notice a change of behavior
with imshow(). The script below produces the attached 2 figures for MPL
0.91.3 and svn from today (labeled "0.98.0"). I believe that the
behavior of 0.91.3 was correct -- the image is not cropped, its aspect
ratio is maintained, and the data coordinates correspond to the pixel
coordinates. I am also including the original image used in this example.
import matplotlib, pylab
import Image
im = Image.open('eye_map.gif')
im_extent = (0, im.size[0], 0, im.size[1])
pylab.imshow(im,origin='lower',
 extent=im_extent,
 aspect='equal')
fname = 'extent_bug_%s.png'%matplotlib.__version__
pylab.savefig(fname)
Please let me know if I can do more. Note that I have shifted the image
mode to an 8-bit palette for the .pngs with GIMP to save space in this
email, but otherwise the images are exactly as emitted by MPL.
Thanks,
Andrew

On Sunday 08 June 2008 16:57:56 Gael Varoquaux wrote:
> Hey guys,
>
> Just got back from 3 weeks holydays (that feels really good, I should try
> this more often). I a fighting with a mountain of emails, but I just
> wanted to give a little heads up. Tout is working on the codebase that I
> originally wrote and got me addicted to the ETS, at the university of
> Toronto.
>
> He tried updating and did run in some minor incompatibility (some ".api"
> added, not the end of the word, I believe).
>
> However, more working (Darren Dale is Cced about that) is that matplotib
> includes its own version of Traits and tends to be quite light on the
> policy to decide when to overide the system one. As a result, and recent
> version of MPL make the code base die in the ETS parts. I have already
> mentioned this problem, and I believe it is a really evil one. I don't
> have time to do some lobbying about this right now, could someone make
> sure this is solved (Darren?).
Matplotlib's setup scripts are designed to avoid this problem. There are three 
conditions under which we install traits:
1) Traits is not installed
2) A previous version of traits is installed, but it is a version installed by 
matplotlib. I added an "-mpl" to the end of traits __version__ string so we 
can keep track.
3) The user explicitly askes for it in setup.cfg
So if matplotlib is overwriting traits when it should not, I want to fix it. 
But I need more information about what is causing it, because I don't see how 
it could happen.
> IMHO one temporary solution, less ugly then the current one, is the one
> we used in nipy: define a matplotlib.externals.traits that can point either
> to a system-wide traits, or to the embedded traits. Using some code in
> matplotlib.externals similar to:
>
> """
> def import_traits():
> """ Import traits, either from a system-wide location, or from our
> copy.
> """
> try:
> 	from enthought import traits
> except ImportError:
> 	from matplotlib.externals.enthought import traits
> return traits
>
> traits = import_traits()
> """
>
> You can put as much logics as you want in "import_traits" to check eg for
> version numbers. If in MPL you only import traits from matplotlib.traits,
> you can thus use traits and not have side effects on other libraries.
I tried this when I first started working with TConfig, and concluded that it 
was not possible because there are too many places where traits expects 
enthought to be a top level package. There were all kind of errors, exceptions 
being raised that were not named as expected, extension code that would need 
to be modified, so we settled on the current solution.
> IMHO, the current situation is untenable.
Please, provide details so I can understand the problem.
Darren

Hey guys,
Just got back from 3 weeks holydays (that feels really good, I should try
this more often). I a fighting with a mountain of emails, but I just
wanted to give a little heads up. Tout is working on the codebase that I
originally wrote and got me addicted to the ETS, at the university of
Toronto.
He tried updating and did run in some minor incompatibility (some ".api"
added, not the end of the word, I believe).
However, more working (Darren Dale is Cced about that) is that matplotib
includes its own version of Traits and tends to be quite light on the
policy to decide when to overide the system one. As a result, and recent
version of MPL make the code base die in the ETS parts. I have already
mentioned this problem, and I believe it is a really evil one. I don't
have time to do some lobbying about this right now, could someone make
sure this is solved (Darren?).
IMHO one temporary solution, less ugly then the current one, is the one
we used in nipy: define a matplotlib.externals.traits that can point either to a
system-wide traits, or to the embedded traits. Using some code in
matplotlib.externals similar to:
"""
def import_traits():
 """ Import traits, either from a system-wide location, or from our
 copy.
 """
 try:
	from enthought import traits
 except ImportError:
	from matplotlib.externals.enthought import traits
 return traits
traits = import_traits()
"""
You can put as much logics as you want in "import_traits" to check eg for
version numbers. If in MPL you only import traits from matplotlib.traits,
you can thus use traits and not have side effects on other libraries.
IMHO, the current situation is untenable.
Cheers,
Gaël
On Tue, Jun 03, 2008 at 01:51:40PM -0500, Dave Peterson wrote:
> Tout Wang wrote:
> That worked to resolve the ImportError for View but now it gets stuck
> at ui. I think ui is still imported from enthought.traits.ui because
> from enthought.traits.ui import ui
> works just fine. It seems that the main problem is that the latest
> version of Enthought has changed how things are imported, which is a
> little annoying because I expected that newer versions would be almost
> entirely backwards compatible. I wonder why this is?
> Anyway, I have reverted to Enthon 1.0.0 (Python 2.4.3) and everything
> imports just fine now from TraitsUI with the original code.
> Enthon 1.0.0 was released in August of 2006. At that time (about 7,000
> svn revisions ago!) Traits was reporting itself as version 1.0.2. EPD
> includes enthought.traits 2.0.4 as you've already seen. Even though our
> policy on version numbers didn't come into being until well after Enthon
> 1.0.0 was released, I think it reasonable that there would be some
> API-incompatible changes between version 1 and version 2.
> IIRC, the changes between these versions are more about adding features
> than they are about breaking or leaving behind functionality. Yes, the
> locations of where to import some things may have changed (centralized to
> an api.py rather than in __init__.py) but in general most everything else
> should work pretty much the same.