Re: [matplotlib-devel] mkpg on OSX

[Russell Owen]

On Aug 4, 2009, at 8:09 PM, John Hunter wrote:

> On Mon, Aug 3, 2009 at 2:58 PM, Russell E. Owen wrote:
>
>> 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.
>
> Following some of the suggestions in this thread and on the sf bug  
> report
>
>  
> https://sourceforge.net/tracker/index.php?func=detail&aid=2831805&group_id=80706&atid=560720
>
> I rebuilt the OSX binaries from scratch, using a src framework build
> of python, and activetcl as suggested by Russell.  The rc2 build
> candidates are at
>
>  http://drop.io/xortel1#
>
> If anyone has a chance to test them, that would be great.

Thank you very much. Unfortunately it doesn't work for me. Trying to  
import pylab results in a bus error (I appended the log in case it has  
anything useful in it).

My configuration:
- Intel Mac
- MacOS X 10.5.7
- Python 2.5.2 (in /Library/Frameworks... from python.org)
- Tcl/Tk 8.4.19 (in /Library/Frameworks... from ActiveState)
- this occurs with or without a ~/.matplotlib/matplotlibrc file (that  
uses TkAgg) and with or without a ~/.matplotlib directory at all
I have confirmed that Tkinter works fine.

I'll see if I can build a binary, though perhaps I should first try  
using a conventional recipe, then if that works, compare it to the  
makefile.

-- Russell

Process: Python [2293]
Path:/Library/Frameworks/Python.framework/Versions/2.5/ 
Resources/Python.app/Contents/MacOS/Python
Identifier:  Python
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  bash [2260]

Interval Since Last Report:  346695 sec
Crashes Since Last Report:   8
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   4

Date/Time:   2009-08-04 20:58:49.631 -0700
OS Version:  Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  683AF09F-7779-4567-A264-ACBF18B9AB0B

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x
Crashed Thread:  0

Thread 0 Crashed:
0   ??? 00 0 + 0
1   org.python.python   0x0049ed67  
_PyImport_LoadDynamicModule + 153 (importdl.c:54)
2   org.python.python   0x0049ca49 load_module + 201  
(import.c:1758)
3   org.python.python   0x0049cf13 import_submodule + 293  
(import.c:2400)
4   org.python.python   0x0049d161 load_next + 195  
(import.c:2220)
5   org.python.python   0x0049d655 import_module_level +  
213 (import.c:2008)
6   org.python.python   0x0049db05  
PyImport_ImportModuleLevel + 45 (import.c:2072)
7   org.python.python   0x00478917 builtin___import__ + 156  
(bltinmodule.c:49)
8   org.python.python   0x003f8b00 PyObject_Call + 45  
(abstract.c:1861)
9   org.python.python   0x0047d6fe  
PyEval_CallObjectWithKeywords + 112 (ceval.c:3442)
10  org.python.python   0x004806e6 PyEval_EvalFrameEx +  
8542 (ceval.c:2067)
11  org.python.python   0x00484e0e PyEval_EvalCodeEx + 1819  
(ceval.c:2836)
12  org.python.python   0x00484fc2 PyEval_EvalCode + 87  
(ceval.c:500)
13  org.python.python   0x0049be36  
PyImport_ExecCodeModuleEx + 193 (import.c:675)
14  org.python.python   0x0049c28c load_source_module + 726  
(import.c:959)
15  org.python.python   0x0049cf13 import_submodule + 293  
(import.c:2400)
16  org.python.python   0x0049d161 load_next + 195  
(import.c:2220)
17  org.python.python   0x0049d60e import_module_level +  
142 (import.c:2001)
18  org.python.python   0x0049db05  
PyImport_ImportModuleLevel + 45 (import.c:2072)
19  org.python.python   0x00478917 builtin___import__ + 156  
(bltinmodule.c:49)
20  org.python.python   0x003f8b00 PyObject_Call + 45  
(abstract.c:1861)
21  org.python.python   0x0047d6fe  
PyEval_CallObjectWithKeywords + 112 (ceval.c:3442)
22  org.python.python   0x004806e6 PyEval_EvalFrameEx +  
8542 (ceval.c:2067)
23  org.python.python   0x00484e0e PyEval_EvalCodeEx + 1819  
(ceval.c:2836)
24  org.python.python   0x00484fc2 PyEval_EvalCode + 87  
(ceval.c:500)
25  org.python.python   0x0049be36  
PyImport_ExecCodeModuleEx + 193 (import.c:675)
26  org.python.python   0x0049c28c load_source_module + 726  
(import.c:959)
27  org.python.python   0x0049cf13 import_submodule + 293  
(import.c:2400)
28  org.python.python   0x0049d4be ensure_fromlist + 448  
(import.c:2311)
29  org.python.python   0x0049d893 import_module_level +  
787 (import.c:2038)
30  org.python.python   0x0049db05  
PyImport_ImportMod

