[matplotlib-devel] Current svn version bug in get_xydata function in line.py

2010-03-02 Thread David Trem
Hi,

 There is a typo in the matplotlib line.py file in function get_xydata
line 662
it should be self._invalidx instead of self.invalidx
(missing leading underscore)

Regards,

David

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


[matplotlib-devel] Cannot import ft2font on Mac OSX

2010-03-02 Thread Michael Hearne
Using the svn build from 2-25:
matplotlib.__version__ = 1.0.svn
Python from Enthought:
Python 2.6.4 -- EPD 6.0.0 (64-bit)

I get the following errors when I try to import ft2font:
Traceback (most recent call last):
File ./testme.py, line 3, in module
from matplotlib import ft2font
ImportError:
dlopen(/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/sit
e-packages/matplotlib/ft2font.so, 2): Symbol not found: _FT_Attach_File
Referenced from:
/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packa
ges/matplotlib/ft2font.so
Expected in: flat namespace
in
/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packa
ges/matplotlib/ft2font.so

My code looks like this:
#!/usr/bin/env python

from matplotlib import ft2font

print 'Hello world'--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] Cannot import ft2font on Mac OSX

2010-03-02 Thread Michael Hearne
I followed your instructions and re-built, and I get the same error.

I also ran nm ft2font.so and I get results that look like this:
 U _FT_Attach_File
 U _FT_Done_Face
 U _FT_Done_FreeType
 U _FT_Done_Glyph
 U _FT_Get_Char_Index
 U _FT_Get_First_Char
 U _FT_Get_Glyph
 U _FT_Get_Glyph_Name
 U _FT_Get_Kerning
 U _FT_Get_Name_Index
 U _FT_Get_Next_Char
 U _FT_Get_PS_Font_Info
 U _FT_Get_Postscript_Name
 U _FT_Get_Sfnt_Name
 U _FT_Get_Sfnt_Name_Count
 U _FT_Get_Sfnt_Table
 U _FT_Glyph_Get_CBox
...

According to the nm man page, the U means that  _FT_Attach_File is 
undefined.

Is there some sort of switch in the makefile that will define these symbols?

--Mike 
On Mar 2, 2010, at 9:11 AM, Tony S Yu wrote:

 
 On Mar 2, 2010, at 9:39 AM, Michael Hearne wrote:
 
 Using the svn build from 2-25:
 matplotlib.__version__ = 1.0.svn
 Python from Enthought:
 Python 2.6.4 -- EPD 6.0.0 (64-bit)
 
 I get the following errors when I try to import ft2font:
 Traceback (most recent call last):
 File ./testme.py, line 3, in module
 from matplotlib import ft2font
 ImportError:
 dlopen(/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/sit
 e-packages/matplotlib/ft2font.so, 2): Symbol not found: _FT_Attach_File
 Referenced from:
 /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packa
 ges/matplotlib/ft2font.so
 Expected in: flat namespace
 in
 /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packa
 ges/matplotlib/ft2font.so
 
 Did you do a clean install, or build over an old build?
 
 I've gotten this error when building over an old build. I usually clean out 
 the mpl directory (where setup.py is found) with the following terminal 
 commands:
 
 $ make clean
 $ find . -name '*.so' | xargs rm
 
 -Tony
 
 
 My code looks like this:
 #!/usr/bin/env python
 
 from matplotlib import ft2font
 
 print 'Hello world'
 
 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


[matplotlib-devel] git migration

2010-03-02 Thread Eric Firing
All,

I think the git migration deserves its own thread on the devel list, so 
here is a start.

The full svn repo includes much more than just matplotlib: also course, 
htdocs, py4science, sample_data, sampledoc_tut, scipy06, toolkits, and 
users_guide.  Before moving matplotlib, I think we should have a clear 
plan as to how these other parts are going to be handled.  Will some or 
all remain as the active parts of the svn repo, with matplotlib somehow 
marked as invalid?  Will some or all get their own github repos? My 
primary interest here is toolkits/basemap, but I am sure other good 
stuff is in there.

Before the transition, it would be good to have a pointers to the 
simplest possible docs illustrating typical workflows after the 
transition; maybe one for present developers with svn access, and 
another for occasional contributors.

Does it makes sense to retain the entire history in the new github repo, 
or would it be just as well to start from a later point so as to reduce 
the size?  The entire history could still be available in a separate 
read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. 
  (Andrew's repo, at just under 200MB, is not prohibitively large by any 
means, but it is a bit hefty.)

Eric

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Andrew Straw
Eric Firing wrote:
 All,

 I think the git migration deserves its own thread on the devel list, so 
 here is a start.
   
