matplotlib-devel Mailing List for matplotlib (Page 5)

Hello,

pywcsgrid2 is my personal project to display astronomical fits images
using matplotlib.
While there are other tools, my approach is to extend the capability
of the matplolib, rather than building something new on top of the
matplotlib. It provides a custom Axes class (derived from the
matplotlib's original Axes) whose main functionality improvement is to
draw ticks, ticklabels, and grids in an appropriate sky coordinate.

**NOTE**
This is a more like a development release. It currently requires the
"svn" version of the matplotlib as it is heavily based on the
axes_grid toolkit.
It also requires the kapteyn package
(http://www.astro.rug.nl/software/kapteyn/). And it is only supported
in linux and mac os X.

Home page : http://leejjoon.github.com/pywcsgrid2/

Overview doc. : http://leejjoon.github.com/pywcsgrid2/users/overview.html

Unfortunately, the code is documented rather sparsely (with poor
english), but I hope the above  overview gives enough idea on how to
start.

pywcsgrid2 is still in development, and there will be bug fixes and
improvements. While a downloadable tar file is available, it is
recommended to use the git repository.

For questions, bug reports or feature suggestions, please email me or
use the issue tracker in the github.

Regards,

-JJ

Hi all,

For those that are interested: the mathtex summer of code project is  
making good progress. On the development list for the project, mat...@go... 
  there is currently some discussion going on about integrating it  
back into matplotlib.

I encourage all of those who are interested to join and participate;  
the more input and guidance I get from the matplotlib developers the  
better.

The most likely course of action is that re-integration will be done  
in a branch of matplotlib until it is deemed stable enough to be  
merged back.

[*] the URL for the project is: http://code.google.com/p/mathtex/ and  
the mailing list is: http://groups.google.com/group/mathtex-dev

Regards, Freddie.

On Sat, Jul 11, 2009 at 08:18:25AM -1000, Eric Firing wrote:
> Thank you for the testing and reporting.  I don't normally use wx and I  
> am not willing to fiddle with multiple versions of it, so I am working  
> almost blind on this.

I use wx a lot, and with MPL embedded in other programs, so I am a good
test bed, and will hopefully catch major problems. However, I of course
cover only the configurations I have installed on the various boxes I
work on.

One of the really nice things with MPL, is that there is a significant
user base working from SVN, and thus catching problems early.

Gaël

On Sat, Jul 11, 2009 at 1:18 PM, Eric Firing<ef...@ha...> wrote:

>> These things are hard problems, thanks for your work.
>
> Thank you for the testing and reporting.  I don't normally use wx and I am
> not willing to fiddle with multiple versions of it, so I am working almost
> blind on this.

This is working for me, and by working I mean not displaying the warning...

Thanks Eric
JDH

Gael Varoquaux wrote:
> On Sat, Jul 11, 2009 at 08:10:23AM -1000, Eric Firing wrote:
>> OK, I tried again in svn 7256.  I think this is a little cleaner.  More  
>> diagnostic information could still be added to the exception messages if  
>> this is going to be a continuing problem.
> 
> It seems to work for me in all the configurations I can think of (and
> does raises the error when 2.6 is imported instead of 2.8.). I could be
> forgetting configurations, as the combinatory is high.
> 
> These things are hard problems, thanks for your work.

Thank you for the testing and reporting.  I don't normally use wx and I 
am not willing to fiddle with multiple versions of it, so I am working 
almost blind on this.

Eric

On Sat, Jul 11, 2009 at 08:10:23AM -1000, Eric Firing wrote:
> OK, I tried again in svn 7256.  I think this is a little cleaner.  More  
> diagnostic information could still be added to the exception messages if  
> this is going to be a continuing problem.

It seems to work for me in all the configurations I can think of (and
does raises the error when 2.6 is imported instead of 2.8.). I could be
forgetting configurations, as the combinatory is high.

These things are hard problems, thanks for your work.

Gaël

Gael Varoquaux wrote:
> On Sat, Jul 11, 2009 at 12:49:03PM -0500, John Hunter wrote:
>>> Can you do an 'import wxversion; print wxversion.__file__', so that we
>>> understand better why you are getting these warnings.
> 
>> In [1]: import wxversion
> 
>> In [2]: print wxversion.__file__
>> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxversion.pyc
> 
> Hell, sorry, I don't understand why you are getting the warning.
> 
> Gaël


OK, I tried again in svn 7256.  I think this is a little cleaner.  More 
diagnostic information could still be added to the exception messages if 
this is going to be a continuing problem.

Eric

On Sat, Jul 11, 2009 at 12:49:03PM -0500, John Hunter wrote:
> > Can you do an 'import wxversion; print wxversion.__file__', so that we
> > understand better why you are getting these warnings.

> In [1]: import wxversion

> In [2]: print wxversion.__file__
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxversion.pyc

Hell, sorry, I don't understand why you are getting the warning.

Gaël

On Sat, Jul 11, 2009 at 12:43 PM, Gael
Varoquaux<gae...@no...> wrote:
> On Sat, Jul 11, 2009 at 12:38:13PM -0500, John Hunter wrote:
>> If I can speak for the typical user, these kinds of warnings are
>> usually annoying and not that helpful.  I am a naive wx user -- I
>> installed it many moons ago from a binary when I installed python and
>> haven't thought about it since.  I don't know what wxversion is or how
>> to upgrade it.  All I know is mpl was working fine, still works fine,
>> and now generates an annoying warning.   So I am not sure this is
>> progress, but may help someone who has a complicated wx setup avoid
>> difficult to trackdown bug.   So I would prefer to silence this, but
>> am not sure what the right solution is. Here is my wx installation
>
> I am a bit like you. I believe these warning are not terribly helpful.
>
> Can you do an 'import wxversion; print wxversion.__file__', so that we
> understand better why you are getting these warnings.




In [1]: import wxversion

In [2]: print wxversion.__file__
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxversion.pyc

In [3]: import wx

In [4]: print wx.__version__
2.8.3.0

In [5]: print wx.__file__
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/__init__.pyc

In [6]: wxversion.
wxversion.UPDATE_URL        wxversion.__setattr__
wxversion.VersionError      wxversion.__str__
wxversion._EM_DEBUG         wxversion._find_default
wxversion.__builtins__      wxversion._find_installed
wxversion.__class__         wxversion._get_best_match
wxversion.__delattr__       wxversion._pattern
wxversion.__dict__          wxversion._selected
wxversion.__doc__           wxversion._wxPackageInfo
wxversion.__file__          wxversion.checkInstalled
wxversion.__getattribute__  wxversion.ensureMinimal
wxversion.__hash__          wxversion.fnmatch
wxversion.__init__          wxversion.getInstalled
wxversion.__name__          wxversion.glob
wxversion.__new__           wxversion.os
wxversion.__reduce__        wxversion.re
wxversion.__reduce_ex__     wxversion.select
wxversion.__repr__          wxversion.sys

In [6]: wxversion.getInstalled?
Type:		function
Base Class:	<type 'function'>
String Form:	<function getInstalled at 0xe62e30>
Namespace:	Interactive
File:		/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxversion.py
Definition:	wxversion.getInstalled()
Docstring:
    Returns a list of strings representing the installed wxPython
    versions that are found on the system.


In [7]: wxversion.getInstalled()
Out[7]: ['2.8-mac-unicode']

On Sat, Jul 11, 2009 at 12:38:13PM -0500, John Hunter wrote:
> If I can speak for the typical user, these kinds of warnings are
> usually annoying and not that helpful.  I am a naive wx user -- I
> installed it many moons ago from a binary when I installed python and
> haven't thought about it since.  I don't know what wxversion is or how
> to upgrade it.  All I know is mpl was working fine, still works fine,
> and now generates an annoying warning.   So I am not sure this is
> progress, but may help someone who has a complicated wx setup avoid
> difficult to trackdown bug.   So I would prefer to silence this, but
> am not sure what the right solution is. Here is my wx installation

I am a bit like you. I believe these warning are not terribly helpful.

Can you do an 'import wxversion; print wxversion.__file__', so that we
understand better why you are getting these warnings.

Cheers,

Gaël

On Fri, Jul 10, 2009 at 4:33 PM, Eric Firing<ef...@ha...> wrote:
> Gael Varoquaux wrote:
>> On Fri, Jul 10, 2009 at 11:05:24PM +0200, Gael Varoquaux wrote:
>>>> Committed to svn.  Please check it.
>>
>>> Certainly does work betters.
>>
>> Actually, I beg your pardon, but it does not really work: if you have
>> 2.6 and 2.8 installed, it will still import 2.6, which is not what you
>> want.
>>
>> Here is a patch that works a bit better: it does import 2.8 even when 2.6
>> is installed:
>
> Committed, thank you.

I just updated mpl from svn and now get

y:126: UserWarning: Update your wxversion.py to one including
AlreadyImportedError
  "Update your wxversion.py to one including AlreadyImportedError")
backend WXAgg version 2.8.3.0


If I can speak for the typical user, these kinds of warnings are
usually annoying and not that helpful.  I am a naive wx user -- I
installed it many moons ago from a binary when I installed python and
haven't thought about it since.  I don't know what wxversion is or how
to upgrade it.  All I know is mpl was working fine, still works fine,
and now generates an annoying warning.   So I am not sure this is
progress, but may help someone who has a complicated wx setup avoid
difficult to trackdown bug.   So I would prefer to silence this, but
am not sure what the right solution is. Here is my wx installation


In [6]: wx.__version__
Out[6]: '2.8.3.0'

In [7]: !ls -ld
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx*
drwxrwxr-x  5 root      admin    170 Mar 22  2007
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx-2.8-mac-unicode
-rw-r--r--  1 root      admin     18 Mar 22  2007
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx.pth
-rw-r--r--  1 root      admin   1266 Mar 22  2007
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxPython_common-2.8.3.0-py2.5.egg-info
drwxr-xr-x  5 root      admin    170 Mar 22  2007
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxaddons
-rw-r--r--  1 root      admin   1259 Mar 22  2007
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxaddons-2.8.3.0-py2.5.egg-info
-rw-r--r--  1 root      admin  17809 Mar 16  2006
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxversion.py
-rw-r--r--  1 jdhunter  admin  15750 Mar 23 20:28
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wxversion.pyc


JDH

The early registration deadline for SciPy 2009 has been extended
for one week to July 17, 2009.  Please register (
http://conference.scipy.org/to_register )
by this date to take advantage of the reduced early registration rate.

About the conference
--------------------

SciPy 2009, the 8th Python in Science conference, will be held from
August 18-23, 2009 at Caltech in Pasadena, CA, USA.  The conference
starts with two days of tutorials to the scientific Python tools.
There will be two tracks, one for introduction of the basic tools to
beginners, and one for more advanced tools.  The tutorials will be
followed by two days of talks.  Both days of talks will begin with a
keynote address.  The first day’s keynote will be given by Peter
Norvig, the Director of Research at Google; while, the second keynote
will be delivered by Jon Guyer, a Materials Scientist in the
Thermodynamics and Kinetics Group at NIST.  The program committee will
select the remaining talks from submissions to our call for papers.
All selected talks will be included in our conference proceedings
edited by the program committee.  After the talks each day we will
provide several rooms for impromptu birds of a feather discussions.
Finally, the last two days of the conference will be used for a number
of coding sprints on the major software projects in our community.

For the 8th consecutive year, the conference will bring together the
developers and users of the open source software stack for scientific
computing with Python.  Attendees have the opportunity to review the
available tools and how they apply to specific problems.  By providing
a forum for developers to share their Python expertise with the wider
commercial, academic, and research communities, this conference
fosters collaboration and facilitates the sharing of software
components, techniques, and a vision for high level language use in
scientific computing.

For further information, please visit the conference homepage:
http://conference.scipy.org.

Important Dates
---------------

* Friday, July 3: Abstracts Due
* Wednesday, July 15: Announce accepted talks, post schedule
* Friday, July 17: Early Registration ends
* Tuesday-Wednesday, August 18-19: Tutorials
* Thursday-Friday, August 20-21: Conference
* Saturday-Sunday, August 22-23: Sprints
* Friday, September 4: Papers for proceedings due

Executive Committee
-------------------

* Jarrod Millman, UC Berkeley, USA (Conference Chair)
* Gaël Varoquaux, INRIA Saclay, France (Program Co-Chair)
* Stéfan van der Walt, University of Stellenbosch, South Africa
(Program Co-Chair)
* Fernando Pérez, UC Berkeley, USA (Tutorial Chair)

Gael Varoquaux wrote:
> On Fri, Jul 10, 2009 at 11:05:24PM +0200, Gael Varoquaux wrote:
>>> Committed to svn.  Please check it.
> 
>> Certainly does work betters. 
> 
> Actually, I beg your pardon, but it does not really work: if you have
> 2.6 and 2.8 installed, it will still import 2.6, which is not what you
> want.
> 
> Here is a patch that works a bit better: it does import 2.8 even when 2.6
> is installed:

Committed, thank you.

Eric

> 
> Index: lib/matplotlib/backends/backend_wx.py
> ===================================================================
> --- lib/matplotlib/backends/backend_wx.py   (revision 7251)
> +++ lib/matplotlib/backends/backend_wx.py   (working copy)
> @@ -124,6 +124,12 @@
>  else:
>      warnings.warn(
>              "Update your wxversion.py to one including
> AlreadyImportedError")
> +    try:
> +        wxversion.ensureMinimal('2.8')
> +    except wxversion.VersionError:
> +        pass
> +    
> +    
>  
>  try:
>      import wx
> 
> Thanks for your work,
> 
> Gaël

On Fri, Jul 10, 2009 at 11:05:24PM +0200, Gael Varoquaux wrote:
> > Committed to svn.  Please check it.

> Certainly does work betters. 

Actually, I beg your pardon, but it does not really work: if you have
2.6 and 2.8 installed, it will still import 2.6, which is not what you
want.

Here is a patch that works a bit better: it does import 2.8 even when 2.6
is installed:

Index: lib/matplotlib/backends/backend_wx.py
===================================================================
--- lib/matplotlib/backends/backend_wx.py   (revision 7251)
+++ lib/matplotlib/backends/backend_wx.py   (working copy)
@@ -124,6 +124,12 @@
 else:
     warnings.warn(
             "Update your wxversion.py to one including
AlreadyImportedError")
+    try:
+        wxversion.ensureMinimal('2.8')
+    except wxversion.VersionError:
+        pass
+    
+    
 
 try:
     import wx

Thanks for your work,

Gaël

On Fri, Jul 10, 2009 at 09:41:30AM -1000, Eric Firing wrote:
>> OK, but right now MPL is broken with my version of wxversion, which is the
>> one shipped by default in Ubuntu. So it is broken for a lot of user.
>
> Are you sure?  Could you be pulling in some other wxversion?  The only  
> other person reporting this problem so far is Tony Yu. I am now on  
> jaunty, and my wxversion has AlreadyImportedError.  What version of  
> ubuntu are you using, and what is the full wx version that it includes?

Ha, interesting:

$ ipython   
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
Type "copyright", "credits" or "license" for more information.

IPython 0.10.bzr.r1163 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: import wxversion

In [2]: wxversion.__file__
Out[2]: '/usr/lib/python2.6/dist-packages/wx-2.6-gtk2-unicode/wxversion.pyc'

So, if wx2.6 is installed (I have 2.8 installed too), we run into these
problem.

Also, it is interesting to see that the older wxversion gets imported.
That does defeat the purpose of wxversion :). It means that you can't
have multiple versions of wx installed.

>> It seems wrong for me to require the users to upgrade wxversion while
>> there is a solution that works, eventhough it may not be exactly what you
>> want.
>
> The solution you propose doesn't work.  It completely defeats the  
> version check.

In a way it does. So we can add a check:

"if 'wx' in sys.module:"

to replace the "AlreadyImportedError", it is clearly bug ware.

>> One solution is to do bugware with hasattr(wxversion, 'AlreadyImportedError')
>
> Committed to svn.  Please check it.

Certainly does work betters. Also, the "AlreadyImported" problem is
caught elsewhere if I preimport an older version of wx:

File "/home/varoquau/dev/matplotlib/lib/pylab.py", line 1, in <module>
    from matplotlib.pylab import *
  File "/home/varoquau/dev/matplotlib/lib/matplotlib/pylab.py", line 244,
in <module>
    from matplotlib.pyplot import *
  File "/home/varoquau/dev/matplotlib/lib/matplotlib/pyplot.py", line 76,
in <module>
    new_figure_manager, draw_if_interactive, show = pylab_setup()
  File
"/home/varoquau/dev/matplotlib/lib/matplotlib/backends/__init__.py", line
25, in pylab_setup
    globals(),locals(),[backend_name])
  File
"/home/varoquau/dev/matplotlib/lib/matplotlib/backends/backend_wxagg.py",
line 23, in <module>
    import backend_wx    # already uses wxversion.ensureMinimal('2.8')
  File
"/home/varoquau/dev/matplotlib/lib/matplotlib/backends/backend_wx.py",
line 137, in <module>
    raise ImportError(missingwx)
ImportError: Matplotlib backend_wx and backend_wxagg require wxPython >=2.8

Thanks for your fix.

Gaël

Gael Varoquaux wrote:
> On Fri, Jul 10, 2009 at 08:12:14AM -1000, Eric Firing wrote:
>> Gael Varoquaux wrote:
>>> It seems that matplotlib needs the following patch for wxPython 2.8
>>> (traceback hard to replicate, as you need to import wx before importing
>>> matplotlib):
> 
>>> Index: lib/matplotlib/backends/backend_wx.py
>>> ===================================================================
>>> --- lib/matplotlib/backends/backend_wx.py   (revision 7250)
>>> +++ lib/matplotlib/backends/backend_wx.py   (working copy)
>>> @@ -117,7 +117,7 @@
>>>   try:
>>>      wxversion.ensureMinimal('2.8')
>>> -except wxversion.AlreadyImportedError:
>>> +except wxversion.VersionError:
>>>      pass
>>>   try:
>> No, that is not a good solution:
>> http://www.mail-archive.com/mat...@li.../msg05003.html
> 
> OK, but right now MPL is broken with my version of wxversion, which is the
> one shipped by default in Ubuntu. So it is broken for a lot of user.

Are you sure?  Could you be pulling in some other wxversion?  The only 
other person reporting this problem so far is Tony Yu. I am now on 
jaunty, and my wxversion has AlreadyImportedError.  What version of 
ubuntu are you using, and what is the full wx version that it includes?

> 
> It seems wrong for me to require the users to upgrade wxversion while
> there is a solution that works, eventhough it may not be exactly what you
> want.

The solution you propose doesn't work.  It completely defeats the 
version check.

> 
> One solution is to do bugware with hasattr(wxversion, 'AlreadyImportedError')

Committed to svn.  Please check it.


Eric

> 
> Gaël
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Gael Varoquaux wrote:
> It seems that matplotlib needs the following patch for wxPython 2.8
> (traceback hard to replicate, as you need to import wx before importing
> matplotlib):
> 
> Index: lib/matplotlib/backends/backend_wx.py
> ===================================================================
> --- lib/matplotlib/backends/backend_wx.py   (revision 7250)
> +++ lib/matplotlib/backends/backend_wx.py   (working copy)
> @@ -117,7 +117,7 @@
>  
>  try:
>      wxversion.ensureMinimal('2.8')
> -except wxversion.AlreadyImportedError:
> +except wxversion.VersionError:
>      pass
>  
>  try:

No, that is not a good solution:
http://www.mail-archive.com/mat...@li.../msg05003.html

Eric

> 
> And, by the way, I just had a brain fart, and sent a stupid e-mail on the
> same subject. I am not sure where it went, but please disregard it.
> 
> Cheers;
> 
> Gaël
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Jul 10, 2009 at 08:12:14AM -1000, Eric Firing wrote:
> Gael Varoquaux wrote:
>> It seems that matplotlib needs the following patch for wxPython 2.8
>> (traceback hard to replicate, as you need to import wx before importing
>> matplotlib):

>> Index: lib/matplotlib/backends/backend_wx.py
>> ===================================================================
>> --- lib/matplotlib/backends/backend_wx.py   (revision 7250)
>> +++ lib/matplotlib/backends/backend_wx.py   (working copy)
>> @@ -117,7 +117,7 @@
>>   try:
>>      wxversion.ensureMinimal('2.8')
>> -except wxversion.AlreadyImportedError:
>> +except wxversion.VersionError:
>>      pass
>>   try:
>
> No, that is not a good solution:
> http://www.mail-archive.com/mat...@li.../msg05003.html

OK, but right now MPL is broken with my version of wxversion, which is the
one shipped by default in Ubuntu. So it is broken for a lot of user.

It seems wrong for me to require the users to upgrade wxversion while
there is a solution that works, eventhough it may not be exactly what you
want.

One solution is to do bugware with hasattr(wxversion, 'AlreadyImportedError')

Gaël

On 2009-07-09 23:19, Andrew Straw wrote:
> Erik Tollerud wrote:

>> 2. Installation of traits or traitsgui should not be a necessity for
>> MPL... perhaps this will change in the future, but it's currently a
>> far bigger task to get traits and traits UI working on an arbitrary
>> system than it is to get MPL up and running (at least, that's been my
>> experience in a number of different settings).
>>
> Well, I don't think we need traits UI, and I don't imagine traits itself
> is hard to build, although I could be wrong (I always use the
> Ubuntu/Debian packages).

Traits itself is pretty trivial. There is one C extension that has no library 
dependencies like libfreetype.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

It seems that matplotlib needs the following patch for wxPython 2.8
(traceback hard to replicate, as you need to import wx before importing
matplotlib):

Index: lib/matplotlib/backends/backend_wx.py
===================================================================
--- lib/matplotlib/backends/backend_wx.py   (revision 7250)
+++ lib/matplotlib/backends/backend_wx.py   (working copy)
@@ -117,7 +117,7 @@
 
 try:
     wxversion.ensureMinimal('2.8')
-except wxversion.AlreadyImportedError:
+except wxversion.VersionError:
     pass
 
 try:

And, by the way, I just had a brain fart, and sent a stupid e-mail on the
same subject. I am not sure where it went, but please disregard it.

Cheers;

Gaël

It seems that the following fix is necessary for matplolitb to work
wxPython 2.8.

Index: lib/matplotlib/backends/backend_wx.py
===================================================================
--- lib/matplotlib/backends/backend_wx.py   (revision 7250)
+++ lib/matplotlib/backends/backend_wx.py   (working copy)
@@ -117,7 +117,7 @@
 
 try:
     wxversion.ensureMinimal('2.8')
-except wxversion.AlreadyImportedError:
+except wxversion.VersionError()
     pass

Cheers,

Gaël

Erik Tollerud wrote:
> Personally, I think traits must be kept out of MPL, for three main reasons:
>   
As these comments are in respose to my email, let me again state the 
main point of my email:

My main feeling about MPL is that there's just too much layout happening to keep using the non-systematic delegation/notification "system" currently in place while allowing the devs to maintain their sanity and day jobs. [...]  Therefore, I'd suggest that before adding on too many more nice features, we revisit the core layout and delegation system -- in the end it will make everything much easier. So, perhaps a useful thing would be for as many MPL devs as possible to sit together and discuss how we could do this.

Thus, I was suggesting traits as a means to an end (a saner core), and not something for its own sake.

> 1. As Eric Bruning points out, while traits is a very powerful tool,
> it also closes a lot of doors by forcing everything to be written in a
> trait-like fashion for it to play nice with everything else.  While
> this is great for many applications, I think it does not necessarily
> belong everywhere, particularly given a tendancy to quickly snowball
> in complexity (not to mention any new people that want to contribute
> code have an extra thick manual to read).
>   
I wasn't proposing to touch the user API for MPL. I think we'd be silly 
to do that.
> 2. Installation of traits or traitsgui should not be a necessity for
> MPL... perhaps this will change in the future, but it's currently a
> far bigger task to get traits and traits UI working on an arbitrary
> system than it is to get MPL up and running (at least, that's been my
> experience in a number of different settings).
>   
Well, I don't think we need traits UI, and I don't imagine traits itself 
is hard to build, although I could be wrong (I always use the 
Ubuntu/Debian packages).
> 3. Chaco - my general mindset on this is that Chaco is great for
> plotting any and everything in a traits gui, but MPL is much better
> for the quickcalculations and plots that I make every day as a
> scientist.  When a critical mass is reached it becomes better to
> integrate a tool into a GUI app, MPL becomes more difficult to manage
> and chaco is a better tool.  But I think it makes a lot of sense to
> leverage MPL most as the wonderful "quick-and-dirty" command-line
> interactive plotting environment that it is rather than making it
> application-centric, which is where I can envision it going as soon as
> it has to run with traits.
>
> Now a great idea would be to include optional support for things like
> setting configuration files from a traits interface - I know I've seen
> talk of doing this for matplotlibrc at some point, and I'd definitely
> use that.  Simlarly, some sort of traits-level extension to support
> more interactive plots and better layout seems like it could be done
> without requiring the core to use traits.
>   
OK, but these don't address my main concern that the core layout of MPL 
is an unwieldy beast.

Anyhow, as I'm way too busy to think about any real coding on MPL's core 
right now, this is just cheap talk...

-Andrew

Personally, I think traits must be kept out of MPL, for three main reasons:

1. As Eric Bruning points out, while traits is a very powerful tool,
it also closes a lot of doors by forcing everything to be written in a
trait-like fashion for it to play nice with everything else.  While
this is great for many applications, I think it does not necessarily
belong everywhere, particularly given a tendancy to quickly snowball
in complexity (not to mention any new people that want to contribute
code have an extra thick manual to read).

2. Installation of traits or traitsgui should not be a necessity for
MPL... perhaps this will change in the future, but it's currently a
far bigger task to get traits and traits UI working on an arbitrary
system than it is to get MPL up and running (at least, that's been my
experience in a number of different settings).

3. Chaco - my general mindset on this is that Chaco is great for
plotting any and everything in a traits gui, but MPL is much better
for the quickcalculations and plots that I make every day as a
scientist.  When a critical mass is reached it becomes better to
integrate a tool into a GUI app, MPL becomes more difficult to manage
and chaco is a better tool.  But I think it makes a lot of sense to
leverage MPL most as the wonderful "quick-and-dirty" command-line
interactive plotting environment that it is rather than making it
application-centric, which is where I can envision it going as soon as
it has to run with traits.

Now a great idea would be to include optional support for things like
setting configuration files from a traits interface - I know I've seen
talk of doing this for matplotlibrc at some point, and I'd definitely
use that.  Simlarly, some sort of traits-level extension to support
more interactive plots and better layout seems like it could be done
without requiring the core to use traits.


As for the question of new directions to go: One thing I would like to
see is a decent, simple 3D package in the core - nothing fancy (mayavi
is great if you want to get fancy), but just something that makes
great publication-quality figures with a quick and simple pylab-like
interface.  That's the main thing I have no good response for when
people are contemplating switching to python/numpy/MPL.  I also think
it might be neat to implement auto-generating function plots - that
is, plots where one of the axes is generated by a function at a
resolution that scales as you change the plot.  I've seen some chaco
demos of something like this, but it's rather complicated to implement
- a function like pyplot.plotfunc(func,'--b',initialrange=(-1,1)) that
does exactly this would be a wonderful capability.


This may be more a user perspective than a "dev" perspective, but
still, there it is.


On Thu, Jul 2, 2009 at 10:45 AM, Eric Bruning<eri...@gm...> wrote:
> On Wed, Jul 1, 2009 at 9:51 PM, Andrew Straw<str...@as...> wrote:
>> Gael Varoquaux wrote:
>>> On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote:
>>>
>>>> Anyone interested?  And if so, feel free to suggest topics or weigh in
>>>> on some I listed.
>>>>
>>>
>>> Actually, I have something I would like to discuss, but never really
>>> could pull myself together to do it. I don't have time right now, but I
>>> am still going to jot down the ideas.
>>>
>>> The axes and figure paradigm inherited from matlab works well for simple
>>> things, but when I want to more complex layouts, I actually end up
>>> struggling with calls to axes with numerical parameters to adjust. In
>>> addition, if I have a function that creates a plot with multiple axes,
>>> like the figure on:
>>> http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html
>>> I may want to reuse that function to create more complex figures,
>>> stacking several of these views, with possibly other plots.
>>>
>>> It seems to me having a level of granularity between the figure, and the
>>> axes would help me a lot achieving these goals. I haven't had time to
>>> hash out an API, or even solid concepts. For people who know LaTeX well,
>>> let me draw an analogy: the figure is the page, the axis is the
>>> character, what we are lacking in a 'minipage'. I would like a container
>>> that can be stacked into a figure, and that can either hold axes, or
>>> similar containers. That way, I could specify subplot, or axis relative
>>> to this container, rather than relative to the whole figure, and it makes
>>> it really easy for me to insert figures in larger figures.
>>>
>>> One possible API would be 'subfigure', which would have a signature
>>> similar to 'axes', but of course things would need to be thought a bit
>>> more in detail: do we want clf to erase the figure and not the subfigure?
>>> I believe so. Do we want subplot to divide the subfigure, rather than the
>>> figure? I believe so too. How do we go back to full figure without
>>> erasing the subfigures it contains? I think subfigure(None) might work.
>>> How do I select a subfigure I already created? Maybe by passing it a
>>> subfigure instance, like the way axes work.
>>>
>>> Also, Chaco has the notion of containers, in which you can stack plots or
>>> other containers. They have an additional feature which is that they
>>> enable you to stack plot (these would be axes, in matplotlib terms) and
>>> do an automatic layout of the plots. Very handy to have an extensible
>>> canvas to display information on. Some sparse documentation:
>>> http://code.enthought.com/projects/chaco/docs/html/api/containers.html
>>>
>>> I have been trying to find time to think about this for more than a year,
>>> and haven't. This is why I am sending unfinished thoughts. I do believe
>>> more thinking has to be done, and the subfigure proposition may not hold
>>> at all. Also, I fear I do not have time to implement this.
>>>
>> I also have some not very fleshed out thoughts: my main feeling about
>> MPL is that there's just too much layout happening to keep using the
>> non-systematic delegation/notification "system" currently in place while
>> allowing the devs to maintain their sanity and day jobs. I don't mean to
>> disparage MPL -- it is quite a fantastic piece of code -- but there is a
>> lack of abstraction of layout hierarchies and layout dependencies that
>> makes development difficult.
>>
>> Therefore, I'd suggest that before adding on too many more nice
>> features, we revisit the core layout and delegation system -- in the end
>> it will make everything much easier. So, perhaps a useful thing would be
>> for as many MPL devs as possible to sit together and discuss how we
>> could do this. My thought right now would be to investigate the use of
>> traits to codify the layout abstractions.
>>
>> Any effort like this will also obviously benefit from having an
>> extensive test suite. I think all that's needed to get the tests at
>> http://mpl-buildbot.code.astraw.com/waterfall to pass is that someone
>> checks in new images made with the current MPL. I'd like to do this, but
>> I'm really short on time at the moment. So, please, someone -- beat me
>> to it -- it won't be hard!
>>
>> Those are my 2 cents. Hope to see you all at SciPy 2009!
>>
>> -Andrew
>
>
> While we're dreaming big re-architecting dreams, I'll throw out an
> idea related to Gael's suggestion: artist containers at the sub-axis
> level.  This would be a drawable / hideable container for an arbitrary
> grouping of Artists that could be directly added to one (or more)
> Axes. For those familiar with IDL, the IDLgrContainer in their object
> graphics system is what I have in mind.
>
> I also concur with Andrew's assessment that interactive and layout
> event handling is holding back some extra fun in interactive apps. I
> have mixed feelings about using Traits; in my experience with writing
> (only one) app, I felt like I had to subsume everything, my data
> modeling included, under the Traits paradigm, such that I was no
> longer writing Python but Traits. I found it very hard to include
> other data objects created by other libraries without making them
> Traitified, too. This could be a knowledge gap on my part, of course.
>
> David Beazley's course on coroutines
> (http://www.dabeaz.com/coroutines/index.html, see esp. Part 3) and
> this talk (http://carlfk.blip.tv/file/2232349) on asynchronous vs.
> threaded multitasking both have some interesting thoughts on
> standard-library ways to model OS-like behaviors such as event
> handling.
>
> Thanks,
> Eric
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Can you provide the compiler output you were seeing?  Which version of 
matplotlib are you using?

I've been using the SVN trunk on F11 for weeks with no issues, so I just 
want to verify the problem and solution are the correct ones here.

Cheers,
Mike

Andrei Smirnov wrote:
> A possible bug:
>
> I just tried to build matplotlib on Fedora 11 with:
>
> python setup.py build
>
> and it aborted with unresolved referecne to vsprintf
>
> I fixed the problem by including:
>
> #include <stdio.h>
>
> into
>
> src/mplutils.cpp
>
> -- 
> Andrei V. Smirnov, PhD.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

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

A possible bug:

I just tried to build matplotlib on Fedora 11 with:

python setup.py build

and it aborted with unresolved referecne to vsprintf

I fixed the problem by including:

#include <stdio.h>

into

src/mplutils.cpp

-- 
Andrei V. Smirnov, PhD.