matplotlib-devel Mailing List for matplotlib (Page 5)

On 9-Mar-10, at 2:24 AM, Tom Loredo wrote:
> I've been experimenting with SVN checkouts of numpy and scipy,
> and found they are not compatible with mpl-0.99.1. The
> problem is that the numpy version number for recent checkouts
> is 2.0.x (2.0.0.dev8289 for the version I'm currently using),
> but mpl's numpy version checking (on the 1st two digits) isn't
> quite smart enough to know that 2.0 > 1.1.
I ran into this too, it's fixed in SVN.
David

Hi folks-
I've been experimenting with SVN checkouts of numpy and scipy,
and found they are not compatible with mpl-0.99.1. The
problem is that the numpy version number for recent checkouts
is 2.0.x (2.0.0.dev8289 for the version I'm currently using),
but mpl's numpy version checking (on the 1st two digits) isn't
quite smart enough to know that 2.0 > 1.1. It's easy enough
to fix by hand; the obvious lines in setupext.py and __init__py
need to be changed to something like:
 if not ( (int(nn[0]) == 1 and int(nn[1]) >= 1) or (int(nn[0]) > 1) ):
I haven't kept up with the recent discussion about how to
number the next numpy (there was some back and forth about
how soon to move to 2.x), but sooner or later it will get
up to 2.x, so this should be fixed in the mpl repo.
Cheers,
Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Hi-
This is probably a low-probability event, however it may be
worth noting that the check for the Tk framework location in
setupext.py's detect_tkinter_darwin examines possible framework
paths in a different order than they are checked in Python's
setup.py for the purpose of building _tkinter. Python's
setup.py searches:
/Library/Frameworks
/System/Library/Frameworks/
$HOME/Library/Frameworks
MPL's setupext.py searches:
$HOME/Library/Frameworks
/Library/Frameworks
/System/Library/Frameworks/
If a user has installed more than one new (non-Apple) Tcl/Tk,
it is possible for MPL and _tkinter to link against different
frameworks. I think MPL does some version checking that
would prevent a build if there is a mismatch, but the source
of the difficulty may not be obvious to the installer.
The Snow Leopard Xcode man page for ld says the following about
ld's framework searching:
 The default framework search path is /Library/Frameworks then 
 /System/Library/Frameworks.
It says nothing about searching under $HOME. So from the
point of view of Xcode it looks like there is no "right"
order between the two options, but MPL's looks "right" to me,
i.e., if a user has installed something under $HOME, the
user probably intends it to override the system.
-Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

I have a system that creates PDF output using matplotlib/basemap, and I'm wondering if anyone can give me some information on how to work around a bug in the PDF backend.
I submitted the following bug to the mailing list:
http://old.nabble.com/error-with-basemap-and-pdf-td25899014.html#a25899014
and then to the bug tracker:
https://sourceforge.net/tracker/index.php?func=detail&aid=2879910&group_id=80706&atid=560720
last October, _after_ the most recent stable matplotlib release.
According to those discussions, the bug has been fixed in SVN. Accordingly, I have recently tried to build matplotlib from source, but cannot use the resulting binaries, due to the problem described in the following mailing list thread and bug report:
http://old.nabble.com/Cannot-import-ft2font-on-Mac-OSX-td27756808.html#a27758227
https://sourceforge.net/tracker/index.php?func=detail&aid=2959725&group_id=80706&atid=560720
I figure I could solve my problem one of three ways:
1) Waiting for the current SVN code to become a stable release. This would need to happen before my system goes live.
2) Patch my current code with the fix already in SVN. I would need someone to point me to the relevant files, and give me some pointers on applying the patch.
3) Getting some help with my SVN build issue.
Does anyone have any tips?
Thanks,
Mike

Günter Lichtenberg wrote:
> On Thursday 04 March 2010 14:20:41 you wrote:
>> 2010年3月4日 Günter Lichtenberg <Gue...@dl...>:
>>> Hi
>>>
>>> I think there is a bug in the conversion routines jul2num() and
>>> num2jul(). I tried to define a date axis for satellite data. The time is
>>> measured in a modified Julian Date (JD). So reading in the data and then
>>> doing
>> Hi Günter,
>>
>> Thanks for digging into this. Could you file a report on the bug tracker
>>
> 
> Done under
> 
> 2963391 Wrong conversion in julian2num/num2julian
> 
> gl
> 
Thanks. Fixed in 8181 (branch) and 8182 (trunk).
Eric

Hello,
Given the interest in participating in the GSoC this summer, I am
forwarding a very interesting email from Titus Brown. If you are
interested in doing a GSoC or mentoring, please read his email
carefully.
Basically, the PSF will be focuing on Py3K-related projects. Given
Pauli's work on Py3K support for NumPy, I think we might be in a good
position to move forward on porting the rest of our stack to Py3K. So
we should focus on projects to:
1. finish porting and testing NumPy with Py3K
2. port and test SciPy with Py3K
3. port and test matplotlib with Py3K
4. port and test ipython with Py3K
5. etc.
Given the PSF's stated emphasis this year, it probably doesn't make
sense to pursue any non-Py3K projects.
Jarrod
---------- Forwarded message ----------
From: C. Titus Brown <ct...@ms...>
Date: Tue, Mar 2, 2010 at 6:12 AM
Subject: [SoC2009-mentors] [ct...@ms...: GSoC 2010 - it's on!]
To: soc...@py...
----- Forwarded message from "C. Titus Brown" <ct...@ms...> -----
Date: 2010年2月24日 12:54:52 -0800
From: "C. Titus Brown" <ct...@ms...>
To: psf...@py...
Cc: gso...@py...
Subject: GSoC 2010 - it's on!
Hi all,
it's that time of year again, and Google has decided to run the Google
Summer of Code again!
 http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f
 http://socghop.appspot.com/
Arc Riley has stepped up to run it for the PSF again this year, and I'm
backstopping him. If you are interested in mentoring or kibbitzing on those
who are, please sign up for the soc2010-mentors mailing list here,
 http://mail.python.org/mailman/listinfo/soc2010-mentors
This year we're proposing to solicit and prioritize applications for
Python 3.x -- 3K tools, porting old projects, etc. Python 2.x projects
will be a distinct second. There will be no "core" category this year,
although obviously if someone on one of the core teams wants to push a
project it'll help!
If you have an idea for a project, please send it to the -mentors list and add
it to the wiki at
 http://wiki.python.org/moin/SummerOfCode/2010
We're also going to change a few things up to make it more useful to the PSF.
Specifically,
 - the foundation is going to *require* 1 blog post/wk from each student.
 - we're going to hire an administrative assistant to monitor the students.
 - the student application process will be a bit more rigorous and job-app
 like; the Django SF has been doing this for at least one round and they
 claim that it results in much better and more serious students.
 - we'll be focusing on student quality more than on project egalitarianism.
 If project X can recruit three fantastic students to one fantastic and one
 mediocre student for project Y, then project X gets three and project Y
 gets one.
The hope is that this will make the GSoC much more useful for Python than
it has been in the past.
Arc will be posting something to the www.python.org site and python-announce
soon, too.
Followups to soc2010-mentors.
cheers,
--titus
--
C. Titus Brown, ct...@ms...
----- End forwarded message -----

It should also be noted that attributes like "weight" and "stretch" are 
only hints for the purpose of finding a font. That is, if you request a 
bold version of a font, and it does not exist, the closest matching font 
will be used instead. matplotlib (more specifically freetype) does not 
do "font synthesis" to generate a pseudo-bold font or pseudo-compressed 
font if one can not be found. So for example, the "condensedFont" set of 
properties you defined will not return a condensed font unless such a 
font exists on your system.
Mike
James Evans wrote:
>
> All,
>
> I just submitted bug #2963827 detailing this, but thought that I would 
> echo the problem here...
>
> When plotting annotations and specifying the FontProperties to use, 
> the specified values are completely ignored. See the attached script 
> and image for an example. Am I doing something inherently wrong, or is 
> this really a bug?
>
> Thanks,
>
> --James Evans
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Download Intel® 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Do you have fonts whose family name is "sans serif"?
Maybe you meant "sans-serif"?
"sans-serif" searches for fonts whose family name is in
rcParams["font.sans-serif"], but "sans serif" only search for "sans
serif".
I don't think it has anything to do with annotation.
Check if findfont gives you a correct font.
Please report back with matplotlib version etc., if findfont finds a
correct font but annotation still shows with a wrong font.
Regards,
-JJ
import matplotlib.font_manager
fm = matplotlib.font_manager.fontManager
print matplotlib.font_manager.findfont(normalFont)
On Thu, Mar 4, 2010 at 7:07 PM, James Evans <jre...@ea...> wrote:
> All,
>
>
>
> I just submitted bug #2963827 detailing this, but thought that I would echo
> the problem here...
>
>
>
> When plotting annotations and specifying the FontProperties to use, the
> specified values are completely ignored. See the attached script and image
> for an example. Am I doing something inherently wrong, or is this really a
> bug?
>
>
>
> Thanks,
>
> --James Evans
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

#!/usr/bin/env python
import pylab
from matplotlib.font_manager import FontProperties
fig = pylab.figure()
ax = pylab.subplot( 1, 1, 1 )
normalFont = FontProperties( family = "Sans Serif",
 style = "normal",
 variant = "normal",
 weight = 500,
 stretch = 500,
 size = 14,
 )
ax.annotate( "Normal Font", (0.1, 0.1), xycoords='axes fraction',
 fontproperties = normalFont )
boldFont = FontProperties( family = "Sans Serif",
 style = "normal",
 variant = "normal",
 weight = 750,
 stretch = 500,
 size = 14,
 )
ax.annotate( "Bold Font", (0.1, 0.2), xycoords='axes fraction',
 fontproperties = boldFont )
boldItemFont = FontProperties( family = "Sans Serif",
 style = "italic",
 variant = "normal",
 weight = 750,
 stretch = 500,
 size = 14,
 )
ax.annotate( "Bold Italic Font", (0.1, 0.3), xycoords='axes fraction',
 fontproperties = boldItemFont )
lightFont = FontProperties( family = "Sans Serif",
 style = "normal",
 variant = "normal",
 weight = 200,
 stretch = 500,
 size = 14,
 )
ax.annotate( "Light Font", (0.1, 0.4), xycoords='axes fraction',
 fontproperties = lightFont )
condensedFont = FontProperties( family = "Sans Serif",
 style = "normal",
 variant = "normal",
 weight = 500,
 stretch = 100,
 size = 14,
 )
ax.annotate( "Condensed Font", (0.1, 0.5), xycoords='axes fraction',
 fontproperties = condensedFont )
pylab.show()

On Thursday 04 March 2010 14:20:41 you wrote:
> 2010年3月4日 Günter Lichtenberg <Gue...@dl...>:
> > Hi
> > 
> > I think there is a bug in the conversion routines jul2num() and
> > num2jul(). I tried to define a date axis for satellite data. The time is
> > measured in a modified Julian Date (JD). So reading in the data and then
> > doing
> 
> Hi Günter,
> 
> Thanks for digging into this. Could you file a report on the bug tracker
> 
Done under
2963391 Wrong conversion in julian2num/num2julian
gl
-- 
Dr. Günter Lichtenberg
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
Institut für Methodik der Fernerkundung (MF-AP)
82234 Weßling
Tel. +49-8153-28-1331
Fax +49-8153-28-1446
Gue...@dl...

2010年3月4日 Günter Lichtenberg <Gue...@dl...>:
> Hi
>
> I think there is a bug in the conversion routines jul2num() and num2jul(). I
> tried to define a date axis for satellite data. The time is measured in a
> modified Julian Date (JD). So reading in the data and then doing
Hi Günter,
Thanks for digging into this. Could you file a report on the bug tracker
http://sourceforge.net/tracker/?group_id=80706&atid=560720
Thanks,
JDH

Hi 
I think there is a bug in the conversion routines jul2num() and num2jul(). I 
tried to define a date axis for satellite data. The time is measured in a 
modified Julian Date (JD). So reading in the data and then doing
mp = julian2num(jd)
dates = num2date(mp)
resulted in an error "year out of range" (or so). I looked at the values and 
they were way to high. Inspection of the source date.py showed for the 
conversion routines
julian2num: j + 1721425.5
num2julian: j - 1721425.5
Since the JD measures days from 4713 BC - earlier than the matplotlib 
zeropoint - the conversion should be the other way round, i.e. for julian2num 
we should subtract. 
After correcting this, I could still not reconcile my measurement dates with 
the result of num2date(). In the source it is stated that counting starts at 
0001年01月01日 00:00:00 UTC (JD 1721423.5), which BTW does not match the number 
used in the routines. The only way to correct this was to use an offset of JD 
1721424.5 (January 2nd, 0001, 00:00:00). 
So the correct formulae should be
julian2num: j - 1721424.5
num2julian: j + 1721424.5
or am I missing something?
VERSION INFO: matplotlib V. 0.99.1.1/python 2.6.2
on opensuse 11.2/x86_64
Cheers
gl
-- 
Günter Lichtenberg

Should be fixed with r8178.
Regards,
-JJ
On Wed, Mar 3, 2010 at 5:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Wed, Mar 3, 2010 at 4:48 PM, John Hunter <jd...@gm...> wrote:
>> JJ is this related to your commit in r8035 : "support
>> unsampled image for ps backend"
>
> It seems to be.
> I'll take a look.
>
> Regards,
>
> -JJ
>

On Wed, Mar 3, 2010 at 4:48 PM, John Hunter <jd...@gm...> wrote:
> JJ is this related to your commit in r8035 : "support
> unsampled image for ps backend"
It seems to be.
I'll take a look.
Regards,
-JJ

examples/pylab_examples/image_nonuniform.py is broken in HEAD
An attempt to access "self._oldxslice" in _get_unsampled_image is
implicated: JJ is this related to your commit in r8035 : "support
unsampled image for ps backend"
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backends/backend_wx.py",
line 1156, in _onPaint
 self.draw(drawDC=drawDC)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backends/backend_wxagg.py",
line 59, in draw
 FigureCanvasAgg.draw(self)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/backends/backend_agg.py",
line 394, in draw
 self.figure.draw(self.renderer)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/figure.py",
line 802, in draw
 func(*args)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/axes.py",
line 1774, in draw
 a.draw(renderer)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/image.py",
line 306, in draw
 self._draw_unsampled_image(renderer, gc)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/image.py",
line 250, in _draw_unsampled_image
 self._get_unsampled_image(self._A, self.get_extent(), self.axes.viewLim)
 File "/home/jdhunter/dev/lib/python2.6/site-packages/matplotlib/image.py",
line 184, in _get_unsampled_image
 if xslice != self._oldxslice or yslice != self._oldyslice:
AttributeError: 'NonUniformImage' object has no attribute '_oldxslice'

On Wed, Mar 3, 2010 at 1:31 PM, Jonathan Taylor <jt...@cs...> wrote:
>> I am strongly in favor of keeping the entire commit history of
>> trunk/matplotlib. While the repo is large now, most of the size comes
>> from data and regression test images, and the early history is largely
>> code so will not add much incremental size. I suppose one of the
>> downsides of git is since you have to get the *entire* history on one
>> checkout, you end up with a bunch of stuff you are unlikely to ever
>> need, like data that was once in the repo but has now been removed (eg
>> the stuff we migrated to sampledata). Not sure if there is an easy
>> solution here.
>
> I think you should be able to use git clone --depth=x to get a shallow
> copy of the repository. The limitation is that you cannot push from
> or pull from your new repository. You can pull to it and create
> patches though, which is enough for most people I think.
Tried a few options from Andrew's repo:
jdhunter@uqbar:~> du -hs mpl.git*
191M mpl.git # no --depth
191M mpl.git0 # --depth=0
147M mpl.git1 # --depth=1
147M mpl.git10 # --depth=10
This compares with 87M for a clean svn checkout. So it doesn't look
like a huge deal to get the whole thing compared to svn, and it looks
like the --depth save very little currently. Didn't notice too much
in terms of checkout time either...
Thanks for the suggestion though!
JDH

> I am strongly in favor of keeping the entire commit history of
> trunk/matplotlib. While the repo is large now, most of the size comes
> from data and regression test images, and the early history is largely
> code so will not add much incremental size. I suppose one of the
> downsides of git is since you have to get the *entire* history on one
> checkout, you end up with a bunch of stuff you are unlikely to ever
> need, like data that was once in the repo but has now been removed (eg
> the stuff we migrated to sampledata). Not sure if there is an easy
> solution here.
I think you should be able to use git clone --depth=x to get a shallow
copy of the repository. The limitation is that you cannot push from
or pull from your new repository. You can pull to it and create
patches though, which is enough for most people I think.
Best,
Jon.

Cool. Looks good.
I did tweak the image a bit to make the colors stand out better. But only slightly. Because when I made the shapes too big, the image lost it's MPL "feel". Here is the source image I used to create the icon. Feel free to give it a go. There are a number of programs that can turn the image into an icon. I like ""Any to Icon". And to preview the icon, you can simply open the file in a web browser.
-Ben
________________________________________
From: John Hunter [jd...@gm...]
Sent: Wednesday, March 03, 2010 12:18 PM
To: Ben Axelrod
Cc: mat...@li...
Subject: Re: [matplotlib-devel] favicon submission
On Wed, Mar 3, 2010 at 11:16 AM, John Hunter <jd...@gm...> wrote:
> On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod <BAx...@co...> wrote:
>> I am a big fan of favicons. I think MPL should definitely have one for the
>> impending 1.0 release. So I made one for you.
>>
>> To use, simply place this file in the top level web directory. That is
>> usually all that is required. But some browsers prefer if you put:
>>
>> <link rel="shortcut icon" href="favicon.ico">
>>
>> in the header of the html pages.
>
> Cool -- we're live
>
> http://matplotlib.sourceforge.net/
>
> (may need to refresh)
If you want to work on this a bit more, I suggest
 * make the circle boundary of the polar plot fill the entire square
of the icon (no dead white space)
 * user fewer and larger shaded areas, with strong colors. At the
size the icon is rendered at in the browser, the features are very
indistinct
JDH

On Wed, Mar 3, 2010 at 11:16 AM, John Hunter <jd...@gm...> wrote:
> On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod <BAx...@co...> wrote:
>> I am a big fan of favicons. I think MPL should definitely have one for the
>> impending 1.0 release. So I made one for you.
>>
>> To use, simply place this file in the top level web directory. That is
>> usually all that is required. But some browsers prefer if you put:
>>
>> <link rel="shortcut icon" href="favicon.ico">
>>
>> in the header of the html pages.
>
> Cool -- we're live
>
> http://matplotlib.sourceforge.net/
>
> (may need to refresh)
If you want to work on this a bit more, I suggest
 * make the circle boundary of the polar plot fill the entire square
of the icon (no dead white space)
 * user fewer and larger shaded areas, with strong colors. At the
size the icon is rendered at in the browser, the features are very
indistinct
JDH

On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod <BAx...@co...> wrote:
> I am a big fan of favicons. I think MPL should definitely have one for the
> impending 1.0 release. So I made one for you.
>
> To use, simply place this file in the top level web directory. That is
> usually all that is required. But some browsers prefer if you put:
>
> <link rel="shortcut icon" href="favicon.ico">
>
> in the header of the html pages.
Cool -- we're live
http://matplotlib.sourceforge.net/
(may need to refresh)
Thanks!
JDH

John Hunter wrote:
> On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing <ef...@ha...> wrote:
> 
>> 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.
>> 
>
> It looks like Andrew has trunk/matplotlib. There is other stuff in
> trunk that definitely should not be migrated, and some stuff that
> needs consideration.
>
> * trunk/py4science, which is a project Fernando and I have been
> working on for several years but is not specific to mpl (it only uses
> mpl). We will eventually migrate this into it's own repo, but this
> is not an mpl project and should not be migrated.
>
> * trunk/course - looks like a very old and no longer used py4science
> dir. Should probably be simply deleted and not frozen
>
> *trunk/htdocs - the old mpl site docs. Should live somewhere for
> archival purposes in case there is a useful code snippet in there, but
> certainly does not need to be in git or the new repo. It could live
> frozen in the sf repo.
>
> * trunk/sampledata - this is important. The mpl trunk examples use
> this to pull example data. We will need to migrate this -- we could
> leave it in sf svn, but it might be preferable to have one version
> control system. Whatever we do here, we will need to update
> matplotlib.cbook.get_sample_data to work with the new system.
> Definitely an argument for getting all this migration sorted out
> before a trunk release.
>
> * trunk/sampledoc_tut - this is the source code for the
> http://matplotlib.sf.net/sampledoc tutorial which shows how to build
> mpl like sites using sphinx and associated extensions. Related to mpl
> in that it uses the plot directive etc, but is by no means integral.
> I can eventually port this to a new repo if there is any reason to.
>
> * trunk/scipy06 should probably be deleted
>
> * trunk/toolkits - should probably be migrated (Andrew you have not
> migrated this right?). One nice thing about having the toolkits in
> the same svn repo as the main codebase was for revision tagging, so
> basemap svn commits are synched with a trunk/matplotlib state. How
> should we proceed with the toolkits repo? Jeff?
> 
John, Eric, Andrew: I am OK with this. Don't know much about DVCS 
systems, but I guess this will be my excuse to learn.
-Jeff
> * trunk/users_guide - the old latex source for the mpl user's guide.
> Deprecated but should not be deleted. Same treatment as trunk/htdocs
> above.
>
> If we end up migratinga the toolkits to git/github (pending Jeff's
> comments) we may want to branch the stuff in trunk we want to keep for
> archival purposes (htdocs, users_guide) and clean as much stuff out of
> trunk as possible to avoid confusion for people browsing the trunk
> (and put a README in there explaining what and where stuff is).
>
> I think the plan is to keep trunk/matplotlib as a tracking repo, so
> that commits to the git master are pushed to the svn repo, so casual
> users who are running from svn HEAD will not be affected by the
> migration. Is this your understanding, Andrew?
>
>
> 
>>> 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.
>> 
>
> I am strongly in favor of keeping the entire commit history of
> trunk/matplotlib. While the repo is large now, most of the size comes
> from data and regression test images, and the early history is largely
> code so will not add much incremental size. I suppose one of the
> downsides of git is since you have to get the *entire* history on one
> checkout, you end up with a bunch of stuff you are unlikely to ever
> need, like data that was once in the repo but has now been removed (eg
> the stuff we migrated to sampledata). Not sure if there is an easy
> solution here.
>
> JDH
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Wed, Mar 3, 2010 at 8:29 AM, william ratcliff
<wil...@gm...> wrote:
> I don't want to get into a flame war over this, but if Sourceforge was
> pressured into this and is having complaints and google has the same
> problem, how does Github get around it? Are they incorporated in the US or
> outside? If this is likely to become a problem, is there another service
> that can be used with git besides github that would not eventually be
> subject to such constraints? Sorry, I'm just ignorant about such matters.
github has it's offices in the US and so they may change their policy
on this in the future if they feel the heat from the long arm of the
US law. Currently they do not appear to enforce export restrictions.
Here is a helpful summary of different open source hosting facilities
and their features and policies:
 http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
On Jan 25th, 2010, SF implemented a ban enforcing US export restrictions.
 http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/
But on Feb 7th, 2010, they lifted the blanket ban and now project
admins can impose the restriction if they are distributing restricted
technologies, which seems like a good compromise.
 http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/
Looks like the wikipedia site I linked above is out of date w/ respect
to sourceforge.
As far as I know, mpl is not distributing any restricted technologies
-- we do make extensive use of message digest functions like md5 for
caching, but these do not appear to be covered (eg, see
http://www.fourmilab.ch/md5). So it would be preferable to be on a
host that does not implement blanket restrictions. github does not
currently, and if they change their policy going forward we may elect
to move. Given that sourceforge has found a way to distribute
compliant code to restricted countries, and github currently does not
impose restrictions, I'm cautiously optimistic that a subsequent move
will not be necessary.
JDH

I don't want to get into a flame war over this, but if Sourceforge was
pressured into this and is having complaints and google has the same
problem, how does Github get around it? Are they incorporated in the US or
outside? If this is likely to become a problem, is there another service
that can be used with git besides github that would not eventually be
subject to such constraints? Sorry, I'm just ignorant about such matters.
William
On Wed, Mar 3, 2010 at 2:45 AM, Matthew Brett <mat...@gm...>wrote:
> Hi,
>
> On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff
> <wil...@gm...> 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
>

On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing <ef...@ha...> wrote:
> 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.
It looks like Andrew has trunk/matplotlib. There is other stuff in
trunk that definitely should not be migrated, and some stuff that
needs consideration.
 * trunk/py4science, which is a project Fernando and I have been
working on for several years but is not specific to mpl (it only uses
mpl). We will eventually migrate this into it's own repo, but this
is not an mpl project and should not be migrated.
 * trunk/course - looks like a very old and no longer used py4science
dir. Should probably be simply deleted and not frozen
 *trunk/htdocs - the old mpl site docs. Should live somewhere for
archival purposes in case there is a useful code snippet in there, but
certainly does not need to be in git or the new repo. It could live
frozen in the sf repo.
 * trunk/sampledata - this is important. The mpl trunk examples use
this to pull example data. We will need to migrate this -- we could
leave it in sf svn, but it might be preferable to have one version
control system. Whatever we do here, we will need to update
matplotlib.cbook.get_sample_data to work with the new system.
Definitely an argument for getting all this migration sorted out
before a trunk release.
 * trunk/sampledoc_tut - this is the source code for the
http://matplotlib.sf.net/sampledoc tutorial which shows how to build
mpl like sites using sphinx and associated extensions. Related to mpl
in that it uses the plot directive etc, but is by no means integral.
I can eventually port this to a new repo if there is any reason to.
 * trunk/scipy06 should probably be deleted
 * trunk/toolkits - should probably be migrated (Andrew you have not
migrated this right?). One nice thing about having the toolkits in
the same svn repo as the main codebase was for revision tagging, so
basemap svn commits are synched with a trunk/matplotlib state. How
should we proceed with the toolkits repo? Jeff?
 * trunk/users_guide - the old latex source for the mpl user's guide.
 Deprecated but should not be deleted. Same treatment as trunk/htdocs
above.
If we end up migratinga the toolkits to git/github (pending Jeff's
comments) we may want to branch the stuff in trunk we want to keep for
archival purposes (htdocs, users_guide) and clean as much stuff out of
trunk as possible to avoid confusion for people browsing the trunk
(and put a README in there explaining what and where stuff is).
I think the plan is to keep trunk/matplotlib as a tracking repo, so
that commits to the git master are pushed to the svn repo, so casual
users who are running from svn HEAD will not be affected by the
migration. Is this your understanding, Andrew?
>> 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.
I am strongly in favor of keeping the entire commit history of
trunk/matplotlib. While the repo is large now, most of the size comes
from data and regression test images, and the early history is largely
code so will not add much incremental size. I suppose one of the
downsides of git is since you have to get the *entire* history on one
checkout, you end up with a bunch of stuff you are unlikely to ever
need, like data that was once in the repo but has now been removed (eg
the stuff we migrated to sampledata). Not sure if there is an easy
solution here.
JDH

Hi,
On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff
<wil...@gm...> 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