Re: [matplotlib-devel] release plans
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 <[EMAIL PROTECTED]> 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 > > > 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 > > > - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release plans
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 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 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Nov 21, 2007 1:52 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Thanks, that works, but unforunately only on emacs21 but not xemacs 21. > Looks like I'll now have to find a way to do the one thing in emacs that > keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.) I think I may have found the ultimate emacs solution. It really annoys me to see the trailing whitespace in my buffer. When I start a new indented line but end up not adding anything there, it highlights the region from the left of the to where the cursor was a trailing whitespace so I have a lot of ugly red blocks in my buffer. My new solution is not to highlight it, but to add a hook to emacs to delete it whenever I save my buffer. (add-hook 'python-mode-hook (lambda () (add-hook 'local-write-file-hooks 'delete-trailing-whitespace) )) Now I can be blissfully unaware of trailing whitespace as before, and my editor will clean it out on save. JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
For those using emacs-22.1 (apparently local-write-file-hooks is deprecated and didn't work for me) ---> (setq python-mode-hook '(lambda () (add-hook 'write-file-functions 'delete-trailing-whitespace) )) Maybe we should do a big trailing whitespace removal en masse once we move the transforms branch to trunk to get this taken care of once and for all... (?) Cheers, Mike John Hunter wrote: > On Nov 21, 2007 1:52 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: >> Thanks, that works, but unforunately only on emacs21 but not xemacs 21. >> Looks like I'll now have to find a way to do the one thing in emacs that >> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.) > > I think I may have found the ultimate emacs solution. It really > annoys me to see the trailing whitespace in my buffer. When I start a > new indented line but end up not adding anything there, it highlights > the region from the left of the to where the cursor was a trailing > whitespace so I have a lot of ugly red blocks in my buffer. My new > solution is not to highlight it, but to add a hook to emacs to delete > it whenever I save my buffer. > > (add-hook 'python-mode-hook > (lambda () > (add-hook 'local-write-file-hooks 'delete-trailing-whitespace) > )) > > Now I can be blissfully unaware of trailing whitespace as before, and > my editor will clean it out on save. > > JDH > > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
John Hunter wrote: > On Nov 21, 2007 1:52 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: >> Thanks, that works, but unforunately only on emacs21 but not xemacs 21. >> Looks like I'll now have to find a way to do the one thing in emacs that >> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.) > > I think I may have found the ultimate emacs solution. It really > annoys me to see the trailing whitespace in my buffer. When I start a > new indented line but end up not adding anything there, it highlights > the region from the left of the to where the cursor was a trailing > whitespace so I have a lot of ugly red blocks in my buffer. My new > solution is not to highlight it, but to add a hook to emacs to delete > it whenever I save my buffer. > > (add-hook 'python-mode-hook > (lambda () > (add-hook 'local-write-file-hooks 'delete-trailing-whitespace) > )) > > Now I can be blissfully unaware of trailing whitespace as before, and > my editor will clean it out on save. John, Excellent! I always thought that something like this should be the solution--and should be a standard part of python mode (and of other language-specific modes)--but not being an emacs user, I did not know how to do it. I assume there is also some sort of C and/or C++ mode, and similar hook additions are needed for them--correct? Or is there a hierarchy of modes, in which case a single hook could go at a higher level? Eric - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Nov 28, 2007 11:46 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > I assume there is also some sort of C and/or C++ mode, and similar hook > additions are needed for them--correct? Or is there a hierarchy of > modes, in which case a single hook could go at a higher level? I don't know about a hierarchy, but there is a c++-mode-hook and a c-mode-hook. I've updated the CODING_GUIDE to advise emacs users to set these hooks. Soon your nightmare of trailing whitespaces will be nothing more than a nasty memory JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Nov 28, 2007 12:22 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > So, I think perhaps this description in CODING_GUIDE is backward, but > wanted to double check before I fix it. Yep, good catch. I updated the doc. I think I have it this time... Please do not commit lines with trailing white space, as it causes noise in svn diffs. If you are an emacs user, the following in your .emacs will cause emacs to strip trailing white space on save for python, C and C++ ; and similarly for c++-mode-hook and c-mode-hook (add-hook 'python-mode-hook (lambda () (add-hook 'write-file-functions 'delete-trailing-whitespace))) for older versions of emacs (emacs<22) you need to do (add-hook 'python-mode-hook (lambda () (add-hook 'local-write-file-hooks 'delete-trailing-whitespace))) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
I think the emacs version dependency in the CODING_GUIDE may be backward. AFAIK, "write-file-functions" is the current one to use for emacs 22 (the latest released version) and beyond. "local-write-file-hooks" is the old deprecated way. The docstring for local-write-file-hooks is: "This variable is obsolete since 22.1; use `write-file-functions' instead." So, I think perhaps this description in CODING_GUIDE is backward, but wanted to double check before I fix it. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA John Hunter wrote: > On Nov 28, 2007 11:46 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > >> I assume there is also some sort of C and/or C++ mode, and similar hook >> additions are needed for them--correct? Or is there a hierarchy of >> modes, in which case a single hook could go at a higher level? > > I don't know about a hierarchy, but there is a c++-mode-hook and a > c-mode-hook. I've updated the CODING_GUIDE to advise emacs users to > set these hooks. Soon your nightmare of trailing whitespaces will be > nothing more than a nasty memory > > JDH > > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Wednesday 28 November 2007 01:12:00 pm John Hunter wrote: > On Nov 28, 2007 11:46 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > > I assume there is also some sort of C and/or C++ mode, and similar hook > > additions are needed for them--correct? Or is there a hierarchy of > > modes, in which case a single hook could go at a higher level? > > I don't know about a hierarchy, but there is a c++-mode-hook and a > c-mode-hook. I've updated the CODING_GUIDE to advise emacs users to > set these hooks. Soon your nightmare of trailing whitespaces will be > nothing more than a nasty memory Am I the only one who never got comfortable using emacs? - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Post-release plans [was: Re: release plans]
On Nov 28, 2007 1:07 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Post-release plans [was: Re: release plans]
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 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Post-release plans [was: Re: release plans]
John Hunter wrote: > On Nov 28, 2007 1:07 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts bug in 0.91.0 release
On Nov 28, 2007 2:21 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I suppose this was bound to happen... > > The released version has a bug that prevents using the (serif) STIX > fonts. Entirely my fault for not checking all font possibilities after > a recent change. > > r4492 fixes this bug. > > Let me know how you want to proceed... I'm happy to help cutting > another release if we decide to do that. I think we should wait until we've had a chance to collect a few bugs first... We'll announce on mpl-users, and after a few days to give bugs a chance to filter in, we'll cut 90.1, and then announce to a wider audience, eg python-list. JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] STIX fonts bug in 0.91.0 release
I suppose this was bound to happen... The released version has a bug that prevents using the (serif) STIX fonts. Entirely my fault for not checking all font possibilities after a recent change. r4492 fixes this bug. Let me know how you want to proceed... I'm happy to help cutting another release if we decide to do that. Sorry, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release plans
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
Re: [matplotlib-devel] STIX fonts bug in 0.91.0 release
So should I bother with binary releases for 0.91.0? I assume you meant 0.91.1 below as well. - Charlie On Nov 28, 2007, at 3:34 PM, John Hunter wrote: > On Nov 28, 2007 2:21 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> I suppose this was bound to happen... >> >> The released version has a bug that prevents using the (serif) STIX >> fonts. Entirely my fault for not checking all font possibilities >> after >> a recent change. >> >> r4492 fixes this bug. >> >> Let me know how you want to proceed... I'm happy to help cutting >> another release if we decide to do that. > > I think we should wait until we've had a chance to collect a few bugs > first... We'll announce on mpl-users, and after a few days to give > bugs a chance to filter in, we'll cut 90.1, and then announce to a > wider audience, eg python-list. > > JDH > > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts bug in 0.91.0 release
On Nov 28, 2007 7:55 PM, Charles Moad <[EMAIL PROTECTED]> wrote: > So should I bother with binary releases for 0.91.0? I assume you > meant 0.91.1 below as well. Yes, I meant 91.1 and yes, we should go ahead with the binary releases. The only way we can find any bugs in the current release, including any problems we may see with the binaries, is to put out 91.0 in full bloom. Since it has been a long time since we did a release, and a lot of work has gone in in the interim, we can anticipate some bugs in the first week and hopefully we can sort them out pretty quickly and pt out a stable bugfix release next week. Now if only your baby will let you get some real work done :-) JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts bug in 0.91.0 release
On Nov 28, 2007 9:21 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Nov 28, 2007 7:55 PM, Charles Moad <[EMAIL PROTECTED]> wrote: > > So should I bother with binary releases for 0.91.0? I assume you > > meant 0.91.1 below as well. > > Yes, I meant 91.1 and yes, we should go ahead with the binary > releases. The only way we can find any bugs in the current release, > including any problems we may see with the binaries, is to put out > 91.0 in full bloom. Alternatively, if it is not much more work since you haven't built the binaries to get the latest snapshot with Michael's fix and just release it as 91.1 now, that would be great too. I just think we need to get a full release out so people can and will test on a variety of systems before we can assume that the important bugs are out. JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
