matplotlib-devel Mailing List for matplotlib

There were a couple of bug fixes in maint that had not yet been merged 
into master, so I just did that. I'm pretty sure it is OK, but in view 
of the impending release, checking and testing is particularly welcome.
Eric

Hi,
This is an extended version of the problems I reported yesterday to the user
listserv here:
http://sourceforge.net/mailarchive/message.php?msg_id=27953357
The basic problem is that key press events for the navigation keys ('up,
'down', 'left', 'right', 'pageup', and 'pagedown') are handled differently
for different backends. This leads to different behaviour when code is run
on a different backend.
Here are my observations:
Tk: -all navigation keys yield the correct event.key values.
 -nav keys are not bound to interactive toolbar
Qt4: -navigation keys all yield 'none'
 -nav keys are not bound to the interactive toolbar
GTK: -navigation keys yield the correct event.key values
 -the nav keys are bound to the interactive toolbar, but in an
inconsistant manner. If the toolbar zoom has not been used then up, left,
and right keys all send events to the connected key handler. If the toolbar
zoom has been used then left and right scrolls through the zoom levels.
Pressing the 'down' key selects the interactive toolbar, further presses of
any key are no longer sent to the connected key_press_event callbacks, but
they do change the selected tool. The zoom behaviour of the left and right
keys can be removed by unconnecting the toolbar's key_press_event handler.
But, this does not change that of the down key: whatever selects the toolbar
upon pressing the 'down' key is at a lower level than matplotlib.
This seems like bad behaviour. My impression has been that code should work
equally well with all backends.
For my application, my preferred backend is GTK, but my desired behaviour is
that of Ag. Can anyone recommend how to get GTK to not select the toolbar
with the down key (while keeping the toolbar)?
Thanks for your help,
-AM

On Wed, Aug 17, 2011 at 7:33 PM, Christoph Gohlke <cg...@uc...> wrote:
> On 8/17/2011 4:05 PM, Skipper Seabold wrote:
> > On Wed, Aug 17, 2011 at 4:21 PM, Christoph Gohlke <cg...@uc...
> > <mailto:cg...@uc...>> wrote:
> >>
> >>
> >> On 8/17/2011 12:03 PM, Skipper Seabold wrote:
> >> > On Wed, Aug 17, 2011 at 4:49 AM, Christoph Gohlke<cg...@uc...
> > <mailto:cg...@uc...>> wrote:
> >> > <snip>
> >> >> The only thing worth providing might be the prebuilt static link
> > libraries
> >> >> and header files for zlib, libpng, and freetype for the 4 different MSC
> >> >> compilers/runtime libraries.
> >> >
> >> > This would be very helpful. I haven't been able to track down the
> >> > plot_directive bugs on windows, because I haven't been able to build
> >> > the dependencies with any luck.
> >> >
> >> > Skipper
> >> >
> >>
> >>
> >> OK. I uploaded matplotlib-1.x-windows-link-libraries.zip at
> >> <http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>.
> >>
> >
> > That's awesome. Thanks!
> >
> >> The archive contains zlib-1.2.5, libpng-1.4.8, and freetype-2.4.6 link
> >> libraries and header files for the build systems listed below.
> >>
> >> All other Python package dependencies can also be downloaded from that
> >> page. Let me know if anything is missing.
> >>
> >> A description on how to build Python 2.6+ extensions using the free
> >> Windows SDK 7.0 is at
> >> <http://wiki.cython.org/64BitCythonExtensionsOnWindows>. I have not
> >> tested it with mpl though.
> >>
> >
> > This is how I've been building python packages with extension on Windows
> > if I need to, but I wouldn't know how to build the dependencies. Can you
> > recommend a good resource for doing so/learning to do so with SDK?
>
> Almost every library is different. Some require CMake, others scons,
> devenv, nmake, Perl... Refer to the readme or install files.
>
Right. Thanks. I got some ways there building zlib dependency with
nmake and/or vcbuild. They appear to be working at least.
> >
> > Now for MPL, I just dropped the msvcr90-x64 files into my matplotlib
> > source directory because I got tired of messing with setupext.py to try
> > to point to them.
>
> Try adding the directory containing the lib and include files to the LIB
> and INCLUDE environment variables.
>
> >I receive the following error
> >
> > <snip>
> > c:\users\skipper\src\matplotlib\zconf.h(380) : fatal error C1083: Cannot
> > open include file: 'unistd.h': No such file or directory
> > error: Command "cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG
> > -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I.
> > -IC:\Python27\lib\site-packages\numpy\core\include -I.
> > -IC:\Python27\include -IC:\Python27\PC /Tpsrc/_png.cpp
> > /Fobuild\temp.win-amd64-2.7\Release\src/_png.obj" failed with exit status 2
> >
> > Whole build log is here: http://pastebin.com/EfxYjMnL
>
> Use an empty unistd.h file. I have added that to the zip file.
>
Thanks, that did the trick. Working mpl from source on windows 7,
python 2.7, 64-bit.
Skipper
> Christoph
>
>
> >
> > Thanks,
> >
> > Skipper
> >
> >> Christoph
> >>
> >>
> >> msvcr71-x32
> >> -----------
> >> Python 2.5 32 bit
> >> Visual Studio .NET 2003
> >> MS C Compiler 13.10
> >> MSVCR71.DLL C runtime
> >>
> >> msvcrt-x64
> >> ----------
> >> Python 2.5 64 bit
> >> Microsoft Platform SDK for Windows Server 2003 R2
> >> MS C Compiler 13.10
> >> MSVCRT.DLL C runtime
> >>
> >> msvcr90-x32
> >> -----------
> >> Python 2.6, 2.7, 3.1, 3.2 32 bit
> >> Microsoft Visual Studio 2008 Pro
> >> (or Microsoft Windows SDK v7.0 for Windows 7 and .NET Framework 3.5
> >> Service Pack 1)
> >> MS C Compiler 15.0
> >> MSVCR90.DLL C runtime
> >>
> >> msvcr90-x64
> >> -----------
> >> Python 2.6, 2.7, 3.1, 3.2 64 bit
> >> Microsoft Visual Studio 2008 Pro
> >> (or Microsoft Windows SDK v7.0 for Windows 7 and .NET Framework 3.5
> >> Service Pack 1)
> >> MS C Compiler 15.0
> >> MSVCR90.DLL C runtime
> >>
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> > user administration capabilities and model configuration. Take
> > the hassle out of deploying and managing Subversion and the
> > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,
I want to plot a scalar function on the sphere in a Mollweide 
projection. My strategy is to:
 1. Generate a rectangular mesh in display coordinates,
 2. Apply the inverse transform for the Mollweide projection to get 
