matplotlib-devel Mailing List for matplotlib (Page 2)

On Tue, Jul 20, 2010 at 9:21 AM, Jeff Klukas <kl...@wi...> wrote:

> Hello,
>
> The documentation for hist seems to indicate that you should be able
> to send a list of values through the 'weights' parameter in axes.hist,
> and this worked in previous versions.  In 1.0, however, this produces
> an error.  I've attached a diff (also pasted below) that I believe
> produces the expected behavior.
>
> It can be tested with:
> plt.hist([1,2,3], weights=[1,2,3])
>
> The above fails in the development version, but works with the diff.
> Could someone add this fix?
>
> Thanks,
> Jeff
>
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://klukas.web.cern.ch/
>
>
> Index: lib/matplotlib/axes.py
> ===================================================================
> --- lib/matplotlib/axes.py      (revision 8565)
> +++ lib/matplotlib/axes.py      (working copy)
> @@ -7587,7 +7587,12 @@
>                 else:
>                     raise ValueError("weights must be 1D or 2D")
>             else:
> -                w = [np.array(wi) for wi in weights]
> +                try:
> +                    weights[0][0]
> +                except TypeError:
> +                    w = [np.array(weights)]
> +                else:
> +                    w = [np.array(wi) for wi in weights]
>
>             if len(w) != nx:
>                 raise ValueError('weights should have the same shape as x')
>
>
Good catch, Jeff.  Looking over the code, looks like both the input data, x,
and the weights get similar pre-processing done to ready it for
histogramming. It appears that a fix was made to how x was being processed,
but the same was not done to weights.  I have a patch that fixes the
pre-processing of weights, and also  adds comments to both blocks of code to
remind future developers to make sure changes are made to both chunks of
code.

The functional part of the change was to check if the first element of
weights was an iterable or not.  Before, the weights array as in the given
example would be considered 1-element weights for 3 datasets, rather than
3-element weights for 1 dataset.

Ben Root

On 07/24/2010 04:01 PM, Benjamin Root wrote:
> On Sat, Jul 24, 2010 at 5:08 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     While running backend_driver.py on the maintenance branch, I found that
>     the mplot3d examples were not working.  Here is an example:
>
>     efiring@manini:~/programs/py/mpl/mpl_v1_0_maint/examples/mplot3d$ python
>     wire3d_demo.py
>     Traceback (most recent call last):
>        File "wire3d_demo.py", line 6, in <module>
>          ax = fig.add_subplot(111, projection='3d')
>        File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
>     line 675, in add_subplot
>          projection_class = get_projection_class(projection)
>        File
>     "/usr/local/lib/python2.6/dist-packages/matplotlib/projections/__init__.py",
>     line 61, in get_projection_class
>          raise ValueError("Unknown projection '%s'" % projection)
>     ValueError: Unknown projection '3d'
>
>     Eric
>
>
> Double-check your axes3d.py file.  The Axes3D class should have a member
> variable called "name" at the very beginning of it, and the very end of
> the axes3d.py file should have two lines of code that registers the
> axes3d object with the projection system.

Bitten by distutils again.  Attempting to get a complete clean rebuild, 
I was deleting dist-packages/matplot*, but not 
dist-packages/mpl_toolkits/.  Of course, doing that blows away basemap, 
which is not really what I want.

It would be simpler if everything installed by matplotlib's setup.py, 
and nothing else, would land in a single tree (package).  Having several 
things land in mpl_toolkits, and having other things also land there, is 
a pain.  Maybe we are stuck with it.  Or maybe things like basemap 
should be packages in their own right, parallel to matplotlib, instead 
of being inside mpl_toolkits.

Eric

>
> Ben Root

On Sat, Jul 24, 2010 at 5:08 PM, Eric Firing <ef...@ha...> wrote:

> While running backend_driver.py on the maintenance branch, I found that
> the mplot3d examples were not working.  Here is an example:
>
> efiring@manini:~/programs/py/mpl/mpl_v1_0_maint/examples/mplot3d$ python
> wire3d_demo.py
> Traceback (most recent call last):
>   File "wire3d_demo.py", line 6, in <module>
>     ax = fig.add_subplot(111, projection='3d')
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
> line 675, in add_subplot
>     projection_class = get_projection_class(projection)
>   File
>
> "/usr/local/lib/python2.6/dist-packages/matplotlib/projections/__init__.py",
> line 61, in get_projection_class
>     raise ValueError("Unknown projection '%s'" % projection)
> ValueError: Unknown projection '3d'
>
> Eric
>
>
Double-check your axes3d.py file.  The Axes3D class should have a member
variable called "name" at the very beginning of it, and the very end of the
axes3d.py file should have two lines of code that registers the axes3d
object with the projection system.

Ben Root

While running backend_driver.py on the maintenance branch, I found that 
the mplot3d examples were not working.  Here is an example:

efiring@manini:~/programs/py/mpl/mpl_v1_0_maint/examples/mplot3d$ python 
wire3d_demo.py
Traceback (most recent call last):
   File "wire3d_demo.py", line 6, in <module>
     ax = fig.add_subplot(111, projection='3d')
   File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py", 
line 675, in add_subplot
     projection_class = get_projection_class(projection)
   File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/projections/__init__.py", 
line 61, in get_projection_class
     raise ValueError("Unknown projection '%s'" % projection)
ValueError: Unknown projection '3d'

Eric

On Thu, Jul 22, 2010 at 9:46 PM, Eric Firing <ef...@ha...> wrote:

> On 07/22/2010 04:34 PM, Benjamin Root wrote:
> > Heh, looks more pervasive than just the Tkinter backend, and it isn't
> > just caused by zooming.  Just moving the image off to the side is
> > enough, and saving that figure using the "Save" button produces this
> > attached image.
> >
> > And further testing shows that this occurs if I manually set my limits
> > before the .show() call and save using .savefig()
> >
> > Attached is a simple script.
>
> Running your script, I don't see any artifacts with gtkagg or with
> tkagg, or if I save the file to png.  I'm also running with latest svn.
>
> I wonder whether your installation has gotten scrambled?  You might try
> deleting your build directory and your installed mpl, then rebuild and
> reinstall.  It is not uncommon that a clean rebuild and reinstallation
> is the solution to mystifying problems.
>
> Eric
>
>
Looks like you are right.  A complete clean-out and rebuild fixes the
problem.  I might have messed something up a while back when testing some
clipping issues.

Thanks,
Ben Root

On 07/22/2010 04:34 PM, Benjamin Root wrote:
> Heh, looks more pervasive than just the Tkinter backend, and it isn't
> just caused by zooming.  Just moving the image off to the side is
> enough, and saving that figure using the "Save" button produces this
> attached image.
>
> And further testing shows that this occurs if I manually set my limits
> before the .show() call and save using .savefig()
>
> Attached is a simple script.

Running your script, I don't see any artifacts with gtkagg or with 
tkagg, or if I save the file to png.  I'm also running with latest svn.

I wonder whether your installation has gotten scrambled?  You might try 
deleting your build directory and your installed mpl, then rebuild and 
reinstall.  It is not uncommon that a clean rebuild and reinstallation 
is the solution to mystifying problems.

Eric

>
> Ben
>
> On Thu, Jul 22, 2010 at 9:14 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>     Attached is a screenshot of what I am seeing with the Tkinter
>     backend (I haven't tested others).  The lines aren't getting plotted
>     outside the zoomed-in region, but the markers are.  I don't recall
>     this happening before, but I can't be 100% sure of that.
>
>     I am using the latest mpl from SVN.
>
>     Ben Root
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Heh, looks more pervasive than just the Tkinter backend, and it isn't just
caused by zooming.  Just moving the image off to the side is enough, and
saving that figure using the "Save" button produces this attached image.

And further testing shows that this occurs if I manually set my limits
before the .show() call and save using .savefig()

Attached is a simple script.

Ben

On Thu, Jul 22, 2010 at 9:14 PM, Benjamin Root <ben...@ou...> wrote:

> Attached is a screenshot of what I am seeing with the Tkinter backend (I
> haven't tested others).  The lines aren't getting plotted outside the
> zoomed-in region, but the markers are.  I don't recall this happening
> before, but I can't be 100% sure of that.
>
> I am using the latest mpl from SVN.
>
> Ben Root
>

On Mon, Jul 19, 2010 at 10:13 AM, Ryan May <rm...@gm...> wrote:

> On Sun, Jul 18, 2010 at 6:16 PM, Benjamin Root <ben...@ou...> wrote:
> > A few corrections.  First, I wrong, it is unusual.  The second axes that
> I
> > noticed in a 2d case came from a colorbar being added.  Second, in the 3d
> > case, it was the Axes3DSubplot object being added twice, not the regular
> > object like I originally said.
> >
> > The cause of this is due to the Axes3D initializer adding itself to the
> > figure object being passed in.  This initializer is called when
> > add_subplot() is called, so add_subplot also adds the axes when it is
> > finished making it.  For normal projections, the initializer does not add
> > itself to the axes.
> >
> > Removing the add_axes in the Axes3D initializer would "solve" the issue
> > outright, however, there are plenty of legacy code where Axes3D is called
> > with a figure passed in in order to create the axes, and this would break
> > that use pattern.
>
> I think the fact that add_axes will just blindly add a duplicate axes
> is a bug. So why not have add_axes do something like the following:
>
> if ax not in axes_list:
>  axes_list.append(ax)
>  <more stuff>
>
> Anyone see anything wrong with this approach?
>
>
I agree, this is probably the best way to nip this in the bud without
breaking backwards compatibility.  However, I am concerned that this might
bury other bugs (current or future) by preventing a mistake from making
itself apparent.  Is there some way to have a special warning put out in the
"else" branch of that if?

Ben Root

On Jul 22, 2010, at 10:07 AM, John Hunter wrote:

> On Thu, Jul 22, 2010 at 8:57 AM, Tony S Yu <tsyu80@
> 
>>> According to backend_bases.FigureCanvas, a renderer attr is not
>>> guaranteed either.
>>> The Agg* backends rely on get_renderer so that they can get a properly
>>> sized renderer on figure resizes, dpi changes, etc.  We could handle
>>> this on the agg side with a property, or require all canvases to
>>> supply get renderer.
> 
> No, this won't work because the sizing information depends on the GUI
> window size.  Agg adapts the renderer to the GUI window size.  So in
> GTKAgg we are using the Agg renderer, but GTK is determining the
> window size when it is raised.   We try to get GTK to produce a canvas
> of a fixed size, but cannot guarantee it so we reset the renderer size
> in necessary when the canvas is raised.
> 
> JDH

I'm not sure if I understand. Are you talking about responding to window resizing events, or are you saying that Figure.get_height/get_width don't match the window size for some GUI backends? 

I create the Agg renderer based on Figure.get_height/get_width. If the window is resized, then the layout would definitely change, but you could call `tight_layout` again to adjust subplot spacing (which would create a new Agg renderer based on the new window size). Am I missing something here? Were you thinking I wanted to interactively adapt the spacings? (If that's the case, I wasn't that ambitious.)

-Tony

--- On Thu, 7/22/10, John Hunter <jd...@gm...> wrote:
> We could handle this on the agg side with a property,
> or require all canvases to supply get renderer.
> 
Do we actually need a renderer in each of the backends? At least when I was writing the Mac OS X backend, it was not clear to me what functionality should go in the renderer and what should go in the graphics context. I expect that the same is true for the other postscript-style backends such as the cairo, pdf, and ps backends.

In the end, I decided to mainly use the graphics context because it nicely maps to the Quartz graphics context at the C level, whereas the renderer doesn't have a corresponding data structure at the C level. In the Mac OS X backend, basically what the renderer does is to forward to the graphics context. In the ps backend most of the work is being done in the renderer instead of the graphics context, but again this is just a choice. I think that we should first remove such inconsistencies between backends.

--Michiel


      

On Thu, Jul 22, 2010 at 8:57 AM, Tony S Yu <tsyu80@

>> According to backend_bases.FigureCanvas, a renderer attr is not
>> guaranteed either.
>> The Agg* backends rely on get_renderer so that they can get a properly
>> sized renderer on figure resizes, dpi changes, etc.  We could handle
>> this on the agg side with a property, or require all canvases to
>> supply get renderer.

No, this won't work because the sizing information depends on the GUI
window size.  Agg adapts the renderer to the GUI window size.  So in
GTKAgg we are using the Agg renderer, but GTK is determining the
window size when it is raised.   We try to get GTK to produce a canvas
of a fixed size, but cannot guarantee it so we reset the renderer size
in necessary when the canvas is raised.

JDH

On Jul 22, 2010, at 8:59 AM, John Hunter wrote:

> On Thu, Jul 22, 2010 at 7:40 AM, Michiel de Hoon <mjl...@ya...> wrote:
> 
>> Is a backend required to implement a get_renderer method? I only see it implemented in backend_agg.py, and it's missing in backend_bases.py, backend_template.py, backend_cairo.py, and in the macosx backend. If you want to try your code with the macosx backend, you can use fig.canvas.renderer instead of fig.canvas.get_renderer().
> 
> According to backend_bases.FigureCanvas, a renderer attr is not
> guaranteed either.
> The Agg* backends rely on get_renderer so that they can get a properly
> sized renderer on figure resizes, dpi changes, etc.  We could handle
> this on the agg side with a property, or require all canvases to
> supply get renderer.
> 
> The tricky bit is that renderers may not be available until draw time
> for some backends, and thus may not have proper size information if
> accessed too early (this is probably at the heart of the gtk bug we
> are seeing).  It is probably a good idea to settle on something so
> developers can get access to the renderer in a consistent state, and
> this might require support a "raise_event" which one could connect to
> and get the figure as soon as it is raised (which would be triggered
> on canvas creation for non gui backends presumably and after the
> window is raised for gui backends).  In the callback, accessing
> canvas.renderer or canvas.get_renderer would return a renderer with
> proper sizing.
> 
> JDH

Sorry, I don't know much about how the backends are structured. But this talk of backends got me thinking: Since the Agg backend (non-GUI version) is guaranteed to be installed (correct?), you could create an Agg renderer, and just use that to calculate all the sizing information. This experiment worked for all GUI backends on my system (Qt4Agg, TkAgg, MacOSX).

Are there any downsides to using Agg to calculate sizing info and then rendering again on a GUI backend? Performance issues? I guess it's possible differences in sizing between backends will show up in the resized subplots, but these differences should be small, right?

-Tony

P.S. I've removed calls to "subplots" in example code for easier testing.

On Thu, Jul 22, 2010 at 7:40 AM, Michiel de Hoon <mjl...@ya...> wrote:

> Is a backend required to implement a get_renderer method? I only see it implemented in backend_agg.py, and it's missing in backend_bases.py, backend_template.py, backend_cairo.py, and in the macosx backend. If you want to try your code with the macosx backend, you can use fig.canvas.renderer instead of fig.canvas.get_renderer().

According to backend_bases.FigureCanvas, a renderer attr is not
guaranteed either.
The Agg* backends rely on get_renderer so that they can get a properly
sized renderer on figure resizes, dpi changes, etc.  We could handle
this on the agg side with a property, or require all canvases to
supply get renderer.

The tricky bit is that renderers may not be available until draw time
for some backends, and thus may not have proper size information if
accessed too early (this is probably at the heart of the gtk bug we
are seeing).  It is probably a good idea to settle on something so
developers can get access to the renderer in a consistent state, and
this might require support a "raise_event" which one could connect to
and get the figure as soon as it is raised (which would be triggered
on canvas creation for non gui backends presumably and after the
window is raised for gui backends).  In the callback, accessing
canvas.renderer or canvas.get_renderer would return a renderer with
proper sizing.

JDH

--- On Wed, 7/21/10, Tony S Yu <ts...@gm...> wrote:
> I get something similar with TkAgg (unfortunately, I get an
> AttributeError with the macosx backend).

This is the AttributeError:

Traceback (most recent call last):
  File "Desktop/tight_layout.py", line 142, in <module>
    tight_layout()
  File "Desktop/tight_layout.py", line 28, in tight_layout
    tight_subplot_spacing(fig, h_pad_inches, w_pad_inches)
  File "Desktop/tight_layout.py", line 64, in tight_subplot_spacing
    ax_bottom, ax_top, ax_left, ax_right = _get_grid_boundaries(fig)
  File "Desktop/tight_layout.py", line 99, in _get_grid_boundaries
    renderer = fig.canvas.get_renderer()
AttributeError: 'FigureCanvasMac' object has no attribute 'get_renderer'
>>> 

Is a backend required to implement a get_renderer method? I only see it implemented in backend_agg.py, and it's missing in backend_bases.py, backend_template.py, backend_cairo.py, and in the macosx backend. If you want to try your code with the macosx backend, you can use fig.canvas.renderer instead of fig.canvas.get_renderer().

--Michiel.


      

On 07/21/2010 05:26 PM, John Hunter wrote:
> On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu<ts...@gm...>  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:


efiring@manini:~/temp$ diff -u tight_layout.py tight_layout_gtk.py
--- tight_layout.py	2010-07-21 20:28:16.000000000 -1000
+++ tight_layout_gtk.py	2010-07-21 20:29:05.000000000 -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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wed, Jul 21, 2010 at 3:38 AM, Andrew Straw <str...@as...> 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

On 07/21/2010 05:26 PM, John Hunter wrote:
> On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu<ts...@gm...>  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

On Jul 21, 2010, at 11:26 PM, John Hunter wrote:

> On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu <ts...@gm...> 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

On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu <ts...@gm...> 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.

On Jul 21, 2010, at 10:44 PM, John Hunter wrote:

> On Wed, Jul 21, 2010 at 7:16 PM, Tony S Yu <ts...@gm...> wrote:
>> 
>> 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'.

[Snip]
> 
> Not sure if I am missing something obvious, but on my system (ubuntu
> linux, mpl svn HEAD, backend GTKAgg) the figures look wrong.  I am
> attaching the results from one run for fig5 for comparison, but almost
> all of the figs appear unusable.  I modified your script slightly to
> use the np random number generator and seeded it so we can (hopefully)
> get comparable results on our systems w/o the confusions of different
> random choices.  Revised code and example fig attached.
> <tight_layout.py><tight5.png>

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

On Wed, Jul 21, 2010 at 5:38 AM, Andrew Straw <str...@as...> 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

On Wed, Jul 21, 2010 at 7:16 PM, Tony S Yu <ts...@gm...> wrote:
> 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.
> 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.

Not sure if I am missing something obvious, but on my system (ubuntu
linux, mpl svn HEAD, backend GTKAgg) the figures look wrong.  I am
attaching the results from one run for fig5 for comparison, but almost
all of the figs appear unusable.  I modified your script slightly to
use the np random number generator and seeded it so we can (hopefully)
get comparable results on our systems w/o the confusions of different
random choices.  Revised code and example fig attached.

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.

On Wed, Jul 21, 2010 at 6:38 AM, Andrew Straw <str...@as...> wrote:
> On 7/20/10 8:06 PM, Fernando Perez wrote:
>> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter<jd...@gm...>  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 rNNNN 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

John Hunter <jdh2358@...> 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