Re: [matplotlib-devel] What would you like to see in a book about Matplotlib?

2009-01-05 Thread Russell E. Owen 
In article 
<[email protected]>,
 "Sandro Tosi"  wrote:

> Hello and Happy 2009!
> 
> I received the interesting proposal to author a book on Matplotlib,
> the powerful 2D plotting library for Python.
> 
> While preparing the arguments list, I'd like to hear even your
> opinion, because different points-of-view will lead to a better
> product.
> 
> Some basic question I'd like to ask are:
> 
> - what are you using matplotlib for?

Plotting data from a networked Tkinter application.

> - what are the (basic) things that, when you were beginning to use
> matplotlib, you wanted to see grouped up but couldn't find?
> - what would you like to see in a book about matplotlib?

I want a user's guide for the class API. So far I've figured it out by 
reading examples, trying to extrapolate from the pylab user's guide 
(which is quite good) and reading the class API reference, but I feel 
that I barely understand what I am doing.

> - what are the things you'd like to explore of matplotlib and never
> had time to do?

I'd like to know how best to handle plotting data as it arrives (e.g. 
strip charts and evolving x-y plots). I've got code that works but am 
not convinced I'm doing it in the best fashion.

Histograms.

-- Russell


--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib Mac binary aborts with 3rd party Tcl/Tk

2009-01-29 Thread Russell E. Owen 
The current matplotlib Mac binary installer unfortunately reintroduces 
an old problem: it does not work if the user has a 3rd party Tcl/Tk 
installed (as anyone who uses Tkinter seriously would have).

The solution is simple: if one is building a matplotlib Mac binary 
installer then please, please install ActiveState Tcl/Tk first 
(preferably the latest version of 8.4 -- which is 8.4.19 last I 
checked). The resulting binary will work with the built-in Tcl/Tk as 
well as any user's 3rd party Tcl/Tk.

Without this "fix", the resulting binary will abort with any attempt to 
produce a graph using TkAgg and a 3rd party Tcl/Tk.

ISo...could I request a new Mac binary with this fix in place? Or at 
least that future Mac binaries will be built this way?

-- Russell

P.S. the situation could get "interesting" with a future version of 
MacOS X during the transition from Tcl/Tk 8.4 to 8.5. But for now just 
sticking with 8.4 is safe since it is the recommended version for Python 
2.5 and is also what comes with MacOS X.

P.P.S. I suspect (but have not confirmed) that Mac Python 2.5.4 has this 
same problem. Mac Python 2.5.2 is definitely OK.


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mkpg on OSX

2009-08-03 Thread Russell E. Owen 
In article 
<[email protected]>,
 John Hunter  wrote:

> I tried testing the OSX binaries I built Friday on my local OSX laptop
> today, and had a problem with the mkpg installer
> 
> http://drop.io/xortel1/asset/matplotlib-0-99-0-rc1-py2-5-macosx10-5-zip
> 
> On the sage box I used to do the builds, the default python path that
> the installer picks up is
> 
>   /Library/Python/2.5/site-packages
> 
> and this is where it put mpl when I ran the installer on my local box.
>  But then when I try and import matplotlib on my local box w/o
> modifying the PYTHONPATH, I can't find it because my local python is
> looking in
> 
>   /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-package
>   s/
> 
> Is one of these two locations preferable for the default?  Is there a
> way to inform bdist_mkpg of the desired install target? Is there any
> notion of the right way to do things w/ python on OSX?

I just tried the 0.99.0 installation myself and ran into the same issue. 
I expected it to work with my python.org python, which would be the 
latter path, but instead it went into /Library/Python/2.5/site-packages 
(where my normal python.org python can't find it).

If you are using bdist_mpkg then it should do the right thing as long as 
you build the python with your python.org python 
(/Library/Frameworks...) instead of the system python.

-- Russell


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] problems installing matplotlib 0.99 for pyhton 2.6 mac osx 10.5

2009-09-10 Thread Russell E. Owen 
In article <[email protected]>,
 Farhan Sheikh  wrote:

> Dear all,
> 
> i have python 2.6 running on my mac osx 10.5, however when installing  
> the binary file provided, it says i need to have python 2.6 on my  
> machine. i dont understand why this is happening as when open a new  
> terminal and type 'python', python version 2.6.2 is the version that  
> is run. My supervisor also had a look at this and could not figure it  
> out. He linked python 2.6 with the python command but the install file  
> still did not recognise python 2.6.
> 
> anybody have the same issue? or know of how to fix this issue?
> 
> is there a.tar.gz version so i can build via terminal?
> 
> Thank You
> 
> Farhan

I think that the official Mac binary installer wants Python 2.6.x to be 
a framework build in /Library/Frameworks (e.g. as you would get by 
installing the Mac python at python.org). Unfortunately, there are many 
other pythons, including fink, MacPorts and Apple's preinstalled version 
(which is 2.5.something on MacOS X 10.5, so that's not the problem).

So which python do you have? One way to find out: in Terminal type 
"which python" and tell us the results.

-- Russell


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mac install 1.0.0

2010-10-22 Thread Russell E. Owen 
In article <[email protected]>,
 Paul Kienzle  wrote:

> Note a small issue on the install of matplotlib-1.0.0 python 2.6 mac  
> dmg.
> 
> The files in mpl-data/images were not installed with read permissions  
> for all.
> 
> This resulted in an error that _cidgcf was not a valid attribute in  
> FigureManager.
> 
> This affected one 10.5 machine but not another --- we have no idea why.
> 
>  - Paul
> 
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev

I produced these binaries and unfortunately ran into a number of 
problems including:
- Incorrect file permissions (an odd bug in bdist_mpkg) subsequently 
fixed with a new binary
- The binary was not compatible with Mac OS X 10.3.9 and 10.4 for 
reasons I still have not worked out.
- The Python 2.5 binary is not compatible with 3rd party Tkinter (which 
is also true of the python.org Python 2.5). I no longer make binaries 
for Python 2.5 because of this.

I finally built binaries on Mac OS X 10.4 (fixing the file permissions 
along the way) and these are available here:

they are not yet being served at the official site.

I have done some testing of TkAgg on 10.3.9 PPC, and 10.4-10.6 Intel, 
but after all the problems I would appreciate any testing. The 2.6 
version should become the official binary, but only after more 
verification.

The 2.7 is quite experimental because I don't yet have any idea if WxAgg 
works (it all depends on whether the wxPython installer for Mac Python 
2.7 is compatible with the 32-bit version of Python 2.7).

-- Russell


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Release schedule for version 1.0.1?

2010-10-22 Thread Russell E. Owen 
I'm curious when the next release of matplotlib is due.

My application is suffering badly from the issue that an incorrect font 
cache will cause matplotlib to fail (the application mysteriously exits 
partway through startup until the user deletes the font cache).

That problem is allegedly fixed on the trunk and I'm trying to decide 
how best to deal with it. Depending on the timing of 1.0.1 I can decide 
whether it's worth putting in my own workaround, bundling a prerelease 
version of matplotlib or just waiting for the official release.

Regards,

-- Russell

P.S. does anyone know a way to get maplotlib to either not use its font 
cache or to use a version in mpl-data instead of ~/.matplotlib? When 
matplotlib is bundled into an application it seems dangerous for it to 
be sharing cached files with potentially older or newer versions that 
are installed or are bundled with other applications.


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release schedule for version 1.0.1?

2010-10-25 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

>   On 10/22/2010 05:45 PM, Russell E. Owen wrote:
> > I'm curious when the next release of matplotlib is due.
> >
> > My application is suffering badly from the issue that an incorrect font
> > cache will cause matplotlib to fail (the application mysteriously exits
> > partway through startup until the user deletes the font cache).
> >
> > That problem is allegedly fixed on the trunk and I'm trying to decide
> > how best to deal with it. Depending on the timing of 1.0.1 I can decide
> > whether it's worth putting in my own workaround, bundling a prerelease
> > version of matplotlib or just waiting for the official release.
> I'm not sure what the timeframe is on 1.0.1.
> 
> What problem with the cache are you referring to?  I'm aware of a 
> problem where if some fonts are moved or removed after the cache is 
> created matplotlib will crash (and this problem is fixed in the trunk), 
> but is that really a problem in everyday practice?  I'm just curious -- 
> if there's another issue with the cache that I'm not aware of, I'd like 
> to fix it.

The known problem what I am referring to. Fortunately.

It has proven to be a very serious problem in practice. I bundle 
matplotlib into a Mac application and for a significant number of my 
users it crashes at startup due to problems with the matplotlib cache 
files. The fix is always the same: delete the cache.

Some reasons this has happened
- The user first runs the application from the distribution dmg file 
before copying to /Applications
- The user installs it and runs it, but then moves or renames it for 
some reason...boom
- The user had an older version of matplotlib installed but then deleted 
it for some reason.

Fortunately the fix from the trunk will do the job.

That said, it still seems risky to me that matplotlib insists on using a 
shared directory for its cache and matplotlibrc file: that there's no 
way to tell matplotlib to put that data somewhere else (e.g. inside the 
application bundle). With bundled applications it is quite likely the 
user may run multiple versions of matplotlib without even knowing it. If 
any of that data is version-dependent then this is a recipe for 
mysterious problems.

-- Russell


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release schedule for version 1.0.1?

2010-10-25 Thread Russell E. Owen 
In article 
,
 John Hunter  wrote:

> On Fri, Oct 22, 2010 at 7:16 PM, Michael Droettboom 
>  wrote:
> >  On 10/22/2010 05:45 PM, Russell E. Owen wrote:
> >> I'm curious when the next release of matplotlib is due.
> >>
> >> My application is suffering badly from the issue that an incorrect font
> >> cache will cause matplotlib to fail (the application mysteriously exits
> >> partway through startup until the user deletes the font cache).
> >>
> >> That problem is allegedly fixed on the trunk and I'm trying to decide
> >> how best to deal with it. Depending on the timing of 1.0.1 I can decide
> >> whether it's worth putting in my own workaround, bundling a prerelease
> >> version of matplotlib or just waiting for the official release.
> > I'm not sure what the timeframe is on 1.0.1.
> 
> I would be happy to do a release early next week.  Is anyone aware of
> any show stopper bugs that need to be fixed first?  I had hoped to do
> it last week ahead of the ETS release, but simply did not get to it.
> 
> 
> > What problem with the cache are you referring to?  I'm aware of a
> > problem where if some fonts are moved or removed after the cache is
> > created matplotlib will crash (and this problem is fixed in the trunk),
> > but is that really a problem in everyday practice?  I'm just curious --
> > if there's another issue with the cache that I'm not aware of, I'd like
> > to fix it.
> 
> I used to see font cache problems when testing and/or doc building for
> a 0.99 branch release on a machine which had been running 1.0svn
> trunk.  I can't replicate it now, so perhaps it is fixed (though I
> have only tried reverting the install and making plots, not doing full
> doc builds).  The only commit related to the cache since the 1.0
> release that I see is
> 
>   r8712 | mdboom | 2010-09-21 16:13:25 -0400 (Tue, 21 Sep 2010) | 2 lines
> 
>   If a font file is looked up in the cache, but that font file no longer 
>   exists
>   on disk, rebuild the cache.
> 
> Not sure why this would caused a failure in the case of going from 1.0
> to 0.99 ...

That's the fix I wanted.

Oddly enough, I never noticed the problem until I started bundling 1.0.0 
with my application. Then I had many reports of it. However, I also 
started bundling a strip chart widget and it's conceivable that my 
earlier simpler plots never needed the font cache.

> Russell, a good solution for you, not just for this particular
> problem, but in general, is to use MPLCONFIGDIR in your application.
> This will give you a custom location for your rc file, font cache,
> etc  We use it on the buildbots which are running multiple
> installations of mpl to avoid clashes.

Thank you. That sounds like precisely what I wanted! I can keep my 
application self-contained. Wonderful!

-- Russell


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release schedule for version 1.0.1?

2010-10-28 Thread Russell E. Owen 
In article <[email protected]>,
 Christopher Barker  wrote:

> On 10/25/10 1:41 PM, Daniel Hyams wrote:
> > It doesn't really insist on it right?  There are MATPLOTLIBDIR and
> > MPLCONFIGDIR environment variables.
> 
> > You can set these env variables within your code, before import of
> > matplotlib via os.environment.
> 
> I'm glad I've learned about this, and will start doing it with my 
> bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it 
> be possible to set this sort of thing without resorting to that little 
> round trip through environment variables?
> 
> Not a big deal, but it feels kludgy.
> 
> -Chris

It's an interesting question. You can't call a matplotlib function to do 
it because it has to happen before matplotlib is loaded. I suppose there 
could be a configuration package to perform the operation.

Having looked into it some, I confess I am not that sold on using 
MPLCONFIGDIR in my bundled applications. Issues include:

* The font cache uses absolute paths.

Thus the cache will break if the application is moved or renamed. So 
there is no point to using MPLCONFIGDIR to avoid the problem of 
matplotlib crashing when the font cache is out of date. It cannot help!

* Where to put it?

I had hoped to put it in the bundled application itself, so that it 
would be thrown out when the application was thrown out. But matplotlib 
crashes if the directory cannot be written (pity that; it'd be nice if 
it could run without a font cache). Thus the application could not be 
run from the disk image or from an Applications directory that an admin 
had protected by making it read-only.

I'd like to avoid generating a new MPLCONFIGDIR directory for every 
version of my application (or every version of matplotlib). So it seems 
to me the only sensible choice is to have one MPLCONFIGDIR shared by all 
versions of the application. The only point I can see to doing this is 
to avoid user-written matplotlibrc files: the danger that they would 
mess up the appearance of the application or be incompatible with the 
version of matplotlib in the application.

An alternative is to just keep using the default MPLCONFIGDIR 
(~/.matplotlib) and put up with the risk of a matplotlibrc file doing 
bad things. That's my plan for now since I know few users who bother to 
set exotic things in their matplotlibrc files, and my application 
already explicitly set the important settings.

-- Russell


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-10 Thread Russell E. Owen 
You may have already seen this in the general mailing list, but I've 
found what I think is a serious memory leak in matplotlib 1.0.0: it 
leaks memory every time canvas.draw() is called, at least when using 
TkAgg on unix and Mac.

Admittedly many graphs do not need canvas.draw() to be called repeatedly 
(which I suspect is how it has survived this long). This came up in the 
context of a strip chart widget, where I am changing the x/time axis 
limits regularly and calling canvas.draw() so that the change is visible.

I submitted ticket 3124990 with a very simple demo script:

(you can disable the setting the x limits if you want to see the leak in 
its purest form, but then nothing changes visually on the graph).

I just wanted to be sure folks know about it in hopes somebody might 
have an idea how to fix it. I have not tried any other back ends.

-- Russell


--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-13 Thread Russell E. Owen 
I'm afraid your change didn't help (I only applied the patch to 
lib/matplotlib/text.py; the cbook.py change appeared to only affect 
whitespace).

However, the memory leak is smaller using the svn trunk than in 
matplotlib 1.0.0. Also, calling subplot.clear() makes the leak worse in 
matplotlib 1.0.0 but not on the trunk.

Here are my results in detail. Before each run I show a few lines of 
code from:
<http://www.astro.washington.edu/users/rowen/python/matplotlibMemoryLeak.
py>
MemoryLeaker's _updateTimeAxis method. Note that the third column is a 
measure of the leak rate and I hold off measuring the leak rate for few 
seconds to give the application a chance to fully load.

-- Russell

matplotlib 1.0.0

self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027676   nan
   5.028980   nan
  10.129084  20.6
  15.129172  19.0
  20.129268  19.1
  25.229368  19.3
  30.229464  19.2
  35.229564  19.4
  40.229660  19.3
  45.229764  19.5

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027696   nan
   5.129012   nan
  10.229152  27.5
  15.229292  27.7
  20.229436  28.0
  25.329580  28.1
  30.429728  28.3
  35.429876  28.5
  40.530024  28.6
  45.530160  28.4
  50.630308  28.5


matplotlib svn trunk rev8836

self.subplot.set_xlim(tMin, tMax)
#self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027664   nan
   5.028864   nan
  10.028880   3.2
  15.128884   2.0
  20.128896   2.1
  25.128908   2.2
  30.128916   2.1
  35.128928   2.1
  40.228940   2.2
  45.228948   2.1

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027684   nan
   5.128856   nan
  10.128856   0.0
  15.128856   0.0
  20.128864   0.5
  25.228872   0.8
  30.228880   1.0
  35.228884   0.9
  40.228892   1.0
  45.228900   1.1
  50.228920   1.4
  55.328924   1.4
  60.328932   1.4
  65.328940   1.4

After applying your patch to svn trunk rev8836:
--- lib/matplotlib/text.py (revision 8819)
+++ lib/matplotlib/text.py (working copy)
@@ -143,6 +143,9 @@
Handle storing and drawing of text in window or data coordinates.
"""
zorder = 3
+
+cached = maxdict(50)
+
def __str__(self):
return "Text(%g,%g,%s)"%(self._y,self._y,repr(self._text))

@@ -168,7 +171,6 @@
"""

Artist.__init__(self)
-self.cached = maxdict(5)
self._x, self._y = x, y

if color is None: color = rcParams['text.color']



self.subplot.set_xlim(tMin, tMax)
#self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027656   nan
   5.028852   nan
  10.128864   2.4
  15.128876   2.4
  20.12   2.4
  25.128908   2.8
  30.128916   2.6
  35.128924   2.4
  40.228936   2.4

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027652   nan
   5.028836   nan
  10.028852   3.2
  15.128852   1.6
  20.128872   2.4
  25.128880   2.2
  30.128900   2.6
  35.128904   2.3
  40.228912   2.2
  45.228920   2.1
  50.328928   2.0


In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I think I'm on to something -- it seems that text layout information has 
> a cyclical reference that prevents the Text object from being freed.
> 
> Can you apply the attached patch and let me know if it solves your issue?
> 
> Mike
> 
> On 12/10/2010 02:19 PM, Russell E. Owen wrote:
> > You may have already seen this in the general mailing list, but I've
> > found what I think is a serious memory leak in matplotlib 1.0.0: it
> > leaks memory every time canvas.draw() is called, at least when using
> > TkAgg on unix and Mac.
> >
> > A

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-13 Thread Russell E. Owen 
I also wanted to say:
- Thank you for the patch. I appreciate the chance to try a fix.
- I doubt the issue is related to text because my scripts shows a memory 
leak even if the displayed text is never updated (comment out the line 
that modifies the x axis limits to see what I mean; though I confess I 
did not try that with the trunk matplotlib, only with 1.0.0).

-- Russell

In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I think I'm on to something -- it seems that text layout information has 
> a cyclical reference that prevents the Text object from being freed.
> 
> Can you apply the attached patch and let me know if it solves your issue?
...


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Russell E. Owen 
8852   1.3
  25.128860   1.4
  30.128868   1.4
  35.128876   1.5
  40.12   1.6
  45.128908   1.9
...
 447.029620   1.8
 452.129628   1.8
...
1180.330940   1.8
1185.330948   1.8


In article <[email protected]>,
 Michael Droettboom  
 wrote:

> If you're able to try this with the 1.0.x SVN branch or the SVN trunk 
> (plus my text patch) let me know.  I am not able to reproduce any sort 
> of memory leak with these newer versions, but I am able to with 1.0.0 as 
> released (with or without my text patch).  This is with or without the x 
> axis limits updating you suggested.  I believe there have been other 
> memory leak fixes since the 1.0.0 release.
> 
> Cheers,
> Mike
> 
> On 12/13/2010 08:35 PM, Russell E. Owen wrote:
> > I also wanted to say:
> > - Thank you for the patch. I appreciate the chance to try a fix.
> > - I doubt the issue is related to text because my scripts shows a memory
> > leak even if the displayed text is never updated (comment out the line
> > that modifies the x axis limits to see what I mean; though I confess I
> > did not try that with the trunk matplotlib, only with 1.0.0).
> >
> > -- Russell
> >
> > In article<[email protected]>,
> >   Michael Droettboom
> >   wrote:
> >
> >
> >> I think I'm on to something -- it seems that text layout information has
> >> a cyclical reference that prevents the Text object from being freed.
> >>
> >> Can you apply the attached patch and let me know if it solves your issue?
> >>  
> > ...
> >
> >
> > 
> > --
> > Lotusphere 2011
> > Register now for Lotusphere 2011 and learn how
> > to connect the dots, take your collaborative environment
> > to the next level, and enter the era of Social Business.
> > http://p.sf.net/sfu/lotusphere-d2d
> > ___
> > Matplotlib-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >

I


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Russell E. Owen 
I tried the test script on linux using matplotlib svn trunk rev8840 
(which appears to include your patch) and found a leak that starts out 
small but gets systematically larger. This is with Python 2.6.5 and 
Tkinter built against Tcl/Tk 8.4.13.

Is anyone else seeing this?

time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.036816   nan
   5.036860   nan
  10.036860   0.0
  15.136860   0.0
  20.136860   0.0
  25.136896   1.8
...
 326.536896   0.1
 331.636972   0.3
...
 401.936972   0.3
 406.936980   0.3
 411.937004   0.4
 417.037016   0.4
 422.037040   0.4
 427.037052   0.5
 432.037076   0.5
 437.137088   0.5
 442.137112   0.6
 447.137124   0.6
 452.137148   0.6
 457.237160   0.7
 462.237184   0.7
 467.237196   0.7
 472.237220   0.8
 477.337232   0.8
 482.337256   0.8
 487.337268   0.8
 492.337292   0.9
 497.337304   0.9
 502.337328   0.9
 507.437340   1.0
 512.437360   1.0
 517.437376   1.0
 522.437396   1.0
 527.537412   1.1
 532.537432   1.1
 537.537448   1.1
 542.537472   1.1
 547.637488   1.2
 552.637504   1.2
 557.637516   1.2
 562.637540   1.2
 567.637556   1.2
 572.737576   1.3
 577.737592   1.3
 582.737612   1.3
 587.737628   1.3
 592.737648   1.3
 597.837664   1.4
 602.837684   1.4
 607.837700   1.4

This is different behavior than on Mac OS X, but still alarming.

-- Russell

In article <[email protected]>,
 Michael Droettboom  
 wrote:

> If you're able to try this with the 1.0.x SVN branch or the SVN trunk 
> (plus my text patch) let me know.  I am not able to reproduce any sort 
> of memory leak with these newer versions, but I am able to with 1.0.0 as 
> released (with or without my text patch).  This is with or without the x 
> axis limits updating you suggested.  I believe there have been other 
> memory leak fixes since the 1.0.0 release.
> 
> Cheers,
> Mike
> 
> On 12/13/2010 08:35 PM, Russell E. Owen wrote:
> > I also wanted to say:
> > - Thank you for the patch. I appreciate the chance to try a fix.
> > - I doubt the issue is related to text because my scripts shows a memory
> > leak even if the displayed text is never updated (comment out the line
> > that modifies the x axis limits to see what I mean; though I confess I
> > did not try that with the trunk matplotlib, only with 1.0.0).
> >
> > -- Russell
> >
> > In article<[email protected]>,
> >   Michael Droettboom
> >   wrote:
> >
> >
> >> I think I'm on to something -- it seems that text layout information has
> >> a cyclical reference that prevents the Text object from being freed.
> >>
> >> Can you apply the attached patch and let me know if it solves your issue?


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] trunk rev 8843 crash on Snow Leopard

2010-12-20 Thread Russell E. Owen 
I built a binary installer for matplotlib trunk rev 8843 (because it 
leaks memory less than 1.0.0 release). I built it the same way I built 
the 1.0.0 binary 
 on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably 
6).

The binary is available here:


It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import 
pylab almost always segfaults (and the few times I've gotten it to work 
on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and 
running Python again). I've tried it on newly created accounts and it 
segfaults. Another user of Snow Leopard first reported the problem. So 
it's not just me.

I've appended part of a crash log.

I built this binary the same way I built the matplotlib 1.0.0 binary, 
which has no problems.

Any ideas?

-- Russell

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_PROTECTION_FAILURE at 0x
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib   0x90e1b176 __kill + 10
1   libSystem.B.dylib   0x90e1b168 kill$UNIX2003 + 32
2   libSystem.B.dylib   0x90ead89d raise + 26
3   libSystem.B.dylib   0x90ec39bc abort + 93
4   org.python.python   0x004e3e99 Py_FatalError + 73
5   libSystem.B.dylib   0x90e2046b _sigtramp + 43
6   ??? 00 0 + 0
7   libSystem.B.dylib   0x90e29378 
_Unwind_GetLanguageSpecificData + 24
8   libstdc++.6.dylib   0x940c4d86 __gxx_personality_v0 + 120
9   libgcc_s.1.dylib0x0389f476 _Unwind_Backtrace + 278
10  libgcc_s.1.dylib0x0389f890 _Unwind_Resume + 112
11  ft2font.so  0x03d5c3a3 
FT2Font::FT2Font(std::string) + 4385
12  ft2font.so  0x03d5c805 
ft2font_module::new_ft2font(Py::Tuple const&) + 505
13  ft2font.so  0x03dc89c2 
Py::ExtensionModule::invoke_method_varargs(void*, 
Py::Tuple const&) + 90
14  ft2font.so  0x03d7170c 
method_varargs_call_handler + 342
15  org.python.python   0x004bcd25 PyEval_EvalFrameEx + 19429
16  org.python.python   0x004bee9d PyEval_EvalCodeEx + 2109
17  org.python.python   0x004bcf0c PyEval_EvalFrameEx + 19916


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] trunk rev 8843 crash on Snow Leopard

2011-01-03 Thread Russell E. Owen 
In article 
,
 John Hunter  wrote:

> On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen 
>  wrote:
> 
> > I built a binary installer for matplotlib trunk rev 8843 (because it
> > leaks memory less than 1.0.0 release). I built it the same way I built
> > the 1.0.0 binary
> > <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> > l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> > 6).
> >
> > The binary is available here:
> > <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> > 843-python.org-py2.6-macosx10.3.dmg<http://www.astro.washington.edu/users/ro
> > wen/python/matplotlib-1.0.0+svn8%0A843-python.org-py2.6-macosx10.3.dmg>
> > >
> >
> > It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> > pylab almost always segfaults (and the few times I've gotten it to work
> > on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> > running Python again). I've tried it on newly created accounts and it
> > segfaults. Another user of Snow Leopard first reported the problem. So
> > it's not just me.
> >
> > I've appended part of a crash log.
> >
> > I built this binary the same way I built the matplotlib 1.0.0 binary,
> > which has no problems.
> >
> 
> 
> Could you try a "divide and conquer" approach to narrow down which svn
> revision introduced the breakage.  I realize this is tedious, especially
> since the bug manifestation is variable, but it if we could figure out the
> revision number, we'd be more likely to be able to fix it.

Good suggestion. I tried remaking the an installer for 1.0.0 and it has 
the exact same issue. I am surprised because I only use the machine for 
one purpose: making binary installers) and I don't recall rebuilding any 
of the libraries but either I did or there's been some corruption.

In any case the good news is that it has nothing to do with matplotlib 
itself and is all my fault. Presumably libfreetype has gotten corrupted 
or I built a new version and messed something up. I'll pursue it.

Regards,

-- Russell


--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] trunk rev 8843 crash on Snow Leopard: fixed

2011-01-03 Thread Russell E. Owen 
In article ,
 "Russell E. Owen"  wrote:

> In article 
>  mane.org>,
>  John Hunter  wrote:
> 
> > On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen 
> >  wrote:
> > 
> > > I built a binary installer for matplotlib trunk rev 8843 (because it
> > > leaks memory less than 1.0.0 release). I built it the same way I built
> > > the 1.0.0 binary
> > > <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> > > l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> > > 6).
> > >
> > > The binary is available here:
> > > <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> > > 843-python.org-py2.6-macosx10.3.dmg<http://www.astro.washington.edu/users/
> > > ro
> > > wen/python/matplotlib-1.0.0+svn8%0A843-python.org-py2.6-macosx10.3.dmg>
> > > >
> > >
> > > It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> > > pylab almost always segfaults (and the few times I've gotten it to work
> > > on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> > > running Python again). I've tried it on newly created accounts and it
> > > segfaults. Another user of Snow Leopard first reported the problem. So
> > > it's not just me.
> > >
> > > I've appended part of a crash log.
> > >
> > > I built this binary the same way I built the matplotlib 1.0.0 binary,
> > > which has no problems.
> > >
> > 
> > 
> > Could you try a "divide and conquer" approach to narrow down which svn
> > revision introduced the breakage.  I realize this is tedious, especially
> > since the bug manifestation is variable, but it if we could figure out the
> > revision number, we'd be more likely to be able to fix it.
> 
> Good suggestion. I tried remaking the an installer for 1.0.0 and it has 
> the exact same issue. I am surprised because I only use the machine for 
> one purpose: making binary installers) and I don't recall rebuilding any 
> of the libraries but either I did or there's been some corruption.
> 
> In any case the good news is that it has nothing to do with matplotlib 
> itself and is all my fault. Presumably libfreetype has gotten corrupted 
> or I built a new version and messed something up. I'll pursue it.

I cleared out /usr/local and rebuilt the necessary libraries and it now 
seems to work fine. I uploaded a new copy of the Mac installer for 
Python 2.6 after performing basic testing on 10.4, 10.5 and 10.6. Please 
give it a try. I'll upload a version for 32-bit Python 2.7 once I have 
it.

-- Russell


--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile

2011-01-03 Thread Russell E. Owen 
In article <[email protected]>,
 Christopher Barker  wrote:

> On 12/9/10 11:57 PM, Ludwig Schwardt wrote:
> > This patch reminded me to ask why the builtin libpng, zlib and
> > libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
> 
> It may be because we still want to support OS-X 10.4 .

Yes -- we are still supporting Mac OS X 10.3.9 and later (the same 
versions supported by python.org python).

It will be a relief to stop building those libraries, but they're easy 
enough to build and some of them are newer than the versions originally 
supplied with Mac OS X (including libz and libfreetype) so it's not 
necessarily a bad thing to include static versions.

Regards,

-- Russell


--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building

2011-01-03 Thread Russell E. Owen 
In article 
,
 John Hunter  wrote:

> We are long overdue on getting a bugfix release of 1.0.0 out, so I have
> uploaded an rc for testing at
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
> 
> Christoph and Russell -- if you have time could you build win32 and OSX
> binaries for testing as well.  I don't believe either of you have developer
> permissions to upload directly to this site, but I would be happy to add you
> if you send me an sf id.  Alternatively, you can upload them to a site of
> your choosing and I'll upload them for you (drop.io was acquired by facebook
> and no longer works).

I have uploaded Mac installers for python.org Python 2.6 and 32-bit 
Python 2.7.

I'm not sure what to do about 64-bit Python 2.7. It does not even 
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved 
too late for python 2.7.1. In my opinion a matplotlib built against 
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6) 
might be of more use. Opinions?

-- Russell


--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] ipython intermittently segfaults when figure is closed.

2011-06-24 Thread Russell E. Owen 
Dale: something is wrong with the way you are closing out issues on the 
old matplotlib tracker because the two of mine you closed out are 
getting an ever accumulating number of copies of the same closeout 
message from you.

This is needless clutter on the old system, and means a lot of garbage 
emails for folks to reported the bugs.

I hope you can fix this quickly. Though I suppose by the time you get to 
it most users will have stopped tracking their issues in sourceforge in 
self defense.

-- Russell


--
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Calling all Mac OSX users!

2011-08-16 Thread Russell E. Owen 
In article 
,
 Benjamin Root  wrote:

> The mpl developers are getting very close to the long-awaited v1.1.0 release
> of matplotlib.  Before we do so, we are doing some final checking of the
> documentation to make sure that all critical pieces of information iss
> correct and up to date.
> 
> In checking over the instructions for building and installing matplotlib on
> MacOSX, I have found two separate sets of instructions.  On the install
> page, there is a reference to a README.txt file in "release/osx".  This file
> is there, but it seems to refer to other files that no longer exists.
> Meanwhile, there is an un-referenced file in the top directory called
> README.osx that seems a lot more current.
> 
> Because I do not have a Mac that I can use for development, I would like to
> ask the community for help in determining the correct set of instructions
> and to eliminate cruft.  I think it would also be useful to point users to
> any relevant instructions for installing/building numpy on Macs.  I would
> also like to make  sure we are current with information on installing on a
> stock Lion install.
> 
> Please feel free to respond on this list, or better, make a branch on github
> and submit pull requests to help us improve these documents.

Building on MacOS X would be just like unix if setupext.py did not have 
the MacOS X-specific stuff commented out. The libraries are here on 
MacOS X:
/usr/X11/lib/ for libpng and libfreetype
/usr/lib/ for libz

That would greatly simplify the readme files.

That said, some Mac users like to use MacPorts, fink or similar software 
to install unix tools. I don't know what happens if those are used. One 
solution is to not search those directories by default and suggest that 
users edit setupext.py if they wish to use those versions.


There are, or were, also files that create the Mac binary installers 
using "make". I suspect one of the readme files you are asking about 
refer to those files. I have no idea if those files still work. I make 
those binaries now, and I do it by hand. Last I looked, those files were 
in the repository, but for some reason were excluded from the source 
distribution.

-- Russell


--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Calling all Mac OSX users!

2011-08-17 Thread Russell E. Owen 
In article <[email protected]>,
 Eric Firing  wrote:

> On 08/16/2011 10:10 AM, John Hunter wrote:
> > On Mon, Aug 15, 2011 at 9:34 PM, Benjamin 
> > Root  wrote:
> >> The mpl developers are getting very close to the long-awaited v1.1.0 
> >> release
> >> of matplotlib.  Before we do so, we are doing some final checking of the
> >> documentation to make sure that all critical pieces of information iss
> >> correct and up to date.
> >>
> >> In checking over the instructions for building and installing matplotlib 
> >> on
> >> MacOSX, I have found two separate sets of instructions.  On the install
> >> page, there is a reference to a README.txt file in "release/osx".  This 
> >> file
> >> is there, but it seems to refer to other files that no longer exists.
> >> Meanwhile, there is an un-referenced file in the top directory called
> >> README.osx that seems a lot more current.
> >>
> >> Because I do not have a Mac that I can use for development, I would like 
> >> to
> >> ask the community for help in determining the correct set of instructions
> >> and to eliminate cruft.  I think it would also be useful to point users to
> >> any relevant instructions for installing/building numpy on Macs.  I would
> >> also like to make  sure we are current with information on installing on a
> >> stock Lion install.
> >>
> >> Please feel free to respond on this list, or better, make a branch on 
> >> github
> >> and submit pull requests to help us improve these documents.
> >
> > I wrote both of those files originally (make.osx and releases/osx/*).
> > The original division of labor was the stuff in "releases" was
> > designed to build the release binaries, and the stuff in make.osx was
> > primarily used to build from svn or src.  Overtime, most of the effort
> > has gone into make.osx, and it now includes support for binaries.  I
> > no longer build the OSX binaries (Russell does) and no longer use OS X
> > (back to ubuntu) so if Russell is not using the stuff in releases/osx,
> > we can flush it.
> 
> The releases/win32/ tree is also unmaintained since 0.99.0.rc1.  Who 
> does the Windows builds these days?  Christophe?
> 
> It would be nice to have a maintained record of how release builds are 
> done, or better yet, up-to-date scripts that fully automate it.

Just for the record, I follow my own instructions to build the Mac 
binaries 
. I already have the libraries built and ready to go (I boot off a 
special drive configured for this task). Most of the remaining work 
involves working around bugs/misfeatures such as needing to edit 
setupext.py and checking for permission errors (thankfully not seen in 
1.0.1), and I'm not sure how easy that would be to script.

I look forward to the day that the Mac binaries can be built using 
Apple's own libraries, but I think that's not likely to happen until 
python.org stops supporting PPC machines.

-- Russell


--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Calling all Mac OSX users!

2011-08-30 Thread Russell E. Owen 
In article 
,
 Benjamin Root  wrote:

> Ok, there has been a lot of useful discussion (for both MacOSX and Windows),
> but in the end, I want to know this: Is it possible for matplotlib to
> provide a single, recommended, fully-supported-by-us method for installing
> our package (possibly for each platform?).  Could it be pip? Or some other
> option?

I think we'll always need to be able to install from source and also 
offer a binary on MacOS X.

* Build from source.

If your version of MacOS X is recent enough then building from source 
could easily be made to work (with a few minor changes to setupext.py). 
Most other projects have managed this. I may be able to find some time 
to work on this.

On the good side it would work with nearly any python build and it means 
any user can install matplotlib in the obvious fashion. For these 
reasons I think this is very much worth doing. However, it has some 
disadvantages:
- It requires that users install XCode
- I don't think the resulting build will work with older versions of 
MacOS X, because Apple's libraries aren't backward compatible. This 
means the user will run into unexpected difficulty if they build and 
distribute a bundled application. This is a serious problem and means 
that users must have a binary installer option:

* Binary installer (.mpkg or egg)

This is how things are done now. The binary installer can include 
statically linked backward compatible libraries and thus be compatible 
with many versions of MacOS X. Thus users can safely include matplotlib 
in bundled applications.

There are many choices, including Apple's build-in python, python.org, 
Enthought, ActiveState, MacPorts... Most projects, including matplotlib, 
provide binary installers for python.org python because Apple's python 
is useless for distributed apps and is hard to upgrade, and most other 
projects provide their own installers for matplotlib.


So I would hate to see matplotlib give up on binary installers, but we 
could and should improve our ability to build matplotlib from source on 
MacOS X.


Another issue is how to distribute the binary installers. I like .mpkg 
installers because they are pretty good about installing with compatible 
versions of Python. We've tried binary eggs in the past and they were 
not good about finding the right version of Python. That may have 
improved.

-- Russell


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] eggs or pythonmac packages on OS X?

2007-12-11 Thread Russell E Owen 
At 10:03 AM -0800 2007-12-05, Christopher Barker wrote:
>Russell E Owen wrote:
>>At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote:
>>>Just for my edification, why can't the egg version be linked
>>>against/include a different Tcl/Tk?
>>
>>If you mean why can't it be built that way in the first place, I 
>>don't know. The guy who builds it apparently doesn't read this list,
>
>Sure he does (if you mean the matplotlib list), and he did ask about 
>it right before this release. Maybe that was asked on 
>matplotlib-devel though (I filter them to the same place).

It was on matploblib-devel. I'll start skimming that newsgroup.

>>I suspect the official egg can somehow be patched, but I find it 
>>easier to just build my own and put that on pythonmac.
>
>Ideally, there would be only one binary version, and it would work 
>with either Tcl/Tk. Is that possible? or is this like the old wx 
>situation, where it  can only be run with the same version it is 
>built against. Arrggg! I hope not.

The version I build *can* be used with the built in Tcl/Tk. The 
version Charlie Moad builds cannot be used with TkAgg and a 3rd party 
Tcl/Tk -- it not only won't use the library, but it also acts flaky. 
Older versions crashed. 0.91.1 doesn't crash, but import of pylab 
fails with a traceback.

For some reason it seems to be necessary to have a 3rd party Tcl/Tk 
installed when building matplotlib. It seems a shame. Tkinter in 
Python 2.4 was the same way, but that got fixed in Python 2.5 (I 
don't whether the installer got fixed or whether whoever builds Mac 
Python 2.5 installed a 3rd party Tcl/Tk).

>If there really do need to be two, then they should be labeled 
>somehow, and both be up on python mac.

Since there don't need to be two versions this is not necessary.

However, Charlie Moad appears to be willing to start building a 
version that works with 3rd party Tcl/Tk. I really hope that happens.

-- Russell

-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Mac binary installer

2008-08-13 Thread Russell E. Owen 
I have a few questions and comments about the Mac binary of matplotlib 
0.98.3:
   matplotlib-0.98.3-py2.5-macosx-10.3.egg.zip
   
A few things struck me as scary:
- There are no instructions; when you unzip it you get just an egg and 
that's it. I was able to find the magic incantation on the web, and 
fortunately I already have easy_install installed. But it would be a big 
help to have a ReadMe that tells how to install easy_install and how to 
use it to install the egg.

- The zipped egg includes dateutil and pytz. But I already have those 
installed (both due to using older matplotlib and because I use dateutil 
in my own code), so now I have two sets in different locations. This is 
worrisome. Which one will get used? Does it matter if I import dateutil 
first or matplotlib first? (I deleted the versions in the matplotlib egg 
to remove doubt.)

I thought easy_install could handle dependencies (and indeed, per the 
next item, it seemed to be trying to do so). If so, couldn't it only 
install them if not already present?

- When I ran easy_install it started searching the web and installing 
stuff. But what was it downloading and installing? The messages were 
very vague. I already had dateutil and pytz, so did the egg, so it would 
be crazy for it to download those. But what in the world else could it 
possibly need? Surely the freetype and png are already statically linked 
in (or perhaps it's using Apple's freetype). Surely it doesn't want to 
download those as libraries and install them? Surely it would not 
install wxpython, since that is optional?

I do appreciate the effort that goes into producing these binaries. (I 
used to make a matplotlib package installer for pythonmac.org and was 
glad to give it up.) And the results do seem to work.

-- Russell


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Mac binary installer

2008-08-15 Thread Russell E. Owen 
In article 
<[EMAIL PROTECTED]>,
 "Charlie Moad" <[EMAIL PROTECTED]> wrote:

> >
> >
> > You can't put a readme in the zip file?
> 
> 
> I think he was referring to the egg as a zip, which it technically is but
> setuptools extracts it for you.

I already find easy_install mysterious and unsettling and I guess you 
can add this notational confusion to the list. Why not call .egg.zip a 
"zipped egg" even if easy_install can handle it directly? But avoiding 
the notational issue entirely, here's my take on it:

The file I downloaded was a .zip file. The obvious naive thing to do 
with a zip file is to unzip it, especially if one is looking for 
instructions!

This yields a .egg file. It could yield a .egg file and a ReadMe file if 
one was included in the zip file. easy_install can install a .egg file 
so it's no harm to unzip the download.

Presumably one could include a ReadMe file into the .egg.zip in such a 
way that easy_install would ignore it.

On the other hand, the web page that is the source of the download could 
also have the ReadMe info, as you point out. Either is fine.

Personally I am not sold on easy_install. It's a clever idea and maybe 
someday it'll live up to its promise, but right now it seems to have 
some many undesirable behaviors (such as mysteriously and needlessly 
downloading stuff).

For now I'd suggest that package installers (e.g. as created by 
bdist_mpkg) be used for Mac because they are standard, are used by 
simply double clicking (thus have no learning curve or need to install 
anything), have ReadMe support build in, and do not mysteriously 
download stuff.
 
-- Russell


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Outdated pytz and dateutil

2008-09-18 Thread Russell E. Owen 
The versions of pytz and dateutil that are included with matplotlib 
0.98.3 are outdated.

dateutil 1.2 is included, but 1.4.1 is available
pytz: 2008c (from pypi)

I am against including them at all (especially if they are installed 
even if the user already has the packages available). They are both 
trivial to install from source.

In the case of pytz one can also use easy_install (and presumably this 
can happen automatically via dependency handling). Unfortunately that is 
not a good idea for dateutil; I just tried it and got version 1.1. Yow.

-- Russell


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Outdated pytz and dateutil

2008-09-23 Thread Russell E. Owen 
In article 
<[EMAIL PROTECTED]>,
 "John Hunter" <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 18, 2008 at 2:33 PM, Russell E. Owen <[EMAIL PROTECTED]> 
> wrote:
> > The versions of pytz and dateutil that are included with matplotlib
> > 0.98.3 are outdated
> 
> Hey Russell, thanks for the head's up.
> 
> For our source installs, by default we install them only if they are
> not on the system, but you can configure this with setup.cfg to
> always, never or conditionally install them.
> 
> I have updated the mpl versions to the ones you point to above.

I just discovered that matplotlib 0.98.3 is not compatible with pytz 
2008c due to an unexpected change in pytz. The following fix works (I 
chucked it into __init__.py near the beginning).

# the following fix for compatibility with pytz 1.4.1 is from
# <http://www.mail-archive.com/[EMAIL PROTECTED]/msg07816.html>
import pytz
try:
import pytz.zoneinfo
except ImportError:
pytz.zoneinfo = pytz.tzinfo
pytz.zoneinfo.UTC = pytz.UTC

-- Russell


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.1.0 branch created

2011-09-27 Thread Russell E. Owen 
In article 
,
 Benjamin Root  wrote:

> The source tarball for the rc can be found here:
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/
> 
> binary builders can use this and upload the binaries there.  Please let me
> know when the windows and mac binaries are ready so that we can make an
> official call for testing.  I also tagged the v1.1.0-rc1 commit on github.

I put up a Mac installer for Python 2.7. It passed all unit tests but 
I've not done anything else with it. If you need an installer for 2.6 I 
can do that as well, but was hoping to wait for the final.

-- Russell


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Problem with proposed 1.0.1 release

2011-10-07 Thread Russell E. Owen 
I'm running into an error building the Mac binary:

d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$ 
bdist_mpkg
basedirlist is: ['/usr/local']
=
===
BUILDING MATPLOTLIB
matplotlib: 1.0.1
python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 
14:13:39)
[GCC 4.0.1 (Apple Inc. build 5493)]
  platform: darwin

REQUIRED DEPENDENCIES
 numpy: 1.6.1
 freetype2: found, but unknown version (no pkg-config)

OPTIONAL BACKEND DEPENDENCIES
libpng: found, but unknown version (no pkg-config)
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line 
8, in 
load_entry_point('bdist-mpkg==0.4.4', 'console_scripts', 
'bdist_mpkg')()
  File 
"build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line 
27, in main
  File "setup.py", line 162, in 
if check_for_tk() or (options['build_tkagg'] is True):
  File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line 
832, in check_for_tk
(Tkinter.__version__.split()[-2], Tkinter.TkVersion, 
Tkinter.TclVersion))
IndexError: list index out of range

I have ActiveState Tk installed. Tkinter reports the following values:
Tkinter.__version__ = "$Revision$"
Tkinter.TkVersion = "8.4"
Tkinter.TclVersion = "8.4"

I assume I can get past this by hacking up setupext.py; I'm willing to 
do that, but I'm wondering if it makes more sense to fix the bug. How 
many other users are going to be bit by this?

1.0.1rc1 built with no problems, but I see that setupext.py had some 
revisions since then.

-- Russell

P.S. I have no idea why freetype2 and libpng install without pkg-config; 
I install them in in /usr/local in the usual way. However, those 
warnings have been present for a long time and it never seems to cause 
any trouble.


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Suggestion for setupext.py darwin changes

2012-03-01 Thread Russell E. Owen 
At present all people buliding matplotlib on Mac OS X must edit 
setupext.py. I have modified setupext.py to make it work with Mac OS X 
("darwin") for Apple's python, python.org python and presumably Homebrew 
python (since that uses /usr/local).

I also included instructions for users of Fink and MacPorts (though 
perhaps those should go in a readme somewhere, instead).

Here are the changes:


I would appreciate a review, so I can submit a pull request.

-- Russell


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Suggestion for setupext.py darwin changes

2012-03-06 Thread Russell E. Owen 
In article <[email protected]>,
 Ludwig Schwardt 
  wrote:

> Hi Russell,
> 
> > At present all people buliding matplotlib on Mac OS X must edit 
> > setupext.py. I have modified setupext.py to make it work with Mac OS X 
> > ("darwin") for Apple's python, python.org (http://python.org) python and 
> > presumably Homebrew 
> > python (since that uses /usr/local).
> > 
> > 
> 
> 
> I've never actually edited setupext.py in order to build matplotlib using 
> Apple's python, and it has never been a problem for me. I guess it's because 
> system python uses the standard include locations (unlike fink and macports).

I'm quite surprised it works. But my changes should not break that 
(unless your /usr/local contains anything that matplotlib needs and that 
is not compatible with Apple's python).

-- Russell


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

2012-03-20 Thread Russell E. Owen 
In article 
,
 John Hunter  wrote:

> I think we are pretty close to cleaning up issues and PRs related to
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> continue to hammer on closing open issues and pull requests, and flag
> anything that needs to be addressed before the release as
> "release_critical" in the issue tracker.  If there are show stoppers I am
> not aware of, chime in.
> 
> Thanks,
> JDH
> 
> -
> --
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> -
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Let me know when the source is ready to be pulled (and a link to 
instructions would be helpful) and I'll cut the Mac binaries.

-- Russell


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

2012-03-23 Thread Russell E. Owen 
In article 
,
 John Hunter  wrote:

> On Mon, Mar 19, 2012 at 12:58 PM, John Hunter 
>  wrote:
> 
> > I think we are pretty close to cleaning up issues and PRs related to
> > v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> > continue to hammer on closing open issues and pull requests, and flag
> > anything that needs to be addressed before the release as
> > "release_critical" in the issue tracker.  If there are show stoppers I am
> > not aware of, chime in.
> >
> >
> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
> are available for testing and building binaries
> 
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/

I have uploaded the Mac builds (no Python 2.6 yet; do we really need 
that?). They pass all unit tests and the 32-bit version seems to work 
well with my software.

The included pytz is outdated (and I did not bother to uprev it in the 
binaries I uploaded); would somebody be willing to update that before we 
cut the final releases, or is that considered too risky at this late 
date?

-- Russell


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] needed: OS X maintainer

2012-06-21 Thread Russell E. Owen 
In article <[email protected]>,
 Eric Firing  wrote:

> If you have expertise in python package building on OS X, including more 
> than one method and more than one OS X version, please see 
> https://github.com/matplotlib/matplotlib/issues/168.
> 
> Eric
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

I have commented and include the suggested change to setupext.py. I'm 
strongly in favor.

-- Russell


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

2012-07-05 Thread Russell E. Owen 
In article ,
 Russell Owen  wrote:

> I just uploaded the Mac binaries.
> 
> Several minor concerns:
> - Many unit tests failed on Mac OS X 10.4 (which is where I build the 10.3.9 
> version) due to "too many files open", but the same binary looks fine on 
> 10.5.
> - The 64-bit version (10.6 and later) had one unexpected failure on 10.7 (I 
> have not yet had time to test it on 10.6)...

When I tested on Mac OS X 10.6 I found that most unit tests were somehow 
missing. Rather than try to diagnose the problem, I built a new binary 
on 10.6, confirmed that it installed properly (with all unit tests) on 
10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary.

The same test I mentioned in my previous post still fails using the new 
binary, on both 10.6 and 10.7.

-- Russell


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

2012-07-06 Thread Russell E. Owen 
In article ,
 Jouni K. Seppänen  wrote:

> Russell Owen  writes:
> 
> > By the way: I installed ghostscript from source and Inkscape
> > application from binary. More tests pass, but many still show K. My
> > guess is that matplotlib can see ghostscript but not the Inkscape
> > application (no surprise). Inkscape has too many dependencies for me
> > to want to try to build it from source.
> 
> The following should help matplotlib find Inkscape:
> 
> PATH=$PATH:/Applications/Inkscape.app/Contents/Resources/bin \
> python -c 'import matplotlib; matplotlib.test(1)'

Yes, thanks. I figured that out this morning and reran the tests for the 
64-bit matplotlib on 10.7. Almost everything passes now. Just a few K 
and one actual failure that appears to be nothing to worry about (though 
a failing unit test is always worrisome.

I'm still wondering how I managed to build a binary installer that 
installed the test packages on 10.7 and failed to install them on 10.6, 
but I don't have time to investigate.

-- Russell


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc1 is cut

2012-09-13 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I have tagged and created a tarball for 1.2.0rc1.  The githash is 
> bda6dd9feab8.  The tarball is on the github download page here:
> 
> https://github.com/matplotlib/matplotlib/downloads

I have a Mac OS X 10.6, python.org 64-bit python 2.7 version ready. 

I have uploaded it here:

since I could not figure out how to upload it to the github page (I am 
logged in as r-owen but no sign of upload capability).

The test results look good to me, though the warning is a pity:

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.
.
.SSS.K...K...
.
.
.
.
.
.
.
.
.
.
.
.
.../Library/F
rameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matpl
otlib/gridspec.py:298: UserWarning: This figure includes Axes that are 
not compatible with tight_layout, so its results might be incorrect.
  warnings.warn("This figure includes Axes that are not "
..
--
Ran 1188 tests in 474.571s

OK (KNOWNFAIL=2, SKIP=3)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/__init__.py:997: UserWarning:  This call to 
matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)



I also tried to build a Mac OS X 10.3, python.org 32-bit python, but 
that failed. Any advice on how to proceed would be welcome. I have 
appended the build log.

-- Russell

Log of failed build for Mac OS X 10.3 (on Mac OS X 10.4) for python.org 
32-bit python 2.7.

d-173-250-206-120:/Archives/PythonPackages/matplotlib-1.2.0rc1 rowen$ 
python setup.py build
basedirlist is: ['/usr/local/', '/usr', '/usr/X11']
=
===
BUILDING MATPLOTLIB
   matplotlib: 1.2.0rc1
   python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 14:13:39)
   [GCC 4.0.1 (Apple Inc. build 5493)]
 platform: darwin

REQUIRED DEPENDENCIES
numpy: 1.6.2
freetype2: found, but unknown version (no pkg-config)

OPTIONAL BACKEND DEPENDENCIES
   libpng: found, but unknown version (no pkg-config)
  Tkinter: Tkinter: version not identified, Tk: 8.4, Tcl: 8.4
 Gtk+: no
   * Building for Gtk+ requires pygtk; you must be 
able
   * to "import gtk" in your build/install 
environment
  Mac OS X native: yes
   Qt: no
  Qt4: no
   PySide: no
Cairo: no

OPTIONAL DATE/TIMEZONE DEPENDENCIES
 dateutil: matplotlib will provide
 pytz: matplotlib will provide
adding pytz

OPTIONAL USETEX DEPENDENCIES
   dvipng: no
  ghostscript: /bin/sh: line 1: gs: command not found
latex: no

[Edit setup.cfg to suppress the above messages]
=
===
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends', 
'matplotlib.backends.qt4_editor', 'matplotlib.projections', 
'matplotlib.testing', 'matplotlib.testing.jpl_units', 
'matplotlib.tests', 'mpl_toolkits', 'mpl_toolkits.mplot3d', 
'mpl_toolkits.axes_grid', 'mpl_toolkits.axes_grid1', 
'mpl_toolkits.axisartist', 'matplotlib.sphinxext', 'matplotlib.tri', 
'matplotlib.delaunay', 'pytz', 'dateutil', 'dateutil.zoneinfo']
running build
running build_py
creating build
creating build/lib.macosx-10.3-fat-2.7
copying lib/pylab.py -> build/lib.macosx-10.3-fat-2.7

Re: [matplotlib-devel] 1.2.0rc1 is cut

2012-09-17 Thread Russell E. Owen 
In article 
,
 Phil Elson  wrote:

> @Sandro: Yes, we merged the two together to simplify our code base and to
> reduce dependencies etc.; Hopefully that doesn't cause you too much grief?
> 
> 
> Eric/Russell, is there an issue on github for the reported problem?

I just submitted ticket #1270


-- Russell


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc1 is cut

2012-09-18 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I have tagged and created a tarball for 1.2.0rc1.  The githash is 
> bda6dd9feab8.  The tarball is on the github download page here:
> 
> https://github.com/matplotlib/matplotlib/downloads
> 
> I have created a new branch, v1.2.x, for continuing 1.2.x development.  
> The feature freeze on master is now lifted and big experimental changes 
> can be merged into master.  Any bugfixes that need to go into 1.2.x 
> should be merged into both places.  Please mark any PRs for the 1.2.x 
> branch with the 1.2.x milestone so we can verify that things are merged 
> in both places.

It appears that 
import matplotlib
no longer imports matplotlib.dates -- that I must do that explicitly:
import matplotlib.dates

Is that an intentional change? It breaks existing code of mine, which is 
easily fixed and perhaps was making unwarranted assumptions. But I 
wonder what else will break.

-- Russell

P.S. Damon McDougall and mdehoon fixed the problem with matplotlib 
building for Mac using gcc 4.0! Many thanks!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

2012-09-24 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I have tagged and created a tarball for 1.2.0rc2.  The githash is 
> 656c88f3e546.  The tarball is on the github download page here:
> 
> https://github.com/matplotlib/matplotlib/downloads
> 
> This includes a number of important bugfixes, including things required 
> for creating Macintosh and Windows binaries.  The Travis tests are also 
> now passing.
> 
> I hope it will be easier for the binaries to be created this time. Once 
> they are available at github, I will make an announcement to 
> matplotlib-users and hopefully get some serious testing out of this thing.
> 
> Thanks for all of the hard work!

I'm sorry that I missed the announcement until today -- I normally try 
to check news every day or two, but got too busy last week.

I'm even more sorry to report that I can't build the 32-bit Mac OS X 
binary. I have appended the log. I suspect the issue is the need to use 
an old compiler for that python.

The 64-bit Mac binary built just fine and I'm uploading it now. I have 
also appended the test results for it (which look fine to me).

-- Russell

Log of build failure on MacOS X 10.4 for python.org's 32-bit python 2.7

d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$ 
bdist_mpkg
basedirlist is: ['/usr/local/', '/usr', '/usr/X11']
...
gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g 
-O3 -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 
-I/usr/local/include -I/usr/include -I/usr/X11/include 
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
ckages/numpy/core/include -I/usr/local/include -I/usr/include -I. 
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
ckages/numpy/core/include -Isrc -Iagg24/include -I. 
-I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c 
src/_macosx.m -o build/temp.macosx-10.3-fat-2.7/src/_macosx.o
src/_macosx.m: In function 'FigureCanvas_write_bitmap':
src/_macosx.m:3557: error: request for member 'pixelsWide' in something 
not a structure or union
src/_macosx.m:3557: error: request for member 'pixelsHigh' in something 
not a structure or union
src/_macosx.m: In function 'FigureCanvas_write_bitmap':
src/_macosx.m:3557: error: request for member 'pixelsWide' in something 
not a structure or union
src/_macosx.m:3557: error: request for member 'pixelsHigh' in something 
not a structure or union
lipo: can't figure out the architecture type of: /var/tmp//ccpc0juI.out
error: command 'gcc-4.0' failed with exit status 1
d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$



Log of test results for the MacOS X 10.6 python.org 64-bit python 2.7 
build:

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.
.
.SSS.KK..
.
.
.
.
.
.
.
.
.
.
.
.
/Libr
ary/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
matplotlib/gridspec.py:298: UserWarning: This figure includes Axes that 
are not compatible with tight_layout, so its results might be incorrect.
  warnings.warn("This figure includes Axes that are not "
...
--
Ran 1194 tests in 329.568s

OK (KNOWNFAIL=2, SKIP=3)


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
h

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

2012-09-24 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> For the compilation problem, I am no Objective-C expert, but in C, line 
> 3557 should certainly read:
> 
>  NSSize pxlSize = NSMakeSize(rep->pixelsWide, rep->pixelsHigh);
> 
> I wonder if that fixes it -- but that's a total stab in the dark. This 
> was a part of the code that was changed quite recently.

I opened issue #1304 

but did not append your comment.

-- Russell


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Delaying rc3 (again)

2012-10-30 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> Agreed!  Thanks to everyone for their hard work.  I think this has 
> shaped up to be a great release.
> 
> I'm fortunate to have power and connectivity today, so I was able to get 
> a release tested, tagged and uploaded.
> 
> To our binary builders: as able, it would be great to put the binaries 
> up (or send them to me to do so), and then I'll make an announcement on 
> matplotlib-users.  I really intend (barring any really serious issues) 
> this to be the last rc before the 1.2.0 final.
> 
> Thanks again,
> Mike

The Mac binaries are now up. This time it built perfectly on MacOS X 
10.4; thanks to the folks that worked so hard fixing those build 
problems.

The 32-bit version is not well tested because I have neither inkscape 
nor ghostscript installed on that ancient system, but it passes the 
tests that it can run under those circumstances.

The 64-bit version passes all tests except 2 knownfail and 3 skipped.

-- Russell

P.S. I had to build the 64-bit version twice. The first time I tried to 
build it using the same directory of code that I used to build 32-bit 
version. I first deleted the "build" and "dist" subdirectories and ran 
"python setup.py clean", then built as usual. There were no errors or 
warnings during the build, but the unit tests would not run on the 
results -- complaining of missing modules.

So I built again using a freshly unpacked code directory and that worked 
just fine.

I'm pretty sure I've seen this problem before, but keep forgetting to 
ask about it.

Is this a bug somewhere (e.g. in matplotlib's setup.py or somewhere in 
python) or is there some better way to clear out a python code directory?


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded

2012-11-08 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> Thanks again to everyone for all of their hard work.  This release has 
> been tagged and uploaded.
> 
> As per the usual drill, once we have the binaries up, I'll make an ANN 
> on matplotlib-users.
> 
> The documentation is currently being rebuilt, and the default for 
> matplotlib.org will update to 1.2.0 around the same time as that 
> announcement.
> 
> Mike

Congratulations!

It looks like the binaries are all there (I uploaded the Mac binaries 
and found the Windows binaries already present).

-- Russell


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Py3 Binaries for OSX?

2012-12-11 Thread Russell E. Owen 
In article 
,
 Fernando Perez  
 wrote:

> Hi folks,
> 
> quick question; on the downloads page
> (https://github.com/matplotlib/matplotlib/downloads) I only see py27
> OSX binaries; is there any official location for Py3 ones?  I just had
> a colleague ask me about them and I couldn't find any in the places
> I'm used to searching for (github, pypi, superpack).

I have not yet made them, but it's on my to do list. One problem is that 
there are so many flavors of Python 3 (version 3.2, version 3.3, each in 
two flavors: for MacOS X 10.5 and later and for MacOS 10.6 and later). 
Anyone have suggestions for easily building against multiple versions of 
python?

- Russell


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.1rc1 Tagged

2013-03-07 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> We've finally squashed all of the bugs slated for 1.2.1, so I have 
> tagged a 1.2.1rc1 for testing.  This is a bugfix release, and improves 
> on the overall quality of 1.2.0.  Thanks to everyone who worked hard to 
> fix a multitude of papercuts.  I'll provide a more detailed list of 
> changes in the announcement of the final version.
> 
> It can be downloaded from the SF files server here:
> 
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1rc
> 1/matplotlib-1.2.1rc1.tar.gz/download
> 
> Packagers: I don't expect a lot of glitches as nothing significant has 
> changed about the build since 1.2.0, but now is the best time to try to 
> build for your various packaging systems and report back any problems.  
> If all goes well, I plan to make a final release in approximately two 
> weeks on March 25.

I uploaded two Mac binaries to SourceForge:
- A 10.3-compatible version built and tested on 10.4
- A 10.6-compatible version built and tested on 10.8 (I should also test 
it on 10.6 but don't have time right now).

They are both built against numpy 1.6.2, which is not ideal, but is the 
best I can do at the moment.

-- Russell


--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.1rc1 Tagged

2013-03-08 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> On 03/07/2013 06:48 PM, Russell E. Owen wrote:
> > In article <[email protected]>,
> >   Michael Droettboom 
> >   wrote:
> >
> >> We've finally squashed all of the bugs slated for 1.2.1, so I have
> >> tagged a 1.2.1rc1 for testing
> >>
> >> It can be downloaded from the SF files server here:
> >>
> >> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.
> >> 1rc
> >> 1/matplotlib-1.2.1rc1.tar.gz/download
> >>...
> > I uploaded two Mac binaries to SourceForge...
> >
> > They are both built against numpy 1.6.2, which is not ideal, but is the
> > best I can do at the moment.
> >
> I think that's fine for now -- for the rc it's most important to just 
> make sure that working packages *can* be built.  We can reevaluate what 
> Numpy version to use for the final release, and let me know if we should 
> push back the final release date to accomodate rejiggering your 
> development environment etc.

Do you have an opinion on the best numpy to use for matplotlib 1.2 
binaries?

Some considerations:

I think numpy 1.7.x is binary compatible with 1.6.x. If so, surely it is 
OK to build matplotlib against numpy 1.6.x, even if a user wants to use 
numpy 1.7.x? I have not tested this (nor the reverse direction).

numpy 1.7.0 has a serious memory leak (though I don't know how many 
users would ever see it). 1.7.1 is due out fairly soon. Personally I 
would rather skip 1.7.0 on my own machine. Yet it would be wise to let 
1.7.1 be used for a week or two before relying on it and I'd hate to 
hold up release of matplotlib 1.2.1.

-- Russell


--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ANN: matplotlib-1.3.0rc1

2013-05-29 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
> 
> Once the binaries from Christoph and Russell have been uploaded, I'll 
> make a broader announcement to get some testing of this in advance of 
> the final release.
> 
> The tarball is available here:
> 
> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3
> .0rc1/matplotlib-1.3.0rc1.tar.gz
> 
> The documentation for this version is viewable here:
> 
> http://matplotlib.org/1.3.0
> 
> Thanks everyone for their hard work getting this out the door!

It looks like the ability to include pytz and other dependencies in 
binary distributions has been removed?

Is this really what we want? In the past we always included them. 
Excluding them certainly makes sense if using pip or a similar installer 
that can handle dependencies, but that is not the case for binaries.

I guess we could serve the associated packages (pytz, dateutil and six), 
or if they can be installed by pip, ask users to install those. But 
users using binary installers may not even have pip available, so it's a 
big initial hurdle.

I'd personally be happier reverting to the old system. Sorry if I missed 
a discussion on this.

-- Russell


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Closing in on 1.3.0 release candidate

2013-05-29 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I am going to hold off one more day on making the release candidate.  
> There are three blocker bugs that were discovered over the weekend and 
> I'd like to give them a chance for review first:...

Thanks for the update.

The Mac version built fine, but I saw several warnings. The only one I'm 
worried about is use of a deprecated Numpy API:

In file included from src/_backend_agg.cpp:12:
In file included from src/_backend_agg.h:43:
In file included from src/agg_py_path_iterator.h:7:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/arrayobject.h:15:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/ndarrayobject.h:17:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/ndarraytypes.h:1728:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using 
deprecated NumPy API, disable it by
  #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it by #defining 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"


These look innocuous, but easy to fix:

./CXX/Python2/Objects.hxx:1133:23: warning: implicit conversion of NULL 
constant to 'int' [-Wnull-conversion]
, offset( NULL )
~ ^~~~

/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_3kcompat.h:247:40: warning: conversion 
from string literal to 'char *' is
  deprecated [-Wdeprecated-writable-strings]
return PyObject_CallFunction(open, "Os", filename, mode);


/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_3kcompat.h:255:37: warning: conversion 
from string literal to 'char *' is
  deprecated [-Wdeprecated-writable-strings]
ret = PyObject_CallMethod(file, "close", NULL);


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Mac binary for 1.3.0rc2; more errors than usual in the unit tests

2013-05-30 Thread Russell E. Owen 
I uploaded a binary installer for MacOS X, 64-bit python.org python 2.7.
I built it using numpy 1.7.1. This version does not include pytz, 
dateutil or six, but the included ReadMe says they are prerequisites and 
suggests installing them with pip.

The tests showed more problems than usual. I have appended the whole set.

A few questions:
- Why does setupext.py's dateutil finder have this:
   return ['python_dateutil']
when the package is called python-dateutil (hyphen instead of 
underscore)? If it is intentional, it might be worth noting with a 
comment.
- Why include licenses for pytz and dateutil?

-- Russell

Here is the test log:

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.
.
.
..kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
EK.K.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
./Library/Frameworks/Python.framework
/Versions/2.7/lib/python2.7/site-packages/numpy/ma/core.py:777: 
RuntimeWarning: invalid value encountered in absolute
  return umath.absolute(a) * self.tolerance >= umath.absolute(b)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/ma/core.py:3791: UserWarning: Warning: converting a masked 
element to nan.
  warnings.warn("Warning: converting a masked element to nan.")
.../Library/Frameworks/Python.fra
mework/Versions/2.7/lib/python2.7/site-packages/matplotlib/gridspec.py:29
8: UserWarning: This figure includes Axes that are not compatible with 
tight_layout, so its results might be incorrect.
  warnings.warn("This figure includes Axes that are not "
/Library/Frameworks/Python.fr
amework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py:8
07: RuntimeWarning: invalid value encountered in absolute
  z = abs(x-y)
E
==
ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
--
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
result = func(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 145, in test_pathclip
plt.savefig(os.path.join(result_dir, "pgf_pathclip.pdf"))
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/pyplot.py", line 561, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/figure.py", line 1410, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backend_bases.py", line 2220, in print_figure
**kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 864, in print_pdf
self._print_pdf_to_fh(fh, *args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 822, in _print_pdf_to_fh
self.print_pgf(fname_pgf, *args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-

Re: [matplotlib-devel] matplotlib 1.3.0rc3 tomorrow

2013-06-19 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I have tagged a 1.3.0rc3 and uploaded a tarball to Sourceforge.
> 
> We may not get all the binaries up in the next little while, so I'll 
> wait for those and then make an announcement on matplotlib-users.  After 
> a couple of weeks, assuming no serious problems, we'll be ready for 
> 1.3.0 final.
> 
> Thanks again to everyone for their help with this release!
> 
> Mike

Why does the distro include a setup.cfg, and why does it bear no 
resemblance to setup.cfg.template? (setup.cfg has just a few lines, and 
none of them are described in setup.cfg.template)

-- Russell


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib 1.3.0rc3 tomorrow

2013-06-19 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I have tagged a 1.3.0rc3 and uploaded a tarball to Sourceforge.
> 
> We may not get all the binaries up in the next little while, so I'll 
> wait for those and then make an announcement on matplotlib-users.  After 
> a couple of weeks, assuming no serious problems, we'll be ready for 
> 1.3.0 final.
> 
> Thanks again to everyone for their help with this release!

I have uploaded the MacOS 10.6 64-bit binary. However, there were a few 
unit test failures, including the font complaint that I first saw in an 
earlier 1.3.0 prerelease, plus one about pep8 that I've never seen 
before.

I have appended the output from python -c "import matplotlib as m ; 
m.test(verbosity=1)"

-- Russell

Last login: Wed Jun 19 12:36:54 on ttys001
localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.
.
.
..kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
EK.K.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
./Library/Frameworks/Python.framework
/Versions/2.7/lib/python2.7/site-packages/numpy/ma/core.py:777: 
RuntimeWarning: invalid value encountered in absolute
  return umath.absolute(a) * self.tolerance >= umath.absolute(b)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/ma/core.py:3791: UserWarning: Warning: converting a masked 
element to nan.
  warnings.warn("Warning: converting a masked element to nan.")
.../Library/Frameworks/Python.fra
mework/Versions/2.7/lib/python2.7/site-packages/matplotlib/gridspec.py:29
8: UserWarning: This figure includes Axes that are not compatible with 
tight_layout, so its results might be incorrect.
  warnings.warn("This figure includes Axes that are not "
/Library/Frameworks/Python.fr
amework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py:8
07: RuntimeWarning: invalid value encountered in absolute
  z = abs(x-y)
E
==
ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
--
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
result = func(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 146, in test_pathclip
plt.savefig(os.path.join(result_dir, "pgf_pathclip.pdf"))
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/pyplot.py", line 561, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/figure.py", line 1410, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backend_bases.py", line 2220, in print_figure
**kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 865, in print_pdf
self._print_pdf_to_fh(fh, *args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_p

Re: [matplotlib-devel] 1.3.0rc5 tagged

2013-07-22 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> At long last, I have a 1.3.0rc5 tagged.  I really hope to the software 
> deities that this is the last rc before final.
> 
> If you wouldn't mind creating and posting the binaries, I'll make an 
> announcment on matplotlib-users, give this a week and then put final out.

I have uploaded a binary for MacOS X 10.6 and later.


There were a few oddities this time around:
- matplotlib now requires pyparsing. I don't remember that being a 
requirement before -- even for previous 1.3 candidates.

- I had a lot of trouble with matplotlib complaining that dateutil was 
not present, even though it was in my site-packages. So I tried to 
reinstall it using pip install -U dateutil. Unfortunately pip has never 
heard of "dateutil". After some searching I realized the package name is 
actually "python-dateutil" (and not dateutils, which is a different 
package, alas). Even then, I had to install/upgrade it twice -- for some 
reason matplotlib couldn't find it at first. Very puzzling. I have no 
idea what was going on, but also didn't want to spend a lot of time 
trying to debug it.

- I get a few unit tests failures, including a slew of 
DeprecationWarnings about Operator '<<' that I don't remember seeing 
before. I have appended the test log.

- I first tried building on 10.8 and running on 10.6 (since that's much 
simpler for me). Unfortunately it doesn't work; on 10.6 it acts as if 
the unit tests themselves aren't part of the package. I have no idea 
why. I appended a log snippet showing the basic message, but I haven't 
looked into it further. This sounds worth spending some time tracking 
down.

-- Russell


Log of unit tests, with a few \n inserted for readability.
This is for a package built on 10.6 and running on 10.8.

python -c "import matplotlib as m ; m.test(verbosity=1)"
.
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2182: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
  float_literal << Regex(r"[-+]?([0-9]+\.?[0-9]*|\.[0-9]+)")
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2183: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
  int_literal   << Regex("[-+]?[0-9]+")
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2185: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
  lbrace<< Literal('{').suppress()
...(and 40-odd more examples of the same that I omitted)...
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2319: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
  main  << (non_math + ZeroOrMore(math_string + non_math)) + 
StringEnd()
.
.
..
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family 
['sans-serif'] not found. Falling back to Helvetica
  (prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match 
:family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
l:size=medium. Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
  UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match 
:family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
l:size=24.0. Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
  UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match 
:family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
l:size=large. Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
  UserWarning)
F...kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
EK.K.
.
.
.
.
.

Re: [matplotlib-devel] 1.3.0rc5 tagged

2013-07-24 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> On 07/22/2013 05:59 PM, Russell E. Owen wrote:
> > In article <[email protected]>,
> >   Michael Droettboom 
> >   wrote:
> >
> >> At long last, I have a 1.3.0rc5 tagged.  I really hope to the software
> >> deities that this is the last rc before final.
> >>
> >> If you wouldn't mind creating and posting the binaries, I'll make an
> >> announcment on matplotlib-users, give this a week and then put final out.
> > I have uploaded a binary for MacOS X 10.6 and later.
> >
> >
> > There were a few oddities this time around:
> > - matplotlib now requires pyparsing. I don't remember that being a
> > requirement before -- even for previous 1.3 candidates.
> 
> It's been a requirement for time immemorial, but only in 1.3.0 (all of 
> the release candidates) has it become an external dependency. What error 
> occurred that suggests something changed?

I suspect what changed is you don't include it anymore (but I would have 
expected that change in earlier 1.3.0 prereleases).

>> - I had a lot of trouble with matplotlib complaining that dateutil was
> > not present, even though it was in my site-packages. So I tried to
> > reinstall it using pip install -U dateutil. Unfortunately pip has never
> > heard of "dateutil". After some searching I realized the package name is
> > actually "python-dateutil" (and not dateutils, which is a different
> > package, alas). Even then, I had to install/upgrade it twice -- for some
> > reason matplotlib couldn't find it at first. Very puzzling. I have no
> > idea what was going on, but also didn't want to spend a lot of time
> > trying to debug it.
> 
> Does `python setup.py install` (of matplotlib) not install it 
> automatically?  We are bearing all the pain of setuptools in order for 
> that to happen, so if it's not, that's a real problem.

I am building a binary installer, so I don't use "python setup.py 
install". I use bdist_mpkg, which presumably does something similar to 
"python setup.py build" and packages the results (without installing 
them).

In any case, I need to know which packages matplotlib needs so I can 
warn users to install them in the binary installer's ReadMe file. The 
list is rather long. I miss having this stuff included in matplotlib. At 
this point I know of the following (aside from numpy):
- python-dateutil (unfortunately matplotlib complains about missing 
"dateutil" if it's absent; it would help to give the name of the package 
as known by pip, rather than what is imported)
- pytz
- six
- pyparsing

> > - I get a few unit tests failures, including a slew of
> > DeprecationWarnings about Operator '<<' that I don't remember seeing
> > before. I have appended the test log.
> 
> That's probably related to pyparsing 2.0.1 (released just this week).  
> I'd like to fix those warnings, but then we'd have to *require* 
> pyparsing 2.0.1 (no earlier Python 2.x release of pyparsing includes an 
> alternative syntax).  I think pyparsing moved too quickly on this one, 
> but I'm not sure what we can do about it. It does make me long for the 
> days when we included our dependencies so we have some control over this 
> stuff.

Great. This sounds innocuous.

> > - I first tried building on 10.8 and running on 10.6 (since that's much
> > simpler for me). Unfortunately it doesn't work; on 10.6 it acts as if
> > the unit tests themselves aren't part of the package. I have no idea
> > why. I appended a log snippet showing the basic message, but I haven't
> > looked into it further. This sounds worth spending some time tracking
> > down.
> 
> That's a puzzler.  I've seen that crop up on Travis erratically as well, 
> but not consistently.  It's not clear what's going on here -- will have 
> to think on it.

I'm not sure how to diagnose this, but if you have any ideas, let me 
know. (Though I should probably read the rest of the messages on this 
thread before saying that.)

-- Russell


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

2013-07-31 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I have tagged and uploaded matplotlib 1.3.0 final.  Congratulations to 
> all involved!  It was a long slog getting this release out, and I 
> appreciate everyone's patience.
> 
> Once we have binaries uploaded to SourceForge, I will make a formal 
> announcement in the usual channels.

I built the Mac binary on MacOS X 10.6 but have run into two problems:
- Most of the unit tests are missing, so I can't properly test the 
results. But my application that uses matplotlib and TkAgg works fine, 
so may well be OK. Also, I checked and the installer was trying to build 
all expected backends (including the native Mac backend).

- When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and 
the pytz and dateutil that it installs) it breaks pytz and dateutils, by 
deleting most of the contents, leaving only a subdir named zoneinfo in 
each package (with different contents for each package).

Installing a new pytz and dateutils and running the 1.3.0 binary 
installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves 
these packages functional (though it changes the modification date, so 
it's doing something).

I have replicated this several times.

I'm not sure whether to upload this installer. It's a bit dangerous and 
ill tested.

-- Russell


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

2013-07-31 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> On 07/31/2013 01:47 PM, Russell E. Owen wrote:
> > In article <[email protected]>,
> >   Michael Droettboom 
> >   wrote:
> >
> >> I have tagged and uploaded matplotlib 1.3.0 final.  Congratulations to
> >> all involved!  It was a long slog getting this release out, and I
> >> appreciate everyone's patience.
> >>
> >> Once we have binaries uploaded to SourceForge, I will make a formal
> >> announcement in the usual channels.
> > I built the Mac binary on MacOS X 10.6 but have run into two problems:
> > - Most of the unit tests are missing, so I can't properly test the
> > results. But my application that uses matplotlib and TkAgg works fine,
> > so may well be OK. Also, I checked and the installer was trying to build
> > all expected backends (including the native Mac backend).
> 
> What do you mean the unit tests are missing?  They don't run?  Can you 
> send the output from nose?

I have appended my test log. I don't know how to run the tests using 
nose, but will be happy to have a go with instructions. (Running 
"nosetests" in the matplotlib source dir does nothing useful).

> Glad to hear about the installer building the macosx backend -- that was 
> pretty serious when it wasn't doing that.
> 
> >
> > - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and
> > the pytz and dateutil that it installs) it breaks pytz and dateutils, by
> > deleting most of the contents, leaving only a subdir named zoneinfo in
> > each package (with different contents for each package).
> >
> > Installing a new pytz and dateutils and running the 1.3.0 binary
> > installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves
> > these packages functional (though it changes the modification date, so
> > it's doing something).
> 
> I thought you were including pytz and dateutils in your installer. Is 
> that not the case?  If not, isn't it enough to document that matplotlib 
> now doesn't ship with these dependencies, and they will need to be 
> installed using pip or other means?  Can they be installed afterward and 
> have things work?

matplotlib used to include pytz and dateutil in its installation. This 
seemed to be a very good thing overall, since it made sure the 
dependencies were satisfied, though it is possible that it occasionally 
overwrite a version the user would have preferred to have.

In any case the matplotlib developers removed support for this feature 
in 1.3. As a result, binary installers now have to tell users to install 
these packages manually (as well as six and pyparsing). It may be 
possible to postprocess the Mac binary installer to install these 
packages, but I don't know how to do it.

The problem is that under some circumstances the new installer may trash 
existing installations of python-dateutils and pytz. I consider that 
unacceptable. Why break things that are already installed?

In other words, we seem to have the worst of the old world and the new: 
don't install the new packages but perhaps break them if they already 
exist. Unfortunately breakage is likely to be the norm because most 
users will be upgrading from matplotlib 1.2.1.

-- Russell

--- log of attempts to run tests -

Last login: Wed Jul 31 09:33:19 on ttys000
rowen$ python -c "import matplotlib as m ; m.test(verbosity=1)"

==
ERROR: Failure: AttributeError ('module' object has no attribute 
'test_agg')
--
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/loader.py", line 402, in loadTestsFromName
module = resolve_name(addr.module)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/util.py", line 321, in resolve_name
obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_agg'

==
ERROR: Failure: AttributeError ('module' object has no attribute 
'test_arrow_patches')
--
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/loader.py", line 402, in loadTestsFromName
module = resolve_name(addr.module)

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

2013-07-31 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> On 07/31/2013 01:47 PM, Russell E. Owen wrote:
> > In article <[email protected]>,
> >   Michael Droettboom 
> >   wrote:
> >
> >> I have tagged and uploaded matplotlib 1.3.0 final.  Congratulations to
> >> all involved!  It was a long slog getting this release out, and I
> >> appreciate everyone's patience.
> >>
> >> Once we have binaries uploaded to SourceForge, I will make a formal
> >> announcement in the usual channels.
> > I built the Mac binary on MacOS X 10.6 but have run into two problems:
> > - Most of the unit tests are missing, so I can't properly test the
> > results. But my application that uses matplotlib and TkAgg works fine,
> > so may well be OK. Also, I checked and the installer was trying to build
> > all expected backends (including the native Mac backend).
> 
> What do you mean the unit tests are missing?  They don't run?  Can you 
> send the output from nose?
> 
> Glad to hear about the installer building the macosx backend -- that was 
> pretty serious when it wasn't doing that.

Yes.

All the interesting information about a build is printed at the 
beginning and soon scrolls out of sight, so it's usually not obvious if 
a build is missing something expected.

That seems to be standard for unix and distutils installers, so I 
suspect it would not be trivial to change. Would it make sense to add a 
unit test that verifies the mac backend was built?

-- Russell


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

2013-07-31 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> On 07/31/2013 05:05 PM, Russell E. Owen wrote:
> > In article <[email protected]>,
> >   Michael Droettboom 
> >   wrote:
> >
> >> On 07/31/2013 01:47 PM, Russell E. Owen wrote:
> >>> In article <[email protected]>,
> >>>Michael Droettboom 
> >>>wrote:
> >>>
> >>>> I have tagged and uploaded matplotlib 1.3.0 final.  Congratulations to
> >>>> all involved!  It was a long slog getting this release out, and I
> >>>> appreciate everyone's patience.
> >>>>
> >>>> Once we have binaries uploaded to SourceForge, I will make a formal
> >>>> announcement in the usual channels.
> >>> I built the Mac binary on MacOS X 10.6 but have run into two problems:
> >>> - Most of the unit tests are missing, so I can't properly test the
> >>> results. But my application that uses matplotlib and TkAgg works fine,
> >>> so may well be OK. Also, I checked and the installer was trying to build
> >>> all expected backends (including the native Mac backend).
> >> What do you mean the unit tests are missing?  They don't run?  Can you
> >> send the output from nose?
> > I have appended my test log. I don't know how to run the tests using
> > nose, but will be happy to have a go with instructions. (Running
> > "nosetests" in the matplotlib source dir does nothing useful).
> 
> Thanks.  It's using nose under the hood, so that's exactly what I 
> meant.  I should have been more clear.
> 
> I'm not sure what might be causing this.  As a sanity check (and maybe 
> you've already done this), have you tried doing "rm -rf matplotlib*" in 
> your site-packages directory?
> 
> >
> >> Glad to hear about the installer building the macosx backend -- that was
> >> pretty serious when it wasn't doing that.
> >>
> >>> - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and
> >>> the pytz and dateutil that it installs) it breaks pytz and dateutils, by
> >>> deleting most of the contents, leaving only a subdir named zoneinfo in
> >>> each package (with different contents for each package).
> >>>
> >>> Installing a new pytz and dateutils and running the 1.3.0 binary
> >>> installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves
> >>> these packages functional (though it changes the modification date, so
> >>> it's doing something).
> >> I thought you were including pytz and dateutils in your installer. Is
> >> that not the case?  If not, isn't it enough to document that matplotlib
> >> now doesn't ship with these dependencies, and they will need to be
> >> installed using pip or other means?  Can they be installed afterward and
> >> have things work?
> > matplotlib used to include pytz and dateutil in its installation. This
> > seemed to be a very good thing overall, since it made sure the
> > dependencies were satisfied, though it is possible that it occasionally
> > overwrite a version the user would have preferred to have.
> 
> It also made it impossible to install security updates in those other 
> packages, which was a problem for Linux distros, MacPorts, homebrew, etc.

I confess I'm surprised because this feature was disabled by default. I 
had to manually enable it whenever I made a binary installer by editing 
setup.cfg.

> > In any case the matplotlib developers removed support for this feature
> > in 1.3. As a result, binary installers now have to tell users to install
> > these packages manually (as well as six and pyparsing). It may be
> > possible to postprocess the Mac binary installer to install these
> > packages, but I don't know how to do it.
> 
> I thought that was the solution we had arrived at in the earlier 
> discussion.  I'm sorry if I misunderstood.  If you "python setup.py 
> install" matplotlib into a fresh virtualenv, it will install all of 
> these dependencies.  Then that virtualenv's site-packages directory can 
> be used as the basis for the contents of the installer.  As I'm not a 
> Mac guy, and I don't understand how the installer is built, is there a 
> reason that wouldn't work?

I build the Mac binaries using bdist_mpkg. I'm afraid I don't know how 
it works under the hood. It creates an "mpkg" binary installer in the 
dist subdirectory. To run tests, I install matplotlib (

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

2013-08-07 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> Ludwig, this is one of the most entertaining e-mails I've read in a 
> while, and I think your arguments make a lot of sense.
> 
> Given infinite developer resources, do you think there's any logic to 
> providing *both* system Python and python.org based binaries? How much 
> additional work would that be?
> 
> I think the big problems to solve now is
> 
> (a) get to the bottom of why the new installer is breaking existing 
> installations of dateutil and pytz.  Russell: even though they are not 
> currently working, could you provide what you have so that others can 
> have a look?

I put the installer here (and announced it earlier -- I thought in this 
thread):


I do not consider it safe because:
- It may trash existing installations of dateutil and pytz (especially 
those installed by the matplotlib 1.2.1 binary installer)
- It does not include pytz, dateutil and six (unlike the 1.2.1 binary 
installer), so it's a real pain to use
- It is missing its unit tests and so is poorly tested
- It also appears that pylab is broken (something I only recently 
discovered)

Unless somebody figures out how to include the dependencies, I think a 
Mac binary installer is a nonstarter.

-- Russell

P.S. the Mac binary installer for numpy used to be easy to find. I was 
quite dismayed to find how buried it had become when I went looking for 
it a week or two ago.


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.3.0 final tagged and uploaded

2013-08-08 Thread Russell E. Owen 
In article ,
 "Russell E. Owen"  wrote:

> In article <[email protected]>,
>  Michael Droettboom  
>  wrote:
> 
> > Ludwig, this is one of the most entertaining e-mails I've read in a 
> > while, and I think your arguments make a lot of sense.
> > 
> > Given infinite developer resources, do you think there's any logic to 
> > providing *both* system Python and python.org based binaries? How much 
> > additional work would that be?
> > 
> > I think the big problems to solve now is
> > 
> > (a) get to the bottom of why the new installer is breaking existing 
> > installations of dateutil and pytz.  Russell: even though they are not 
> > currently working, could you provide what you have so that others can 
> > have a look?
> 
> I put the installer here (and announced it earlier -- I thought in this 
> thread):
> <http://www.astro.washington.edu/users/rowen/python/>
> 
> I do not consider it safe because:
> - It may trash existing installations of dateutil and pytz (especially 
> those installed by the matplotlib 1.2.1 binary installer)
> - It does not include pytz, dateutil and six (unlike the 1.2.1 binary 
> installer), so it's a real pain to use
> - It is missing its unit tests and so is poorly tested
> - It also appears that pylab is broken (something I only recently 
> discovered)

I was able to fix the last two problems and I uploaded a new binary 
installer to the location mentioned above. It still will delete 
python-dateutil under some circumstances (not fully tested, but the last 
one would not trash it if it was installed by pip, but would trash it if 
installed by the matplotlib 1.2.1 binary installer). I could imagine 
making it the official installer anyway, for lack of anything better. 
But it's certainly not ideal.

It is surely not that hard to make an installer that can also install 
other packages. But it's not something I have time to investigate right 
now.

BTW: pip refuses to install pytz for me, claiming a suitable version was 
not found, and listing dozens of versions. Anyone else seen this? I 
don't recall seeing it before recently. I ended up downloading the 
source and using distutils.

-- Russell


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] I have a Mac!

2013-08-20 Thread Russell E. Owen 
A few hints:

If you just want to build matplotlib for your own computer (and don't 
care about making an installer that will work on anybody else's) then 
you can install from source with very little trouble:
- You may want to edit setupext.py to limit searching to those dirs that 
really matter, but this is only needed if you have installed extras that 
might conflict.
- You may want to edit setup.cfg to select a better default back end.

You have to be much more careful if you want to build a binary installer 
that can be used by others. I've found that bdist_mpkg works, and I've 
found it is safest to build on the oldest platform I want the installer 
to support (for example /usr/X11/lib moved in 10.8 or 10.7 in a way that 
is forward but not backwards compatible).

For Apple's python you need install anything; all you need is in 
/usr/lib and /usr/X11/lib. I have no idea if TkAgg works well.

For python.org python you should install a version of Tcl/Tk. I suggest 
ActiveState Tcl/Tk 8.5.11. Be warned that versions 8.5.12, 8.5.12.1, 
8.5.13 all have known crashing problems; I have not tried 8.5.14 (which 
came out fairly recently) as 8.5.11 seems to do well enough.

I've cannot comment on building matplotlib for macports, fink or 
homebrew.

-- Russell

In article <[email protected]>,
 Michael Droettboom  
 wrote:

> We actually discussed this very issue yesterday in our Google hangout 
> about continuous integration. We're probably going to need to script a 
> full setup from a clean Mac + XCode to a working matplotlib development 
> environment in order to make that happen, and obviously that will be 
> shared with the world.  Things are even more complex on Windows, and I'd 
> like to do that there, too.  So stay tuned.
> 
> Mike
> 
> On 08/16/2013 10:02 AM, Paul Hobson wrote:
> > Mike,
> >
> > That's great news. Is there any chance we can look forward to 
> > "official" instructions for setting up a Mac to develop matplotlib?
> >
> > I gave up a long time ago and started piecing to together my meager 
> > PRs in a linux VM.
> > -paul
> >
> >
> > On Fri, Aug 16, 2013 at 6:52 AM, Michael Droettboom 
> >  > > wrote:
> >
> > Thanks to the gracious donation from Hans Petter Langtangen and the
> > Center for Biomedical Computing at Simula
> > (http://home.simula.no/~hpl ),
> > I now have a new Mac Mini sitting at my desk.  This should allow me to
> > keep on top of changes that affect the Mac builds and to better track
> > down Mac-only issues.
> >
> > Stay tuned over the next few weeks and months as we will most
> > likely be
> > using some more of these funds to pay for hosted continuous
> > integration
> > services (as discussed yesterday in our MEP19 Google Hangout).
> >
> > Cheers,
> > Mike


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] I have a Mac!

2013-08-22 Thread Russell E. Owen 
In article 
,
 Matt Terry  wrote:

> That is handy information.  I'll start adding a python.org target.
> 
> How broad coverage do we want?
> 10.6, 10.7, 10.8
> system, python.org (2.7, 3.3), brew, macports
> virtualenv, no virtualenv
> with/without third party X
> 
> The testing matrix blows up pretty quickly.  For those of you with longer
> memories, where are the corners where things tend to break?

That list looks reasonable to me, and I'm not sure how to whittle it 
down, and it may need to grow. MacOS X 10.9 will be out soon and you may 
also want to include fink. 

I'm not quite sure what you mean by with/without third party X. If you 
are referring to Tck/Tk:
- For Apple's python: I suggest testing both the built-in Tcl/TK and (if 
you can) ActiveState Tcl/Tk, since anyone who really cares about Tcl/Tk 
will probably not use the one provided by Apple (at least that was true 
in older versions of MacOS X; I can't speak for 10.8).
- For python.org I think you only need to test with ActiveState Tcl/Tk.
- for homebrew, macports and fink, I'm not sure how many choices you 
have; just one X11-based and one Aqua-based Tcl/Tk (if both are even 
available)?

-- Russell

> 
> -matt
> 
> 
> 
> On Tue, Aug 20, 2013 at 12:09 PM, Russell E. Owen 
>  wrote:
> 
> > A few hints:
> >
> > If you just want to build matplotlib for your own computer (and don't
> > care about making an installer that will work on anybody else's) then
> > you can install from source with very little trouble:
> > - You may want to edit setupext.py to limit searching to those dirs that
> > really matter, but this is only needed if you have installed extras that
> > might conflict.
> > - You may want to edit setup.cfg to select a better default back end.
> >
> > You have to be much more careful if you want to build a binary installer
> > that can be used by others. I've found that bdist_mpkg works, and I've
> > found it is safest to build on the oldest platform I want the installer
> > to support (for example /usr/X11/lib moved in 10.8 or 10.7 in a way that
> > is forward but not backwards compatible).
> >
> > For Apple's python you need install anything; all you need is in
> > /usr/lib and /usr/X11/lib. I have no idea if TkAgg works well.
> >
> > For python.org python you should install a version of Tcl/Tk. I suggest
> > ActiveState Tcl/Tk 8.5.11. Be warned that versions 8.5.12, 8.5.12.1,
> > 8.5.13 all have known crashing problems; I have not tried 8.5.14 (which
> > came out fairly recently) as 8.5.11 seems to do well enough.
> >
> > I've cannot comment on building matplotlib for macports, fink or
> > homebrew.
> >
> > -- Russell
> >
> > In article <[email protected]>,
> >  Michael Droettboom 
> >  wrote:
> >
> > > We actually discussed this very issue yesterday in our Google hangout
> > > about continuous integration. We're probably going to need to script a
> > > full setup from a clean Mac + XCode to a working matplotlib development
> > > environment in order to make that happen, and obviously that will be
> > > shared with the world.  Things are even more complex on Windows, and I'd
> > > like to do that there, too.  So stay tuned.
> > >
> > > Mike
> > >
> > > On 08/16/2013 10:02 AM, Paul Hobson wrote:
> > > > Mike,
> > > >
> > > > That's great news. Is there any chance we can look forward to
> > > > "official" instructions for setting up a Mac to develop matplotlib?
> > > >
> > > > I gave up a long time ago and started piecing to together my meager
> > > > PRs in a linux VM.
> > > > -paul
> > > >
> > > >
> > > > On Fri, Aug 16, 2013 at 6:52 AM, Michael Droettboom
> > > >  > > > <mailto:[email protected]>> wrote:
> > > >
> > > > Thanks to the gracious donation from Hans Petter Langtangen and the
> > > > Center for Biomedical Computing at Simula
> > > > (http://home.simula.no/~hpl <http://home.simula.no/%7Ehpl>),
> > > > I now have a new Mac Mini sitting at my desk.  This should allow
> > me to
> > > > keep on top of changes that affect the Mac builds and to better
> > track
> > > > down Mac-only issues.
> > > >
> > > > Stay tuned over the next few weeks and months as we will most
> > > > likely be
> > > > using some more of these funds to pay for hosted conti

[matplotlib-devel] font problems: fc-list takes up 100% of CPU and runs forever

2013-10-01 Thread Russell E. Owen 
I distribute a Mac application using matplotlib.

Recent versions that use matplotlib 1.3.0 fail to run on some new 
accounts. The symptoms are that the application never finishes loading 
and a task named "fc-list" takes up 100% of a core -- for as long as 
we've let it run (a good fraction of an hour).

The only solution we've found is to copy ~/.matplotlib from an account 
where it works to the new account.

It is reproducible on some machines, but unfortunately not mine. When I 
create a new account on my machine I do not see the problem. Thus I have 
not yet been able to come up with a minimal case that shows the problem. 
I'll try to get more info.

Is this is a known issue?

-- Russell


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] font problems: fc-list takes up 100% of CPU and runs forever

2013-10-02 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> I haven't heard of this issue before.
> 
> fc-list comes from the fontconfig project.  It is used to get a list of 
> all of the fonts installed on the system.  It sounds like there is some 
> bug there -- the usual culprit is that there is a slightly non-standard 
> font installed on the system and fontconfig has a hard time parsing it.  
> You could try updating fc-list (it's in all the major package managers).
> 
> As for a workaround from our end, we could try to set a timeout on 
> fc-list and just skip it if it takes too long.  We can't rely on it 
> being there on a Mac at all, so already we gracefully degrade to a less 
> thorough search for fonts when fc-list can't be found.

Thanks for the advice. A defective font is an interesting possibility.

I was wrong it's new in 1.3.0; turns out it's seen in much older 
versions of my application (back to using mpl 1.0.0), but apparently on 
few machines. 

The issue showed up when I added some fancy animated strip charts to my 
application (which may be a coincidence), not when I upgraded mpl.

I'm surprised the timeout on fc-list isn't working. Maybe something else 
is also using fc-list, but the fix is to add an ~/.matplotlib dir, which 
suggests it's an mpl issue.

-- Russell


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] font problems: fc-list takes up 100% of CPU and runs forever

2013-10-04 Thread Russell E. Owen 
In article <[email protected]>,
 Michael Droettboom  
 wrote:

> On 10/02/2013 01:34 PM, Russell E. Owen wrote:
> > In article <[email protected]>,
> >   Michael Droettboom 
> >   wrote:
> >
> >> I haven't heard of this issue before.
> >>
> >> fc-list comes from the fontconfig project.  It is used to get a list of
> >> all of the fonts installed on the system.  It sounds like there is some
> >> bug there -- the usual culprit is that there is a slightly non-standard
> >> font installed on the system and fontconfig has a hard time parsing it.
> >> You could try updating fc-list (it's in all the major package managers).
> >>
> >> As for a workaround from our end, we could try to set a timeout on
> >> fc-list and just skip it if it takes too long.  We can't rely on it
> >> being there on a Mac at all, so already we gracefully degrade to a less
> >> thorough search for fonts when fc-list can't be found.
> > Thanks for the advice. A defective font is an interesting possibility.
> >
> > I was wrong it's new in 1.3.0; turns out it's seen in much older
> > versions of my application (back to using mpl 1.0.0), but apparently on
> > few machines.
> >
> > The issue showed up when I added some fancy animated strip charts to my
> > application (which may be a coincidence), not when I upgraded mpl.
> >
> > I'm surprised the timeout on fc-list isn't working.
> 
> We don't currently do a timeout -- we make a blocking call to fc-list.  
> I was only suggesting it as a possible fix for this problem.

Sorry. I read too hastily. If it's not too hard to code a time limit, it 
sounds like a good idea.

> >   Maybe something else
> > is also using fc-list, but the fix is to add an ~/.matplotlib dir, which
> > suggests it's an mpl issue.
> 
> When you copy over the .matplotlib dir, you copy over the font cache.  
> When matplotlib finds a font cache, it doesn't need to generate a list 
> of fonts, so thus doesn't need to call fc-list.  But copying font caches 
> from one machine to another is unlikely to work (the set of fonts and 
> their locations is quite likely different). Worse yet, if matplotlib 
> attempts to look up a font and finds that it isn't where the cache says 
> it is, it regenerates the cache again, and thus you could get this 
> hanging anyway.

Thank you for that warning.

As a followup: one of the two computers had 3 copies of fc-list (one 
from darwinports, one in /usr/local/bin and the on provided with Apple's 
X11). Making sure Apple's version ran seems to have cleared up the 
problem, based on one test. So we may have a fix.

I really appreciate the help.

-- Russell


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib user guide

2013-10-04 Thread Russell E. Owen 
In article <[email protected]>,
 mark  wrote:

> Many thanks for the feedback.
> 
> So ,my first cut was to segregate the user guide by topic.  Below is
> the summary I had in mind for an Introduction for New Users.
> 
> Hopefully this gives a flavour of what I have in mind.
> 
> I will attempt to put this into practice and post again when I have a
> user guide coded that might work in my view.
> 
> mark
> 
> 
> Introducing Plotting with Matplotlib
> 
> Pyplot tutorial
> Controlling line properties
> Working with multiple figures and axes
> Working with text
> Interactive navigation
> Navigation Keyboard Shortcuts
> Working with text
> Text introduction
> Basic text commands
> Text properties and layout
> Writing mathematical expressions
> Text rendering With LaTeX
> Annotating text
...

On the whole this looks good to me. I so have a few comments, however:
- Would you be willing to include a section on using the class API? (I'm 
assuming the above is all based on using pyplot?). I find there is a 
huge gap between pyplot and the class API, and the documentation I've 
found does little to bridge that gap.
- You have "Working with text" (including "annotating text") early on, 
then "Legend guide" and "Annotating Axes" much later on. I wish these 
were all together, as axes (values and labels), plot titles and legends 
are arguably the main use cases for text in plots. Perhaps it would 
suffice to have "Working with text" give a brief overview of how to do 
each of these things, with pointers to the other sections for details. 
An alternative is subsections within Working with text.
- In a similar vein: I'm surprised GridSpec comes before legends and 
annotating axes.
- Please consider a section on 3-d plots.
- Please consider a section on animation.

-- Russell


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] OS-X binaries?

2013-10-23 Thread Russell E. Owen 
In article 
,
 Matthew Brett  
 wrote:

> Hi Chris,
> 
> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
>  wrote:
> > Are there recent binaries for OS-X anywhere? There don't seem to be
> > any for recent releases on the MPL download page.
> >
> > I know we had a discussion about this a whole back, but don't remember
> > the outcome. But I hope we'll continue to put them up-- macports and
> > friends really aren't the best solutions for everyone.
> 
> I hope I have this cracked now, at least in principle.
> 
> The latest versions are here:
> 
> http://nipy.bic.berkeley.edu/scipy_installers/
> 
> Following Matt Terry's example, I'm testing the builds and then the
> installers here:
> 
> https://travis-ci.org/matthew-brett/mpl-osx-binaries

The last ones I got from you worked very well: just a few test failures 
and the current one seems to be doing about the same.

Thank you very much for providing these! I hope you will post them to 
the matplotlib official site.

One odd failure (in both of them) that I don't remember seeing before:
/2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485: 
RuntimeWarning: invalid value encountered in arcsin
  theta = np.arcsin(y / np.sqrt(2))

There's a complaint about an invalid font name, but I've seen that for 
quite some time:
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '

FAILED (KNOWNFAIL=2, SKIP=1, errors=2)

One small suggestion: if it's not too much trouble, might you make them 
.dmgs? It's a bit more convenient then having to unzip them to use them. 
But if it's too much work don't bother; zipped mpkg are fine and it's 
wonderful to have complete binary installers.

-- Russell


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

2014-06-03 Thread Russell E. Owen 
In article 
,
 Chris Barker  wrote:

> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett 
> 
> wrote:
> 
> > > what is this going to do on OS-X 10.7 and 10.8  systems running homebrew
> > or
> > > macports pythons? It seems this list could get pretty long!
> >
> Yes, it could, but this list:
> >
> > so we would have to add all those if we wanted to support them...
> 
> 
> 
> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion
> >
> >
> very interesting stats! I wonder how representative those are? Makes we
> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries
> could be 64 bit only. It would simplify things a bit.

I hope you will not drop 32-bit support yet.. I still use it to 
distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk 
8.5 have a nasty crashing bug that I have not found a workaround for, 
and old enough versions that don't have the bug need to run in 32-bit 
mode on Mavericks.

-- Russell


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

2014-06-04 Thread Russell E. Owen 
In article 
,
 Matthew Brett  
 wrote:

> Hi,
> 
> On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen 
>  wrote:
> > In article
> >  > public.gmane.org>,
> >  Chris Barker  wrote:
> >
> >> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett
> >> 
> >> wrote:
> >>
> >> > > what is this going to do on OS-X 10.7 and 10.8  systems running 
> >> > > homebrew
> >> > or
> >> > > macports pythons? It seems this list could get pretty long!
> >> >
> >> Yes, it could, but this list:
> >> >
> >> > so we would have to add all those if we wanted to support them...
> >>
> >>
> >>
> >> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion
> >> >
> >> >
> >> very interesting stats! I wonder how representative those are? Makes we
> >> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org 
> >> binaries
> >> could be 64 bit only. It would simplify things a bit.
> >
> > I hope you will not drop 32-bit support yet.. I still use it to
> > distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk
> > 8.5 have a nasty crashing bug that I have not found a workaround for,
> > and old enough versions that don't have the bug need to run in 32-bit
> > mode on Mavericks.
> 
> Do you need 32 bit support for the wheels or just for the MacPython
> binaries?   It's getting harder to build 32 / 64 bit universal
> binaries these days...

What I need is a python, numpy, and matplotlib that support 32-bit and 
(preferably) 64-bit for MacOS X 10.6 and later. I have been using 
python.org python and the standard binary installers until now.

Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is 
required for older versions of Tcl/Tk to run under Mavericks and as I 
noted, I can't use recent versions due to due to a bug (example 
appended) that I've not found a workaround for.

I realize I'm in an unusual situation, and I"m not the one building the 
binaries and trying to deal with the ATLAS headaches. If worst comes to 
worst we can stay at the current version of numpy and matplotlib (at 
least for now). Long term we should probably switch away from Tcl/TK, 
though that would be a huge undertaking, or hire somebody to fix the 
Tcl/Tk bug.

-- Russell

# tcl menu crash; run in wish and push the Change Font button
menu .parentMenu
menu .parentMenu.apple -tearoff 0
# the following line is optional, but shows the menu is created
.parentMenu add cascade -label Wish -menu .parentMenu.apple
font create testFont
option add "*Button.font" testFont
button .btn -text "Change Font" -command { font configure testFont -size 
20 }
pack .btn
. configure -menu .parentMenu


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel