matplotlib-devel Mailing List for matplotlib

On Jul 8, 2010, at 2:51 PM, Michael Droettboom wrote:

> On 07/08/2010 02:38 PM, John Hunter wrote:
>> On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu<ts...@gm...>  wrote:
>>   
>>> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>>> 
>>> Can you get a gdb backtrace?
>>> 
>>> Mike
>>> 
>>> Ignore my last email. The crash occurs here:
>>> #---
>>> Continuing.
>>> Reading symbols for shared libraries . done
>>> Reading symbols for shared libraries + done
>>> 2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
>>> Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
>>> just leaking
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries ++ done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x0000003000000040
>>> agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
>>> (this=0x7fff5fbf8130) at agg_array.h:521
>>> 521                pod_allocator<T>::deallocate(*blk, block_size);
>>> #---
>>> and the first few lines of the traceback are here:
>>> #---
>>> #0  agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
>>> (this=0x7fff5fbf8130) at agg_array.h:521
>>> #1  0x0000000101795b65 in ~vertex_sequence [inlined] () at
>>> /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
>>> #2  0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke
>>> (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
>>> #3  0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at
>>> kiva_graphics_context.h:410
>>> #4  0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
>>> /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
>>> #---
>>> I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
>>> Are there conflicting versions of agg?
>>>     
>> Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
>> several 2.4 release without changing any version numbers.  Can you
>> diff the two agg_rasterizer_cells_a.h files?  The problems could lie
>> in a different file, but this would be a start.  You might recursively
>> diff the src dirs as well.
>>   
> We also have some custom changes in the matplotlib tree -- because upstream agg 2.4 is basically closed.
> 
> Mike
> 

I've attached a diff of the file you suggested, John.There's a pretty significant output when diff-ing recursively. It doesn't sound like there's much to be done about this issue if matplotlib and enthought are using different versions of Agg (assuming this difference is actually the cause of the segfault).

In any case, I'll just refactor my code so that I don't run into this conflict.

Thanks,
-Tony


$ diff -b mpl/agg24/include/agg_rasterizer_cells_aa.h enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h32,33d31
< #include "CXX/Exception.hxx"
< #include <exception>
38a37
> 
40a40
> 
52c52
<             cell_block_limit = 4096
---
>             cell_block_limit = 1024
186,194c186
<                 if(m_num_blocks >= cell_block_limit) {
<                     static Py::Exception e(
<                         Py::OverflowError(
<                             "Agg rendering complexity exceeded. Consider downsampling or decimating your data."));
< 
<                     /* If this exception is thrown too often, one can
<                        increase cell_block_limit */
<                     throw e;
<                 }
---
>                 if(m_num_blocks >= cell_block_limit) return;
654a647
> 
678,679d670
<         i = m_num_cells & cell_block_mask;
<         if (i) {
680a672
>         i = m_num_cells & cell_block_mask;
686d677
<         }
713,714d703
<         i = m_num_cells & cell_block_mask;
<         if (i) {
715a705
>         i = m_num_cells & cell_block_mask;
723d712
<         }

On 07/08/2010 02:38 PM, John Hunter wrote:
> On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu<ts...@gm...>  wrote:
>    
>> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>>
>> Can you get a gdb backtrace?
>>
>> Mike
>>
>> Ignore my last email. The crash occurs here:
>> #---
>> Continuing.
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries + done
>> 2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
>> Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
>> just leaking
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries ++ done
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries + done
>> Reading symbols for shared libraries + done
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x0000003000000040
>> agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
>> (this=0x7fff5fbf8130) at agg_array.h:521
>> 521                pod_allocator<T>::deallocate(*blk, block_size);
>> #---
>> and the first few lines of the traceback are here:
>> #---
>> #0  agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
>> (this=0x7fff5fbf8130) at agg_array.h:521
>> #1  0x0000000101795b65 in ~vertex_sequence [inlined] () at
>> /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
>> #2  0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke
>> (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
>> #3  0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at
>> kiva_graphics_context.h:410
>> #4  0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
>> /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
>> #---
>> I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
>> Are there conflicting versions of agg?
>>      
> Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
> several 2.4 release without changing any version numbers.  Can you
> diff the two agg_rasterizer_cells_a.h files?  The problems could lie
> in a different file, but this would be a start.  You might recursively
> diff the src dirs as well.
>    
We also have some custom changes in the matplotlib tree -- because 
upstream agg 2.4 is basically closed.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu <ts...@gm...> wrote:
>
> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>
> Can you get a gdb backtrace?
>
> Mike
>
> Ignore my last email. The crash occurs here:
> #---
> Continuing.
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries + done
> 2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
> Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
> just leaking
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries ++ done
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries + done
> Reading symbols for shared libraries + done
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000003000000040
> agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
> (this=0x7fff5fbf8130) at agg_array.h:521
> 521                pod_allocator<T>::deallocate(*blk, block_size);
> #---
> and the first few lines of the traceback are here:
> #---
> #0  agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
> (this=0x7fff5fbf8130) at agg_array.h:521
> #1  0x0000000101795b65 in ~vertex_sequence [inlined] () at
> /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
> #2  0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke
> (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
> #3  0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at
> kiva_graphics_context.h:410
> #4  0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
> /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
> #---
> I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
> Are there conflicting versions of agg?

Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
several 2.4 release without changing any version numbers.  Can you
diff the two agg_rasterizer_cells_a.h files?  The problems could lie
in a different file, but this would be a start.  You might recursively
diff the src dirs as well.

On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

> Can you get a gdb backtrace?
> 
> Mike

Ignore my last email. The crash occurs here:

#---
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries + done
2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool(): Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place - just leaking
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++ done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000003000000040
agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521
521	                pod_allocator<T>::deallocate(*blk, block_size);
#---

and the first few lines of the traceback are here:

#---
#0  agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521
#1  0x0000000101795b65 in ~vertex_sequence [inlined] () at /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
#2  0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
#3  0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at kiva_graphics_context.h:410
#4  0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
#---

I posted the full traceback on pastebin: http://pastebin.com/ViefksDC

Are there conflicting versions of agg?

-Tony



> 
> On 07/08/2010 12:13 PM, Tony S Yu wrote:
>> The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)
>> 
>> If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin.  Below is a simple script that segfaults on my computer.
>> 
>> I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.
>> 
>> -Tony

On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

> Can you get a gdb backtrace?
> 
> Mike
> 

This is as far as I can get with gdb:

#---------

$ gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar  5 04:43:10 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done

(gdb) run test_import_chaco_and_plt.py 
Starting program: /usr/bin/python test_import_chaco_and_plt.py
Reading symbols for shared libraries .++..... done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff5fc01028 in __dyld__dyld_start ()
(gdb) bt
#0  0x00007fff5fc01028 in __dyld__dyld_start ()
#1  0x0000000100000000 in ?? ()
(gdb) 

#---------

I'm not very experienced with gdb, so I'm not sure if I'm doing something wrong. 

Thanks,
-Tony


> On 07/08/2010 12:13 PM, Tony S Yu wrote:
>> The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)
>> 
>> If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin.  Below is a simple script that segfaults on my computer.

On Jul 8, 2010, at 12:16 PM, John Hunter wrote:

> On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu <ts...@gm...> wrote:
>> The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)
>> 
>> If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin.  Below is a simple script that segfaults on my computer.
>> 
>> I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.
>> 
>> -Tony
>> 
>> P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).
> 
> First question -- are you compiling both yourself and are they
> compiled against the same version of numpy.  If not, I suspect we are
> seeing a numpy version conflict.

I am compiling both myself. I did clean compiles of both when Numpy had the whole ABI change (and change back). I've recompiled since then, but without cleaning out compiled code.

I can try clean builds, but that will have to be later in the day. I'll post an update.

Thanks,
-Tony

I am not a usetex user, but in testing mpl on a linux box I got a new
error for dvipng.  I hadn't seen this on this box before (it used to
work there) but I am not suspecting an mpl bug at this point, rather a
bug on the system.  I don't really know, but others have reported
similar dvipng bugs unrelated to mpl on ubuntu so I suspect the
problem lies there.  I am posting it here as a warning to others, and
also in case anyone has any idea how to fix, debug or diagnose it.  I
would like to fix it because this is my primary machine for building
and testing and updating the docs, so I'd like to have usetex working.

If you google

  glibc detected *** dvipng: free(): invalid pointer

there are a number of but reports

And now the bug, using the mpl 1.0.0 release

jdhunter@uqbar:pylab_examples> dvipng --version
This is dvipng 1.11 Copyright 2002-2008 Jan-Ake Larsson
dvipng 1.11
kpathsea version 3.5.4
Compiled with Freetype 2.3.5
Using libft 2.3.11
Copyright (C) 2002-2008 Jan-Ake Larsson.
There is NO warranty.  You may redistribute this software
under the terms of the GNU Lesser General Public License
version 3, see the COPYING file in the dvipng distribution
or <http://www.gnu.org/licenses/>.
jdhunter@uqbar:pylab_examples> uname -a Linux uqbar 2.6.32-23-generic
#37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux
jdhunter@uqbar:pylab_examples>
PYTHONPATH=~/dev/lib/python2.6/site-packages/ python tex_demo.py
--debug-annoying -dAgg
*** glibc detected *** dvipng: free(): invalid pointer: 0x0000000001b365b1 ***
======= Backtrace: =========
/lib/libc.so.6(+0x775b6)[0x7fe691b7e5b6]
/lib/libc.so.6(cfree+0x73)[0x7fe691b84e53]
dvipng[0x41480b]
dvipng[0x414a6a]
dvipng[0x412296]
dvipng[0x4071ce]
dvipng[0x405908]
dvipng[0x405a6c]
dvipng[0x40298c]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7fe691b25c4d]
dvipng[0x402859]
======= Memory map: ========
00400000-00422000 r-xp 00000000 08:05 6390264
  /home/jdhunter/dev/bin/dvipng
00621000-00623000 rw-p 00021000 08:05 6390264
  /home/jdhunter/dev/bin/dvipng
00623000-00627000 rw-p 00000000 00:00 0
01965000-01b60000 rw-p 00000000 00:00 0                                  [heap]
7fe68c000000-7fe68c021000 rw-p 00000000 00:00 0
7fe68c021000-7fe690000000 ---p 00000000 00:00 0
7fe6904fd000-7fe690513000 r-xp 00000000 08:02 5160983
  /lib/libgcc_s.so.1
7fe690513000-7fe690712000 ---p 00016000 08:02 5160983
  /lib/libgcc_s.so.1
7fe690712000-7fe690713000 r--p 00015000 08:02 5160983
  /lib/libgcc_s.so.1
7fe690713000-7fe690714000 rw-p 00016000 08:02 5160983
  /lib/libgcc_s.so.1
7fe690714000-7fe690719000 r-xp 00000000 08:02 1433640
  /usr/lib/libXdmcp.so.6.0.0
7fe690719000-7fe690918000 ---p 00005000 08:02 1433640
  /usr/lib/libXdmcp.so.6.0.0
7fe690918000-7fe690919000 r--p 00004000 08:02 1433640
  /usr/lib/libXdmcp.so.6.0.0
7fe690919000-7fe69091a000 rw-p 00005000 08:02 1433640
  /usr/lib/libXdmcp.so.6.0.0
7fe69091a000-7fe69091c000 r-xp 00000000 08:02 2787952
  /usr/lib/libXau.so.6.0.0
7fe69091c000-7fe690b1c000 ---p 00002000 08:02 2787952
  /usr/lib/libXau.so.6.0.0
7fe690b1c000-7fe690b1d000 r--p 00002000 08:02 2787952
  /usr/lib/libXau.so.6.0.0
7fe690b1d000-7fe690b1e000 rw-p 00003000 08:02 2787952
  /usr/lib/libXau.so.6.0.0
7fe690b1e000-7fe690b44000 r-xp 00000000 08:02 5161212
  /lib/libexpat.so.1.5.2
7fe690b44000-7fe690d44000 ---p 00026000 08:02 5161212
  /lib/libexpat.so.1.5.2
7fe690d44000-7fe690d46000 r--p 00026000 08:02 5161212
  /lib/libexpat.so.1.5.2
7fe690d46000-7fe690d47000 rw-p 00028000 08:02 5161212
  /lib/libexpat.so.1.5.2
7fe690d47000-7fe690d49000 r-xp 00000000 08:02 5163771
  /lib/libdl-2.11.1.so
7fe690d49000-7fe690f49000 ---p 00002000 08:02 5163771
  /lib/libdl-2.11.1.so
7fe690f49000-7fe690f4a000 r--p 00002000 08:02 5163771
  /lib/libdl-2.11.1.so
7fe690f4a000-7fe690f4b000 rw-p 00003000 08:02 5163771
  /lib/libdl-2.11.1.so
7fe690f4b000-7fe690f66000 r-xp 00000000 08:02 2788524
  /usr/lib/libxcb.so.1.1.0
7fe690f66000-7fe691165000 ---p 0001b000 08:02 2788524
  /usr/lib/libxcb.so.1.1.0
7fe691165000-7fe691166000 r--p 0001a000 08:02 2788524
  /usr/lib/libxcb.so.1.1.0
7fe691166000-7fe691167000 rw-p 0001b000 08:02 2788524
  /usr/lib/libxcb.so.1.1.0
7fe691167000-7fe69119a000 r-xp 00000000 08:02 2786757
  /usr/lib/libfontconfig.so.1.4.4
7fe69119a000-7fe69139a000 ---p 00033000 08:02 2786757
  /usr/lib/libfontconfig.so.1.4.4
7fe69139a000-7fe69139b000 r--p 00033000 08:02 2786757
  /usr/lib/libfontconfig.so.1.4.4
7fe69139b000-7fe69139c000 rw-p 00034000 08:02 2786757
  /usr/lib/libfontconfig.so.1.4.4
7fe69139c000-7fe6913bf000 r-xp 00000000 08:02 2791065
  /usr/lib/libjpeg.so.62.0.0
7fe6913bf000-7fe6915be000 ---p 00023000 08:02 2791065
  /usr/lib/libjpeg.so.62.0.0
7fe6915be000-7fe6915bf000 r--p 00022000 08:02 2791065
  /usr/lib/libjpeg.so.62.0.0
7fe6915bf000-7fe6915c0000 rw-p 00023000 08:02 2791065
  /usr/lib/libjpeg.so.62.0.0
7fe6915c0000-7fe6916f1000 r-xp 00000000 08:02 2789161
  /usr/lib/libX11.so.6.3.0
7fe6916f1000-7fe6918f1000 ---p 00131000 08:02 2789161
  /usr/lib/libX11.so.6.3.0
7fe6918f1000-7fe6918f2000 r--p 00131000 08:02 2789161
  /usr/lib/libX11.so.6.3.0
7fe6918f2000-7fe6918f6000 rw-p 00132000 08:02 2789161
  /usr/lib/libX11.so.6.3.0
7fe6918f6000-7fe691906000 r-xp 00000000 08:02 2790617
  /usr/lib/libXpm.so.4.11.0
7fe691906000-7fe691b05000 ---p 00010000 08:02 2790617
  /usr/lib/libXpm.so.4.11.0
7fe691b05000-7fe691b06000 r--p 0000f000 08:02 2790617
  /usr/lib/libXpm.so.4.11.0
7fe691b06000-7fe691b07000 rw-p 00010000 08:02 2790617
  /usr/lib/libXpm.so.4.11.0
7fe691b07000-7fe691c7f000 r-xp 00000000 08:02 5161404
  /lib/libc-2.11.1.so
7fe691c7f000-7fe691e7f000 ---p 00178000 08:02 5161404
  /lib/libc-2.11.1.so
7fe691e7f000-7fe691e83000 r--p 00178000 08:02 5161404
  /lib/libc-2.11.1.so
7fe691e83000-7fe691e84000 rw-p 0017c000 08:02 5161404
  /lib/libc-2.11.1.so
7fe691e84000-7fe691e89000 rw-p 00000000 00:00 0
7fe691e89000-7fe691f0b000 r-xp 00000000 08:02 5163772
  /lib/libm-2.11.1.so
7fe691f0b000-7fe69210a000 ---p 00082000 08:02 5163772
  /lib/libm-2.11.1.so
7fe69210a000-7fe69210b000 r--p 00081000 08:02 5163772
  /lib/libm-2.11.1.so
7fe69210b000-7fe69210c000 rw-p 00082000 08:02 5163772
  /lib/libm-2.11.1.so
7fe69210c000-7fe692122000 r-xp 00000000 08:02 5161322
  /lib/libz.so.1.2.3.3
7fe692122000-7fe692321000 ---p 00016000 08:02 5161322
  /lib/libz.so.1.2.3.3
7fe692321000-7fe692322000 r--p 00015000 08:02 5161322
  /lib/libz.so.1.2.3.3
7fe692322000-7fe692323000 rw-p 00016000 08:02 5161322
  /lib/libz.so.1.2.3.3
7fe692323000-7fe692348000 r-xp 00000000 08:02 5161357
  /lib/libpng12.so.0.42.0
7fe692348000-7fe692548000 ---p 00025000 08:02 5161357
  /lib/libpng12.so.0.42.0
7fe692548000-7fe692549000 r--p 00025000 08:02 5161357
  /lib/libpng12.so.0.42.0Aborted
Traceback (most recent call last):
  File "tex_demo.py", line 32, in <module>
    savefig('tex_demo')
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/pyplot.py",
line 353, in savefig
    return fig.savefig(*args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/figure.py",
line 1084, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backend_bases.py",
line 1859, in print_figure
    **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backends/backend_agg.py",
line 438, in print_png
    FigureCanvasAgg.draw(self)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backends/backend_agg.py",
line 394, in draw
    self.figure.draw(self.renderer)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/figure.py",
line 798, in draw
    func(*args)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/axes.py",
line 1892, in draw
    a.draw(renderer)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/axis.py",
line 806, in draw
    tick.draw(renderer)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/axis.py",
line 197, in draw
    self.label1.draw(renderer)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/text.py",
line 567, in draw
    self._fontproperties, angle)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backends/backend_agg.py",
line 198, in draw_tex
    Z = texmanager.get_grey(s, size, self.dpi)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/texmanager.py",
