From: KURT P. <pet...@ms...> - 2008-11-06 17:28:12
|
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 |
From: Jeff W. <js...@fa...> - 2008-11-06 21:05:23
|
John Hunter wrote: > On Thu, Nov 6, 2008 at 11:28 AM, KURT PETERS <pet...@ms...> 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 : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Michael D. <md...@st...> - 2008-11-07 13:24:57
|
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 |
From: John H. <jd...@gm...> - 2008-11-08 12:53:27
|
On Fri, Nov 7, 2008 at 7:24 AM, Michael Droettboom <md...@st...> 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 |
From: Jae-Joon L. <lee...@gm...> - 2008-11-08 23:45:41
Attachments:
imflip.patch
|
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 On Sat, Nov 8, 2008 at 7:53 AM, John Hunter <jd...@gm...> wrote: > On Fri, Nov 7, 2008 at 7:24 AM, Michael Droettboom <md...@st...> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
From: John H. <jd...@gm...> - 2008-11-08 23:55:09
|
On Sat, Nov 8, 2008 at 5:45 PM, Jae-Joon Lee <lee...@gm...> 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. Thanks, JDH |
From: Jae-Joon L. <lee...@gm...> - 2008-11-09 00:10:30
Attachments:
imflip2.patch
|
> 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 |
From: John H. <jd...@gm...> - 2008-11-09 00:28:41
|
On Sat, Nov 8, 2008 at 6:10 PM, Jae-Joon Lee <lee...@gm...> 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 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 |
From: Jae-Joon L. <lee...@gm...> - 2008-11-09 04:39:30
Attachments:
imflip3.patch
|
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 On Sat, Nov 8, 2008 at 7:28 PM, John Hunter <jd...@gm...> wrote: > On Sat, Nov 8, 2008 at 6:10 PM, Jae-Joon Lee <lee...@gm...> 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 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 > |
From: John H. <jd...@gm...> - 2008-11-09 13:22:13
|
On Sat, Nov 8, 2008 at 10:39 PM, Jae-Joon Lee <lee...@gm...> 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 |
From: Michael D. <md...@st...> - 2008-11-10 18:01:47
|
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...@gm...> 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 |
From: Michael D. <md...@st...> - 2008-11-06 20:55:02
|
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: > http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=608758 > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: John H. <jd...@gm...> - 2008-11-06 20:58:20
|
On Thu, Nov 6, 2008 at 11:28 AM, KURT PETERS <pet...@ms...> 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 |
From: Darren D. <dar...@co...> - 2008-11-06 22:28:49
|
On Thursday 06 November 2008 03:58:08 pm John Hunter wrote: > On Thu, Nov 6, 2008 at 11:28 AM, KURT PETERS <pet...@ms...> 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? 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. |
From: John H. <jd...@gm...> - 2008-11-08 12:56:04
|
On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <dar...@co...> 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.... JDH |
From: Darren D. <dsd...@gm...> - 2008-11-08 18:39:45
|
On Sat, Nov 8, 2008 at 7:55 AM, John Hunter <jd...@gm...> wrote: > On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <dar...@co...> > 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.... > 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. |
From: David C. <da...@ar...> - 2008-11-09 06:34:28
|
John Hunter wrote: > On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <dar...@co...> 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 |