First of all let me apologize for the problems we have been seeing with the binaries as of late. Frankly the root of the problem might be my detachment from the matplotlib source for some time. Unfortunately due to my time constraints, this won't be changing soon. I used to think being somewhat on the outside helped me keep the ease of the build process in check. This gap has apparently grown too wide. Moving ahead, python 2.6 and 3.0 are going to pose new challenges since they require new versions of visual studio I do not have access to. Doing builds for 4 windows versions poses a great time to work on a standard cygwin build setup (not that the cygwin build process doesn't work as is). In addition to that we are going to possibly be seeing osx fat binaries with 4 architectures! I am more than happy to continue to contribute my time to create these builds, but I think it only makes sense to have a release candidate cycle before formally pushing to sourceforge. - Charlie
On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote: > First of all let me apologize for the problems we have been > seeing with the binaries as of late. Frankly the root of the problem > might be my detachment from the matplotlib source for some time. > Unfortunately due to my time constraints, this won't be changing soon. > I used to think being somewhat on the outside helped me keep the ease > of the build process in check. This gap has apparently grown too > wide. I appreciate that this is a difficult task and that you have plenty of other responsibilities, and appreciate your effort. However, I've been trying to get to the bottom of why the windows installer is overwriting configobj and I could use some feedback from you. I really need to know whether you delete the build/ directory before creating a new installer. > > Moving ahead, python 2.6 and 3.0 are going to pose new challenges > since they require new versions of visual studio I do not have access > to. I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free Visual C++ 2008 express can be used to create extension modules. I the past I have built and distributed extension modules built with mingw32 on windows XP, but I have not been able to put together a working mingw32/msys on a 64-bit windows vista machine. This is my only windows computer, so it looks like I will only be supporting py2.6 in the near future. > Doing builds for 4 windows versions poses a great time to work on > a standard cygwin build setup (not that the cygwin build process > doesn't work as is). In addition to that we are going to possibly be > seeing osx fat binaries with 4 architectures! I am more than happy to > continue to contribute my time to create these builds, but I think it > only makes sense to have a release candidate cycle before formally > pushing to sourceforge. > What are the four architectures? I'd be willing to get things together on my windows install so I can build mpl from source and help test with python-2.6. (I know I'm going to regret this.) Darren
On Sun, Dec 14, 2008 at 1:28 PM, Michael Abshoff <mab...@go...>wrote: > On Sun, Dec 14, 2008 at 10:22 AM, Darren Dale <dsd...@gm...> wrote: > > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote: > > Hi, > > >> First of all let me apologize for the problems we have been > >> seeing with the binaries as of late. Frankly the root of the problem > >> might be my detachment from the matplotlib source for some time. > >> Unfortunately due to my time constraints, this won't be changing soon. > >> I used to think being somewhat on the outside helped me keep the ease > >> of the build process in check. This gap has apparently grown too > >> wide. > > > > I appreciate that this is a difficult task and that you have plenty of > other > > responsibilities, and appreciate your effort. However, I've been trying > to > > get to the bottom of why the windows installer is overwriting configobj > and > > I could use some feedback from you. I really need to know whether you > delete > > the build/ directory before creating a new installer. > > > >> > >> Moving ahead, python 2.6 and 3.0 are going to pose new challenges > >> since they require new versions of visual studio I do not have access > >> to. > > > > I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the > free > > Visual C++ 2008 express can be used to create extension modules. > > The express edition can only produce 32 bit binaries, but I guess this > is better than nothing. > According to wikipedia ( http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express) : "natively compiling 64-bit <http://en.wikipedia.org/wiki/64-bit>applications through the IDE is not supported. If the freely available Windows SDK <http://en.wikipedia.org/wiki/Windows_SDK> is installed, 64-bit applications can be built on the command line using the x64 cross-compiler (Cl.exe) supplied with the SDK." The documentation at python.org does not indicate whether or not it is possible to cross-compile with the express edition if the Windows SDK is installed ( http://docs.python.org/distutils/builtdist.html#cross-compiling-on-windows) > > > I the past > > I have built and distributed extension modules built with mingw32 on > windows > > XP, but I have not been able to put together a working mingw32/msys on a > > 64-bit windows vista machine. This is my only windows computer, so it > looks > > like I will only be supporting py2.6 in the near future. > > Since numpy 1.3 (probably out January 2009) will start supporting > python 2.6 and official Python 3k support for numpy is currently > anticipated not for a while I would guess Python 3k support is a > non-issue for now. OTOH the many Python libraries depending on numpy > might make Python 3K support happen sooner. > Last I heard, the numpy folks think py-3 support is at least a year out.
On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsd...@gm...> wrote: > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote: >> >> First of all let me apologize for the problems we have been >> seeing with the binaries as of late. Frankly the root of the problem >> might be my detachment from the matplotlib source for some time. >> Unfortunately due to my time constraints, this won't be changing soon. >> I used to think being somewhat on the outside helped me keep the ease >> of the build process in check. This gap has apparently grown too >> wide. > > I appreciate that this is a difficult task and that you have plenty of other > responsibilities, and appreciate your effort. However, I've been trying to > get to the bottom of why the windows installer is overwriting configobj and > I could use some feedback from you. I really need to know whether you delete > the build/ directory before creating a new installer. I don't have my build directories anymore, but they were made from extracting the source release so there was no previous build directory. It is possible that I missed those settings in setup.cfg, because I do not have either of those module installed. > >> >> Moving ahead, python 2.6 and 3.0 are going to pose new challenges >> since they require new versions of visual studio I do not have access >> to. > > I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free > Visual C++ 2008 express can be used to create extension modules. I the past > I have built and distributed extension modules built with mingw32 on windows > XP, but I have not been able to put together a working mingw32/msys on a > 64-bit windows vista machine. This is my only windows computer, so it looks > like I will only be supporting py2.6 in the near future. > Good to know there is a free option. >> >> Doing builds for 4 windows versions poses a great time to work on >> a standard cygwin build setup (not that the cygwin build process >> doesn't work as is). In addition to that we are going to possibly be >> seeing osx fat binaries with 4 architectures! I am more than happy to >> continue to contribute my time to create these builds, but I think it >> only makes sense to have a release candidate cycle before formally >> pushing to sourceforge. > > What are the four architectures? I'd be willing to get things together on my > windows install so I can build mpl from source and help test with > python-2.6. (I know I'm going to regret this.) > "32-bit PowerPC, 32-bit x86, 64-bit PowerPC, and 64-bit x86" http://en.wikipedia.org/wiki/Fat_binary
On Sun, Dec 14, 2008 at 1:58 PM, Charlie Moad <cw...@gm...> wrote: > On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsd...@gm...> wrote: > > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote: > >> > >> First of all let me apologize for the problems we have been > >> seeing with the binaries as of late. Frankly the root of the problem > >> might be my detachment from the matplotlib source for some time. > >> Unfortunately due to my time constraints, this won't be changing soon. > >> I used to think being somewhat on the outside helped me keep the ease > >> of the build process in check. This gap has apparently grown too > >> wide. > > > > I appreciate that this is a difficult task and that you have plenty of > other > > responsibilities, and appreciate your effort. However, I've been trying > to > > get to the bottom of why the windows installer is overwriting configobj > and > > I could use some feedback from you. I really need to know whether you > delete > > the build/ directory before creating a new installer. > > I don't have my build directories anymore, but they were made from > extracting the source release so there was no previous build > directory. It is possible that I missed those settings in setup.cfg, > because I do not have either of those module installed. > If you did not explicitly disable these modules in setup.cfg, then I think we understand the problem. Would you please make a note that configobj and traits should be explicitly disabled in setup.cfg for future releases of the maintenance branches? It will not be an issue for the trunk. Thanks, Darren
On Sun, Dec 14, 2008 at 10:55 AM, Darren Dale <dsd...@gm...> wrote: > On Sun, Dec 14, 2008 at 1:28 PM, Michael Abshoff <mab...@go...> > wrote: >> On Sun, Dec 14, 2008 at 10:22 AM, Darren Dale <dsd...@gm...> wrote: >> > On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote: Hi, <SNIP> >> The express edition can only produce 32 bit binaries, but I guess this >> is better than nothing. > > According to wikipedia > (http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express) : > > "natively compiling 64-bit applications through the IDE is not supported. If > the freely available Windows SDK is installed, 64-bit applications can be > built on the command line using the x64 cross-compiler (Cl.exe) supplied > with the SDK." The documentation at python.org does not indicate whether or > not it is possible to cross-compile with the express edition if the Windows > SDK is installed > (http://docs.python.org/distutils/builtdist.html#cross-compiling-on-windows) Ok, I didn't know that. There is also some movement with the 64 bit MinGW port, so hopefully in 2009 one might see a stable release there, too. >> >> > I the past >> > I have built and distributed extension modules built with mingw32 on >> > windows >> > XP, but I have not been able to put together a working mingw32/msys on a >> > 64-bit windows vista machine. This is my only windows computer, so it >> > looks >> > like I will only be supporting py2.6 in the near future. >> >> Since numpy 1.3 (probably out January 2009) will start supporting >> python 2.6 and official Python 3k support for numpy is currently >> anticipated not for a while I would guess Python 3k support is a >> non-issue for now. OTOH the many Python libraries depending on numpy >> might make Python 3K support happen sooner. > > Last I heard, the numpy folks think py-3 support is at least a year out. > Yes, I have seen that figure thrown around on the list last week, too. The reasoning seems to be that it would take until 2010 until "major" distributions shipped Py3K, but given the dependency of many libs I would be surprised if there wasn't enough pressure earlier to get this fixed. Given that numpy uses the Python C API directly this might be more work than some people think. In the end it would probably greatly help if the same codebase could support Python 2.x and Py3K at the same time, but we will see. Slightly OT: What is the preferred way to submit bug fixes? The sf tracker? I have two tiny build fixes for 0.98.3 (that also apply to 0.98.5) that fix the build on FreeBSD 7 and also works around some tcl/tl detection strangeness. Both patches are one liners to setupext.py. Cheers, Michael
On Sun, Dec 14, 2008 at 8:31 PM, Michael Abshoff <mab...@go...> wrote: > Slightly OT: What is the preferred way to submit bug fixes? The sf > tracker? I have two tiny build fixes for 0.98.3 (that also apply to Even though it's not a FAQ, we have a FAQ entry for it :-) http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch JDH
On Sun, Dec 14, 2008 at 11:24 AM, Charlie Moad <cw...@gm...> wrote: > First of all let me apologize for the problems we have been > ...snip... > seeing with the binaries as of late. Frankly the root of the problem > seeing osx fat binaries with 4 architectures! I am more than happy to > continue to contribute my time to create these builds, but I think it > only makes sense to have a release candidate cycle before formally > pushing to sourceforge. I think this is a good suggestion which we will adopt going forward. I rushed the process because I was interested in getting a release out before my talk last week since I wanted to show off some of the new stuff, and thought we had done this enough times that it would go smoothly under an expedited schedule, but clearly it did not. So going forward we will make the release branch first, post release candidates with binaries, announce testing of them, give them at least a week to shake out the bugs, fix the changes on the branch and merge into trunk, and then build the final release from the branch. I have updated the release_guide instructions in the developer's guide http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/devel/release_guide.rst?view=markup What are the architectures you are referring to when you write "osx fat binaries with 4 architectures". I am not sure what they are, but I doubt we will choose to support all of them :-) I do think having platform specific make scripts which do everything necessary to checkout and build the dependencies and releases is the right way to go. As you probably saw from my post yesterday, I wrote one of these for OSX yesterday and put it in release/osx, so we should update and use that going forward -- we can refine this even further to incorporate some testing, etc, but it is a good start. If you have time to work on an analog for win32, that would be great, otherwise I may hold my nose and give it a try. Sorry for the extra workload and stress created by this fumble of a release.... JDH