matplotlib-devel Mailing List for matplotlib

In article <513...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> On 03/07/2013 06:48 PM, Russell E. Owen wrote:
> > In article <513...@st...>,
> > Michael Droettboom <md...@st...>
> > wrote:
> >
> >> We've finally squashed all of the bugs slated for 1.2.1, so I have
> >> tagged a 1.2.1rc1 for testing....
> >>
> >> It can be downloaded from the SF files server here:
> >>
> >> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.
> >> 1rc
> >> 1/matplotlib-1.2.1rc1.tar.gz/download
> >>...
> > I uploaded two Mac binaries to SourceForge...
> >
> > They are both built against numpy 1.6.2, which is not ideal, but is the
> > best I can do at the moment.
> >
> I think that's fine for now -- for the rc it's most important to just 
> make sure that working packages *can* be built. We can reevaluate what 
> Numpy version to use for the final release, and let me know if we should 
> push back the final release date to accomodate rejiggering your 
> development environment etc.
Do you have an opinion on the best numpy to use for matplotlib 1.2 
binaries?
Some considerations:
I think numpy 1.7.x is binary compatible with 1.6.x. If so, surely it is 
OK to build matplotlib against numpy 1.6.x, even if a user wants to use 
numpy 1.7.x? I have not tested this (nor the reverse direction).
numpy 1.7.0 has a serious memory leak (though I don't know how many 
users would ever see it). 1.7.1 is due out fairly soon. Personally I 
would rather skip 1.7.0 on my own machine. Yet it would be wise to let 
1.7.1 be used for a week or two before relying on it and I'd hate to 
hold up release of matplotlib 1.2.1.
-- Russell

On 3/8/2013 2:16 AM, Tejashri Kandolkar wrote:
> Thanks Christoph, thanks for the help.
>
> However I found the issue.
> The issue is that somehow matplotlib_release variant linked to the debug
> lib of libpng.
> And so on a non-developer machine, which dosent have msvcr90d.dll (debug
> crt), DLL Load fails.
Good to know. The zlib, png and freetype libraries should be built as 
"Release, Static Library, Multi-threaded DLL" to be compatible with 
CPython. See also <https://github.com/matplotlib/matplotlib/issues/1717>
>
> So now I have another question:
>
> I have built the static libs of freetype, libpng (and zlib which is
> required by libpng) from source
> And I mention the paths of these static libs in setupext.py (by
> modifying "basedir") while building matplotlib.
No need to modify the source code. You can add the directories 
containing the headers and libraries to the INCLUDE and LIB environment 
variables.
>
> Now when matplotlib builds, and generates a _png.pyd, will it still need
> the static libs to be present in the location where the _png.pyd is present?
> What I understand is that it shouldn't since it is a static library and
> should be built into the binary.
The static libs are not needed at runtime. They are part of the pyd binary.
>
> Why I am asking this is because I am unable to build the libpng DLLs
> (for some reason I dont know).
> So I have to go forward with the static lib approach.
The static approach is recommended. If you link to the DLLs instead you 
will need to ship those with the binaries, which is not done in setup.py.
Christoph
>
> Thanks,
> Regards,
> Tej.
>
> On Thu, Mar 7, 2013 at 10:53 PM, Christoph Gohlke <cg...@uc...
> <mailto:cg...@uc...>> wrote:
>
> On 3/7/2013 8:39 AM, Christoph Gohlke wrote:
> > On 3/7/2013 6:00 AM, Tejashri Kandolkar wrote:
> >> Hi,
> >>
> >> I built matplotlib1.2.0 with python3.2 on Windows7 from source.
> >> I built the libpng and freetype libs and linked them statically to
> >> matplotlib.
> >>
> >> Everything works fine on my machine, I can run the matplotlib examples etc
> >> But on a new Win7 machine(with the exact same configuration as mine,
> >> except a few softwares), I get the following error when i try to import
> >> png module like this:
> >>
> >> import matplotlib._png
> >>
> >> ImportError: DLL load failed: The application has failed to start
> >> because its side-by-side configuration is incorrect. Please see the
> >> application event log or use the command-line sxstrace.exe tool for more
> >> detail.
> >>
> >>
> >> I used the dependency walker and found that pyd_ DLL was indeed having
> >> issues during load.
> >>
> >> What could be the reason. Surprisingly it works all fine on my machine.
> >>
> >>
> >> Regards,
> >> Tej
> >>
> >
> > Assuming this is 32 bit Python, install the Microsoft Visual C++ 2008
> > Redistributable Package (x86) <from
> >http://www.microsoft.com/en-us/download/details.aspx?id=29>
> >
>
> Besides that, look for extra msvcp90.dll or msvcr90.dll files in PATH
> (for example MikteX is known for that) and resolve conflicts.
>
> Christoph
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On 03/07/2013 06:48 PM, Russell E. Owen wrote:
> In article <513...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> We've finally squashed all of the bugs slated for 1.2.1, so I have
>> tagged a 1.2.1rc1 for testing. This is a bugfix release, and improves
>> on the overall quality of 1.2.0. Thanks to everyone who worked hard to
>> fix a multitude of papercuts. I'll provide a more detailed list of
>> changes in the announcement of the final version.
>>
>> It can be downloaded from the SF files server here:
>>
>> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1rc
>> 1/matplotlib-1.2.1rc1.tar.gz/download
>>
>> Packagers: I don't expect a lot of glitches as nothing significant has
>> changed about the build since 1.2.0, but now is the best time to try to
>> build for your various packaging systems and report back any problems.
>> If all goes well, I plan to make a final release in approximately two
>> weeks on March 25.
> I uploaded two Mac binaries to SourceForge:
> - A 10.3-compatible version built and tested on 10.4
> - A 10.6-compatible version built and tested on 10.8 (I should also test
> it on 10.6 but don't have time right now).
>
> They are both built against numpy 1.6.2, which is not ideal, but is the
> best I can do at the moment.
>
I think that's fine for now -- for the rc it's most important to just 
make sure that working packages *can* be built. We can reevaluate what 
Numpy version to use for the final release, and let me know if we should 
push back the final release date to accomodate rejiggering your 
development environment etc.
Cheers,
Mike

On Fri, Mar 8, 2013 at 3:46 PM, Tejashri Kandolkar <
tej...@gm...> wrote:
> Thanks Christoph, thanks for the help.
>
> However I found the issue.
> The issue is that somehow matplotlib_release variant linked to the debug
> lib of libpng.
> And so on a non-developer machine, which dosent have msvcr90d.dll (debug
> crt), DLL Load fails.
>
> So now I have another question:
>
> I have built the static libs of freetype, libpng (and zlib which is
> required by libpng) from source
> And I mention the paths of these static libs in setupext.py (by modifying
> "basedir") while building matplotlib.
>
> Now when matplotlib builds, and generates a _png.pyd, will it still need
> the static libs to be present in the location where the _png.pyd is present?
> What I understand is that it shouldn't since it is a static library and
> should be built into the binary.
>
> Why I am asking this is because I am unable to build the libpng DLLs (for
> some reason I dont know).
> So I have to go forward with the static lib approach.
>
> Thanks,
> Regards,
> Tej.
>
>
> On Thu, Mar 7, 2013 at 10:53 PM, Christoph Gohlke <cg...@uc...> wrote:
>
>> On 3/7/2013 8:39 AM, Christoph Gohlke wrote:
>> > On 3/7/2013 6:00 AM, Tejashri Kandolkar wrote:
>> >> Hi,
>> >>
>> >> I built matplotlib1.2.0 with python3.2 on Windows7 from source.
>> >> I built the libpng and freetype libs and linked them statically to
>> >> matplotlib.
>> >>
>> >> Everything works fine on my machine, I can run the matplotlib examples
>> etc
>> >> But on a new Win7 machine(with the exact same configuration as mine,
>> >> except a few softwares), I get the following error when i try to import
>> >> png module like this:
>> >>
>> >> import matplotlib._png
>> >>
>> >> ImportError: DLL load failed: The application has failed to start
>> >> because its side-by-side configuration is incorrect. Please see the
>> >> application event log or use the command-line sxstrace.exe tool for
>> more
>> >> detail.
>> >>
>> >>
>> >> I used the dependency walker and found that pyd_ DLL was indeed having
>> >> issues during load.
>> >>
>> >> What could be the reason. Surprisingly it works all fine on my machine.
>> >>
>> >>
>> >> Regards,
>> >> Tej
>> >>
>> >
>> > Assuming this is 32 bit Python, install the Microsoft Visual C++ 2008
>> > Redistributable Package (x86) <from
>> > http://www.microsoft.com/en-us/download/details.aspx?id=29>
>> >
>>
>> Besides that, look for extra msvcp90.dll or msvcr90.dll files in PATH
>> (for example MikteX is known for that) and resolve conflicts.
>>
>> Christoph
>>
>>
>> ------------------------------------------------------------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>