line 513, in get_grey
    pngfile = self.make_png(tex, fontsize, dpi)
  File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/texmanager.py",
line 459, in make_png
    \n\n'% dvifile + report)
RuntimeError: dvipng was not able to process the flowing file:
/home/jdhunter/.matplotlib/tex.cache/3751fe08829ac873c509bb548895020f.dvi
Here is the full report generated by dvipng:

This is dvipng 1.11 Copyright 2002-2008 Jan-Ake Larsson

Can you get a gdb backtrace?

Mike

On 07/08/2010 12:13 PM, Tony S Yu wrote:
> The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)
>
> If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin.  Below is a simple script that segfaults on my computer.
>
> I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.
>
> -Tony
>
> P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).
>
> #---
>
> import matplotlib.pyplot as plt
>
> import enthought.traits.api as traits
> import enthought.traits.ui.api as ui
> import enthought.chaco.api as chaco
> from enthought.enable.component_editor import ComponentEditor
>
>
> class LinePlot(traits.HasTraits):
>      plot = traits.Instance(chaco.Plot)
>      traits_view = ui.View(
>          ui.Item('plot', editor=ComponentEditor()),
>                  width=500, height=500, resizable=True)
>
>      def __init__(self):
>          plotdata = chaco.ArrayPlotData(x=[1,2,3], y=[1,2,3])
>          self.plot = chaco.Plot(plotdata)
>          self.plot.plot(('x', 'y'))
>
> viewer = LinePlot()
> viewer.configure_traits()
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu <ts...@gm...> wrote:
> The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)
>
> If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin.  Below is a simple script that segfaults on my computer.
>
> I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.
>
> -Tony
>
> P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).

First question -- are you compiling both yourself and are they
compiled against the same version of numpy.  If not, I suspect we are
seeing a numpy version conflict.

The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin.  Below is a simple script that segfaults on my computer.

I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.

-Tony

P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).

#---

import matplotlib.pyplot as plt

import enthought.traits.api as traits
import enthought.traits.ui.api as ui
import enthought.chaco.api as chaco
from enthought.enable.component_editor import ComponentEditor


class LinePlot(traits.HasTraits): 
    plot = traits.Instance(chaco.Plot) 
    traits_view = ui.View(
        ui.Item('plot', editor=ComponentEditor()),
                width=500, height=500, resizable=True)

    def __init__(self): 
        plotdata = chaco.ArrayPlotData(x=[1,2,3], y=[1,2,3]) 
        self.plot = chaco.Plot(plotdata) 
        self.plot.plot(('x', 'y')) 

viewer = LinePlot()
viewer.configure_traits()

On Thu, Jul 8, 2010 at 9:53 AM, Neal Becker <ndb...@gm...> wrote:
> Use case is I have a module that does digital design.  If run as main, it
> has a little test that does a plot.  The plot is supposed to use a gui and
> display.
>
> But if not run as main, there is no plot, and maybe no display.
>
> I had:
>
> if __name__ == "__main__":
>  from matplotlib.pyplot  import *

This is the right way.

> but this gives a warning about import * not at module level, so I changed to

Not to be overly blunt, but the way to solve this warning is to use:

import matplotlib.pyplot as plt

not move the import and complain about matplotlib's import behavior.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

We've had users run into the same problem (and have a similar reaction).  At least on our end, there was a key assumption that users were making about how a plotting system worked.  They expected to be able to do something like this:

... plot stuff here
if outputFile:
   P.savefig( "plot.png" )
else:
   P.show()

The thing they were missing is that they assumed that you don't need to have anything to do w/ the GUI until it pops up on the screen (i.e. until the show call) which just isn't true right now.  Depending on the backend, the gui is a required element during the construction of the plot because it's doing the drawing and layout.  

One item we thought might help (or at least be more obvious) but haven't had time to look at what it would take to implement is to be able to control the backend on a per figure basis - more of an object-oriented control after you create a figure.  Something along the lines of:

f = Figure(...)
if outputFile:
   f.set_backend( "agg" )

...


Ted

________________________________________
From: Michael Droettboom [md...@st...]
Sent: Thursday, July 08, 2010 8:02 AM
To: mat...@li...
Subject: Re: [matplotlib-devel] nasty import behavior

It's not that simple.  In order to get text metrics and start laying out
a plot for some backends (notably Gtk and Wx), the GUI framework needs
to be imported.  Sure, we could import them on demand once the user
actually starts doing stuff, but that would require sprinkling the code
with "import gtk" (etc.) in a number of functions, possibly decreasing
performance, and it would only delay the kind of exception you point
out, not eliminate it.

Mike

On 07/08/2010 10:16 AM, Neal Becker wrote:
> Thanks for the info, but I still think this is rude behavior for a python
> module, and believe it would be a good thing to fix it.
>
> Michael Droettboom wrote:
>
>
>> You need to set your backend to a non-GUI one (such as Agg) if you want
>> to run without a display.  This FAQ answer may be helpful:
>>
>> http://matplotlib.sourceforge.net/faq/howto_faq.html#matplotlib-in-a-web-
>>
> application-server
>
>> Mike
>>
>> On 07/08/2010 08:26 AM, Neal Becker wrote:
>>
>>> A python module  of mine could draw a plot, and so imports from
>>> matplotlib. Actually, plotting is part of the module test that is in
>>>    if __name__==__main__
>>>
>>> But this kills my job trying to run non-interactively.
>>> This is IMO rather nasty behavior.  matplotlib should not try to open the
>>> display just because you import it.
>>>
>>>       from matplotlib.pyplot import *
>>>     File "/usr/lib64/python2.6/site-packages/matplotlib/pyplot.py", line
>>>     78,
>>> in<module>
>>>       new_figure_manager, draw_if_interactive, show = pylab_setup()
>>>     File
>>>     "/usr/lib64/python2.6/site-packages/matplotlib/backends/__init__.py",
>>> line 25, in pylab_setup
>>>       globals(),locals(),[backend_name])
>>>     File "/usr/lib64/python2.6/site-
>>> packages/matplotlib/backends/backend_gtkagg.py", line 10, in<module>
>>>       from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK,
>>> FigureCanvasGTK,\
>>>     File "/usr/lib64/python2.6/site-
>>> packages/matplotlib/backends/backend_gtk.py", line 8, in<module>
>>>       import gtk; gdk = gtk.gdk
>>>     File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py",
>>>     line
>>> 64, in<module>
>>>       _init()
>>>     File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py",
>>>     line
>>> 52, in _init
>>>       _gtk.init_check()
>>> RuntimeError: could not open display
>>>
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------------
>
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>


--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

It's not that simple.  In order to get text metrics and start laying out 
a plot for some backends (notably Gtk and Wx), the GUI framework needs 
to be imported.  Sure, we could import them on demand once the user 
actually starts doing stuff, but that would require sprinkling the code 
with "import gtk" (etc.) in a number of functions, possibly decreasing 
performance, and it would only delay the kind of exception you point 
out, not eliminate it.

Mike

On 07/08/2010 10:16 AM, Neal Becker wrote:
> Thanks for the info, but I still think this is rude behavior for a python
> module, and believe it would be a good thing to fix it.
>
> Michael Droettboom wrote:
>
>    
>> You need to set your backend to a non-GUI one (such as Agg) if you want
>> to run without a display.  This FAQ answer may be helpful:
>>
>> http://matplotlib.sourceforge.net/faq/howto_faq.html#matplotlib-in-a-web-
>>      
> application-server
>    
>> Mike
>>
>> On 07/08/2010 08:26 AM, Neal Becker wrote:
>>      
>>> A python module  of mine could draw a plot, and so imports from
>>> matplotlib. Actually, plotting is part of the module test that is in
>>>    if __name__==__main__
>>>
>>> But this kills my job trying to run non-interactively.
>>> This is IMO rather nasty behavior.  matplotlib should not try to open the
>>> display just because you import it.
>>>
>>>       from matplotlib.pyplot import *
>>>     File "/usr/lib64/python2.6/site-packages/matplotlib/pyplot.py", line
>>>     78,
>>> in<module>
>>>       new_figure_manager, draw_if_interactive, show = pylab_setup()
>>>     File
>>>     "/usr/lib64/python2.6/site-packages/matplotlib/backends/__init__.py",
>>> line 25, in pylab_setup
>>>       globals(),locals(),[backend_name])
>>>     File "/usr/lib64/python2.6/site-
>>> packages/matplotlib/backends/backend_gtkagg.py", line 10, in<module>
>>>       from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK,
>>> FigureCanvasGTK,\
>>>     File "/usr/lib64/python2.6/site-
>>> packages/matplotlib/backends/backend_gtk.py", line 8, in<module>
>>>       import gtk; gdk = gtk.gdk
>>>     File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py",
>>>     line
>>> 64, in<module>
>>>       _init()
>>>     File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py",
>>>     line
>>> 52, in _init
>>>       _gtk.init_check()
>>> RuntimeError: could not open display
>>>
>>>
>>>
>>>
>>>        
> ------------------------------------------------------------------------------
>    
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>        
>>
>>      
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Use case is I have a module that does digital design.  If run as main, it 
has a little test that does a plot.  The plot is supposed to use a gui and 
display.

But if not run as main, there is no plot, and maybe no display.

I had:

if __name__ == "__main__":
  from matplotlib.pyplot  import *

but this gives a warning about import * not at module level, so I changed to

from matplotlib.pyplot  import *
if __name__ == "__main__":

Then if imported from another module, this crashes my program when run non-
interactively.

I didn't expect merely importing matplotlib to try to open the display.  I'm 
not changing backends in my rc file, because there are plenty of times when 
I want matplotlib to use my favorite gui.

On Thu, Jul 8, 2010 at 9:16 AM, Neal Becker <ndb...@gm...> wrote:
> Thanks for the info, but I still think this is rude behavior for a python
> module, and believe it would be a good thing to fix it.

Generally we try and make it easy for the user to express their
intention rather than guess what they are trying to do.  So you can
set your backend in an rc file

  http://matplotlib.sourceforge.net/users/customizing.html

or harcode it in your script (before importing pylab/pyplot)

  import matplotlib
  matplotlib.use('Agg')

Or you can run your script from the command line with the -d flag

  python myscript.py -dAgg  # will generate PNG, no GUI
  python myscript.py -dGTKAgg  # will popup a GTK GUI
  python myscript.py -dTKAgg  # will popup a Tkinter GUI


This is convenient because the same script, unmodified, can either be
used in a headless or a GUI environment.

We support 6 user interface toolkits across 4 or more operating
systems and many UI, python and OS versions.  We basically decided it
is too hard to guess what a user is trying to do across these
environments (embedding in apps, web app servers, headless scripts
generating PNG, working interactively from the shell), so we try to
make it easy for them to express their preferences.

If you have concrete suggestions on how we might accurately do this
detection in these scenarios, feel free to contribute, but a solution
that works for one environment, windowing system, or user interface
toolkit is of limited use.

See also

  http://matplotlib.sourceforge.net/faq/installing_faq.html#what-is-a-backend

JDH

Thanks for the info, but I still think this is rude behavior for a python 
module, and believe it would be a good thing to fix it. 

Michael Droettboom wrote:

> You need to set your backend to a non-GUI one (such as Agg) if you want
> to run without a display.  This FAQ answer may be helpful:
> 
> http://matplotlib.sourceforge.net/faq/howto_faq.html#matplotlib-in-a-web-
application-server
> 
> Mike
> 
> On 07/08/2010 08:26 AM, Neal Becker wrote:
>> A python module  of mine could draw a plot, and so imports from
>> matplotlib. Actually, plotting is part of the module test that is in
>>   if __name__==__main__
>>
>> But this kills my job trying to run non-interactively.
>> This is IMO rather nasty behavior.  matplotlib should not try to open the
>> display just because you import it.
>>
>>      from matplotlib.pyplot import *
>>    File "/usr/lib64/python2.6/site-packages/matplotlib/pyplot.py", line
>>    78,
>> in<module>
>>      new_figure_manager, draw_if_interactive, show = pylab_setup()
>>    File
>>    "/usr/lib64/python2.6/site-packages/matplotlib/backends/__init__.py",
>> line 25, in pylab_setup
>>      globals(),locals(),[backend_name])
>>    File "/usr/lib64/python2.6/site-
>> packages/matplotlib/backends/backend_gtkagg.py", line 10, in<module>
>>      from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK,
>> FigureCanvasGTK,\
>>    File "/usr/lib64/python2.6/site-
>> packages/matplotlib/backends/backend_gtk.py", line 8, in<module>
>>      import gtk; gdk = gtk.gdk
>>    File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py",
>>    line
>> 64, in<module>
>>      _init()
>>    File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py",
>>    line
>> 52, in _init
>>      _gtk.init_check()
>> RuntimeError: could not open display
>>
>>
>>
>> 
------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>    
> 
> 

You need to set your backend to a non-GUI one (such as Agg) if you want 
to run without a display.  This FAQ answer may be helpful:

http://matplotlib.sourceforge.net/faq/howto_faq.html#matplotlib-in-a-web-application-server

Mike

On 07/08/2010 08:26 AM, Neal Becker wrote:
> A python module  of mine could draw a plot, and so imports from matplotlib.
> Actually, plotting is part of the module test that is in
>   if __name__==__main__
>
> But this kills my job trying to run non-interactively.
> This is IMO rather nasty behavior.  matplotlib should not try to open the
> display just because you import it.
>
>      from matplotlib.pyplot import *
>    File "/usr/lib64/python2.6/site-packages/matplotlib/pyplot.py", line 78,
> in<module>
>      new_figure_manager, draw_if_interactive, show = pylab_setup()
>    File "/usr/lib64/python2.6/site-packages/matplotlib/backends/__init__.py",
> line 25, in pylab_setup
>      globals(),locals(),[backend_name])
>    File "/usr/lib64/python2.6/site-
> packages/matplotlib/backends/backend_gtkagg.py", line 10, in<module>
>      from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK,
> FigureCanvasGTK,\
>    File "/usr/lib64/python2.6/site-
> packages/matplotlib/backends/backend_gtk.py", line 8, in<module>
>      import gtk; gdk = gtk.gdk
>    File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line
> 64, in<module>
>      _init()
>    File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line
> 52, in _init
>      _gtk.init_check()
> RuntimeError: could not open display
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

A python module  of mine could draw a plot, and so imports from matplotlib.  
Actually, plotting is part of the module test that is in
 if __name__==__main__

But this kills my job trying to run non-interactively.
This is IMO rather nasty behavior.  matplotlib should not try to open the 
display just because you import it.

    from matplotlib.pyplot import *
  File "/usr/lib64/python2.6/site-packages/matplotlib/pyplot.py", line 78, 
in <module>
    new_figure_manager, draw_if_interactive, show = pylab_setup()
  File "/usr/lib64/python2.6/site-packages/matplotlib/backends/__init__.py", 
line 25, in pylab_setup
    globals(),locals(),[backend_name])
  File "/usr/lib64/python2.6/site-
packages/matplotlib/backends/backend_gtkagg.py", line 10, in <module>
    from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK, 
FigureCanvasGTK,\
  File "/usr/lib64/python2.6/site-
packages/matplotlib/backends/backend_gtk.py", line 8, in <module>
    import gtk; gdk = gtk.gdk
  File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 
64, in <module>
    _init()
  File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 
52, in _init
    _gtk.init_check()
RuntimeError: could not open display

Hey Mike,

> Instead, it would make more sense to make use of the clipping
> algorithm already in matplotlib (and implemented in fast C++) that will
> actually splice the line segments at the boundary.  I've attached a patch
> for this.

Good call. Our main clipping issue that still needs to be resolved is
for markers. This is actually a wider topic since our biggest
performance handicap
is drawing plots with large numbers of markers. Unlike, say SVG, there
is no concept of a predefined shape that we can use in the HTML5
canvas element to create a marker once and then simply copy or
reference for later markers. This is something we will hopefully
investigate at some later date.

> The display at the bottom that says "Cursor at: X, Y" is in pixels, not in
> data units.  It would be great if this could display data units, though
> being general enough to support custom scales (eg. log) and projections (eg.
> polar) may be tricky without making a round-trip to the server.

As you mentioned, the trick is in giving the client some view on how
pixels should map to data values without fetching these for each mouse
movement. For simple cartesian plots this is probably pretty
straightforward. It is something we need to get working for our
internal use so it should get solved at some stage.

> If I resize the plotting area (using either the "+" or "arrows" icon), the
> area where the mouse cursor can draw a zooming rectangle does not seem to be
> updated.

The benefit of external users :) This was an old bug that crept back
in. It has been fixed in the latest commit (along with your clipping
patch).

> Minor point: I seem to get a traceback when "text.usetex" is True.

Fixed in latest commit so that it warns the user that tex is not
currently supported. Another thing to do for the next release :)

> Thinking more broadly -- how difficult would it be to just use the plotting
> area part of the display, and not the plot selection and layout buttons
> along the top?  I think a really great use case of this backend would be to
> embed plots in a web page, and have an interactive plot inline in the
> document.  In that case, the extra layout features may be unnecessary.

There is already some sort of selector in place (you can append a
number onto the base URL to select a specific layout). I think we will
extend this to allow
selection of individual plots with/without extra decorators. Then
other pages could embed these URLs directly as iframes that contain
only the canvas and associated javascript
to display the plot.

I imagine this would also be useful in the context of applications like Sage.

>  Also, (and I'm getting a bit out of my depth here as I haven't done a lot
> of web development), how hard would it be to integrate this inside of a
> WSGI-based webapp, perhaps a Django app?  The standalone server this is nice
> for demos, but I can see this becoming very useful as part of a larger web
> application.

Certainly possible. I imagine that as the WebSocket standard becomes
more prevalent it will get integrated
into existing frameworks. Once this happens then the framework can
associate a specific WebSocket URL with a request
that gets internally redirected to the running mplh5canvas server,
making the user experience a bit more seamless.

Our internal use is certainly heading along similar lines, with the
plots being integrated into a number of container technologies
including Flex
and basic HTML pages. As these new use cases come along we can
evaluate the architecture and integrate things a bit more seamlessly.

Thanks again for the feedback, although we are quite familiar with mpl
as users, we are pretty inexperienced with the backend side, and it
helps a lot to get input from people who know the code well.

Simon