I recently tried to install for python 2.6 and got an error that the dll is incompatible. Is there a version for 2.6? I didn't see one here:
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=608758
Kurt
There hasn't been a release of matplotlib since Python 2.6 was released, and in general, Python packages only work with a specific version of Python.
You can build yourself from SVN (which has some minor fixes for Python-2.6 compatibility), or wait until the next binary release. I haven't heard any plans for one lately, and I'm not the Windows release manager, so I don't know what's involved in getting a Python 2.6 build out.
Cheers,
Mike
KURT PETERS wrote:
···
I recently tried to install for python 2.6 and got an error that the dll is incompatible. Is there a version for 2.6? I didn't see one here:
matplotlib - Browse /matplotlib/matplotlib-0.98.1 at SourceForge.net
Kurt-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
No, we haven't released any binaries for 2.6. It is probably getting
to be time to release a new version of mpl, especially since 2.6 has
been out for a while and lots of new fixes have gone into mpl since
our last major release.
Charlie, what is your availability? We would need to wait until at
least next week so we could do a feature freeze and a last round of
fixes. What say you other developers -- any major holdups? And
should we stop doing binary builds for python 2.4 according to our
unofficial policy of supporting the most recent two python releases?
JDH
···
On Thu, Nov 6, 2008 at 11:28 AM, KURT PETERS <peterskurt@...1954...> wrote:
I recently tried to install for python 2.6 and got an error that the dll is
incompatible. Is there a version for 2.6? I didn't see one here:
John Hunter wrote:
···
On Thu, Nov 6, 2008 at 11:28 AM, KURT PETERS <peterskurt@...1954...> wrote:
I recently tried to install for python 2.6 and got an error that the dll is
incompatible. Is there a version for 2.6? I didn't see one here:
No, we haven't released any binaries for 2.6. It is probably getting
to be time to release a new version of mpl, especially since 2.6 has
been out for a while and lots of new fixes have gone into mpl since
our last major release.Charlie, what is your availability? We would need to wait until at
least next week so we could do a feature freeze and a last round of
fixes. What say you other developers -- any major holdups? And
should we stop doing binary builds for python 2.4 according to our
unofficial policy of supporting the most recent two python releases?JDH
John: I think we have to wait till there is a binary numpy windows installer available for Python 2.6, which won't happen till version 1.3 is released.
-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory
Stan West checked out my subprocess patch on windows with python-2.5, which should take care of a bunch of deprecation warnings. I need to double check that I got them all, maybe I can get to it this weekend.
I’m in favor of dropping support for python-2.4, but on the other hand I think the most recent version of RHEL still uses this version.
···
On Thursday 06 November 2008 03:58:08 pm John Hunter wrote:
On Thu, Nov 6, 2008 at 11:28 AM, KURT PETERS <peterskurt@…1954…> wrote:
I recently tried to install for python 2.6 and got an error that the dll
is incompatible. Is there a version for 2.6? I didn’t see one here:
No, we haven’t released any binaries for 2.6. It is probably getting
to be time to release a new version of mpl, especially since 2.6 has
been out for a while and lots of new fixes have gone into mpl since
our last major release.
Charlie, what is your availability? We would need to wait until at
least next week so we could do a feature freeze and a last round of
fixes. What say you other developers – any major holdups? And
should we stop doing binary builds for python 2.4 according to our
unofficial policy of supporting the most recent two python releases?
John Hunter wrote:
What say you other developers -- any major holdups?
I think this bug is reasonably serious, if anyone wants to take a look at it. It affects PDF, PS, SVG as well as the Gtk and GtkCairo mentioned in the report. I've taken a kick at it a couple of times, but haven't found the magic incantation. I suspect it's a one-liner fix, just don't know which one... 
https://sourceforge.net/tracker/index.php?func=detail&aid=2160909&group_id=80706&atid=560720
Mike
···
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
I spent some time trying to fix this yesterday, and I too was
confounded by all the flipud_out calls in the various parts of the
code. I was not able to figure ot why agg was working and svg not,
since they appear to be making similar calls, and eventually had to
give up to work on some other stuff. I'll try and find some time this
weekend to plan another attack, and hopefully simplify and document
the code a bit if I am successful.
JDH
···
On Fri, Nov 7, 2008 at 7:24 AM, Michael Droettboom <mdroe@...86...> wrote:
John Hunter wrote:
What say you other developers -- any major holdups?
I think this bug is reasonably serious, if anyone wants to take a look at
it. It affects PDF, PS, SVG as well as the Gtk and GtkCairo mentioned in
the report. I've taken a kick at it a couple of times, but haven't found
the magic incantation. I suspect it's a one-liner fix, just don't know
which one...https://sourceforge.net/tracker/index.php?func=detail&aid=2160909&group_id=80706&atid=560720
Actually, we still use 2.4 at work, so I'd like to continue supporting
2.4 for a while I guess, for purely selfish reasons. But perhaps we
should stop making binaries for it to ease the burden on Charlie.
Once the 2.6 binaries for numpy are out and we are making binaries for
the next release, that is....
JDH
···
On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <darren.dale@...163...> wrote:
Stan West checked out my subprocess patch on windows with python-2.5, which
should take care of a bunch of deprecation warnings. I need to double check
that I got them all, maybe I can get to it this weekend.I'm in favor of dropping support for python-2.4, but on the other hand I
think the most recent version of RHEL still uses this version.
It looks like I’m not going to have a chance to check this patch on windows with py24 after all. I have to send my new laptop back to Sony, and won’t have it back for another week or two.
Off topic: Like any self-respecting linux user, one of the first things I did with my new laptop was wipe the hard disk and perform a system recovery into a smaller partition, which failed and probably exposed a problem with the DVD drive. Sony tech support, incredulously: “You performed a system recovery with a brand new computer?” Me: “That is correct.” Sony tech: “Let me refer this to the next level of support.” On the upside, the new Sony SR series is really nice, the keyboard is phenomenal, and although I couldn’t install kubuntu from CD, I was able to install it from a bootable USB stick, which is more than can be said for Vista. I think this might be the first report of Linux running on this model.
···
On Sat, Nov 8, 2008 at 7:55 AM, John Hunter <jdh2358@…287…> wrote:
On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <darren.dale@…163…> wrote:
Stan West checked out my subprocess patch on windows with python-2.5, which
should take care of a bunch of deprecation warnings. I need to double check
that I got them all, maybe I can get to it this weekend.
I’m in favor of dropping support for python-2.4, but on the other hand I
think the most recent version of RHEL still uses this version.
Actually, we still use 2.4 at work, so I’d like to continue supporting
2.4 for a while I guess, for purely selfish reasons. But perhaps we
should stop making binaries for it to ease the burden on Charlie.
Once the 2.6 binaries for numpy are out and we are making binaries for
the next release, that is…
I think the problem is caused by the image compositing logic in the
Axes.draw() method.
It currently makes a composite image first and then flip the resulting
image if necessary.
But I think what should happen is to flip the original images first
and then do the compositing.
So, test the attached patch and see if it solves the problem.
Regards,
-JJ
imflip.patch (968 Bytes)
···
On Sat, Nov 8, 2008 at 7:53 AM, John Hunter <jdh2358@...287...> wrote:
On Fri, Nov 7, 2008 at 7:24 AM, Michael Droettboom <mdroe@...86...> wrote:
John Hunter wrote:
What say you other developers -- any major holdups?
I think this bug is reasonably serious, if anyone wants to take a look at
it. It affects PDF, PS, SVG as well as the Gtk and GtkCairo mentioned in
the report. I've taken a kick at it a couple of times, but haven't found
the magic incantation. I suspect it's a one-liner fix, just don't know
which one...https://sourceforge.net/tracker/index.php?func=detail&aid=2160909&group_id=80706&atid=560720
I spent some time trying to fix this yesterday, and I too was
confounded by all the flipud_out calls in the various parts of the
code. I was not able to figure ot why agg was working and svg not,
since they appear to be making similar calls, and eventually had to
give up to work on some other stuff. I'll try and find some time this
weekend to plan another attack, and hopefully simplify and document
the code a bit if I am successful.JDH
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
Hey Jae Joon -- thanks for looking into this. I don't have time to
test this patch, but I wanted to mention that there is an analogous
problem for figure image compositing -- see figimage_demo.py. agg
shows the correct behavior: the two images should be in the lower
left, and the blue should be down for image origin=lower and the blue
should be up for image origin=upper. So if you are having success
with the image compositing orientation problems on the various
backends, you may want to see if your fixes apply to the figimage
problems as well.
Thanks,
JDH
···
On Sat, Nov 8, 2008 at 5:45 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
I think the problem is caused by the image compositing logic in the
Axes.draw() method.
It currently makes a composite image first and then flip the resulting
image if necessary.
But I think what should happen is to flip the original images first
and then do the compositing.
So, test the attached patch and see if it solves the problem.
Hey Jae Joon -- thanks for looking into this. I don't have time to
test this patch, but I wanted to mention that there is an analogous
problem for figure image compositing -- see figimage_demo.py. agg
shows the correct behavior: the two images should be in the lower
left, and the blue should be down for image origin=lower and the blue
should be up for image origin=upper. So if you are having success
with the image compositing orientation problems on the various
backends, you may want to see if your fixes apply to the figimage
problems as well.
My original patch does not work for this case, because the figimage is
drawn by Figure.draw() not by Axes.draw() method.
I'm attaching a new patch where I applied the same correction to the
Figure.draw().
I tested GtkAgg, Gtk, GtkCairo, Pdf, Ps and they all worked fine.
-JJ
imflip2.patch (1.74 KB)
So I managed to sneak some time to apply and test these after all --
but I am getting in a little trouble with my wife 
The layer images demo looks great for pdf, svg and png, but I am still
seeing problems with the figimage_demo for origin "upper". On svg and
pdf in my tests, blue still appears down, though is correctly up on
png. I went ahead and committed your changes (with a minor variation
that the list comprehensions are expressed as plain-ol-loops because
some people consider the use of a list comprehension simply to do in
place modifications where the list itself is discarded to be an abuse
of the construct) to revision 6380.
Make sure I didn't screw something up, but the figimage_demo still
looks broken to me for the case currently in fsvn
Thanks for all the progress!
JDH
···
On Sat, Nov 8, 2008 at 6:10 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
My original patch does not work for this case, because the figimage is
drawn by Figure.draw() not by Axes.draw() method.
I'm attaching a new patch where I applied the same correction to the
Figure.draw().
I tested GtkAgg, Gtk, GtkCairo, Pdf, Ps and they all worked fine.
John,
I'm attaching an another patch, which seems to give a correct result
for the figimage_demo.
The flipud_out() calls before compositing seems to have no effect, so
I deleted those lines. The make_image() routine seems to take care of
the fliping already, but note the comments I added. Let me know if
there are cases this patch does not work.
-JJ
imflip3.patch (3.16 KB)
···
On Sat, Nov 8, 2008 at 7:28 PM, John Hunter <jdh2358@...287...> wrote:
On Sat, Nov 8, 2008 at 6:10 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
My original patch does not work for this case, because the figimage is
drawn by Figure.draw() not by Axes.draw() method.
I'm attaching a new patch where I applied the same correction to the
Figure.draw().
I tested GtkAgg, Gtk, GtkCairo, Pdf, Ps and they all worked fine.So I managed to sneak some time to apply and test these after all --
but I am getting in a little trouble with my wifeThe layer images demo looks great for pdf, svg and png, but I am still
seeing problems with the figimage_demo for origin "upper". On svg and
pdf in my tests, blue still appears down, though is correctly up on
png. I went ahead and committed your changes (with a minor variation
that the list comprehensions are expressed as plain-ol-loops because
some people consider the use of a list comprehension simply to do in
place modifications where the list itself is discarded to be an abuse
of the construct) to revision 6380.Make sure I didn't screw something up, but the figimage_demo still
looks broken to me for the case currently in fsvnThanks for all the progress!
JDH
John Hunter wrote:
Stan West checked out my subprocess patch on windows with python-2.5, which
should take care of a bunch of deprecation warnings. I need to double check
that I got them all, maybe I can get to it this weekend.I'm in favor of dropping support for python-2.4, but on the other hand I
think the most recent version of RHEL still uses this version.
Actually, we still use 2.4 at work, so I'd like to continue supporting
2.4 for a while I guess, for purely selfish reasons. But perhaps we
should stop making binaries for it to ease the burden on Charlie.
Once the 2.6 binaries for numpy are out and we are making binaries for
the next release, that is....
I think it would be a mistake to stop supporting python 2.4 as well.
RHEL indeed still uses 2.4 as its default python. It would make the
installation of the numpy/mpl stack even harder than it already is on
those platforms, which does not strike me as a good idea (I am a numpy
developer, and I find it already quite difficult). Does python 2.5 have
that many interesting features compared to 2.4 ?
cheers,
David
···
On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <darren.dale@...163...> wrote:
Ahh, I think you found the ultimate source of our woes and flupud
complexity: the _image.from_images module was ignoring the stride, as
you noted in the comment in your patch. I just fixed this n r6381, so
the code behaves properly at the extension code level and we don't
have to do all those confusing flips in the axes or figure compositing
methods. So the code is now simpler, and it works.
Thanks for digging into this.
JDH
···
On Sat, Nov 8, 2008 at 10:39 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
John,
I'm attaching an another patch, which seems to give a correct result
for the figimage_demo.
The flipud_out() calls before compositing seems to have no effect, so
Great. Does this mean we can close the bug?
Mike
John Hunter wrote:
···
On Sat, Nov 8, 2008 at 10:39 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
John,
I'm attaching an another patch, which seems to give a correct result
for the figimage_demo.
The flipud_out() calls before compositing seems to have no effect, so
Ahh, I think you found the ultimate source of our woes and flupud
complexity: the _image.from_images module was ignoring the stride, as
you noted in the comment in your patch. I just fixed this n r6381, so
the code behaves properly at the extension code level and we don't
have to do all those confusing flips in the axes or figure compositing
methods. So the code is now simpler, and it works.Thanks for digging into this.
JDH
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA