matplotlib-devel Mailing List for matplotlib

On Mon, Nov 9, 2009 at 3:55 PM, Andrew Straw <str...@as...> wrote:
> What's the motivation of the ps backend "compositing" (rasterizing to a
> single bitmap) multiple images? It seems it will, by design, preclude the
> use of non-image artists between two images. I guess the motivation is to
> reduce output file size. Maybe Axes.draw() should disable compositing in the
> scenario where a non-image artist is sandwiched by image artists and suffer
> the increased file size.
>
I can't say about what the original intention was, but I guess one of
the benefit is that you can have alpha compositing of multiple images.
I personally think that no alpha support for images is a more serious
issue than no alpha support for other artists like lines and patches.
So, I'm +1 for doing the alpha compositing of images before passing it
to the backends (that do not support the alpha compositing).
However, as I said in my first email, I don't think there are much
cases that this actually matters,
while I'm also not sure about the benefit of having images above other
artists like lines.
Anyhow, as far as zorders between images are respected (in all
backends!), it should be good.
Regards,
-JJ

On Mon, Nov 9, 2009 at 3:08 PM, Leonid Petrov <ma...@lp...> wrote:
> Hi, John,
>
> I got mpl from
>
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1.tar.gz/download
>
> /d1/incoming> md5sum matplotlib-0.99.1.1.tar.gz
> bd0894dd924eb5bec84c42d26041a544 matplotlib-0.99.1.1.tar.gz
>
> I removed source code of matplotlib-0.99.1.1 from my previous attempt to
> install it and did it again.
>
> cd /d1/dist
> tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz
> cd matplotlib-0.99.1.1/
> python setup.py install --prefix=/opt64 > & matplotlib-0.99.1.1_comp.log
>
> gzip matplotlib-0.99.1.1_comp.log
> cp matplotlib-0.99.1.1_comp.log.gz     /pub/
> cp setup.cfg                /pub/matplotlib-0.99.1.1_comp.log.gz
> cp /d1/incoming/matplotlib-0.99.1.1.tar.gz /pub/
>
> You can get them from
>
> ftp://71.178.13.84/matplotlib-0.99.1.1_comp.log
> ftp://71.178.13.84/matplotlib-0.99.1.1.tar.gz
> ftp://71.178.13.84/matplotlib-0.99.1.1_setup.cfg
>
> But stop, stop, stop... I looked at setup.cfg and found there at line 58
> macosx = True
Glad you found the fix -- I'm just uploaded a new tarball now with the
setup.cfg removed.
JDH

Hi, John,
 I got mpl from 
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1.tar.gz/download
/d1/incoming> md5sum matplotlib-0.99.1.1.tar.gz
bd0894dd924eb5bec84c42d26041a544 matplotlib-0.99.1.1.tar.gz
I removed source code of matplotlib-0.99.1.1 from my previous attempt to
install it and did it again.
cd /d1/dist
tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz
cd matplotlib-0.99.1.1/
python setup.py install --prefix=/opt64 > & matplotlib-0.99.1.1_comp.log
gzip matplotlib-0.99.1.1_comp.log 
cp matplotlib-0.99.1.1_comp.log.gz /pub/
cp setup.cfg /pub/matplotlib-0.99.1.1_comp.log.gz 
cp /d1/incoming/matplotlib-0.99.1.1.tar.gz /pub/
You can get them from
ftp://71.178.13.84/matplotlib-0.99.1.1_comp.log
ftp://71.178.13.84/matplotlib-0.99.1.1.tar.gz
ftp://71.178.13.84/matplotlib-0.99.1.1_setup.cfg
But stop, stop, stop... I looked at setup.cfg and found there at line 58
macosx = True
One more attempt:
cd /d1/dist
rm -fR matplotlib-0.99.1.1
tar -zxf /d1/incoming/matplotlib-0.99.1.1.tar.gz
cd matplotlib-0.99.1.1/
sed -i 's@macosx = True@macosx = False@g' setup.cfg
python setup.py install --prefix=/opt64 > & matplotlib-0.99.1.1_comp.log
echo $?
0
tail -2 matplotlib-0.99.1.1_comp.log
Removing /opt64/lib/python2.6/site-packages/matplotlib-0.99.1.1-py2.6.egg-info
Writing /opt64/lib/python2.6/site-packages/matplotlib-0.99.1.1-py2.6.egg-info
Success!!
Thank you for a quick reply and suggestion to look at setup.cfg .
Leonid

Jae-Joon Lee wrote:
> On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing <ef...@ha...> wrote:
> 
>> PS backend already does things differently from others because it doesn't
>> handle alpha, correct? Does the patch make this situation any worse?
>>
>> 
>
> When there are multiple Images and render.option_image_nocomposite()
> is false (as in the ps backend ), the images are composited
> (rasterized) into a single image before it is passed to the backend.
> So, AS FAR AS the images are concerned, I think the ps backend does
> handle alpha correctly and the results are consistent between
> backends.
>
> And with the Andrew's patch, and if there are non-image artists
> between two images, the results can be different. For example, those
> non-image artists can be obscured by the foreground image in the agg
> backend, but will always show up in the ps backend.
> So, I think this is somewhat different issue than alpha being ignored
> in the ps backend.
> 
What's the motivation of the ps backend "compositing" (rasterizing to a 
single bitmap) multiple images? It seems it will, by design, preclude 
the use of non-image artists between two images. I guess the motivation 
is to reduce output file size. Maybe Axes.draw() should disable 
compositing in the scenario where a non-image artist is sandwiched by 
image artists and suffer the increased file size.
-Andrew

Darren,
Have you happened to review Pierre's patch for the toolbar
improvement? I am interested to see this integrated in mpl soon.
Thanks.
On Mon, Nov 9, 2009 at 2:43 PM, Pierre Raybaut <co...@py...> wrote:
> Hi,
>
> I've already sent everything to Darren. I don't have any news but I
> guess that it will be integrated soon.
>
> Pierre
>
> 2009年11月9日 Gökhan Sever <gok...@gm...>:
>> Hi Pierre,
>>
>> What is the latest status on this improvement? Will you give a patch
>> to the matplotlib?
>>
>> Please let me know.
>>
>> Thanks
>>
>> On Sat, Jun 6, 2009 at 9:49 AM, Pierre Raybaut <co...@py...> wrote:
>>> 2009年4月28日 Dave Peterson <dpe...@en...>:
>>>> Darren Dale wrote:
>>>>
>>>> On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <co...@py...>
>>>> wrote:
>>>>>
>>>>> 2009年4月28日 John Hunter <jd...@gm...>:
>>>>> >
>>>>> >
>>>>> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...>
>>>>> > wrote:
>>>>> >>
>>>>> >> Hi all,
>>>>> >>
>>>>> >> I would like to contribute to matplotlib with this enhancement for the
>>>>> >> PyQt4 backend: the idea is to add a toolbar button to configure figure
>>>>> >> options (axes, curves, ...).
>>>>> >>
>>>>> >> It's based on a tiny module called formlayout to generate PyQt4 form
>>>>> >> dialog automatically.
>>>>> >>
>>>>> >> Some screenshots:
>>>>> >> http://code.google.com/p/formlayout/
>>>>> >>
>>>>> >> So, if you're interested (all the following is GPL2):
>>>>> >>
>>>>> >> *matplotlib patch*
>>>>> >>
>>>>> >> In FigureManagerQT.__init__, added:
>>>>> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
>>>>> >>
>>>>> >> In NavigationToolbar2QT._init_toolbar, added:
>>>>> >> a = self.addAction(self._icon("customize.png"), 'Customize',
>>>>> >> self.edit_parameters)
>>>>> >> a.setToolTip('Edit curves line and axes parameters')
>>>>> >>
>>>>> >> Added the following method in NavigationToolbar2QT:
>>>>> >> def edit_parameters(self):
>>>>> >>  from figureoptions import figure_edit
>>>>> >>  figure_edit(self.canvas, self)
>>>>> >>
>>>>> >> *additionnal modules and data*
>>>>> >>
>>>>> >> formlayout.py (http://code.google.com/p/formlayout/)
>>>>> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
>>>>> >> customize.png (http://code.google.com/p/PyQtShell/)
>>>>> >
>>>>> > Hi Pierre -- this looks very nice (the last link is broken though , I
>>>>> > get a
>>>>> > 404 error). We would be happy to include this in matplotlib or as a
>>>>>
>>>>> Here is the last link:
>>>>> http://code.google.com/p/pyqtshell/
>>>>>
>>>>> > toolkit. To contribute it to to mpl, the license needs to be
>>>>> > matplotlib
>>>>> > compatible
>>>>> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but
>>>>> > we
>>>>> > have more licensing flexibility in a toolkit, though we prefer to keep
>>>>> > everything BSD compatible where possible.  And of course you would need
>>>>> > to
>>>>> > agree to maintain it :-) but I think many users would appreciate a GUI
>>>>> > plot
>>>>> > configuration dialog.
>>>>>
>>>>> I was not aware of this license restriction in matplotlib... I fully
>>>>> understand the motivation, of course, but still: I wrote all this on
>>>>> my free time which means no PyQt4 commercial license, so it can't be
>>>>> anything but GPL. Sorry...
>>>>
>>>> I think you have overlooked a subtlety of PyQt4's license. The author of
>>>> PyQt4 wrote on the enthought-dev mailing list:
>>>>
>>>> "PyQt is GPL but has exceptions that allow it to be used with BSD code -
>>>> hence it's Ok for TraitsBackendQt to be BSD.
>>>>
>>>> However, the exception imposes additional conditions which, to all intents
>>>> and purposes, infects the code with the GPL. To be fair to people that
>>>> should be made clear in any text.
>>>>
>>>> It's still a good idea for TraitsBackendQt to use a BSD license because it
>>>> allows commercial (ie. non-GPL) users to use it without problems."
>>>>
>>>> Darren
>>>>
>>>> I think it might be worth contacting the PyQt folks (Phil Thompson) about
>>>> this. I think there might be some differences here because Phil was the
>>>> author of TraitsBackendQt and thus his efforts didn't quite fall under the
>>>> "develop under a free license, your results needs to be GPL" clause Qt/PyQt
>>>> have in their licensing.
>>>>
>>>> -- Dave
>>>>
>>>>
>>>
>>> Hi all,
>>>
>>> Dave, you are absolutely right.
>>>
>>> Last week-end, I found myself surfing on PyQt's website and I told to
>>> myself: what about re-reading the license? (always a pleasure) And
>>> surprisingly, I found out that anyone using the GPL version of PyQt
>>> can release source code under a very permissive license (like MIT or
>>> BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
>>> part of the distributed package (otherwise the whole package has to be
>>> licensed under GPL) - and with other little restrictions. It was a
>>> surprise because I've read here and there a lot of things on PyQt
>>> license and the general idea was "if you write PyQt code without the
>>> commercial license, your code *must* be licensed under GPL" - I can
>>> tell now that it's not true (to be absolutely certain about it, I even
>>> asked to Phil Thompson to confirm this, and he did).
>>>
>>> So, I switched all the code I was referring to in my original e-mail
>>> to MIT license.
>>> I guess now it could be integrated to matplotlib Qt4 backend?
>>>
>>> formlayout (generate option dialogs):
>>> http://code.google.com/p/formlayout/
>>>
>>> pydee (IDE which integrates matplotlib and the option dialog):
>>> http://code.google.com/p/pydee/
>>> Meanwhile, thanks to the brand new Google-code Mercurial support, you
>>> may browse the source code if you like:
>>> http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
>>>
>>> Cheers,
>>> Pierre
>>>
>>> ------------------------------------------------------------------------------
>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>> looking to deploy the next generation of Solaris that includes the latest
>>> innovations from Sun and the OpenSource community. Download a copy and
>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>>
>> --
>> Gökhan
>>
>
-- 
Gökhan

On Mon, Nov 9, 2009 at 1:29 PM, Leonid Petrov <ma...@lp...> wrote:
> Hi, matplotlibers,
>
> I tried to compile matplotlib0.99.1.1 against Python-2.6.4, numpy-1.3.0,
> libpng-1.2.40, freetype-2.3.11 with the following command:
> python setup.py install --prefix=/opt64 > & comp.log
>
> I got
>
> building 'matplotlib.backends._macosx' extension
> /opt64/bin/gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt64/include -I/opt64/include/wx-2.8 -I/opt64/lib/wx/include/gtk2-ansi-release-2.8 -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/opt64/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/opt64/lib/python2.6/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/opt64/include/python2.6 -c src/_macosx.m -o build/temp.linux-x86_64-2.6/src/_macosx.o
> src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory
> src/_macosx.m:2:53: error: ApplicationServices/ApplicationServices.h: No such file or directory
> src/_macosx.m:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'style'
>
>
> I checked, I have neither Cocoa.h , nor ApplicationServices.h in my system
> ( Linux 2.6.28-16-generic #55-Ubuntu SMP ). I have no idea to which
> package headers Cocoa.h and ApplicationServices.h belong.
>
> Which additional source packages, not mentioned in
> http://matplotlib.sourceforge.net/users/installing.html, should I download
> and compile in order to build matplotli
For some reason mpl is trying to build the macosx backend (for OSX)
even though you are on linux. Please do a clean build (rm -rf build)
and capture all stdout and stderr into a file when rebuilding and post
it. Also see if you have a setup.cfg file in your mpl dir next to
setup.py and post it.
Finally, where did you get the mpl src from?
JDH

Hi, matplotlibers,
 I tried to compile matplotlib0.99.1.1 against Python-2.6.4, numpy-1.3.0,
libpng-1.2.40, freetype-2.3.11 with the following command:
python setup.py install --prefix=/opt64 > & comp.log
 I got 
building 'matplotlib.backends._macosx' extension
/opt64/bin/gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt64/include -I/opt64/include/wx-2.8 -I/opt64/lib/wx/include/gtk2-ansi-release-2.8 -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/opt64/lib/python2.6/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/opt64/lib/python2.6/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/opt64/include/python2.6 -c src/_macosx.m -o build/temp.linux-x86_64-2.6/src/_macosx.o
src/_macosx.m:1:25: error: Cocoa/Cocoa.h: No such file or directory
src/_macosx.m:2:53: error: ApplicationServices/ApplicationServices.h: No such file or directory
src/_macosx.m:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'style'
 I checked, I have neither Cocoa.h , nor ApplicationServices.h in my system 
( Linux 2.6.28-16-generic #55-Ubuntu SMP ). I have no idea to which 
package headers Cocoa.h and ApplicationServices.h belong. 
 Which additional source packages, not mentioned in 
http://matplotlib.sourceforge.net/users/installing.html, should I download 
and compile in order to build matplotlib?
Thank you in advance,
Leonid

On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing <ef...@ha...> wrote:
> PS backend already does things differently from others because it doesn't
> handle alpha, correct? Does the patch make this situation any worse?
>
When there are multiple Images and render.option_image_nocomposite()
is false (as in the ps backend ), the images are composited
(rasterized) into a single image before it is passed to the backend.
So, AS FAR AS the images are concerned, I think the ps backend does
handle alpha correctly and the results are consistent between
backends.
And with the Andrew's patch, and if there are non-image artists
between two images, the results can be different. For example, those
non-image artists can be obscured by the foreground image in the agg
backend, but will always show up in the ps backend.
So, I think this is somewhat different issue than alpha being ignored
in the ps backend.
Regards,
-JJ

On Mon, Nov 9, 2009 at 12:16 PM, Andrew Straw <str...@as...> wrote:
> So now the question for me is what is this option_image_nocomposite is so
> that I can generalize the patch to both when it's True and False. From the
The compositing is in support of things like
pylab_examples/layer_images.py, where two images, possibly of
different sizes, are composited together

On Mon, Nov 9, 2009 at 12:12 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Mon, Nov 9, 2009 at 1:01 PM, John Hunter <jd...@gm...> wrote:
>> Your
>> patch is only applied when len(images)<=1 or
>> renderer.option_image_nocomposite(), both of which will be False when
>> using Agg with multiple images, no?
>
> I believe renderer.option_image_nocomposite() is True for the agg backend.
> So, it will work with agg.
Ahh, you're right. Thanks.
JDH

John Hunter wrote:
> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
> 
>> Hi All,
>>
>> I have addressed what I think is a long-standing wart: zorder is mostly
>> ignored for imshow(). (See e.g.
>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>> ) The question is whether I should apply the attached patch.
>> 
>
> Will this help with the OP's original "wart", which was the inability
> to add multiple images and move one to the top with zorder. Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?
> 
OK, sorry I linked to a motivating example that actually wasn't exactly 
the same as the use case I have -- I want a single image to play well 
with other artists' zorder. This patch does handle that scenario. I 
simply was too quick choosing this example out of the email history to 
justify the patch.
So now the question for me is what is this option_image_nocomposite is 
so that I can generalize the patch to both when it's True and False. 
 From the emails here, (my only knowledge on it so far) it seems it has 
something to do with the capabilities of the renderer rather than a 
run-time option selected by the user. I'll dig a little deeper into this 
option and see if my patch can deal with other cases, too. Stay tuned...
-Andrew

On Mon, Nov 9, 2009 at 1:01 PM, John Hunter <jd...@gm...> wrote:
> Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?
I believe renderer.option_image_nocomposite() is True for the agg backend.
So, it will work with agg.
-JJ

On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly
> ignored for imshow(). (See e.g.
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
> ) The question is whether I should apply the attached patch.
Will this help with the OP's original "wart", which was the inability
to add multiple images and move one to the top with zorder. Your
patch is only applied when len(images)<=1 or
renderer.option_image_nocomposite(), both of which will be False when
using Agg with multiple images, no?
JDH

Jae-Joon Lee wrote:
> Andrew,
> 
> One of my worry is that this can results in inconsistent ouputs
> between backends. Your patch only affects backends with compositing
> capabilities. And backends such as ps backend will still render images
> at the bottom of all other artists.
PS backend already does things differently from others because it 
doesn't handle alpha, correct? Does the patch make this situation any 
worse?
Eric
> 
> I think it is often sufficient if we draw images at the bottom but
> respect zorders among images, and I guess this actually solves the
> issue of the original post.
> 
> So, my inclination is to respect zorders between images by default
> (images still drawn at the bottom), and optionally with all other
> artists.
> 
> Anyhow, I guess the cases affected by this issue is quite rare, and
> I'm actually fine if you submit the patch as is.
> 
> Regards,
> 
> -JJ
> 
> 
> 
> 
> On Mon, Nov 9, 2009 at 11:21 AM, Andrew Straw <str...@as...> wrote:
>> Hi All,
>>
>> I have addressed what I think is a long-standing wart: zorder is mostly
>> ignored for imshow(). (See e.g.
>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>> ) The question is whether I should apply the attached patch.
>>
>> The worry is that someone is relying on the old behavior of images being
>> underneath everything else. To a degree, this could be achieved by having
>> the default image zorder be lower than everything else. Currently, imshow()
>> creates images with zorder 1, which is pretty low on the hierarchy, but
>> there may be something lower. (The artist base class default is 0, but the
>> Line2D class bumps it to 2.) All tests pass with the change, and manual
>> inspection of several of the pylab_examples don't show any difference before
>> and after the patch.
>>
>> -Andrew
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Andrew,
One of my worry is that this can results in inconsistent ouputs
between backends. Your patch only affects backends with compositing
capabilities. And backends such as ps backend will still render images
at the bottom of all other artists.
I think it is often sufficient if we draw images at the bottom but
respect zorders among images, and I guess this actually solves the
issue of the original post.
So, my inclination is to respect zorders between images by default
(images still drawn at the bottom), and optionally with all other
artists.
Anyhow, I guess the cases affected by this issue is quite rare, and
I'm actually fine if you submit the patch as is.
Regards,
-JJ
On Mon, Nov 9, 2009 at 11:21 AM, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly
> ignored for imshow(). (See e.g.
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
> ) The question is whether I should apply the attached patch.
>
> The worry is that someone is relying on the old behavior of images being
> underneath everything else. To a degree, this could be achieved by having
> the default image zorder be lower than everything else. Currently, imshow()
> creates images with zorder 1, which is pretty low on the hierarchy, but
> there may be something lower. (The artist base class default is 0, but the
> Line2D class bumps it to 2.) All tests pass with the change, and manual
> inspection of several of the pylab_examples don't show any difference before
> and after the patch.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Andrew Straw wrote:
> Hi All,
> 
> I have addressed what I think is a long-standing wart: zorder is mostly 
> ignored for imshow(). (See e.g. 
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
> ) The question is whether I should apply the attached patch.
Andrew,
Looks good to me. I think you should go ahead.
Eric
> 
> The worry is that someone is relying on the old behavior of images being 
> underneath everything else. To a degree, this could be achieved by 
> having the default image zorder be lower than everything else. 
> Currently, imshow() creates images with zorder 1, which is pretty low on 
> the hierarchy, but there may be something lower. (The artist base class 
> default is 0, but the Line2D class bumps it to 2.) All tests pass with 
> the change, and manual inspection of several of the pylab_examples don't 
> show any difference before and after the patch.
> 
> -Andrew
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Nov 09, 2009 at 08:21:30AM -0800, Andrew Straw wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly 
> ignored for imshow(). (See e.g. 
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
> ) The question is whether I should apply the attached patch.
IMHO: go for it!
Gaël

Hi All,
I have addressed what I think is a long-standing wart: zorder is mostly 
ignored for imshow(). (See e.g. 
http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 
) The question is whether I should apply the attached patch.
The worry is that someone is relying on the old behavior of images being 
underneath everything else. To a degree, this could be achieved by 
having the default image zorder be lower than everything else. 
Currently, imshow() creates images with zorder 1, which is pretty low on 
the hierarchy, but there may be something lower. (The artist base class 
default is 0, but the Line2D class bumps it to 2.) All tests pass with 
the change, and manual inspection of several of the pylab_examples don't 
show any difference before and after the patch.
-Andrew

You are right. The error disappeared after re-building the matploblib.
Thanks for pointing out this.
On Mon, Nov 9, 2009 at 8:41 AM, Michael Droettboom <md...@st...> wrote:
> I can't reproduce this here. These sorts of CXX errors are usually caused
> by distutils not rebuilding enough when things change. Can you try removing
> the build directory, rebuilding matplotlib, and then rebuilding the docs?
>
> Mike
>
>
> On 11/07/2009 12:10 PM, Gökhan Sever wrote:
>
> Hello,
>
> The latest check-out gives an error while trying to build the
> documentation. Hitting "q" in pdb prompt resumes the execution and finishes
> the creation successfully.
>
>
> [gsever@ccn doc]$ python make.py all
> Running Sphinx v0.6.2
> loading pickled environment... done
> animation, api, axes_grid, event_handling, misc, mplot3d, pngsuite,
> pylab_examples, tests, units, user_interfaces, widgets,
> building [html]: targets for 470 source files that are out of date
> updating environment: 0 added, 13 changed, 0 removed
> generating thumbnails... Exception occurred while building, starting
> debugger:
> Traceback (most recent call last):
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/cmdline.py",
> line 172, in main
> app.build(all_files, filenames)
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
> line 130, in build
> self.builder.build_update()
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
> line 265, in build_update
> 'out of date' % len(to_build))
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
> line 285, in build
> purple, length):
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
> line 131, in status_iterator
> for item in iterable:
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/environment.py",
> line 527, in update_generator
> app.emit('env-updated', self)
> File
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
> line 222, in emit
> result.append(callback(self, *args))
> File
> "/home/gsever/Desktop/python-repo/matplotlib/doc/sphinxext/gen_gallery.py",
> line 112, in gen_gallery
> pool.map(make_thumbnail, thumbnails.iteritems())
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
> return self.map_async(func, iterable, chunksize).get()
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
> raise self._value
> TypeError: PyCXX: Error creating object of type N2Py7SeqBaseINS_4CharEEE
> from <open file
> 'build/plot_directive/mpl_examples/pylab_examples/transoffset.png', mode
> 'rb' at 0xaa3fcf0>
> > /usr/lib/python2.6/multiprocessing/pool.py(422)get()
> -> raise self._value
> (Pdb)
>
>
> --
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
-- 
Gökhan

I can't reproduce this here. These sorts of CXX errors are usually 
caused by distutils not rebuilding enough when things change. Can you 
try removing the build directory, rebuilding matplotlib, and then 
rebuilding the docs?
Mike
On 11/07/2009 12:10 PM, Gökhan Sever wrote:
> Hello,
>
> The latest check-out gives an error while trying to build the 
> documentation. Hitting "q" in pdb prompt resumes the execution and 
> finishes the creation successfully.
>
>
> [gsever@ccn doc]$ python make.py all
> Running Sphinx v0.6.2
> loading pickled environment... done
> animation, api, axes_grid, event_handling, misc, mplot3d, pngsuite, 
> pylab_examples, tests, units, user_interfaces, widgets,
> building [html]: targets for 470 source files that are out of date
> updating environment: 0 added, 13 changed, 0 removed
> generating thumbnails... Exception occurred while building, starting 
> debugger:
> Traceback (most recent call last):
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/cmdline.py", 
> line 172, in main
> app.build(all_files, filenames)
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py", 
> line 130, in build
> self.builder.build_update()
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py", 
> line 265, in build_update
> 'out of date' % len(to_build))
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py", 
> line 285, in build
> purple, length):
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py", 
> line 131, in status_iterator
> for item in iterable:
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/environment.py", 
> line 527, in update_generator
> app.emit('env-updated', self)
> File 
> "/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py", 
> line 222, in emit
> result.append(callback(self, *args))
> File 
> "/home/gsever/Desktop/python-repo/matplotlib/doc/sphinxext/gen_gallery.py", 
> line 112, in gen_gallery
> pool.map(make_thumbnail, thumbnails.iteritems())
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
> return self.map_async(func, iterable, chunksize).get()
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
> raise self._value
> TypeError: PyCXX: Error creating object of type 
> N2Py7SeqBaseINS_4CharEEE from <open file 
> 'build/plot_directive/mpl_examples/pylab_examples/transoffset.png', 
> mode 'rb' at 0xaa3fcf0>
> > /usr/lib/python2.6/multiprocessing/pool.py(422)get()
> -> raise self._value
> (Pdb)
>
>
> -- 
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>