Re: [matplotlib-devel] git migration
On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
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 wrote: > Hi, > > On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff > 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® 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
On Wed, Mar 3, 2010 at 8:29 AM, william ratcliff 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] favicon submission
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: in the header of the html pages. Enjoy, -Ben <>-- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
John Hunter wrote: > On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing 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® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine
Re: [matplotlib-devel] favicon submission
On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod 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: > > > > in the header of the html pages. Cool -- we're live http://matplotlib.sourceforge.net/ (may need to refresh) Thanks! JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] favicon submission
On Wed, Mar 3, 2010 at 11:16 AM, John Hunter wrote: > On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod 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: >> >> >> >> 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] favicon submission
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 [jdh2...@gmail.com] Sent: Wednesday, March 03, 2010 12:18 PM To: Ben Axelrod Cc: matplotlib-devel@lists.sourceforge.net Subject: Re: [matplotlib-devel] favicon submission On Wed, Mar 3, 2010 at 11:16 AM, John Hunter wrote: > On Wed, Mar 3, 2010 at 9:33 AM, Ben Axelrod 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: >> >> >> >> 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 <>-- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
> 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. -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Wed, Mar 3, 2010 at 1:31 PM, Jonathan Taylor 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: jdhun...@uqbar:~> du -hs mpl.git* 191Mmpl.git # no --depth 191Mmpl.git0 # --depth=0 147Mmpl.git1 # --depth=1 147Mmpl.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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] image_nonuniform.py broken in trunk HEAD
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' -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image_nonuniform.py broken in trunk HEAD
On Wed, Mar 3, 2010 at 4:48 PM, John Hunter 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image_nonuniform.py broken in trunk HEAD
Should be fixed with r8178. Regards, -JJ On Wed, Mar 3, 2010 at 5:19 PM, Jae-Joon Lee wrote: > On Wed, Mar 3, 2010 at 4:48 PM, John Hunter 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 > -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
