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
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
Chris.Barker@...236...
I just completed a successful test of r4472 so lets go ahead with the
release on that version number.
Thanks!
JDH
On Nov 26, 2007 5:42 PM, Charles Moad <cwmoad@...149...> 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.
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 <jdh2358@...149...> wrote:
On Nov 26, 2007 5:42 PM, Charles Moad <cwmoad@...149...> 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
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 2:05 PM, Charlie Moad <cwmoad@...149...> 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?
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 <jdh2358@...149...> wrote:
On Nov 27, 2007 2:05 PM, Charlie Moad <cwmoad@...149...> 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
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 27, 2007 5:00 PM, Charlie Moad <cwmoad@...149...> 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.
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
Chris.Barker@...236...
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
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
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.
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331
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 <hetland@...345...> 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
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
On Nov 28, 2007 1:07 PM, Michael Droettboom <mdroe@...31...> 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 specificPLAN:
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.
John Hunter 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 specificPLAN:
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
On Nov 28, 2007 1:07 PM, Michael Droettboom <mdroe@...31...> wrote:
--
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 matplotlib · PyPI
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
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
Chris.Barker@...236...
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 <cwmoad@...149...> 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 <hetland@...345...> 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
>
>
>
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
On Nov 29, 2007 7:45 PM, Charlie Moad <cwmoad@...149...> 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.
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 <cwmoad@...149...> 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 <cwmoad@...149...> 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 <hetland@...345...> 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
> >
> >
> >
>
OK, I'll do this on Monday when more people are working and thinking
about python. Thanks again for the build!
JDH
On Dec 1, 2007 12:03 PM, Charlie Moad <cwmoad@...149...> 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.
