A couple of weeks ago we talked about doing a release, but with the deluge of changes (stix fonts, site.cfg, and others) I thought it might be a good idea to shake the tree for bugs. I think enough time has elapsed since these changes went in that we should proceed with the plan to release 0.91 if there are no objections. Charlie, what does your schedule look like? JDH
Ready whenever. I did a test 10.5 bulid a few days ago targeting 10.4 with the latest libpng and freetype statically linked in. All went pretty well. I'll write up build instructions similar to yours when I go through the motions again. - Charlie On Nov 26, 2007, at 4:55 PM, John Hunter wrote: > A couple of weeks ago we talked about doing a release, but with the > deluge of changes (stix fonts, site.cfg, and others) I thought it > might be a good idea to shake the tree for bugs. I think enough time > has elapsed since these changes went in that we should proceed with > the plan to release 0.91 if there are no objections. Charlie, what > does your schedule look like? > > JDH
On Nov 26, 2007 5:42 PM, Charles Moad <cw...@gm...> wrote: > Ready whenever. I did a test 10.5 bulid a few days ago > targeting 10.4 with the latest libpng and freetype statically linked > in. All went pretty well. I'll write up build instructions similar > to yours when I go through the motions again. I just completed a successful test of r4472 so lets go ahead with the release on that version number. Thanks! JDH
To clarify.... - 0.91 - numpy only - no wx compiled in (since 2.8 is pure python) - should tk use the default OSX installation for leopard? 10.5 comes with a working freetype, but I was still going to statically link it in for 10.4 users. It will be a FAT build. - Charlie On Nov 27, 2007 1:45 PM, John Hunter <jd...@gm...> wrote: > On Nov 26, 2007 5:42 PM, Charles Moad <cw...@gm...> wrote: > > Ready whenever. I did a test 10.5 bulid a few days ago > > targeting 10.4 with the latest libpng and freetype statically linked > > in. All went pretty well. I'll write up build instructions similar > > to yours when I go through the motions again. > > I just completed a successful test of r4472 so lets go ahead with the > release on that version number. > > Thanks! > JDH >
On Nov 27, 2007 2:05 PM, Charlie Moad <cw...@gm...> wrote: > To clarify.... > > - 0.91 > - numpy only > - no wx compiled in (since 2.8 is pure python) > - should tk use the default OSX installation for leopard? Yes on the first three -- I am not sure what the last question is referring to so perhaps you could elaborate. JDH
The last few builds for OSX I have done, somone (don't remember who) complained that I didn't build against ActiveTCL. I didn't know if others had a preference on this. - Charlie On Nov 27, 2007 5:05 PM, John Hunter <jd...@gm...> wrote: > On Nov 27, 2007 2:05 PM, Charlie Moad <cw...@gm...> wrote: > > To clarify.... > > > > - 0.91 > > - numpy only > > - no wx compiled in (since 2.8 is pure python) > > - should tk use the default OSX installation for leopard? > > Yes on the first three -- I am not sure what the last question is > referring to so perhaps you could elaborate. > > JDH >
On Nov 27, 2007 5:00 PM, Charlie Moad <cw...@gm...> wrote: > The last few builds for OSX I have done, somone (don't remember who) > complained that I didn't build against ActiveTCL. I didn't know if > others had a preference on this. I think native tcl/tk is preferable, but this is not a terribly informed opinion. If you don't hear otherwise from someone else, just build under that assumption. JDH
On Nov 28, 2007, at 12:03 AM, John Hunter wrote: > I think native tcl/tk is preferable, but this is not a terribly > informed opinion. If you don't hear otherwise from someone else, just > build under that assumption. I am still having issues with Tk on my machine (native? version 8.4.7). In particular, event.key does not register (which I use quite a bit in my interactive grid generation tools). Not even the 'g' to toggle the grid. I also get an error when creating a figure instance: 2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool(): Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased with no pool in place - just leaking <matplotlib.figure.Figure instance at 0x711300> Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the latest svn. I don't think anyone else is experiencing this problem. I reported it earlier, and John said it works fine for him -- nobody else chimed in to say they had the same problem... I just wanted to be sure you all were aware of potential Tk problems before your release. -Rob ---- Rob Hetland, Associate Professor Dept. of Oceanography, Texas A&M University http://pong.tamu.edu/~rob phone: 979-458-0096, fax: 979-845-6331
Charles Moad wrote: > Ready whenever. I did a test 10.5 bulid a few days ago > targeting 10.4 with the latest libpng and freetype statically linked > in. Great! A note about that -- I just built an app with Py2exe and delivered to someone that then couldn't run it, 'cause it's linked with the freetype in Apple's X11 -- I guess X11 isn't installed by default, so we really do need to keep that statically linked. are libpng and libfreetype the only two we need now? Charlie, is there somewhere I can get that built to try it out? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Charlie Moad wrote: > - 0.91 > - numpy only > - no wx compiled in (since 2.8 is pure python) > - should tk use the default OSX installation for leopard? > 10.5 comes with a working freetype, but I was still going to > statically link it in for 10.4 users. It will be a FAT build. sounds good to me. I'm +0 on the Tk issue -- I don't use it. I think it may have been Russell Owen that had issues with Tk -- I've forwarded a note to him, so he can comment if he wants to. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Before I push the OSX binary to SF I have 2 questions. 1. I used to be able to rename the file from "i386" to "fat" and have it install on a ppc or intel machine. This doesn't seem to work anymore even though this is a fat build. Any clues on how to approach this? 2. Can anyone test this on 10.4? This brings up a similar naming issue. Will 10.5 detect and install 10.4 labeled eggs from SF? http://dev.imamuseum.org/~cmoad/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg - Charlie
My 1 year old only let me get the source release pushed last night and build the mac release. I'll try to get the windows builds posted tonight. On Nov 28, 2007 8:23 AM, Rob Hetland <he...@ta...> wrote: > > On Nov 28, 2007, at 12:03 AM, John Hunter wrote: > > > > I think native tcl/tk is preferable, but this is not a terribly > > informed opinion. If you don't hear otherwise from someone else, just > > build under that assumption. > > I am still having issues with Tk on my machine (native? version > 8.4.7). In particular, event.key does not register (which I use > quite a bit in my interactive grid generation tools). Not even the > 'g' to toggle the grid. I also get an error when creating a figure > instance: > > 2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool(): > Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased > with no pool in place - just leaking > <matplotlib.figure.Figure instance at 0x711300> > > Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the > latest svn. > > I don't think anyone else is experiencing this problem. I reported > it earlier, and John said it works fine for him -- nobody else chimed > in to say they had the same problem... > > I just wanted to be sure you all were aware of potential Tk problems > before your release. > > -Rob > > ---- > Rob Hetland, Associate Professor > Dept. of Oceanography, Texas A&M University > http://pong.tamu.edu/~rob > phone: 979-458-0096, fax: 979-845-6331 > > >
Great work everyone with getting the release out! Now is probably a good time to discuss how the SVN repository will look after the release. My thoughts are below -- any and all concerns or suggestions are welcome. I'm happy to do this work, and will probably wait until next week sometime to give the release some time to cool off, in case a major stopper bug is discovered in the meantime. A lot of this is perhaps obvious, but it doesn't hurt to be specific ;) PLAN: 1. Create a new branch based on the release version (I think Charlie last put it at r4477), in "branches/RELEASE_0_91_0". This branch will be "locked" to provide a little speedbump to remind us not to commit to it. This branch is useful to have as a point of comparison -- though not strictly necessary, since we know the release version on the trunk. 2. Create a new branch based on the head of the trunk, in "branches/MAINT_0_x". This will be used for bug fixes to the 0.x tree. It may get copied into "branches/RELEASE_0_91_1" (or some such) in the future, if we want to make a bugfix release without the transforms changes. 3. Setup the svnmerge.py properties so that it is easy to merge bugfixes on MAINT_0_x back into the trunk. (This is the "Merging branches back to trunk" case in [1]). 4. Merge "branches/transforms" back into "trunk". All developers who currently have the trunk checked out will transparently be moved to the new transforms branch on their next "svn up". 5. Move "branches/transforms" to "branches/closed/transforms" (or "closed_branches/transforms", if you prefer). There are two minds about moving or deleting closed branches, but personally, I like to retain them to make it easier to find history within the branch. One possible downside of this plan is with anyone committing while I do this. It's easy enough to lock things while I do all this, but that may inconvenience some. Any suggestions about making the transition smoother are welcome. [1] Svnmerge.py documentation. http://www.orcaware.com/svn/wiki/Svnmerge.py#Quick_Usage_Overview Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Nov 28, 2007 1:07 PM, Michael Droettboom <md...@st...> wrote: > Great work everyone with getting the release out! > > Now is probably a good time to discuss how the SVN repository will look > after the release. > > My thoughts are below -- any and all concerns or suggestions are > welcome. I'm happy to do this work, and will probably wait until next > week sometime to give the release some time to cool off, in case a major > stopper bug is discovered in the meantime. A lot of this is perhaps > obvious, but it doesn't hurt to be specific ;) > > PLAN: > > 1. Create a new branch based on the release version (I think Charlie > last put it at r4477), in "branches/RELEASE_0_91_0". This branch will > be "locked" to provide a little speedbump to remind us not to commit to > it. This branch is useful to have as a point of comparison -- though > not strictly necessary, since we know the release version on the trunk. Bearing in mind that I am a branch newbie, this seems a bit overly complicated. I envisioned having a single branch which would be the svn trunk before you merge your transforms in. Call this MAINTAIN_91 or something like that. Then merge the transforms branch into the trunk, and close or move the transforms branch as you see fit. That way we have one active branch (the 0.91 maintenance) and one trunk. I don't see the benefit of having RELEASE_0_91_0 and MAINT_0_x branches, since we can use use -r checkouts to get 0.91.0 right? Basically, I hope we can get by w/o multiple branches for the 91 maintenance. But feel free to educate me :-) JDH
John Hunter wrote: > On Nov 28, 2007 1:07 PM, Michael Droettboom <md...@st...> wrote: >> Great work everyone with getting the release out! >> >> Now is probably a good time to discuss how the SVN repository will look >> after the release. >> >> My thoughts are below -- any and all concerns or suggestions are >> welcome. I'm happy to do this work, and will probably wait until next >> week sometime to give the release some time to cool off, in case a major >> stopper bug is discovered in the meantime. A lot of this is perhaps >> obvious, but it doesn't hurt to be specific ;) >> >> PLAN: >> >> 1. Create a new branch based on the release version (I think Charlie >> last put it at r4477), in "branches/RELEASE_0_91_0". This branch will >> be "locked" to provide a little speedbump to remind us not to commit to >> it. This branch is useful to have as a point of comparison -- though >> not strictly necessary, since we know the release version on the trunk. > > Bearing in mind that I am a branch newbie, this seems a bit overly > complicated. I envisioned having a single branch which would be the > svn trunk before you merge your transforms in. Call this MAINTAIN_91 > or something like that. Then merge the transforms branch into the > trunk, and close or move the transforms branch as you see fit. > > That way we have one active branch (the 0.91 maintenance) and one > trunk. I don't see the benefit of having RELEASE_0_91_0 and MAINT_0_x > branches, since we can use use -r checkouts to get 0.91.0 right? > Basically, I hope we can get by w/o multiple branches for the 91 > maintenance. But feel free to educate me :-) You're correct -- it isn't strictly necessary. IMHO, however, it makes the released 0.91 version more obvious. As it stands now, one has to know to look for the revision associated with 0.91 in the CHANGELOG. It's an attempt to follow standard SVN practice to make things easier for someone coming into the project. Which leads me to a "Doh!" -- it should be under "tags", rather than under "branches". (Of course, in SVN there's no difference, other than the name...) I also should revise these names to fit in with the mpl's tags brought over from CVS: branches/RELEASE_0_91_0 ---> tags/v0_91_0 branches/MAINT_0_x ---> branches/v0_91_maint Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Charlie Moad wrote: > 2. Can anyone test this on 10.4? > http://dev.imamuseum.org/~cmoad/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg I downloaded this, and did: $ easy_install matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg and got what I enclosed below. The short version: it went and found the source from pypi, and built it on my machine. The build appears to work fine. However, I do have freetype and libpng. It would have presumably failed otherwise. Was it supposed to install a binary? OS-X 10.4.10 PPC Dual G5. Python2.5 Universal Framework build from pythonmac.org/packages -Chris Processing matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg creating /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg Extracting matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg to /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages Removing matplotlib 0.90.1-r4407 from easy-install.pth file Adding matplotlib 0.91.0 to easy-install.pth file Installed /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.91.0-py2.5-macosx-10.5-i386.egg Processing dependencies for matplotlib==0.91.0 Searching for matplotlib==0.91.0 Reading http://cheeseshop.python.org/pypi/matplotlib/ Reading http://matplotlib.sourceforge.net Reading http://cheeseshop.python.org/pypi/matplotlib/0.91.0 Best match: matplotlib 0.91.0 Downloading http://pypi.python.org/packages/source/m/matplotlib/matplotlib-0.91.0.tar.gz#md5=059aa32556644760aef9cec9fb8fc3ac Processing matplotlib-0.91.0.tar.gz Running matplotlib-0.91.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-8sWQab/matplotlib-0.91.0/egg-dist-tmp-I3Dgc1 ============================================================================ BUILDING MATPLOTLIB matplotlib: 0.91.0 python: 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] platform: darwin REQUIRED DEPENDENCIES numpy: 1.0.3.1 freetype2: found, but unknown version (no pkg-config) OPTIONAL BACKEND DEPENDENCIES libpng: found, but unknown version (no pkg-config) Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4 wxPython: 2.8.4.0 * WxAgg extension not required for wxPython >= 2.8 Gtk+: no * Building for Gtk+ requires pygtk; you must be able * to "import gtk" in your build/install environment Qt: no Qt4: no Cairo: no OPTIONAL DATE/TIMEZONE DEPENDENCIES datetime: present, version unknown dateutil: matplotlib will provide pytz: matplotlib will provide OPTIONAL USETEX DEPENDENCIES dvipng: no ghostscript: 7.07.1 latex: 3.141592 EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES configobj: matplotlib will provide enthought.traits: matplotlib will provide [Edit setup.cfg to suppress the above messages] ============================================================================ warning: no files found matching 'NUMARRAY_ISSUES' warning: no files found matching 'MANIFEST' warning: no files found matching 'matplotlibrc' warning: no files found matching 'lib/matplotlib/toolkits' no previously-included directories found matching 'examples/_tmp_*' i686-apple-darwin8-gcc-4.0.1: powerpc-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: Tcl: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: Tk: linker input file unused because linking not done -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: Tcl: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: Tk: linker input file unused because linking not done zip_safe flag not set; analyzing archive contents... dateutil.zoneinfo.__init__: module references __file__ enthought.etsconfig.etsconfig: module references __file__ enthought.traits.trait_db: module MAY be using inspect.stack enthought.traits.ui.tk.helper: module references __file__ enthought.traits.ui.tk.image_enum_editor: module references __file__ matplotlib.__init__: module references __file__ matplotlib.pyparsing: module MAY be using inspect.stack matplotlib.backends.backend_cocoaagg: module references __file__ matplotlib.config.cutils: module references __file__ pytz.__init__: module references __file__ pytz.tzfile: module references __file__ Removing matplotlib 0.91.0 from easy-install.pth file Adding matplotlib 0.91.0 to easy-install.pth file Installed /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.91.0-py2.5-macosx-10.3-fat.egg Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x1659f58>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/transforms.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x16598f0>> ignored Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x1659c60>> ignored -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
So here's my plan. I just got an iMac a few weeks ago and I had to spend a little time getting parallels setup with VS2003... yada yada yada. I plan on cutting a 0.91.1 release tomorrow followed shortly by windows and mac builds. Hopefully nothing radical has snuck into the svn tree since the 0.91.0 build. - Charlie On Nov 28, 2007 8:32 AM, Charlie Moad <cw...@gm...> wrote: > My 1 year old only let me get the source release pushed last night and > build the mac release. I'll try to get the windows builds posted > tonight. > > > On Nov 28, 2007 8:23 AM, Rob Hetland <he...@ta...> wrote: > > > > On Nov 28, 2007, at 12:03 AM, John Hunter wrote: > > > > > > > I think native tcl/tk is preferable, but this is not a terribly > > > informed opinion. If you don't hear otherwise from someone else, just > > > build under that assumption. > > > > I am still having issues with Tk on my machine (native? version > > 8.4.7). In particular, event.key does not register (which I use > > quite a bit in my interactive grid generation tools). Not even the > > 'g' to toggle the grid. I also get an error when creating a figure > > instance: > > > > 2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool(): > > Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased > > with no pool in place - just leaking > > <matplotlib.figure.Figure instance at 0x711300> > > > > Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the > > latest svn. > > > > I don't think anyone else is experiencing this problem. I reported > > it earlier, and John said it works fine for him -- nobody else chimed > > in to say they had the same problem... > > > > I just wanted to be sure you all were aware of potential Tk problems > > before your release. > > > > -Rob > > > > ---- > > Rob Hetland, Associate Professor > > Dept. of Oceanography, Texas A&M University > > http://pong.tamu.edu/~rob > > phone: 979-458-0096, fax: 979-845-6331 > > > > > > >
On Nov 29, 2007 7:45 PM, Charlie Moad <cw...@gm...> wrote: > So here's my plan. I just got an iMac a few weeks ago and I had to > spend a little time getting parallels setup with VS2003... yada yada > yada. I plan on cutting a 0.91.1 release tomorrow followed shortly by > windows and mac builds. Hopefully nothing radical has snuck into the > svn tree since the 0.91.0 build. No nothing radical, but there have been a few of changes and patches so at a minimum, be sure and run backend driver to test. Good luck, JDH
Sorry for the delay. Apparently at some point the mingw compiler became default, and it was giving me problems since I was trying to build with the VS libpng and freetype. All binaries are posted now. Jon, you should probably send the announcement since I am a little out of touch with the changes since 0.90. - Charlie On Nov 29, 2007 8:45 PM, Charlie Moad <cw...@gm...> wrote: > So here's my plan. I just got an iMac a few weeks ago and I had to > spend a little time getting parallels setup with VS2003... yada yada > yada. I plan on cutting a 0.91.1 release tomorrow followed shortly by > windows and mac builds. Hopefully nothing radical has snuck into the > svn tree since the 0.91.0 build. > > - Charlie > > > On Nov 28, 2007 8:32 AM, Charlie Moad <cw...@gm...> wrote: > > My 1 year old only let me get the source release pushed last night and > > build the mac release. I'll try to get the windows builds posted > > tonight. > > > > > > On Nov 28, 2007 8:23 AM, Rob Hetland <he...@ta...> wrote: > > > > > > On Nov 28, 2007, at 12:03 AM, John Hunter wrote: > > > > > > > > > > I think native tcl/tk is preferable, but this is not a terribly > > > > informed opinion. If you don't hear otherwise from someone else, just > > > > build under that assumption. > > > > > > I am still having issues with Tk on my machine (native? version > > > 8.4.7). In particular, event.key does not register (which I use > > > quite a bit in my interactive grid generation tools). Not even the > > > 'g' to toggle the grid. I also get an error when creating a figure > > > instance: > > > > > > 2007年11月28日 14:19:46.440 Python[19291] *** _NSAutoreleaseNoPool(): > > > Object 0x17ca2f30 of class NSCarbonWindowContentView autoreleased > > > with no pool in place - just leaking > > > <matplotlib.figure.Figure instance at 0x711300> > > > > > > Other backends (tried Wx 2.8.6.1 and Qt4) _do_ work fine on the > > > latest svn. > > > > > > I don't think anyone else is experiencing this problem. I reported > > > it earlier, and John said it works fine for him -- nobody else chimed > > > in to say they had the same problem... > > > > > > I just wanted to be sure you all were aware of potential Tk problems > > > before your release. > > > > > > -Rob > > > > > > ---- > > > Rob Hetland, Associate Professor > > > Dept. of Oceanography, Texas A&M University > > > http://pong.tamu.edu/~rob > > > phone: 979-458-0096, fax: 979-845-6331 > > > > > > > > > > > >
On Dec 1, 2007 12:03 PM, Charlie Moad <cw...@gm...> wrote: > Sorry for the delay. Apparently at some point the mingw compiler > became default, and it was giving me problems since I was trying to > build with the VS libpng and freetype. All binaries are posted now. > Jon, you should probably send the announcement since I am a little out > of touch with the changes since 0.90. OK, I'll do this on Monday when more people are working and thinking about python. Thanks again for the build! JDH