To the uninitiated - a decision is being made that MPL is moving to git
and github. We hope that this move will foster greater contributions
from the community and a blurring of the line between MPL committers and
users.

The decision process happened off-list to keep the flames and
bike-shedding minimal. Several of the core developers were consulted and
we all agreed that a move to a DVCS was desirable and inevitable. We did
not unanimously agree that git was best, but it was preferred by most
developers over mercurial/bitbucket, the other serious contender, and
neither camp voiced strong objections to the other system.



 The full svn repo includes much more than just matplotlib: also course, 
 htdocs, py4science, sample_data, sampledoc_tut, scipy06, toolkits, and 
 users_guide.  Before moving matplotlib, I think we should have a clear 
 plan as to how these other parts are going to be handled.  Will some or 
 all remain as the active parts of the svn repo, with matplotlib somehow 
 marked as invalid?  Will some or all get their own github repos? My 
 primary interest here is toolkits/basemap, but I am sure other good 
 stuff is in there.
   
This is a good point. My preferred option is that we jettison all the
stuff that is not going to be shipped with MPL 1.0 from the git repo.
(More correctly - we build a git repo without that stuff ever going in.)
We can keep the old svn tree around and migrate the other projects to
git as desired. I think this is what's present in
http://github.com/astraw/matplotlib . Or am I missing something?

Another issue is whether to use github's Issue's system over
SourceForge's tracker. Personally, I'm in favor of moving the issue
tracking to github, but I think we should take stock of how we use the
tracker as see if github's features will support that.

 Before the transition, it would be good to have a pointers to the 
 simplest possible docs illustrating typical workflows after the 
 transition; maybe one for present developers with svn access, and 
 another for occasional contributors.
   
I agree. I think the best learning material is from github. See
http://help.github.com/ and http://learn.github.com/ , for example. To
get to the a ha feeling, I highly recommend Git from the bottom up
by John Wiegley, available from
http://ftp.newartisans.com/pub/git.from.bottom.up.pdf . This latter is
what it took for me to come to a real understanding of git. Git was
designed from the data structures and plumbing up, and that the rest
(porcelain in git parlance) came later and was less the focus of
initial development. Hence, the history is that git had a rougher UI
from the start and other DVCSs having nicer UIs but less stable and fast
repository formats. (Understanding the git model of the universe was key
to me becoming really fluent in git, but according to my office mate,
it's absolutely not necessary to use git for daily tasks. )


 Does it makes sense to retain the entire history in the new github repo, 
 or would it be just as well to start from a later point so as to reduce 
 the size?  The entire history could still be available in a separate 
 read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. 
   (Andrew's repo, at just under 200MB, is not prohibitively large by any 
 means, but it is a bit hefty.)
   
I can see advantages either way, but I'm in favor keeping it. Tons of
MPL is undercommented, and seeing the history is extremely useful when
spelunking.

-Andrew

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Gökhan Sever
On Tue, Mar 2, 2010 at 9:17 PM, Andrew Straw straw...@astraw.com wrote:

 Eric Firing wrote:
  All,
 
  I think the git migration deserves its own thread on the devel list, so
  here is a start.
 
 To the uninitiated - a decision is being made that MPL is moving to git
 and github. We hope that this move will foster greater contributions
 from the community and a blurring of the line between MPL committers and
 users.

 The decision process happened off-list to keep the flames and
 bike-shedding minimal. Several of the core developers were consulted and
 we all agreed that a move to a DVCS was desirable and inevitable. We did
 not unanimously agree that git was best, but it was preferred by most
 developers over mercurial/bitbucket, the other serious contender, and
 neither camp voiced strong objections to the other system.


Apart from being inflammatory, has anyone considered code.google.com (GC) as
a solution? To me amongst all code hosting sites (launchpad, sourceforge,
bitbucket, github) GC provides the simplest and the most effective
interface. There is also practically very less learning curve on GC
comparing to other alternatives. This is a great advantage for the newcomers
to the project. For instance SF has all the useful code management
functionalities but their interface is really not inviting --at least to my
eyes. It takes a while also before the site content are indexed by crawlers.

On the negative side, GC doesn't offer git. However the source could be
externally linked like in the sympy project.

What do you think? Does simplicity really counts on the decision or the
functionality beats simplicity?


-- 
Gökhan
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Matthew Brett
Hi,

 Apart from being inflammatory, has anyone considered code.google.com (GC) as
 a solution?

;)  - speaking as someone with no right to offer an opinion - please,
no.   Google blocks Cuba from google code completely, for no obvious
reason, and a) that seems to me quite wrong and outside the spirit of
free software and b) I work there fairly often and it's hard for me to
persuade the excellent scientists there to use Python if they are
being specifically blocked for political reasons.

See you,

Matthew

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Gökhan Sever
On Tue, Mar 2, 2010 at 11:03 PM, Matthew Brett matthew.br...@gmail.comwrote:

 Hi,

  Apart from being inflammatory, has anyone considered code.google.com(GC) as
  a solution?

 ;)  - speaking as someone with no right to offer an opinion - please,
 no.   Google blocks Cuba from google code completely, for no obvious
 reason, and a) that seems to me quite wrong and outside the spirit of
 free software and b) I work there fairly often and it's hard for me to
 persuade the excellent scientists there to use Python if they are
 being specifically blocked for political reasons.

 See you,

 Matthew


I didn't really know that Google was embargoing countries on their code
hosting site. I was more inspired after watching this talk Google I/O 2008 -
Project Hosting on Google Code http://www.youtube.com/watch?v=62x17hG6Wvo

It is very interesting for a company that does great things for the OSS also
blocking code access on certain countries. Thanks for pointing this out.
Indeed an important point consider.

This is not the first time today my Google integration idea has been
rejected. During our school's tech forum I asked them the possibilities of
integrating Google Apps to the university network. The lower cost was a
reasonable answer, but it is beyond my logic to understand that possible
plans to integrate something that is not even up (live.edu) :)

-- 
Gökhan
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Eric Firing
Andrew Straw wrote:
[...]
 This is a good point. My preferred option is that we jettison all the
 stuff that is not going to be shipped with MPL 1.0 from the git repo.
 (More correctly - we build a git repo without that stuff ever going in.)
 We can keep the old svn tree around and migrate the other projects to
 git as desired. I think this is what's present in
 http://github.com/astraw/matplotlib . Or am I missing something?
 

No, that is what you have, and I agree that this strategy makes sense. 
I just wanted to make sure everyone understood, and make the plan explicit.

Eri

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Eric Firing
Eric Firing wrote:
 All,
 
 I think the git migration deserves its own thread on the devel list, so 
 here is a start.

Explanation: the last bit of discussion was actually off-list, but 
because it was tacked onto a matplotlib-users list thread, and appeared 
there in my mailer, I failed to notice that matplotlib-users was not in 
the address list.  So I jumped to the conclusion that it was already on 
a list, but was merely misplaced and should be shifted to 
matplotlib-devel.  I apologize for the error.  To minimize the potential 
unproductive thrashing, I request that everyone restrain their urges to 
comment on the choice of git and github, to suggest alternatives, to 
raise objections, etc.

Eric

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread william ratcliff
I think there's a legal reason for the embargo--sourceforge apparently also
has such a policy:

http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/

http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/So,
as a US company, they may not have a choice...

On Wed, Mar 3, 2010 at 12:39 AM, Gökhan Sever gokhanse...@gmail.com wrote:



 On Tue, Mar 2, 2010 at 11:03 PM, Matthew Brett matthew.br...@gmail.comwrote:

 Hi,

  Apart from being inflammatory, has anyone considered code.google.com(GC) as
  a solution?

 ;)  - speaking as someone with no right to offer an opinion - please,
 no.   Google blocks Cuba from google code completely, for no obvious
 reason, and a) that seems to me quite wrong and outside the spirit of
 free software and b) I work there fairly often and it's hard for me to
 persuade the excellent scientists there to use Python if they are
 being specifically blocked for political reasons.

 See you,

 Matthew


 I didn't really know that Google was embargoing countries on their code
 hosting site. I was more inspired after watching this talk Google I/O 2008
 - Project Hosting on Google Code
 http://www.youtube.com/watch?v=62x17hG6Wvo

 It is very interesting for a company that does great things for the OSS
 also blocking code access on certain countries. Thanks for pointing this
 out. Indeed an important point consider.

 This is not the first time today my Google integration idea has been
 rejected. During our school's tech forum I asked them the possibilities of
 integrating Google Apps to the university network. The lower cost was a
 reasonable answer, but it is beyond my logic to understand that possible
 plans to integrate something that is not even up (live.edu) :)

 --
 Gökhan


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] git migration

2010-03-02 Thread Matthew Brett
Hi,

On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff
william.ratcl...@gmail.com wrote:
 I think there's a legal reason for the embargo--sourceforge apparently also
 has such a policy:
 http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/
 So, as a US company, they may not have a choice...

In my experience Google is the worst in this respect by a considerable
margin, and has become more so in the last year.

See you,

Matthew

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel