matplotlib-devel Mailing List for matplotlib

Michael Fitzgerald wrote:
> Hi all,
> 
> I found a small bug, where Figure.clf() was erroneously leaving some axes 
> instances in the Figure.axes list. It turns out the method was deleting 
> items from the list while iterating over it. Attached is a patch.
> 
> Mike
> 
Mike,
Thanks for finding that rather subtle bug. I committed an equivalent 
change; I used tuple(self.axes) instead of copy.copy(self.axes) because 
for this purpose it accomplishes the same thing, but faster, and without 
the extra import.
Eric
> 
> 
> ------------------------------------------------------------------------
> 
> Index: figure.py
> ===================================================================
> --- figure.py	(revision 3198)
> +++ figure.py	(working copy)
> @@ -1,7 +1,7 @@
> """
> Figure class -- add docstring here!
> """
> -import sys
> +import sys, copy
> import artist
> from artist import Artist
> from axes import Axes, Subplot, PolarSubplot, PolarAxes
> @@ -515,7 +515,7 @@
> """
> Clear the figure
> """
> - for ax in self.axes:
> + for ax in copy.copy(self.axes):
> ax.cla()
> self.delaxes(ax)
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,
I found a small bug, where Figure.clf() was erroneously leaving some axes 
instances in the Figure.axes list. It turns out the method was deleting 
items from the list while iterating over it. Attached is a patch.
Mike

I'd personally be happy to move on to wxPython 2.8 but I'm using
enthought's matplotlib egg, which apparently requires enthought's
wxPython egg, and that's still at version 2.6.
--bb
On 4/12/07, Christopher Barker <Chr...@no...> wrote:
> Hi all,
>
> The world of wxAgg and versions of wxPython has been a big pain for a
> while. I've been poking around trying to get MPL working with wxPython
> on OS-X with wxPython2.8, and it's been far too much work.
>
> However, Ken McIvor has apparently solved the problem. Unfortunately, he
> committed the changes on Feb 22, and it looks like the 0.90.0 release
> was done on Feb 6. Darn.
>
> My understanding of the changes is:
>
> There is now code in backend_wxagg.py that uses methods to create and
> manipulate wx.Bitmaps that is new to wxPython2.8. This should make the
> old accelerator code obsolete.
>
> At runtime, the code determines if you are running >2.8, and if so, uses
> the new code. If not, it reverts to the old code, which checks for the
> accelerator, uses it if it's there, and uses the pure-python
> non-accelerated code if not.
>
> So -- this should allow one to build a single executable that will work
> well with wxPython 2.6, 2.8 and future wxPythons.
>
> Personally, I think we should just drop the accelerator altogether. If
> someone needs better performance, let them use wxPython2.8 ( I think
> there is some room for improvement in the pre-2.8 python code too -- you
> could build the wxImage from a buffer, rather than a string, saving one
> data copy).
>
> If the accelerator is dropped, then the whole build process gets easier.
>
> If people want to keep the accelerator, I wrote some code for
> setup_ext.py that checks what version of wx you have installed, and
> finds the wx-config that matches it. It could be adapted a bit to try to
> build only a wxPython2.6 version, and not try to build a 2.8 version,
> which fails at this point.
>
> So, with a bit more testing and tweaking, we could get this all settled.
>
> What's the consensus on keeping the accelerator?
>
> Is it worth putting out a point release with these fixes?
>
>
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,
The world of wxAgg and versions of wxPython has been a big pain for a 
while. I've been poking around trying to get MPL working with wxPython 
on OS-X with wxPython2.8, and it's been far too much work.
However, Ken McIvor has apparently solved the problem. Unfortunately, he 
committed the changes on Feb 22, and it looks like the 0.90.0 release 
was done on Feb 6. Darn.
My understanding of the changes is:
There is now code in backend_wxagg.py that uses methods to create and 
manipulate wx.Bitmaps that is new to wxPython2.8. This should make the 
old accelerator code obsolete.
At runtime, the code determines if you are running >2.8, and if so, uses 
the new code. If not, it reverts to the old code, which checks for the 
accelerator, uses it if it's there, and uses the pure-python 
non-accelerated code if not.
So -- this should allow one to build a single executable that will work 
well with wxPython 2.6, 2.8 and future wxPythons.
Personally, I think we should just drop the accelerator altogether. If 
someone needs better performance, let them use wxPython2.8 ( I think 
there is some room for improvement in the pre-2.8 python code too -- you 
could build the wxImage from a buffer, rather than a string, saving one 
data copy).
If the accelerator is dropped, then the whole build process gets easier.
If people want to keep the accelerator, I wrote some code for 
setup_ext.py that checks what version of wx you have installed, and 
finds the wx-config that matches it. It could be adapted a bit to try to 
build only a wxPython2.6 version, and not try to build a 2.8 version, 
which fails at this point.
So, with a bit more testing and tweaking, we could get this all settled.
What's the consensus on keeping the accelerator?
Is it worth putting out a point release with these fixes?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...