the data coordinates of every display coordinate,
 3. Evaluate the function at each data coordinate, and finally,
 4. Plot with imshow.
I noticed that the inverse transform in 
matplotlib.projections.geo.MollweideAxes is not implemented. I'm 
attaching a patch that fills in the missing inverse.
Also attached is a minimal example of the type of plot I am interested 
in making.
Cheers,
Leo Singer
Graduate Student @ LIGO-Caltech

On 08/17/2011 09:34 PM, Jae-Joon Lee wrote:
> Hi Eric,
>
> I just pushed a commit that I believe fix the problem.
>
> https://github.com/matplotlib/matplotlib/commit/fcebc2338ad730098520c866122061eefd866641
>
> The documentation now builds fine in my linux box.
Excellent, thank you.
Eric
>
> Regards,
>
> -JJ
>
>
> On Tue, Aug 16, 2011 at 8:52 AM, Eric Firing<ef...@ha...> wrote:
>> On 08/15/2011 12:07 PM, Eric Firing wrote:
>>> JJ,
>>>
>>> Thanks for your fast fix of the last problem I reported.
>>>
>>> Now that the doc build is trying to run scripts with the __main__
>>> conditional, one of the examples it is tripping over is
>>> make_room_for_ylabel_using_axesgrid.py.
>>>
>>> When I try to run it on the command line or in ipython, it displays
>>> nothing at all. I suspect that is related to the failure in the doc
>>> build, but I haven't looked into it at all. (In the doc build it
>>> generates a huge traceback ending in
>>> RuntimeError: maximum recursion depth exceeded in __instancecheck__
>>> ).
>>
>> Correction: running it from the command line generates the same problem
>> as is seen in the doc build and described above.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at: http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

Hi Eric,
I just pushed a commit that I believe fix the problem.
https://github.com/matplotlib/matplotlib/commit/fcebc2338ad730098520c866122061eefd866641
The documentation now builds fine in my linux box.
Regards,
-JJ
On Tue, Aug 16, 2011 at 8:52 AM, Eric Firing <ef...@ha...> wrote:
> On 08/15/2011 12:07 PM, Eric Firing wrote:
>> JJ,
>>
>> Thanks for your fast fix of the last problem I reported.
>>
>> Now that the doc build is trying to run scripts with the __main__
>> conditional, one of the examples it is tripping over is
>> make_room_for_ylabel_using_axesgrid.py.
>>
>> When I try to run it on the command line or in ipython, it displays
>> nothing at all. I suspect that is related to the failure in the doc
>> build, but I haven't looked into it at all. (In the doc build it
>> generates a huge traceback ending in
>> RuntimeError: maximum recursion depth exceeded in __instancecheck__
>> ).
>
> Correction: running it from the command line generates the same problem
> as is seen in the doc build and described above.
>
> Eric
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>