Re: [matplotlib-devel] mkpg on OSX

[Russell Owen]

The segfault I reported on was on home computer. Today at work I tried  
the same installer and it works fine on my work machine. I performed  
the tests (though I doubt they're relevant since TkAgg works) and came  
up with:



python myscript.py -dTkAgg


works (at work)


python myscript.py -dWXAgg


I don't have wxPython installed so it fails as expected.


python myscript.py -dAgg


Works but I have no idea where the output goes.


python myscript.py -dmacosx


Works.

I can try more tests at home, but not until this evening. My *guess*  
based on past experience with matplotlib segfaults in TkAgg is that  
all those tests will pass except TkAgg, and that TkAgg will work if I  
move my /Library/Frameworks Tcl/Tk aside.


-- Russell

On Aug 5, 2009, at 3:27 AM, John Hunter wrote:

On Tue, Aug 4, 2009 at 11:04 PM, Russell  
Owen wrote:


Thank you very much. Unfortunately it doesn't work for me. Trying  
to import
pylab results in a bus error (I appended the log in case it has  
anything

useful in it).

My configuration:
- Intel Mac
- MacOS X 10.5.7
- Python 2.5.2 (in /Library/Frameworks... from python.org)
- Tcl/Tk 8.4.19 (in /Library/Frameworks... from ActiveState)
- this occurs with or without a ~/.matplotlib/matplotlibrc file  
(that uses

TkAgg) and with or without a ~/.matplotlib directory at all
I have confirmed that Tkinter works fine.\


Can you create a small test script that creates an mpl figure and
saves it with savefig, and run it with


python myscript.py -dTkAgg



python myscript.py -dWXAgg



python myscript.py -dAgg



python myscript.py -dmacosx


and let me know if all segfault, and if not, which ones do?

JDH


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] mkpg on OSX

[Russell Owen]

I did the following and now matplotlib 0.99.0 rc2 runs fine on my home  
computer:
- I reverted my site-packages to its state before running the  
matplotlib-0.99.0.rc2-py2.5-macosx10.5.mpkg installer

 (I had saved a zip file just in case anything went wrong)
- I found I had numpy 1.2.1 installed, so I upgraded to 1.3.0
- I found I had some version of pytz and dateutil installed, so I  
deleted them (in case there was a conflict with the versions  
matplotlib wanted to use)
- I ran the matplotlib-0.99.0.rc2-py2.5-macosx10.5.mpkg again (from a  
dmg that I'd created)


Now it all works!

I hope that numpy was too old, since I don't see how the other changes  
could possibly be relevant.



By the way: the ReadMe in the matplotlib Mac binary installer is for  
the source distro, and so not very relevant to the Mac installer. If  
and when you have time I suggest writing one for the Mac. Relevant  
info includes:

- which back ends are supported in this build
- minimum required versions for wxPython (if using wxAgg), numpy, Tcl/ 
Tk, GTK (if relevant), etc.


I will send you the file I used to use when I built a matplotlib  
installer. bdist_mpkg has a --readme flag or you can just copy it  
manually, overwriting whatever it put in there. Please feel free to do  
as you like with the file; I have no proprietary feelings about it.


Thank you very, very much for making the installer and being willing  
to work on the Tcl/Tk crash. It's great that you have figured out an  
automated way to build it that works and supports Tcl/Tk. My process  
was manual and rather a pain (copying object libraries into /usr/local/ 
lib, bdist_mpkg, removing the libraries again...).


Regards,

-- Russell

On Aug 5, 2009, at 3:27 AM, John Hunter wrote:

On Tue, Aug 4, 2009 at 11:04 PM, Russell  
Owen wrote:


Thank you very much. Unfortunately it doesn't work for me. Trying  
to import
pylab results in a bus error (I appended the log in case it has  
anything

useful in it).

My configuration:
- Intel Mac
- MacOS X 10.5.7
- Python 2.5.2 (in /Library/Frameworks... from python.org)
- Tcl/Tk 8.4.19 (in /Library/Frameworks... from ActiveState)
- this occurs with or without a ~/.matplotlib/matplotlibrc file  
(that uses

TkAgg) and with or without a ~/.matplotlib directory at all
I have confirmed that Tkinter works fine.\


Can you create a small test script that creates an mpl figure and
saves it with savefig, and run it with


python myscript.py -dTkAgg



python myscript.py -dWXAgg



python myscript.py -dAgg



python myscript.py -dmacosx


and let me know if all segfault, and if not, which ones do?

JDH


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:

On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root   
wrote:



On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen  wrote:
On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:

On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen   
wrote:

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
  ...

 602.837684   1.4
 607.837700   1.4

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

-- Russell


Russell,

I am curious, I recently ran into problems with mixing builds of  
numpy and matplotlib at various levels of revisions.  I eventually  
had to do a complete clean rebuild.  Note, what I mean by a  
complete clean rebuild is that I removed the numpy and matplotlib  
source directories and re-checkout the codes from source and then  
rebuild.  I would be curious if the problem persists after that.


An interesting question. I can say that this was a clean build of  
matplotlib since I ran it "in place" (in build/lib.linux- 
x86_64-2.6/) after building it rather than installing it in site- 
packages to avoid messing up other users (on the linux system this  
was a shared python). I modified the script to print  
matplotlib.__file__ to make sure I was running the right version. I  
doubt it was a clean build of numpy. But considering no numerics are  
occurring in this example (it is literally just creating an Axes on  
a Canvas and calling canvas.draw() repeatedly) do you think numpy  
could possibly come into this?



It is quite possible.  Numpy is used extensively throughout the  
matplotlib system, regardless of whether you are using it or not.   
Also, the fact that you are on a shared system is interesting.  For  
those situations, try doing


"python setupegg.py develop --user"

for the build command.  What this does is builds everything in-place  
(the build directory symbolically links to those files), and then  
uses your ~/.local directory to install an egg.lnk file to point  
back to the build directory.  This should have higher search  
precedence than the system install of matplotlib and numpy.


Note, I had mixed success with this approach on a RHEL (5?) system  
recently.  I don't know how recently ~/.local became widely accepted  
among various distros.


Might you run the script on your system with the clean build?

-- Russell


I will give it a shot (once my other analysis programs are done for  
the day).


Ben Root

I ran your script from the url you posted earlier.  My build does  
not show any leak for about a minute.  I am fairly certain that what  
we have here is a build mixing issue or an issue with an unknown  
combination of libraries interacting.  Could you post your build logs?


Ben Root



I tried your suggestion -- installing numpy from scratch (deleting the  
old numpy first) and then building matplotlib fresh. Here are my build  
logs:

<http://www.astro.washington.edu/users/rowen/python/numpy_build_log.txt>
<http://www.astro.washington.edu/users/rowen/python/matplotlib_build_log.txt 
>


Much like last time (with a fresh matplotlib) the test program shows  
no leak at first, then it starts growing to alarming levels (though it  
took longer to start leaking this time than it did last time):


matplotlib.__file__= /astro/users/rowen/build/matplotlib-trunk/build/ 
lib.linux-x86_64-2.6/matplotlib/__init__.py

time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.036860   nan
   5.136904   nan
  10.136904   0.0
  15.136904   0.0
  20.236904   0.0
  25.236904   0.0
  30.236904   0.0
  35.236904   0.0
  40.236904   0.0
  45.236904   0.0
  50.336904   0.0
  55.336904   0.0
  60.336904   0.0
  65.436904   0.0
  70.436904   0.0
  75.436904   0.0
  80.436904   0.0
  85.436904   0.0
  90.536904   0.0
  95.536904   0.0
 100.536976   0.8
 105.536976   0.7
 110.636976   0.7
 115.636976   0.7
 120.636976   0.6
 125.636976   0.6
 130.736976   0.6
 135.736976   0.6
 140.736976   0.5
 145.736976   0.5
 150.836976   0.5
 155.836976   0.5
 160.836976   0.5
 165.836976   0.4
 170.936976   0.4
 175.936976   0.4
 180.936976   0.4
 185.936976  

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

[Russell Owen]

On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:


On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen  wrote:
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
  ...
 602.837684   1.4
 607.837700   1.4

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

-- Russell


Russell,

I am curious, I recently ran into problems with mixing builds of  
numpy and matplotlib at various levels of revisions.  I eventually  
had to do a complete clean rebuild.  Note, what I mean by a complete  
clean rebuild is that I removed the numpy and matplotlib source  
directories and re-checkout the codes from source and then rebuild.   
I would be curious if the problem persists after that.


An interesting question. I can say that this was a clean build of  
matplotlib since I ran it "in place" (in build/lib.linux-x86_64-2.6/)  
after building it rather than installing it in site-packages to avoid  
messing up other users (on the linux system this was a shared python).  
I modified the script to print matplotlib.__file__ to make sure I was  
running the right version. I doubt it was a clean build of numpy. But  
considering no numerics are occurring in this example (it is literally  
just creating an Axes on a Canvas and calling canvas.draw()  
repeatedly) do you think numpy could possibly come into this?


Might you run the script on your system with the clean build?

-- Russell

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

I just build and uploaded a version for python 2.6. I have tested it  
on Intel 10.4 and plan to test it on 10.5 and 10.6 before trying to  
build a version for 32-bit Python 2.7. I will keep you posted.


Regards,

-- Russell

On Jan 2, 2011, at 9:52 AM, 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).


There are a number of bugs and patches on the tracker that it would  
have been nice to tackle before this release, but there have been  
enough improvements in the branch that delaying at this point would  
be a case of the perfect being the enemy of the good so I think we  
should move forward now.  Nonetheless, if there are important bugs  
or patches that anyone can tackle before we cut the final release,  
that would be great.


In sf, we used to be able to tag a file as the preferred file for a  
given OS, but in the new file manager interface I no longer see a  
way to do this, so that for example the rc files don't show up as  
the default download options.  Does anyone know how to do this, or  
perhaps someone can suggest a drop.io replacement that supports  
multiple user uploaders (eg the different binary builders) and  
public, no-registration downloads.  I googled a bit and didn't find  
anything that fit the bill.


JDH


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

The news:
- The Mac binary installer for python.org Python 2.6 works on my Mac  
OS X 10.4 and 10.5 machines (both Intel). However, it segfaults on my  
10.6 machine if there is no existing ~/.matplotlib and ~/.fontconfig.  
If others could test this it would be most helpful. I have not yet  
tried it on 10.3.9.


To reiterate: a proper test is:
- delete ~/.matplotlib if it exists
- delete ~/.fontconfig if it exists
- run python and try to import pylab or matplotlib

-- Russell

On Jan 2, 2011, at 9:52 AM, 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).


There are a number of bugs and patches on the tracker that it would  
have been nice to tackle before this release, but there have been  
enough improvements in the branch that delaying at this point would  
be a case of the perfect being the enemy of the good so I think we  
should move forward now.  Nonetheless, if there are important bugs  
or patches that anyone can tackle before we cut the final release,  
that would be great.


In sf, we used to be able to tag a file as the preferred file for a  
given OS, but in the new file manager interface I no longer see a  
way to do this, so that for example the rc files don't show up as  
the default download options.  Does anyone know how to do this, or  
perhaps someone can suggest a drop.io replacement that supports  
multiple user uploaders (eg the different binary builders) and  
public, no-registration downloads.  I googled a bit and didn't find  
anything that fit the bill.


JDH


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib 1.0.1rc has an outdated pytz

[Russell Owen]

matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o.  
(dateutil is current at 1.5).

Should I report this as a bug or is this email sufficient?

-- 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib on PyPI

[Russell Owen]

I have not built modern versions of matplotlib for python.org's Python  
2.5 because its  Tcl/Tk support is badly broken such that any attempt  
to use a "reasonable" version of Tcl/Tk (e.g. ActiveState 8.4.19) will  
cause segfaults. Perhaps I am being unreasonable but:
- I use Tcl/Tk extensively so I care about it a lot
- Segfaults are frustrating for everybody and reflect badly on  
matplotlib (however unfairly)

The Tcl/Tk 8.4 included by Apple in all versions of its OS to date has  
is old and buggy. (Even the last version of 8.4 -- 8.4.19 -- has bugs,  
but it's a lot better than Apple's version). Hence it is important for  
users to be able to upgrade without getting segfaults.

So my recommendation is not to Python 2.5 on a Mac.


Regarding binary eggs for matplotlib, I suspect there are issues that  
will make easy_install not work well:
- The builder script setupegg.py does not seem to include dependency  
information. I found setupegg.py a bit confusing so I may have missed  
something. But if the dependencies are missing, surely this is a bug?
- Is there some way to name the eggs to disambiguate between 32-bit  
Python 2.7 (which works on all versions of Mac OS X) and 64-bit Python  
2.7 (which only works on 10.6) that is compatible with easy_install?  
In the past if the eggs had strange names easy_install misbehaved.

Also setup.cfg is a bit of a pain when making distributions because:
- The default back end is Agg instead of TkAgg. Surely it should be  
TkAgg if Tkinter is present in the Python?
- For binary installers your desire is to include pytz and dateutil in  
the distribution. But for eggs your desire is to exclude them and list  
them as dependencies instead. I think these are reasonable rules, but  
they're not the default. Instead one has to edit setup.cfg one way for  
binary distributions and another way for eggs. That makes building  
releases more error-prone.

I do realize that in the long term you'd be better off with only one  
kind of binary: eggs or binary installers (presumably eggs). But  
unless easy_install has improved a lot I don't think we're there yet.

Regards,

-- Russell

On Jan 20, 2011, at 9:07 AM, John Hunter wrote:

> On Thu, Jan 20, 2011 at 10:23 AM, Jeffrey Wong   
> wrote:
>> On Jan 20, 2011, at 6:14 AM, John Hunter wrote:
>>
>>> On Thu, Jan 20, 2011 at 2:50 AM, Jeffrey Wong   
>>> wrote:
 Hi,

 I tried to install matplotlib on python 2.7 and use the graph  
 drawing functionality with NetworkX (nodes and edges).

 easy_install and pip both think that the latest version is  
 0.91.1, which is wrong because it will import numpy.core.ma  
 instead of numpy.ma.


 I'm not sure how to fix this but PyPI lists you as the maintainer  
 so I thought you might know.

 Thanks for putting it in PyPI anyhow!
>>>
>>> CC-ing the devel list.
>>>
>>> It's not clear to me why this is -- I have 1.0.1 as the active  
>>> version
>>> on pypi, which is reflected on  http://pypi.python.org/pypi/matplotlib
>>> and the download URL is listed as
>>>
>>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>>>
>>> 0.91.1 is flagged as hidden.  I am not a pypi expert, but don't see
>>> anything wrong here,
>>
>>
>> I can't use my python 2.7 to reproduce the problem since I  
>> installed matplotlib manually using the MacOS X Python 2.7 dmg/ 
>> installer.
>> It now sees matplotlib 1.0.1-r0 as current.
>>
>> However with the system python 2.5, it makes the following search:
>>
>> emcs-imac:Facethingy jeffwong$ /usr/bin/easy_install -n matplotlib
>> Searching for matplotlib
>> Reading http://pypi.python.org/simple/matplotlib/
>> Reading http://matplotlib.sourceforge.net
>> Reading 
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0
>> Reading 
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3/
>> Reading 
>> http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
>> Reading 
>> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
>> Reading http://sourceforge.net/project/showfiles.php?group_id=80706
>> Reading 
>> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
>> Reading 
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
>> Reading 
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>> Best match: matplotlib 0.91.1
>> Downloading 
>> http://pypi.python.org/packages/source/m/matplotlib/matplotlib-0.91.1.tar.gz#md5
>>  
>> =56a9344b077b5accbc4823be19f69dd6
>> ^Cinterrupted
>> emcs-imac:Facethingy jeffwong$
>>
>>
>> Perhaps someone sees something obviously wrong with this...
>
> I see -- we have seen problems with this before.  It is very difficult
> to get eggs names properly for OSX that are recognized.  We have
>
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/matplotlib-1.

Re: [matplotlib-devel] mpl release candidate branch

[Russell Owen]

I just uploaded a Mac binary for 32-bit Python 2.7. I propose to leave it at 
that unless the 2.6 version is required for the release candidate.

-- Russell

On Sep 27, 2011, at 9:32 AM, John Hunter wrote:

> On Tue, Sep 27, 2011 at 11:30 AM, Sandro Tosi  wrote:
>> On Tue, Sep 27, 2011 at 18:23, John Hunter  wrote:
>>> On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root  wrote:
>>> 
 Working through the checklist, I am wary of cutting an RC at this 
 particular
 moment.
>> 
>> It was announced here:
>> 
>> http://sourceforge.net/mailarchive/message.php?msg_id=28136691
>> 
>> I'm testing the debian package and I'll follow up with my thoughts on
>> it when done.
> 
> Thanks, missed that.  Christoph and Russell, will you have a chance to
> build some binaries we can upload for testing?   Once this is done, we
> should announce to the user list.


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Problem with proposed 1.0.1 release

[Russell Owen]

Oops. Sorry about that.

1.1.0 built fine under Python 2.7 and passes all tests (except one known skip).

I'll build 2.6 next and then upload both.

-- Russell

On Oct 7, 2011, at 12:11 PM, Benjamin Root wrote:

> This build you are doing is v1.0.1, which  is the old version.  Did you grab 
> the wrong source, or did we upload the wrong stuff?


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

[Russell Owen]

Mac binaries for Python 2.6 and 32-bit Python 2.7 are now uploaded.

-- Russell

On Oct 6, 2011, at 8:18 AM, John Hunter wrote:

> On Thu, Oct 6, 2011 at 9:57 AM, John Hunter  wrote:
> ...
> Actually, if you can just upload the binaries directly to
> 
> https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/
> 
> that will save a step...
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:

> On Sat, Mar 24, 2012 at 18:13, Derek Homeier
>  wrote:
>> I used the 1.1.0 version to build with the fink Python installation on MaxOS 
>> X
>> and everything seems to work there, passing the tests at least (does 
>> pylab.test('full')
>> execute all tests? It seems a rather small number…).
> 
> to run tests I use:
> 
> python -c "import matplotlib as m ; m.test(verbosity=1)"

Thank you for the test instructions. That's a much more complete test than I 
had been using. I get the following one failure on Mac OS X 10.6 using my new 
binary installer (results are appended). I'm also concerned about the complaint:
"""
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/__init__.py:921:
 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.
"""
which suggests a test that is mis-written.

-- Russell

localhost$ python
imporPython 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 14:13:39) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
matplotlib.>>> matplotlib.test(verbosity=1)
..K.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK..KK.KK.KK.KK.KK.KK.KKK...KK...KK.KK....KK.KK.KK.KK.KK..KK.KK.KKKK..K..K..KKKK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1218:
 UserWarning: findfont: Font family ['sans-serif'] not found. Falling back to 
Bitstream Vera Sans
  (prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
 UserWarning: findfont: Could not match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=14.0. 
Returning 
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
  UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
 UserWarning: findfont: Could not match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=bold:stretch=500:size=14.0. Returning 
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
  UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1218:
 UserWarning: findfont: Font family ['sans serif'] not found. Falling back to 
Bitstream Vera Sans
  (prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
 UserWarning: findfont: Could not match :family=Bitstream Vera 
Sans:style=italic:variant=normal:weight=750:stretch=500:size=14.0. Returning 
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
  UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
 UserWarning: findfont: Could not match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=200:stretch=500:size=14.0. Returning 
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
  UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
 UserWarning: findfont: Could not match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=500:stretch=100:size=14.0. Returning 
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
  UserWarning)
FKK.KK.KK.KK.KK.KK.KK.KK.K...K..KKK...KK.KK
==
FAIL: matplotlib.tests.test_text.test_font_styles.test
--
Traceback (most recent call last):
  File 
"/Library/Frameworks

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

[Russell Owen]

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)

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
..K..KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK..KK.KK.KK.KK.KK.KK.KKK...KK...KK.KK....KK.KK.KK.KK.KK.KK..KK.KK.KK.F..KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK...KK.KK.KK.KK.KK.KK.KK.KK..KK.KK
==
FAIL: matplotlib.tests.test_mathtext.mathfont_stix_14_test.test
--
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py",
 line 197, in runTest
self.test(*self.arg)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
 line 36, in failer
result = f(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
 line 140, in do_test
'(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: 
/Users/rowen/result_images/test_mathtext/mathfont_stix_14.png vs. 
/Users/rowen/result_images/test_mathtext/expected-mathfont_stix_14.png (RMS 
3377.889)

--
Ran 1068 tests in 161.293s

-- Russell

On Jun 9, 2012, at 2:14 PM, John Hunter wrote:

> I just uploaded the v1.1.1rc2 tarballs to the sourceforge site
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
> 
> As soon as we get binaries, I'll send out another call for testing on
> the users list.  Russell and Christoph, easiest if you just upload the
> binaries directly.  You should both have permissions on the sf site.
> 
> A copy of the site docs are available at
> http://matplotlib.sourceforge.net/rc/v1.1.1rc2/


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

When I say "somehow missing" I'm not referring to the K (known fail). I'm 
referring to exceptions and tracebacks caused by trying to import test_X for 
various value of X: the modules were actually missing. I've never seen that 
before, so I was quite shocked. Normally I build on the oldest version of Mac 
OS X I can for the desired binary, but in this case I wanted to see what would 
happen if I built on 10.7 for a binary that works on 10.6 and 10.7. It resulted 
in this odd situation: the binary installed everything correctly on 10.7 but 
somehow failed to install some sub-packages on 10.6. Unfortunately I don't have 
time to look into it right now; I just took the simple way out of building 
again on 10.6. Unfortunately that meant a binary with known issues was up for a 
few hours. I do have the defective binary installer if anyone wants a look at 
it.

-- Russell

On Jul 5, 2012, at 12:47 PM, John Hunter wrote:

> 
> 
> On Thu, Jul 5, 2012 at 2:43 PM, Russell E. Owen  wrote:
> 
> 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.
> 
> 
> Almost all of the test failures you ported were 'K' ie KNOWNFAIL.  Usually 
> when you get a bunch of knownfails, it is because you don't have a prereq 
> installed, eg inkscape for converting SVG.
> 
> Are you sure you have the requirements on all of the platforms
> 
> http://matplotlib.sourceforge.net/devel/coding_guide.html#requirements
> 
> Thanks,
> JDH  

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

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.

That leaves one unexpected failure with matplotlib 1.1.1 with the 64-bit 
10.6-and-later binary and no failures with the 32-bit 10.3.9-and-later binary.

Regards,

-- Russell

On Jul 5, 2012, at 12:47 PM, John Hunter wrote:

> On Thu, Jul 5, 2012 at 2:43 PM, Russell E. Owen  wrote:
> 
> 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.
> 
> 
> Almost all of the test failures you ported were 'K' ie KNOWNFAIL.  Usually 
> when you get a bunch of knownfails, it is because you don't have a prereq 
> installed, eg inkscape for converting SVG.
> 
> Are you sure you have the requirements on all of the platforms
> 
> http://matplotlib.sourceforge.net/devel/coding_guide.html#requirements
> 
> Thanks,
> JDH  

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc1 is cut

[Russell Owen]

On Sep 18, 2012, at 4:05 PM, Paul Hobson wrote:

> On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen  wrote:
>> In article <50509fb1.7070...@stsci.edu>,
>> 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.
> 
> Russel,
> 
> Which version were you on? with MPL v1.1 i get:
> In [28]: import matplotlib
> 
> In [29]: matplotlib.dates
> ---
> AttributeErrorTraceback (most recent call last)
>  in ()
> > 1 matplotlib.dates
> 
> AttributeError: 'module' object has no attribute 'dates'
> 
> In [30]: matplotlib.__version__
> Out[30]: '1.1.0'
> 
> In [31]: import matplotlib.dates
> 
> In [32]: matplotlib.dates
> Out[32]:  'C:\Python27\lib\site-packages\matplotlib\dates.pyc'>

I was using 1.1.1 most recently. I'm not sure when I started using 
matplotlib.dates without explicitly importing it.

In any case, it sounds as if it's not meant to work, so there's no need to 
change anything in matplotlib.

Regards,

-- 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

On May 29, 2013, at 4:01 PM, Chris Barker - NOAA Federal 
 wrote:

> On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen  wrote:
> 
>> 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.
> 
> If the binary installers are available (and easy to find), not such a
> big deal -- this is teh case with Christoph's repository for Windows,
> for instance.
> 
> Russell, have you been following the thread I started on the pythonmac
> list? We really need a way to deal better with binaries on the Mac,
> including dependency handling.
> 
> Note that supposedly the "wheel" format is coming (soon?), and after
> that support for binary wheels by pip.
> 
> Of course, none of that helps right now...

I have been following that thread with great interest. If such a repository 
becomes available I do intend to contribute to it.

For the record:
- I prefer static libraries
- The wheel format sounds very promising. But until we have it and until pip 
supports it, my suspicion is that it's not worth trying to automate dependency 
handling, and we should live with mpkg binary installers.


In the short term I'd be happier if matplotlib continued to support including 
dateutils, pytz and six. It is not ideal to include dependencies, but 
convenient and pragmatic. Failing that, i think we should ask users to install 
pip and use pip to install dateutils, pytz and six. I fear it would be too much 
work to provide binary installers for pytz, dateutils and six because we would 
need to make different packages for different versions of python (which feels 
silly for pure python packages!), keep them up to date, find somewhere to serve 
them...

In the long term, I hope wheel format will allow us to use pip to install 
matplotlib, in which case it will handle dependencies and we need not include 
them.

-- 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib 1.3.0rc3 tomorrow

[Russell Owen]

I found setup.cfg in the 1.3.0rc3 tarball that I downloaded from the usual 
location:

Here is the complete contents. None of these entries except [egg_info] appear 
in setup.cfg.template. However,  setup.cfg.template has *NO* entries after 
[egg_info] which suggests that it could use more documentation.

--- start setup.cfg 
[egg_info]
tag_build = 
tag_date = 0
tag_svn_revision = 0

--- end setup.cfg 


-- Russell


On Jun 19, 2013, at 2:13 PM, Damon McDougall  wrote:

> 
> 
> 
> On Wed, Jun 19, 2013 at 2:29 PM, Russell E. Owen  wrote:
> In article <51c0b2f6.5070...@stsci.edu>,
>  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)
> 
> I don't see a setup.cfg file.  I'm looking here: 
> https://github.com/matplotlib/matplotlib/tree/v1.3.x
> 
> All I see is the setup.cfg.template file.
>  
> 
> -- Russell
> 
> 
> --
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> 
> -- 
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229

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

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

I am glad that the numpy and scipy projects are still creating binary 
installers for python.org python, but it is a serious problem for users of the 
matplotlib binary installers that they are so difficult to find.

If a user googles for "numpy download" then the user finds this page

and the link Getting Numpy points to this page

which does not the binary installers at all.

I agree that most users should probably use Anaconda or its ilk, but I think it 
would be good to mention the Mac and Windows python.org binary installers quite 
prominently after that.

-- Russell

On Aug 7, 2013, at 1:00 PM, Thomas Kluyver  wrote:

> On 7 August 2013 12:54, Russell E. Owen  wrote:
> 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.
> 
> Is this down to the redesign of the SciPy site. If so, blame me ;-). I felt, 
> and others seemed to agree, that setting up individual packages separately 
> wasn't a route that we wanted to promote to newcomers, so the new site 
> emphasises all-in-one installers that get you the whole Scipy Stack (numpy, 
> scipy, matplotlib, etc.) in one go.
> 
> Thomas

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

On Aug 23, 2013, at 8:14 AM, Matt Terry  wrote:

> I'm banging away at installing MPL on top of python.org's python.  I'm at the 
> libfreetype/freetype issue.  There seems to be three approaches to getting 
> MPL's dependencies.
> 
> 1) install libpng[1] and freetype[2] from source
> 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's 
> directions[4]) so MPL finds XQuartz's libpng/freetype
> 3) install XQuartz[3] and install pkg-config[5] so MPL can find the cleverly 
> installed libraries
> 4) create the MPL binary installer and use that
> 
> Option 1 seems simple-est, but installing freetype requires more than 
> ./configure && make && sudo make install.
> Option 2 worries me with the manual symlinking and such.  Who knows what 
> we'll clobber.
> Option 3: haven't fully explored.
> Option 4: This would require some input from whoever (Gohlke?, Owen?) makes 
> the binary installers.
> 
> [1] http://www.libpng.org/pub/png/libpng.html
> [2] http://www.freetype.org/index.html
> [3] http://xquartz.macosforge.org/landing/
> [4] http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.html
> [5] http://www.freedesktop.org/wiki/Software/pkg-config/

I'm a bit puzzled what you are trying to do. I've found that matplotlib "just 
builds" if I only want to use it on the Mac I'm building it on. Depending on 
what you've added to your Mac you may find you have to restrict the search dirs 
in setupext.py, but that's all I have ever had to do for years.

For me the problems arise when trying to build a binary installer that runs on 
multiple versions of MacOS.

The following comments all deal with that case (making a binary installer):

I would eliminate (2) as an option; I thought it would help but it doesn't 
(perhaps I need to update my matplotlib build instructions). The issue is that 
when I build a binary installer on 10.8, it cannot be used on 10.6 because it 
is looking for some libraries in /opt/X11 (which is where XQuartz is installed 
on 10.8) instead of /usr/X11 (which is where X11 is installed on 10.6). It's 
only an issue for binary installers; I haven't had any problem just building 
matplotlib for python.org python.

I have pretty much given up building binary installers on anything but the 
oldest version of MacOS X that they can be used on (or as close as I can get). 
I've just run into too many problems like this.

I like (1) for binary installers. It eliminates the need for a user to have 
installed X11 at all. The hassle is making sure matplotlib statically links 
these libraries. I've always done this by taking the crude approach of deleting 
the shared object libraries, leaving only the static libraries; it always 
worked in the past, but recently I ran into a problem where something I was 
building simply refused to use a static library (I don't remember the details).

Regarding option [4]. You can get a binary installer for matplotlib 1.3 from 
here:

but it may clobber your python-dateutil and pytz (especially likely if they 
were installed by the matplotlib 1.2.1 binary installer). That's the main 
reason it's not an official binary installer.

-- Russell

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Russell Owen]

On Aug 22, 2013, at 8:24 PM, Matt Terry  wrote:

> > with/without third party X
> I'm not quite sure what you mean by with/without third party X. If you
> are referring to Tck/Tk:
> 
> I had an issue where MPL found the headers to freetype in /opt/local, but 
> library in /usr/X11.  Hilarity ensues.  I *think* /usr/X11 showed up when I 
> installed XQuartz, but I don't have a clean image to compare against.
> 
> The with-X / without-X builds would be there to check that the default search 
> paths are compatible with common environments.

Have you tried eliminating /opt from the search path in setupext.py? If that 
does the trick, I think we may be stuck. The default search paths are trying to 
work for default python, python.org python, macports and homebrew, plus 
user-built libraries in /usr/local. I'm not convinced one file can do it all. 
Apple moving X from /usr/X11 to /opt/X11 did not help.

Regards,

-- Russell--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel