Re: [matplotlib-devel] question about svnmerge
On 7/20/10 8:06 PM, Fernando Perez wrote: > On Tue, Jul 20, 2010 at 7:43 PM, John Hunter wrote: > >> The major issues I am aware of are: >> >> * what do to about all the various subdirs of the mpl trunk >> (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to >> one tags all with a unique revision number. In git, how do we >> synchronize between them? Putting them all in the same tree would be >> monolithic and require huge checkouts. Unlike svn, in git it is >> difficult/impossible to check out just a subdir (eg trunk/matplotlb) >> and also commit to it. So we might end up having to informally >> synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in >> the CHANGELOG or release notes. >> > Probably using a common tag across repos would be the easiest. Any > time you want a known 'sync point', you tag all the relevant repos > with the same tag. It then becomes very simple to write a little > script that will update checkout a bunch of repos sitting in the same > parent directory (each as its own dir, of course) at a common tag. > You can make up a convention for these special tags so that they are > always named with a given pattern (you could even use r if you > wanted). > We could also make a meta repository that uses git submodules (somewhat akin to svn externals). Each commit in a repo that links to submodules specifies a specific revision of the submodule repo, so this meta repository would be a fairly natural way of linking across several repositories at specific revisions. That being said, a convention to simply use the standard git tags would also work fine, and wouldn't require people to learn git submodules. So, it's really a question of sticking to a convention (that has a lesser learning curve) or using a new set of commands that would more or less do exactly what we want, but would have to be learned. I'm agnostic on the issue. >> * organizational stuff: how do we handle the notion of the central >> repo? Now that github support "organizations" this should be >> relatively easy. Andrew and I registered a matplotlib user acct at >> github and created a gmail acct mplgithub as a central administrator >> (matplot...@gmail.com was taken, the bastards). Email me offlist if >> you are interested in obtaining the passwd for the github or gmail >> admin accts -- but you should probably coordinate with Andrew who is >> our point person as soon as he re-emerges. >> > No need. Organizations let you designate more than one 'owner', so you > can mark more than one person with full admin privileges without > having to give out the password around. I recently converted the > extra ipython account to an organization, added Brian Granger as a > second 'owner', and that's it. You can then make as many teams and > repos as you want within an organization. The github org model is > fairly simple but very effective (much nicer than how launchpad uses > teams). > I went ahead and switched our github.com/matplotlib account into an organization when github announced organization support a few weeks ago. Just now I added the jdh2358 and fperez users into the matplotlib owner's team. (And I'm trying to re-emerge, I promise...) >> * porting the buildbot to work w/ github commits >> I should be able to handle that fairly easily. I do it for my other projects. (Bigger on my buildbot priority list is stopping the annoying occasional config directory multi-process conflict. >> * related: porting the trunkdocs build to work with github commits >> As this is run by the buildbot, it should be taken care of with the above. For me, the main remaining issue is how do we want to pull the svn repo into git? Right now, the unofficial git repo at github.com/astraw/matplotlib is too big for my likes because it has a lot of stuff besides the matplotlib source code and its history. Before moving to an official git repository, I think we should prune down the main repository to just the source code files, their history, and no binary files. But then that leaves the question of what to do with the binary files. -Andrew -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
John Hunter writes: > * what do to about all the various subdirs of the mpl trunk > (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to > one tags all with a unique revision number. In git, how do we > synchronize between them? Putting them all in the same tree would be > monolithic and require huge checkouts. Unlike svn, in git it is > difficult/impossible to check out just a subdir (eg trunk/matplotlb) > and also commit to it. I think git submodules could help here: http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules http://github.com/guides/developing-with-submodules The Basemap project would have a submodule pointing to some revision of the matplotlib project, etc. Jouni -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] colors documentation
Hello, I was just peeking through the code for hsv_to_rgb() and rgb_to_hsv() and found that they were lacking in comments. While I haven't quite figured out hsv_to_rgb() and there are some missing documentation regarding how hsv is represented, I figured that I should make available what I could figure out for rgb_to_hsv(). Attached is a patch that would comment the two functions. Please feel free to add to this if you have extra knowledge that is relevant. Thanks, Ben Root colors_comments.patch Description: Binary data -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Wed, Jul 21, 2010 at 6:38 AM, Andrew Straw wrote: > On 7/20/10 8:06 PM, Fernando Perez wrote: >> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter wrote: >> >>> The major issues I am aware of are: >>> >>> * what do to about all the various subdirs of the mpl trunk >>> (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to >>> one tags all with a unique revision number. In git, how do we >>> synchronize between them? Putting them all in the same tree would be >>> monolithic and require huge checkouts. Unlike svn, in git it is >>> difficult/impossible to check out just a subdir (eg trunk/matplotlb) >>> and also commit to it. So we might end up having to informally >>> synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in >>> the CHANGELOG or release notes. >>> >> Probably using a common tag across repos would be the easiest. Any >> time you want a known 'sync point', you tag all the relevant repos >> with the same tag. It then becomes very simple to write a little >> script that will update checkout a bunch of repos sitting in the same >> parent directory (each as its own dir, of course) at a common tag. >> You can make up a convention for these special tags so that they are >> always named with a given pattern (you could even use r if you >> wanted). >> > We could also make a meta repository that uses git submodules (somewhat > akin to svn externals). Each commit in a repo that links to submodules > specifies a specific revision of the submodule repo, so this meta > repository would be a fairly natural way of linking across several > repositories at specific revisions. That being said, a convention to > simply use the standard git tags would also work fine, and wouldn't > require people to learn git submodules. So, it's really a question of > sticking to a convention (that has a lesser learning curve) or using a > new set of commands that would more or less do exactly what we want, but > would have to be learned. I'm agnostic on the issue. Is it possible to do both simultaneously for a while, to test whether submodules works for us in practice? I have long been interested in using something along the lines of submodules or nested repositories, and a metarepository would seem to be exactly what we need. But this business about cloning yielding empty submodules until you initialize them, but then they are detached heads, remembering not using trailing slashes when staging changes in a superproject... hopefully these will not be issues, but we might need some time before we decide whether we like submodules enough to embrace it long term. I just finished a long run at work, and should have some time in the next couple weeks during evenings and weekends that I could contribute to the git and python3 transitions. Darren -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] tight subplot parameters
Unused whitespace is a pet-peeve of mine, so I tend to use bbox_inches='tight' when saving figures. However, when producing publications, I want figures with a very specific size (i.e., fit column width of page), but calling bbox_inches='tight' changes the figure size. Stretching to fit is out of the question (screws up the font sizes). Anyway, I coded up a way to automatically choose values for subplots_adjust. My main goal was to tighten the borders (top, bottom, left, right). Nevertheless, I ended up coding up a solution to automatically adjust 'hspace' and 'wspace'. Just curious if there's any interest in adding this functionality. Cheers, -Tony Code Notes: - * The code to tighten the subplot spacing only works for regular grids: not with subplots that span multiple columns/rows. * The code to tighten up the borders is short and fairly intuitive, but the code for subplot spacing is pretty messy (mainly because wspace/hspace depends on the border spacing and the number of rows/columns). * The code draws the figure twice to calculate subplot parameters (not sure if this is a big issue, but I thought it was worth mentioning). * Just execute the file to plot some examples with random label sizes to demonstrate subplot adjustment. import numpy as np import matplotlib.pyplot as plt from matplotlib.transforms import TransformedBbox, Affine2D PAD_INCHES = 0.1 def tight_layout(pad_inches=PAD_INCHES, h_pad_inches=None, w_pad_inches=None): """Adjust subplot parameters to give specified padding. Parameters -- pad_inches : float minimum padding between the figure edge and the edges of subplots. h_pad_inches, w_pad_inches : float minimum padding (height/width) between edges of adjacent subplots. Defaults to `pad_inches`. """ if h_pad_inches is None: h_pad_inches = pad_inches if w_pad_inches is None: w_pad_inches = pad_inches fig = plt.gcf() tight_borders(fig, pad_inches=pad_inches) # NOTE: border padding affects subplot spacing; tighten border first tight_subplot_spacing(fig, h_pad_inches, w_pad_inches) def tight_borders(fig, pad_inches=PAD_INCHES): """Stretch subplot boundaries to figure edges plus padding.""" # call draw to update the renderer and get accurate bboxes. fig.canvas.draw() bbox_original = fig.bbox_inches bbox_tight = _get_tightbbox(fig, pad_inches) # figure dimensions ordered like bbox.extents: x0, y0, x1, y1 lengths = np.array([bbox_original.width, bbox_original.height, bbox_original.width, bbox_original.height]) whitespace = (bbox_tight.extents - bbox_original.extents) / lengths # border padding ordered like bbox.extents: x0, y0, x1, y1 current_borders = np.array([fig.subplotpars.left, fig.subplotpars.bottom, fig.subplotpars.right, fig.subplotpars.top]) left, bottom, right, top = current_borders - whitespace fig.subplots_adjust(bottom=bottom, top=top, left=left, right=right) def _get_tightbbox(fig, pad_inches): renderer = fig.canvas.get_renderer() bbox_inches = fig.get_tightbbox(renderer) return bbox_inches.padded(pad_inches) def tight_subplot_spacing(fig, h_pad_inches, w_pad_inches): """Stretch subplots so adjacent subplots are separated by given padding.""" # Zero hspace and wspace to make it easier to calculate the spacing. fig.subplots_adjust(hspace=0, wspace=0) fig.canvas.draw() figbox = fig.bbox_inches ax_bottom, ax_top, ax_left, ax_right = _get_grid_boundaries(fig) nrows, ncols = ax_bottom.shape subplots_height = fig.subplotpars.top - fig.subplotpars.bottom if nrows > 1: h_overlap_inches = ax_top[1:] - ax_bottom[:-1] hspace_inches = h_overlap_inches.max() + h_pad_inches hspace_fig_frac = hspace_inches / figbox.height hspace = _fig_frac_to_cell_frac(hspace_fig_frac, subplots_height, nrows) fig.subplots_adjust(hspace=hspace) subplots_width = fig.subplotpars.right - fig.subplotpars.left if ncols > 1: w_overlap_inches = ax_right[:,:-1] - ax_left[:,1:] wspace_inches = w_overlap_inches.max() + w_pad_inches wspace_fig_frac = wspace_inches / figbox.width wspace = _fig_frac_to_cell_frac(wspace_fig_frac, subplots_width, ncols) fig.subplots_adjust(wspace=wspace) def _get_grid_boundaries(fig): """Return grid boundaries for bboxes of subplots Returns --- ax_bottom, ax_top, ax_left, ax_right : array bbox cell-boundaries of subplot grid. If a subplot spans cells, the grid boundaries cutting through that subplot will be masked. """ nrows, ncols, n = fig.axes[0].get_geometry() # Initialize boundaries as masked arrays; in the future, support subplots # that span multiple rows/columns, which would have masked values for grid # boundaries that cu
Re: [matplotlib-devel] question about svnmerge
On Wed, Jul 21, 2010 at 5:38 AM, Andrew Straw wrote: > > I should be able to handle that fairly easily. I do it for my other > projects. (Bigger on my buildbot priority list is stopping the annoying > occasional config directory multi-process conflict. This should just take a couple of minutes. Just set MPLCONFIGDIR to be a unique dir for each buildbot on the shell line that runs the tests. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu wrote: > Wow, I don't see that at all. I'm on OS X, mpl svn HEAD (r8567), and Qt4Agg. > I don't have GTK installed, so unfortunately, I can't really do a proper > comparison. Here's the output I get from your modified script. I get > something similar with TkAgg (unfortunately, I get an AttributeError with the > macosx backend). Works on my system for tkagg and qtagg4, so the bug appears gtkagg specific. Must be something in the draw vs window realized and sized pipeline. It appears you are getting some bogus size info.Wonder if connecting to the draw_event might help here (longshot) or if any any of Eric's recent work on show is impacting th behavior here. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On Jul 21, 2010, at 11:26 PM, John Hunter wrote: > On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu wrote: >> Wow, I don't see that at all. I'm on OS X, mpl svn HEAD (r8567), and Qt4Agg. >> I don't have GTK installed, so unfortunately, I can't really do a proper >> comparison. Here's the output I get from your modified script. I get >> something similar with TkAgg (unfortunately, I get an AttributeError with >> the macosx backend). > > Works on my system for tkagg and qtagg4, so the bug appears gtkagg > specific. Must be something in the draw vs window realized and sized > pipeline. It appears you are getting some bogus size info.Wonder > if connecting to the draw_event might help here (longshot) or if any > any of Eric's recent work on show is impacting th behavior here. Well, since I don't have access to GTK, it's not really something I can debug (kind of a cop out, I know). Your original GTK image is really strange: it seems as though the script moves the ticks, axis labels, and titles relative to their associated axes-frame. But the only function I use to affect the plot spacing is Figure.subplots_adjust (everything else in the script serves to calculate appropriate spacing-values). I don't think Figure.subplots_adjust is designed to move the ticks/axis-labels/titles relative to its own axes, right? -Tony -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On 07/21/2010 05:26 PM, John Hunter wrote: > On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu wrote: >> Wow, I don't see that at all. I'm on OS X, mpl svn HEAD (r8567), and Qt4Agg. >> I don't have GTK installed, so unfortunately, I can't really do a proper >> comparison. Here's the output I get from your modified script. I get >> something similar with TkAgg (unfortunately, I get an AttributeError with >> the macosx backend). > > Works on my system for tkagg and qtagg4, so the bug appears gtkagg > specific. Must be something in the draw vs window realized and sized > pipeline. It appears you are getting some bogus size info.Wonder > if connecting to the draw_event might help here (longshot) or if any > any of Eric's recent work on show is impacting th behavior here. No. I modified the script to eliminate the subplots() calls so that I could run it on 0.99.3 (the first 2 figures only), and it still doesn't work on gtkagg, but does work on qt4agg. Eric -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Wed, Jul 21, 2010 at 3:38 AM, Andrew Straw wrote: > We could also make a meta repository that uses git submodules (somewhat akin > to svn externals). I have to confess that I first heard of git submodules when you first mentioned them on this list a while ago, but a reasonable amount of reading left me with the feeling that it was far more git-fu than I was willing to handle for everyday work. They seemed like a fairly complex system, with a very nasty set of failure modes (easy to make mistakes having serious consequences). I say this as the guy who's been raving about git to anyone who won't shut me up, but git submodules seemed just a tad much. Maybe I just didn't find the right explanation, or it was my natural slowness, but I found all the descriptions to be confusing, with lots of moving parts and many things to remember carefully. The tags approach is certainly simple-minded, but it seemed easy enough and something that one or two shell scripts would turn into mindless one-liners in day-to-day practice, I think. Glad to have you around again :) Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On 07/21/2010 05:26 PM, John Hunter wrote:
> On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu wrote:
>> Wow, I don't see that at all. I'm on OS X, mpl svn HEAD (r8567), and Qt4Agg.
>> I don't have GTK installed, so unfortunately, I can't really do a proper
>> comparison. Here's the output I get from your modified script. I get
>> something similar with TkAgg (unfortunately, I get an AttributeError with
>> the macosx backend).
>
> Works on my system for tkagg and qtagg4, so the bug appears gtkagg
> specific. Must be something in the draw vs window realized and sized
> pipeline. It appears you are getting some bogus size info.Wonder
> if connecting to the draw_event might help here (longshot) or if any
> any of Eric's recent work on show is impacting th behavior here.
It is not anything I changed, but it is related to when drawing occurs.
The following change makes it work with gtk, and keep working with qt4agg:
efir...@manini:~/temp$ diff -u tight_layout.py tight_layout_gtk.py
--- tight_layout.py 2010-07-21 20:28:16.0 -1000
+++ tight_layout_gtk.py 2010-07-21 20:29:05.0 -1000
@@ -131,6 +131,7 @@
if __name__ == '__main__':
import numpy as np
np.random.seed(1234)
+plt.ion()
fontsizes = [8, 16, 24, 32]
def example_plot(ax):
ax.plot([1, 2])
@@ -164,5 +165,6 @@
for ax in row:
example_plot(ax)
tight_layout()
+plt.ioff()
fig.savefig('tight5')
plt.show()
I have not tracked down the reason why gtk is behaving differently;
drawing with gtkagg is a bit convoluted. It appears that gtk is more
efficient in delaying drawing, and in drawing only once at the end,
while the others are less clever, and actually draw when the
canvas.draw() method is executed.
Eric
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
