matplotlib-devel Mailing List for matplotlib

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.

On Monday 02 June 2008 09:12:45 Michael Droettboom wrote:
> John Hunter wrote:
> > On Sat, May 31, 2008 at 9:19 AM, Darren Dale <dar...@co...> 
wrote:
> >> I'll be working on converting docstrings to rest this weekend. Should
> >> any of this be done on the branch? Or should we just focus on the trunk?
> >
> > As far as I am concerned, the documentation effort is for the trunk.
> > The only reason to do them on the branch too is to make merges of
> > other code changes easier, which may be a compelling reason. If the
> > docstrings get far out of whack, it may make merging other changes
> > very painful. But at the same time, I don't want the burden of
> > trying to keep the two in sync stopping you from getting the work done
> > that you need to do. Maybe you can try it and see how hard it is, and
> > if proves to be too much of an impediment, just concentrate on the
> > trunk. Michael, any advice here?
>
> I was away on the weekend, so just getting back. Darren: you rock. The
> documentation is looking great!
I agree, the documentation is coming along nicely. But I don't think I should 
be singled out for credit, there's lots of good stuff appearing that I haven't 
had anything to do with.

On Monday 02 June 2008 08:33:55 Michael Droettboom wrote:
> Darren Dale wrote:
> > On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
> >> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
> >>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fpe...@gm...>
> >
> > I tracked this down by checking the contents of the generated
> > build/latex/Matplotlib.tex, line 954. It is from the following code from
> >
> > mathtext.rst:
> >> When using the STIX fonts, you also have the choice of:
> >>
> >> ================ =================================
> >> Command Result
> >> ================ =================================
> >> ``\mathbb`` :math:`\mathbb{Blackboard}`
> >> ``\mathcircled`` :math:`\mathcircled{Circled}`
> >> ``\mathfrak`` :math:`\mathfrak{Fraktur}`
> >> ``\mathsf`` :math:`\mathsf{sans-serif}`
> >> ================ =================================
> >
> > I'm not sure this is being properly rendered in the HTML output for me,
> > either. Mike, are you able to compile this into a pdf on your machine,
> > and if so, would you tell us how to configure STIX support? I commented
> > this block out in svn for now.
>
> Sorry about that. It requires the amssymb and/or amsmath LaTeX packages
> to render correctly. Perhaps it is better to not require the LaTeX
> installation to have anything special though. I think the best course
> of action is to just include pre-generated images in the documentation
> source for this. I'll go ahead and do that.
I added doc/static_figs to hold scripts that require optional dependencies to 
generate images for the docs. I would like to be able to keep track of how the 
images are generated, so if we lose one we know how to recreate it. I added 
two scripts (softlinks actually) a README and a make.py to that directory. 
make.py saves the images to doc/_static.

Eric Firing wrote:
> Ryan May wrote:
> 
>> Eric Firing wrote:
>> 
>>> rcsetup can't get it from backends/__init__.py because that would set 
>>> a backend selection in stone. But backends/__init__.py can get it 
>>> from rcsetup, and I am in the process of making that change on the 
>>> trunk. This duplication had annoyed me earlier, but I didn't do 
>>> anything about it then. Thanks for the prompt.
>>> 
>> Good to know. If you can't get to it, let me know and I'll take a stab.
>> 
>
> It's done now.
>
> 
>>> Are you actually looking into adding a new backend?
>>> 
>> Yeah. I'm finally getting back around to the OpenGL backend I've been 
>> kicking around for awhile now, based (right now) on Gtk. gtkglext 
>> (which has python bindings) will let you render to a pixmap, so that 
>> should make it easy to integrate into the current matplotlib way of 
>> doing things. If things go well, I should have more on this after awhile.
>> 
>
> Is the motivation 3D plotting?
> 
I am all ears.... ;)
JCT
> 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
> 

Ryan May wrote:
> Eric Firing wrote:
>> rcsetup can't get it from backends/__init__.py because that would set 
>> a backend selection in stone. But backends/__init__.py can get it 
>> from rcsetup, and I am in the process of making that change on the 
>> trunk. This duplication had annoyed me earlier, but I didn't do 
>> anything about it then. Thanks for the prompt.
> 
> Good to know. If you can't get to it, let me know and I'll take a stab.
It's done now.
> 
>> Are you actually looking into adding a new backend?
> 
> Yeah. I'm finally getting back around to the OpenGL backend I've been 
> kicking around for awhile now, based (right now) on Gtk. gtkglext 
> (which has python bindings) will let you render to a pixmap, so that 
> should make it easy to integrate into the current matplotlib way of 
> doing things. If things go well, I should have more on this after awhile.
Is the motivation 3D plotting?
Eric

Eric Firing wrote:
> rcsetup can't get it from backends/__init__.py because that would set a 
> backend selection in stone. But backends/__init__.py can get it from 
> rcsetup, and I am in the process of making that change on the trunk. 
> This duplication had annoyed me earlier, but I didn't do anything about 
> it then. Thanks for the prompt.
Good to know. If you can't get to it, let me know and I'll take a stab.
> Are you actually looking into adding a new backend?
Yeah. I'm finally getting back around to the OpenGL backend I've been 
kicking around for awhile now, based (right now) on Gtk. gtkglext 
(which has python bindings) will let you render to a pixmap, so that 
should make it easy to integrate into the current matplotlib way of 
doing things. If things go well, I should have more on this after awhile.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Hi,
> 
> Is there any reason that adding a backend requires modifying both 
> rcsetup.py and the __init__.py in the backends subdirectory? Couldn't 
> rcsetup.py fetch the list from the __init__.py (or vice-versa)?
> 
> Thanks,
> 
> Ryan
> 
Ryan,
rcsetup can't get it from backends/__init__.py because that would set a 
backend selection in stone. But backends/__init__.py can get it from 
rcsetup, and I am in the process of making that change on the trunk. 
This duplication had annoyed me earlier, but I didn't do anything about 
it then. Thanks for the prompt.
Are you actually looking into adding a new backend?
Eric