matplotlib-devel Mailing List for matplotlib

A few days ago I committed a patch with which I tried to improve the
coordinate handling of annotation.
And I updated the annotation guide which describes the change in some detail.

http://matplotlib.sourceforge.net/trunk-docs/users/annotations_guide.html#using-complex-coordinate-with-annotation

And here is an example

http://matplotlib.sourceforge.net/trunk-docs/examples/pylab_examples/annotation_demo3.html

I hope this is useful for others as this has been one of my wishlist.
Regards,

-JJ

When testing the cairo backend on Mac OS X, I did experience crashes with long path lengths even with the current version (1.8.8) of cairo / pycairo. So the path length check is still needed. I put it back in.

--Michiel.

--- On Mon, 2/22/10, Michiel de Hoon <mjl...@ya...> wrote:

> From: Michiel de Hoon <mjl...@ya...>
> Subject: Re: [matplotlib-devel] Path length in the cairo backend
> To: "Eric Firing" <ef...@ha...>
> Cc: mat...@li...
> Date: Monday, February 22, 2010, 9:09 PM
> Yes I tried without path
> simplification, and I don't get any crashes. If we need to
> support older versions of cairo / pycairo, I suggest that we
> have the path length check after checking the version of
> cairo / pycairo, and that we perform the path length check
> after path simplification, so we know how many points will
> actually be drawn.
> 
> --Michiel.
> 
> --- On Mon, 2/22/10, Eric Firing <ef...@ha...>
> wrote:
> 
> > From: Eric Firing <ef...@ha...>
> > Subject: Re: [matplotlib-devel] Path length in the
> cairo backend
> > To: "Michiel de Hoon" <mjl...@ya...>
> > Cc: mat...@li...
> > Date: Monday, February 22, 2010, 1:00 PM
> > Michiel de Hoon wrote:
> > > Dear all,
> > > 
> > > The draw_path method in backend_cairo.py starts
> with a
> > check for the number of vertices in the path, and
> raises an
> > error if the path contains more than 18980 vertices:
> > > 
> > >      def draw_path(self, gc, path,
> > transform, rgbFace=None):
> > >          if
> > len(path.vertices) > 18980:
> > >              raise
> > ValueError("The Cairo backend can not draw paths
> longer than
> > 18980 points.")
> > > 
> > > This was needed in the past when cairo version
> 1.4.10
> > / pycairo version 1.4.0 would segfault:
> > > 
> > > http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu
> > > 
> > > However, we're now at cairo, pycairo version
> 1.8.8,
> > and I haven't seen any segfaults after removing this
> check.
> > > 
> > 
> > Is path simplification in effect?  If so, have you
> > tested after turning simplification off, so that you
> can be
> > sure how many points cairo is trying to plot?
> > 
> > Eric
> > 
> > 
> > > Does anybody object if I remove this check from
> the
> > code?
> > > 
> > > --Michiel.
> > > 
> > > 
> > > 
> > >       
> > >
> >
> ------------------------------------------------------------------------------
> > > 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
> > 
> > 
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> 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
> 


      

If that may help the discussion, here are two links related to works I did on Python/OpenGL/scientific visualization and matplotlib:

glumpy: http://code.google.com/p/glumpy/
scigl: http://www.loria.fr/~rougier/coding/scigl/index.html

I also tried to write an OpenGL matplolib backend but it was not very convincing in terms of speed. This was the reason why I headed for glumpy. I think OpenGL may be a good framework for realtime visualization but is far from ideal to have paper quality output like the Agg backend. However, there exist a GL2PS (or pdf, svg, etc) library that may offer a very good compromise. Furthemore, there is no native way to display text even if FTGL is relatively widespread now.

Concerning threading and OpenGL, it might be a bit more complex than other backends since (from what I've understood), OpenGL requires to be in the main thread, this means no OpenGL call from other threads. I managed to implement an interactive console in glumpy using the GLUT system, and had some good experience with GTK as well but I don't know how it may work with qt or wx for example.



Nicolas




On Feb 26, 2010, at 05:16 , Jonathan Taylor wrote:

> Hi,
> 
> I cannot answer your questions specifically but perhaps I can provide some insight.  My current understanding is that most of mplot3d is a bit of a hack.  I say this because I use it daily and I was the one who hacked it into a half working state out of necessity after it was originally fell out repair.  Reiner finished the job in terms of returning it to its original usability.
> 
> Unfortunately, it still has many warts.  Part of the problem is that matplotlib continues to evolve and add features that we have not added to mplot3d.  I think that part of the reason this is happening is because it is not easily apparent what works and what does not.  Indeed, the classes in mplot3d such as axes3d, axis3d, etc inherit from the mainline 2d classes axes, axis, etc.  Thus it appears that methods have been implemented simply because the 3d objects have inherited them.  This just gets worse as the 2d classes add more features.  This causes a lot of frustration for users as sometimes these methods work by fluke and sometimes don't.  Even worse is that it is possible for an addition to some 2D code to call a method that has not been masked in the 3D object causing a breakage.
> 
> The reason this happened in the first place is that the original author realized that a lot of the 2d code could be reused to render a 2d view of the 3d space.  I think that this reuse is a good idea but I think it would be much better if this was done more explicitly instead of using inheritance.  In particular, I think that Axes3D should not inherit from Axes and simply contain an Axes object stored in self.axes.  Then each method that is actually supported can be explicitly written and appropriately proxied to self.axes.method.
> 
> I have been thinking about trying to do a rewrite as I describe above for some time.  I think that this would not only make it easier for users but would make a much clearer code base in which it was more obvious how someone could contribute.  Alas, I have not found the time to do this, but perhaps in a month. ;)
> 
> The other issue is that of speed.  In the longer term, that can be addressed more easily.  It will be a lot more work and more complicated but I am guessing that what needs to be done is a complete rewrite in something like OpenGL.  That said, I am not sure how well this would work and if there are complications with ipython and threading, etc.  I would be interested to know what people think about this.
> 
> I realize that I did not answer your questions except to provide some insight as to why mplot3d behaves oddly sometimes.  Sorry ;)
> 
> Best,
> Jonathan.
> 
> 
> On Thu, Feb 25, 2010 at 12:14 PM, Ben Axelrod <BAx...@co...> wrote:
> Hi Reinier,
>  
> Here are a number of issues in mplot3d that I would really like fixed, but can't quite figure out.  I would very much appreciate some feedback from you on these.  (Where to start, what might be the cause, how hard is the fix...)
>  
>  * Global 3d object sorting.  Not just for polygons, but all 3d objects like lines, and text as well.  These objects have z values after all, so should be able to be placed in some sort of global z buffer. 
>  
>  * When I implement 'picking' for bar3d plots, how can I know which bar was picked?  In the picker callback, the event.artist is a Poly3DCollection object.  I can call event.artist.get_paths() to get all the polygon paths, and determine which one the mouse click was in.  But this data does not have any 'z' data.  So, this will find 2 faces for the box you clicked.  (You may get many more results from other boxes as well).  And even with this data, I am unable to determine which box the path corresponds to.  I can think of a few solutions:
>   - Store some kind of data in Poly3DCollection corresponding to all path polygons, *with* the real world data so they can be matched up.  (maybe this is already the case?)
>   - make some kind of Bar3DPath class that inherits from Path which contains an extra data field to store the index of the bar the path belongs to. It should probably also store the real world coordinates and the screen z value as well.
>  - override some pick event method and do this logic in the mplot3d code so that the user's picker callback can simply use event.ind to get the bar index that was picked. just like the pick event for scatter().
>  
>  * picking does not seem to work for the 3D axis labels.  The normal 'picker=True' parameter of set_xlabel(), set_ylabel() , and set_zlabel() does not seem to make the axis label pickable. Other 2d and 3d text on the plot is pickable however. It may be possible that the Axis3D object does not add the label to the Axes3D's list of artists. Which means it doesn't get searched for and found in Axes.__pick().
>  
>  * Is it possible to make 3d bars with transparent faces, so that they appear wireframe?  I am pretty sure that patches support this, but I think the fancy face coloring bar3d does overrides the 'none' color specification.
>  
> * How can I set axis tick label properties for 3D axes?  This code does not work on Axes3D, but it works for normal 2D axes: setp(ax.get_xticklabels(), color='r').  Furthermore, there is no such ax.get_zticklabels().  Is there another way that this must be done?  How can we support the setp(ax.get_zticklabels(), color='r') paradigm?
>  
> Thanks!
> -Ben
>  
>  
> Ben Axelrod
> Robotics Engineer
> (800) 641-2676 x737
> 
> www.coroware.com
> www.corobot.net
>  
> 
> ------------------------------------------------------------------------------
> 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
> 
> 
> ------------------------------------------------------------------------------
> 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

Ben.

Sorry I did not see the other posts surrounding mplot3d or your patch.  I am
very excited to have that though.  Thank you.

My opinion about a redesign still stands though.

Jon.

On Thu, Feb 25, 2010 at 11:16 PM, Jonathan Taylor <jt...@cs...>wrote:

> Hi,
>
> I cannot answer your questions specifically but perhaps I can provide some
> insight.  My current understanding is that most of mplot3d is a bit of a
> hack.  I say this because I use it daily and I was the one who hacked it
> into a half working state out of necessity after it was originally fell out
> repair.  Reiner finished the job in terms of returning it to its original
> usability.
>
> Unfortunately, it still has many warts.  Part of the problem is that
> matplotlib continues to evolve and add features that we have not added to
> mplot3d.  I think that part of the reason this is happening is because it is
> not easily apparent what works and what does not.  Indeed, the classes in
> mplot3d such as axes3d, axis3d, etc inherit from the mainline 2d classes
> axes, axis, etc.  Thus it appears that methods have been implemented simply
> because the 3d objects have inherited them.  This just gets worse as the 2d
> classes add more features.  This causes a lot of frustration for users as
> sometimes these methods work by fluke and sometimes don't.  Even worse is
> that it is possible for an addition to some 2D code to call a method that
> has not been masked in the 3D object causing a breakage.
>
> The reason this happened in the first place is that the original author
> realized that a lot of the 2d code could be reused to render a 2d view of
> the 3d space.  I think that this reuse is a good idea but I think it would
> be much better if this was done more explicitly instead of using
> inheritance.  In particular, I think that Axes3D should not inherit from
> Axes and simply contain an Axes object stored in self.axes.  Then each
> method that is actually supported can be explicitly written and
> appropriately proxied to self.axes.method.
>
> I have been thinking about trying to do a rewrite as I describe above for
> some time.  I think that this would not only make it easier for users but
> would make a much clearer code base in which it was more obvious how someone
> could contribute.  Alas, I have not found the time to do this, but perhaps
> in a month. ;)
>
> The other issue is that of speed.  In the longer term, that can be
> addressed more easily.  It will be a lot more work and more complicated but
> I am guessing that what needs to be done is a complete rewrite in something
> like OpenGL.  That said, I am not sure how well this would work and if there
> are complications with ipython and threading, etc.  I would be interested to
> know what people think about this.
>
> I realize that I did not answer your questions except to provide some
> insight as to why mplot3d behaves oddly sometimes.  Sorry ;)
>
> Best,
> Jonathan.
>
>
> On Thu, Feb 25, 2010 at 12:14 PM, Ben Axelrod <BAx...@co...>wrote:
>
>>  Hi Reinier,
>>
>> Here are a number of issues in mplot3d that I would really like fixed, but
>> can't quite figure out.  I would very much appreciate some feedback from you
>> on these.  (Where to start, what might be the cause, how hard is the fix...)
>>
>>  * Global 3d object sorting.  Not just for polygons, but all 3d objects
>> like lines, and text as well.  These objects have z values after all, so
>> should be able to be placed in some sort of global z buffer.
>>
>>  * When I implement 'picking' for bar3d plots, how can I know which bar
>> was picked?  In the picker callback, the event.artist is a Poly3DCollection
>> object.  I can call event.artist.get_paths() to get all the polygon paths,
>> and determine which one the mouse click was in.  But this data does not have
>> any 'z' data.  So, this will find 2 faces for the box you clicked.  (You may
>> get many more results from other boxes as well).  And even with this data, I
>> am unable to determine which box the path corresponds to.  I can think of a
>> few solutions:
>>   - Store some kind of data in Poly3DCollection corresponding to all path
>> polygons, *with* the real world data so they can be matched up.  (maybe this
>> is already the case?)
>>   - make some kind of Bar3DPath class that inherits from Path which
>> contains an extra data field to store the index of the bar the path belongs
>> to. It should probably also store the real world coordinates and the screen
>> z value as well.
>>  - override some pick event method and do this logic in the mplot3d code
>> so that the user's picker callback can simply use event.ind to get the bar
>> index that was picked. just like the pick event for scatter().
>>
>>  * picking does not seem to work for the 3D axis labels.  The normal
>> 'picker=True' parameter of set_xlabel(), set_ylabel() , and set_zlabel()
>> does not seem to make the axis label pickable. Other 2d and 3d text on the
>> plot is pickable however. It may be possible that the Axis3D object does not
>> add the label to the Axes3D's list of artists. Which means it doesn't get
>> searched for and found in Axes.__pick().
>>
>>  * Is it possible to make 3d bars with transparent faces, so that they
>> appear wireframe?  I am pretty sure that patches support this, but I think
>> the fancy face coloring bar3d does overrides the 'none' color specification.
>>
>> * How can I set axis tick label properties for 3D axes?  This code does
>> not work on Axes3D, but it works for normal 2D axes: setp(ax.get_xticklabels(),
>> color='r').  Furthermore, there is no such ax.get_zticklabels().  Is there
>> another way that this must be done?  How can we support the setp(ax.get_zticklabels(),
>> color='r') paradigm?
>>
>> Thanks!
>> -Ben
>>
>>
>> *Ben Axelrod*
>> Robotics Engineer
>> (800) 641-2676 x737
>>  www.coroware.com
>> www.corobot.net
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>

Hi,

I cannot answer your questions specifically but perhaps I can provide some
insight.  My current understanding is that most of mplot3d is a bit of a
hack.  I say this because I use it daily and I was the one who hacked it
into a half working state out of necessity after it was originally fell out
repair.  Reiner finished the job in terms of returning it to its original
usability.

Unfortunately, it still has many warts.  Part of the problem is that
matplotlib continues to evolve and add features that we have not added to
mplot3d.  I think that part of the reason this is happening is because it is
not easily apparent what works and what does not.  Indeed, the classes in
mplot3d such as axes3d, axis3d, etc inherit from the mainline 2d classes
axes, axis, etc.  Thus it appears that methods have been implemented simply
because the 3d objects have inherited them.  This just gets worse as the 2d
classes add more features.  This causes a lot of frustration for users as
sometimes these methods work by fluke and sometimes don't.  Even worse is
that it is possible for an addition to some 2D code to call a method that
has not been masked in the 3D object causing a breakage.

The reason this happened in the first place is that the original author
realized that a lot of the 2d code could be reused to render a 2d view of
the 3d space.  I think that this reuse is a good idea but I think it would
be much better if this was done more explicitly instead of using
inheritance.  In particular, I think that Axes3D should not inherit from
Axes and simply contain an Axes object stored in self.axes.  Then each
method that is actually supported can be explicitly written and
appropriately proxied to self.axes.method.

I have been thinking about trying to do a rewrite as I describe above for
some time.  I think that this would not only make it easier for users but
would make a much clearer code base in which it was more obvious how someone
could contribute.  Alas, I have not found the time to do this, but perhaps
in a month. ;)

The other issue is that of speed.  In the longer term, that can be addressed
more easily.  It will be a lot more work and more complicated but I am
guessing that what needs to be done is a complete rewrite in something like
OpenGL.  That said, I am not sure how well this would work and if there are
complications with ipython and threading, etc.  I would be interested to
know what people think about this.

I realize that I did not answer your questions except to provide some
insight as to why mplot3d behaves oddly sometimes.  Sorry ;)

Best,
Jonathan.


On Thu, Feb 25, 2010 at 12:14 PM, Ben Axelrod <BAx...@co...> wrote:

>  Hi Reinier,
>
> Here are a number of issues in mplot3d that I would really like fixed, but
> can't quite figure out.  I would very much appreciate some feedback from you
> on these.  (Where to start, what might be the cause, how hard is the fix...)
>
>  * Global 3d object sorting.  Not just for polygons, but all 3d objects
> like lines, and text as well.  These objects have z values after all, so
> should be able to be placed in some sort of global z buffer.
>
>  * When I implement 'picking' for bar3d plots, how can I know which bar was
> picked?  In the picker callback, the event.artist is a Poly3DCollection
> object.  I can call event.artist.get_paths() to get all the polygon paths,
> and determine which one the mouse click was in.  But this data does not have
> any 'z' data.  So, this will find 2 faces for the box you clicked.  (You may
> get many more results from other boxes as well).  And even with this data, I
> am unable to determine which box the path corresponds to.  I can think of a
> few solutions:
>   - Store some kind of data in Poly3DCollection corresponding to all path
> polygons, *with* the real world data so they can be matched up.  (maybe this
> is already the case?)
>   - make some kind of Bar3DPath class that inherits from Path which
> contains an extra data field to store the index of the bar the path belongs
> to. It should probably also store the real world coordinates and the screen
> z value as well.
>  - override some pick event method and do this logic in the mplot3d code so
> that the user's picker callback can simply use event.ind to get the bar
> index that was picked. just like the pick event for scatter().
>
>  * picking does not seem to work for the 3D axis labels.  The normal
> 'picker=True' parameter of set_xlabel(), set_ylabel() , and set_zlabel()
> does not seem to make the axis label pickable. Other 2d and 3d text on the
> plot is pickable however. It may be possible that the Axis3D object does not
> add the label to the Axes3D's list of artists. Which means it doesn't get
> searched for and found in Axes.__pick().
>
>  * Is it possible to make 3d bars with transparent faces, so that they
> appear wireframe?  I am pretty sure that patches support this, but I think
> the fancy face coloring bar3d does overrides the 'none' color specification.
>
> * How can I set axis tick label properties for 3D axes?  This code does
> not work on Axes3D, but it works for normal 2D axes: setp(ax.get_xticklabels(),
> color='r').  Furthermore, there is no such ax.get_zticklabels().  Is there
> another way that this must be done?  How can we support the setp(ax.get_zticklabels(),
> color='r') paradigm?
>
> Thanks!
> -Ben
>
>
> *Ben Axelrod*
> Robotics Engineer
> (800) 641-2676 x737
>  www.coroware.com
> www.corobot.net
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Hi Reinier,

I hope you had a nice holiday.

I am glad you like the patch and find it useful.  Applying it over the weekend is fine with me.

- You are right that the CuboidCollection is not that necessary.  In fact I used to have my histogram heuristic in the Poly3DCollection just as you describe.  But while running through the examples before submitting the patch, I found that it broke the surface plots.  So I refactored the code so that my changes only affected the bar3d plots, since this is the only thing I wrote code for and tested.  

My plan for the z-order sorting heuristic is to allow the user to choose the best one for his specific needs.  (This is only needed until we have a more general purpose 3D engine as being discussed in another thread.)  You can see that I split out the z-order sorting code into self-contained methods.  They don't reference any 'self' members, so these methods don't even need to be in the Poly3DCollection class.  It would be really nice if the user could pass in a function pointer for the heuristic parameter, in addition to 'average' and 'histogram'.  That way, users could even write their own specialized heuristic and not need to modify the mplot3d source.  

I wanted to create a standard set of data for the parameter of the sorting heuristic function.  You can see that _sort_polygons_avg() is the same algorithm as your original, except that I give the method, the x,y,z coords instead of just x and y.  There is a little extra work to strip out the z data, but it allows the more advanced histogram heuristic function to take the same data.  In fact, I have an idea for a slightly improved heuristic, but I would need to pass in the 'real world' XYZ coords, in addition to the 'screen' XYZ coords.  There is a note about this in the code comments of _sort_polygons_hist().  

I'd like to hear your thoughts on this.

- about the text() function, that is fine.

- about the #end comments, that is fine.  I'll try not to use them in the code anymore.

I have a number of other specific questions about mplot3d for you.  They will follow in another email.

Thanks,
-Ben


-----Original Message-----
From: Reinier Heeres [mailto:re...@he...] 
Sent: Wednesday, February 24, 2010 7:12 PM
To: Ben Axelrod
Cc: mat...@li...
Subject: Re: [matplotlib-devel] many mplot3d fixes

Hi Ben, all,

First of all: thanks for your patch. With a few minor modifications I think we should apply most of it. I had a quick look now, but let's aim to get it in over the weekend.

Let me also say that as far as I'm concerned, mplot3d is here to stay and I will try to continue to support it. However, some help for this would be greatly appreciated, and it seems you can find your way around the code just fine!

- I'm not entirely sure whether the CuboidCollection class you wrote is completely necessary, wouldn't it also be possible to use Poly3DCollection instances? (which should be correctly sorted). Then the only thing that would have to be added to Poly3DCollection is the histogram heuristic.

- For the text() function, I think we should probably pass all kwargs to Axes.text() instead of the explicit version you used.

- If you don't mind I'll remove the #endif etc comments, they appear nowhere in the codebase as far as I know.

Pleas let me know what you think!

Cheers,
Reinier

On Wed, Feb 24, 2010 at 7:39 PM, Ben Axelrod <BAx...@co...> wrote:
> Here is a major patch for mplot3d.  Here is a summary of the changes:
>
>  * bug fix: placement of title in 3D plots to match 2D plot behavior 
> (see nonecolortester.py to demonstrate)
>  * bug fix: allow facecolors and edgecolors to be specified as 'none' 
> in 3D scatter plots to match the 2D scatter plot behavior (see 
> nonecolortester.py to demonstrate)
>  * bug fix: allow all keyword arguments to be used in text3D (see 
> modified example code text3d_demo.py)
>  * bug fix: allow an array of colors to be passed into bar3d to 
> specify the colors on a per-bar or per-face basis (see new example 
> code hist3d_demo2.py)
>  * bug fix: allow all keyword arguments to be used in bar3d (see new 
> example code hist3d_demo2.py)
>  * bug fix: allow 3d scatter plots with 3 or 4 points with colors 
> specified (see colortester2.py to demonstrate)
>  * new feature: new method to disable mouse rotation in 3D plots
>  * new feature: allow mouse rotation and zoom buttons to be specified 
> by user
>  * new feature: new Z-order sorting heuristic to eliminate rendering 
> issues for the common case of using bar3d to visualize a 2D histogram 
> (see modified example code hist3d_demo.py)
>  * new feature: new method text2D (see modified example code 
> text3d_demo.py)
>  * code cleanup: warn when canvas is None which disables mouse 
> callbacks
>  * code cleanup: document more methods in mplot3d
>
> Thanks,
> -Ben
> ----------------------------------------------------------------------
> -------- 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
>
>



--
Reinier Heeres
Tel: +31 6 10852639

Hi Ben, all,

First of all: thanks for your patch. With a few minor modifications I
think we should apply most of it. I had a quick look now, but let's
aim to get it in over the weekend.

Let me also say that as far as I'm concerned, mplot3d is here to stay
and I will try to continue to support it. However, some help for this
would be greatly appreciated, and it seems you can find your way
around the code just fine!

- I'm not entirely sure whether the CuboidCollection class you wrote
is completely necessary, wouldn't it also be possible to use
Poly3DCollection instances? (which should be correctly sorted). Then
the only thing that would have to be added to Poly3DCollection is the
histogram heuristic.

- For the text() function, I think we should probably pass all kwargs
to Axes.text() instead of the explicit version you used.

- If you don't mind I'll remove the #endif etc comments, they appear
nowhere in the codebase as far as I know.

Pleas let me know what you think!

Cheers,
Reinier

On Wed, Feb 24, 2010 at 7:39 PM, Ben Axelrod <BAx...@co...> wrote:
> Here is a major patch for mplot3d.  Here is a summary of the changes:
>
>  * bug fix: placement of title in 3D plots to match 2D plot behavior (see nonecolortester.py to demonstrate)
>  * bug fix: allow facecolors and edgecolors to be specified as 'none' in 3D scatter plots to match the 2D scatter plot behavior (see nonecolortester.py to demonstrate)
>  * bug fix: allow all keyword arguments to be used in text3D (see modified example code text3d_demo.py)
>  * bug fix: allow an array of colors to be passed into bar3d to specify the colors on a per-bar or per-face basis (see new example code hist3d_demo2.py)
>  * bug fix: allow all keyword arguments to be used in bar3d (see new example code hist3d_demo2.py)
>  * bug fix: allow 3d scatter plots with 3 or 4 points with colors specified (see colortester2.py to demonstrate)
>  * new feature: new method to disable mouse rotation in 3D plots
>  * new feature: allow mouse rotation and zoom buttons to be specified by user
>  * new feature: new Z-order sorting heuristic to eliminate rendering issues for the common case of using bar3d to visualize a 2D histogram (see modified example code hist3d_demo.py)
>  * new feature: new method text2D (see modified example code text3d_demo.py)
>  * code cleanup: warn when canvas is None which disables mouse callbacks
>  * code cleanup: document more methods in mplot3d
>
> Thanks,
> -Ben
> ------------------------------------------------------------------------------
> 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
>
>



-- 
Reinier Heeres
Tel: +31 6 10852639

Ian Thomas wrote:
> Eric,
> 
>> I hit a bug (segfault) in cntr.c that is likely related to your changes. It
>> is ID 2956378 in the tracker.
> 
> Attached is a patch file with a fix for this bug.  I've also included
> a minimal test file to demonstrate the behaviour before and after the
> fix, along with a brief explanation which I can expand upon if you
> wish.
> 
> Ian

Ian,

Excellent!  Applied in svn 8152.  I also added your test case to the 
tracker and closed the bug. Thanks for the great work!

Eric

Here is a major patch for mplot3d.  Here is a summary of the changes:

 * bug fix: placement of title in 3D plots to match 2D plot behavior (see nonecolortester.py to demonstrate)
 * bug fix: allow facecolors and edgecolors to be specified as 'none' in 3D scatter plots to match the 2D scatter plot behavior (see nonecolortester.py to demonstrate)
 * bug fix: allow all keyword arguments to be used in text3D (see modified example code text3d_demo.py)
 * bug fix: allow an array of colors to be passed into bar3d to specify the colors on a per-bar or per-face basis (see new example code hist3d_demo2.py)
 * bug fix: allow all keyword arguments to be used in bar3d (see new example code hist3d_demo2.py)
 * bug fix: allow 3d scatter plots with 3 or 4 points with colors specified (see colortester2.py to demonstrate)
 * new feature: new method to disable mouse rotation in 3D plots
 * new feature: allow mouse rotation and zoom buttons to be specified by user
 * new feature: new Z-order sorting heuristic to eliminate rendering issues for the common case of using bar3d to visualize a 2D histogram (see modified example code hist3d_demo.py)
 * new feature: new method text2D (see modified example code text3d_demo.py)
 * code cleanup: warn when canvas is None which disables mouse callbacks
 * code cleanup: document more methods in mplot3d

Thanks,
-Ben

On Tue, Feb 23, 2010 at 10:14 PM, Fernando Perez <fpe...@gm...> wrote:

> Final question: should I put the little demo code at the bottom that I
> used for testing this up in an example file?  I put some of that in
> the docstring as an example, but not all to avoid clutter.

OK, since I know people are busy, I took silence as acquiescence.
Committed in r8151, please let me know if I messed anything up and
I'll try to fix it.  I'm used to the numpy docstring standard, but I
tried to adapt it to the mpl  one by looking at the rest of pyplot,
let me know if  it needs fine-tuning.

Cheers,

f

Eric,

> I hit a bug (segfault) in cntr.c that is likely related to your changes. It
> is ID 2956378 in the tracker.

Attached is a patch file with a fix for this bug.  I've also included
a minimal test file to demonstrate the behaviour before and after the
fix, along with a brief explanation which I can expand upon if you
wish.

Ian

On Sat, Feb 20, 2010 at 3:50 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>
> After quickly going through the mpl source (and in my experience), I
> think it is quite safe to assume that there is no master-slave
> relation among the shared axes.
>
>
>> One more, related question: is it possible/reasonable to share *both*
>> x and y axes?
>
> Yes, it is possible as I often do.

OK, thanks for the feedback. I've just finalized it here:

http://gfif.udea.edu.co/idf/indefero/www/index.php/p/mscomp-2010/source/tree/master/0217/figsubp.py

Knowing now that the sharing doesn't have an actual master/slave
relationship (like the existing examples suggest since they appear to
require an explicit index for sharing), the actual implementation was
really trivial in the end.  It might be a good idea to clarify this in
the main docs, the current examples make axis sharing look harder than
it actually is (all those tricks with order creation I was playing are
completely unnecessary).

If you all like this API, I'm happy to push into the real svn repo.

Final question: should I put the little demo code at the bottom that I
used for testing this up in an example file?  I put some of that in
the docstring as an example, but not all to avoid clutter.

Cheers,

f

==========================
SciPy 2010 Call for Papers
==========================

SciPy 2010, the 9th Python in Science Conference, will be held from
June 28th - July 3rd, 2010 in Austin, Texas.

At this conference, novel applications and breakthroughs made in the
pursuit of science using Python are presented.  Attended by leading
figures from both academia and industry, it is an excellent
opportunity to experience the cutting edge of scientific software
development.

The conference is preceded by two days of paid tutorials, during which
community experts provide training on several scientific Python
packages.

We invite you to take part by submitting a talk abstract on the
conference website at:

http://conference.scipy.org

Talk/Paper Submission
=====================

We solicit talks and accompanying papers (either formal academic or
magazine-style articles) that discuss topics regarding scientific
computing using Python, including applications, teaching, development
and research.  Papers are included in the peer-reviewed conference
proceedings, published online.

Please note that submissions primarily aimed at the promotion of a
commercial product or service will not be considered.

Important dates for authors include:

 * 11 April: Talk abstracts due
 * 20 April: Notification of acceptance
 * 13 June: Papers due
 * 15 August: Publication of proceedings

Further detail will be made available on http://conference.scipy.org

Conference Dates
================

 * Friday, 10 May: Early registration ends
 * Monday-Tuesday, 28-29 June: Tutorials
 * Wednesday-Thursday, June 30-July 1: Conference
 * Friday-Saturday, July 2-3: Coding Sprints

Executive Committee
===================

 * Conference: Jarrod Millman & Eric Jones
 * Program: Stefan van der Walt & Ondrej Certik
 * Student Sponsorship: Travis Oliphant

For more information on Python, visit http://www.python.org.

On Tue, Feb 23, 2010 at 10:22 AM, Ben Axelrod <BAx...@co...> wrote:
> Here is a patch for a new feature for the rectangle selector.  it allows the user to specify which mouse button or buttons to use for the rectangle selection.  Also included in the diff is a one line change to the rectangle_selector example code to demonstrate the use of the feature.

Thanks, committed this.  Renamed "useBtn" to simply "button".

JDH

Here is a patch for a new feature for the rectangle selector.  it allows the user to specify which mouse button or buttons to use for the rectangle selection.  Also included in the diff is a one line change to the rectangle_selector example code to demonstrate the use of the feature.  

Thanks,
-Ben

Yes I tried without path simplification, and I don't get any crashes. If we need to support older versions of cairo / pycairo, I suggest that we have the path length check after checking the version of cairo / pycairo, and that we perform the path length check after path simplification, so we know how many points will actually be drawn.

--Michiel.

--- On Mon, 2/22/10, Eric Firing <ef...@ha...> wrote:

> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] Path length in the cairo backend
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li...
> Date: Monday, February 22, 2010, 1:00 PM
> Michiel de Hoon wrote:
> > Dear all,
> > 
> > The draw_path method in backend_cairo.py starts with a
> check for the number of vertices in the path, and raises an
> error if the path contains more than 18980 vertices:
> > 
> >      def draw_path(self, gc, path,
> transform, rgbFace=None):
> >          if
> len(path.vertices) > 18980:
> >              raise
> ValueError("The Cairo backend can not draw paths longer than
> 18980 points.")
> > 
> > This was needed in the past when cairo version 1.4.10
> / pycairo version 1.4.0 would segfault:
> > 
> > http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu
> > 
> > However, we're now at cairo, pycairo version 1.8.8,
> and I haven't seen any segfaults after removing this check.
> > 
> 
> Is path simplification in effect?  If so, have you
> tested after turning simplification off, so that you can be
> sure how many points cairo is trying to plot?
> 
> Eric
> 
> 
> > Does anybody object if I remove this check from the
> code?
> > 
> > --Michiel.
> > 
> > 
> > 
> >       
> >
> ------------------------------------------------------------------------------
> > 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
> 
> 


      

sweet!

John Hunter wrote:
> On Mon, Feb 22, 2010 at 11:00 AM, Tom Holroyd (NIH/NIMH) [E]
> <hol...@ma...> wrote:
>> ok, this is how i do it
>> pro'ly could make this better
> 
> python -c "import pylab; pylab.plotfile('temp.dat', cols=(0,2),
> delimiter=' '); pylab.show()"
> 
> 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

-- 
Dr. Tom
---
I would dance and be merry,
Life would be a ding-a-derry,
If I only had a brain.
        -- The Scarecrow

On Mon, Feb 22, 2010 at 11:00 AM, Tom Holroyd (NIH/NIMH) [E]
<hol...@ma...> wrote:
> ok, this is how i do it
> pro'ly could make this better

python -c "import pylab; pylab.plotfile('temp.dat', cols=(0,2),
delimiter=' '); pylab.show()"

JDH

Michiel de Hoon wrote:
> Dear all,
> 
> The draw_path method in backend_cairo.py starts with a check for the number of vertices in the path, and raises an error if the path contains more than 18980 vertices:
> 
>      def draw_path(self, gc, path, transform, rgbFace=None):
>          if len(path.vertices) > 18980:
>              raise ValueError("The Cairo backend can not draw paths longer than 18980 points.")
> 
> This was needed in the past when cairo version 1.4.10 / pycairo version 1.4.0 would segfault:
> 
> http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu
> 
> However, we're now at cairo, pycairo version 1.8.8, and I haven't seen any segfaults after removing this check.
> 

Is path simplification in effect?  If so, have you tested after turning 
simplification off, so that you can be sure how many points cairo is 
trying to plot?

Eric


> Does anybody object if I remove this check from the code?
> 
> --Michiel.
> 
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> 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

Sorry -- I meant remove the check for cairo >= 1.8.

Michael Droettboom wrote:
> Can you write it in such a way that the check is only removed on cairo < 
> 1.8?  My employer is still standardized on RHEL4, for example, which has 
> cairo 1.2.
>
> Mike
>
> Michiel de Hoon wrote:
>   
>> Dear all,
>>
>> The draw_path method in backend_cairo.py starts with a check for the number of vertices in the path, and raises an error if the path contains more than 18980 vertices:
>>
>>      def draw_path(self, gc, path, transform, rgbFace=None):
>>          if len(path.vertices) > 18980:
>>              raise ValueError("The Cairo backend can not draw paths longer than 18980 points.")
>>
>> This was needed in the past when cairo version 1.4.10 / pycairo version 1.4.0 would segfault:
>>
>> http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu
>>
>> However, we're now at cairo, pycairo version 1.8.8, and I haven't seen any segfaults after removing this check.
>>
>> Does anybody object if I remove this check from the code?
>>
>> --Michiel.
>>
>>
>>
>>       
>>
>> ------------------------------------------------------------------------------
>> 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
>>   
>>     
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

ok, this is how i do it
pro'ly could make this better

./plot file.dat

just does the first two columns

needs smarts

Tom Holroyd wrote:
> here's the old way
> 
> 	cut and paste some numbers from a web page
> 	like the number of live births by year
> 	dump it in a file named moo
> 	run gnuplot
> 	and say
> 
> 		plot '/tmp/moo' w l 3
> 
> 	boom
> 	default graph to show friends
> 
> the thing is
> in the new way [python import pylab plot show]
> what's the best default graph
> i wanna say what?
> ipython -c 'readplotfile blah ... parse file ugh ...'
> um
> 
> i need a one liner
> ya know
> 
> find the baby boom
> 
> 1910    2777000       30.1
> 1915    2965000       29.5
> 1920    2950000       27.7
> 1925    2909000       25.1
> 1930    2618000       21.3
> 1935    2377000       18.7
> 1940    2559000       19.4
> 1945    2858000       20.4
> 1950    3632000       24.1
> 1952   3913000       25.1
> 1953   3965000       25.1
> 1954   4078000       25.3
> 1955    4104000       25.0
> 1956   4218000       25.2
> 1957   4308000       25.3
> 1958   4255000       24.5
> 1959   4295000       24.3
> 1960   4257850       23.7
> 1961   4268326       23.3
> 1962   4167362       22.4
> 1963   4098020       21.7
> 1964   4027490       21.0
> 1965   3760358       19.4
> 1966   3606274       18.4
> 1967   3520959       17.8
> 1968   3501564       17.5
> 1969   3600206       17.8
> 1970   3731386       18.4
> 1971   3555970       17.2
> 1972    3258411       15.6
> 1973    3136965       14.9
> 1974    3159958       14.9
> 1975    3144198       14.8
> 1976    3167788       14.8
> 1977    3326632       15.4
> 1978    3333279       15.3
> 1979    3494398       15.9
> 1980    3612258       15.9
> 1982    3680537       15.9
> 1983    3638933       15.5
> 1984    3669141       15.5
> 1985    3760561       15.8
> 1986    3731000       15.5
> 1987    3829000       15.7
> 1988    3913000       15.9
> 1989    4021000       16.2
> 1990    4179000       16.7
> 1991    4111000       16.2
> 1992    4084000       16.0
> 1993    4039000       15.7
> 1994    3979000       15.3
> 1995    3892000       14.8
> 1996    3899000       14.7
> 1997    3882000       14.5
> 1998    3941553       14.6
> 1999    3959417       14.5
> 2000    4058814       14.7
> 2001    4025933       14.1
> 2002    4021726       13.9
> 2003    4089950       14.1
> 2004    4112052       14.0
> 2005    4138349       14.0
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

-- 
Dr. Tom
---
I would dance and be merry,
Life would be a ding-a-derry,
If I only had a brain.
        -- The Scarecrow

Can you write it in such a way that the check is only removed on cairo < 
1.8?  My employer is still standardized on RHEL4, for example, which has 
cairo 1.2.

Mike

Michiel de Hoon wrote:
> Dear all,
>
> The draw_path method in backend_cairo.py starts with a check for the number of vertices in the path, and raises an error if the path contains more than 18980 vertices:
>
>      def draw_path(self, gc, path, transform, rgbFace=None):
>          if len(path.vertices) > 18980:
>              raise ValueError("The Cairo backend can not draw paths longer than 18980 points.")
>
> This was needed in the past when cairo version 1.4.10 / pycairo version 1.4.0 would segfault:
>
> http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu
>
> However, we're now at cairo, pycairo version 1.8.8, and I haven't seen any segfaults after removing this check.
>
> Does anybody object if I remove this check from the code?
>
> --Michiel.
>
>
>
>       
>
> ------------------------------------------------------------------------------
> 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
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric,

It appears to be caused by an infinite loop, and may well be due to my
changes.  I'll take a look on Wednesday and get back to you.

Ian


On 22 February 2010 01:07, Eric Firing <ef...@ha...> wrote:
> Ian,
>
> I hit a bug (segfault) in cntr.c that is likely related to your changes. It
> is ID 2956378 in the tracker.  Sample script and data file are there.  Will
> you be able to take a look soon?
>
> (Not sure whether the following link will work for you.)
> https://sourceforge.net/tracker/?func=detail&aid=2956378&group_id=80706&atid=560720
>
> Thanks.
>
> Eric
>

Ian,

I hit a bug (segfault) in cntr.c that is likely related to your changes. 
It is ID 2956378 in the tracker.  Sample script and data file are there. 
  Will you be able to take a look soon?

(Not sure whether the following link will work for you.)
https://sourceforge.net/tracker/?func=detail&aid=2956378&group_id=80706&atid=560720

Thanks.

Eric

John Hunter wrote:
> Andrew, the failure is on the font cache again -- is this the race
> condition you've mentioned in the past?
>
> matplotlib.tests.test_mathtext.test_mathtext_stixsans ... ok
> Failure: IOError ([Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache') ... ERROR
>
> "/home/mpl-chslave/slave-py24/build_test_py24/build/PYmpl/lib/python2.4/site-packages/matplotlib/font_manager.py",
> line 942, in pickle_dump
>     fh = open(filename, 'w')
> IOError: [Errno 2] No such file or directory:
> '/home/mpl-chslave/.matplotlib/fontList.cache'

John, yes, this is the multiprocess race condition. I don't think the
issue is buildbot specific, but I can see that the use case may be rare
in which one process deletes the MPL directory after another had already
determined it is present. Nevertheless, I think it's something that
could happen in other circumstances, and I'm not sure the fontlist cache
file itself is multiprocess safe (I'm not saying it isn't -- I haven't
looked).

It does appear that a locking based solution is possible in a
cross-platform way, as sqlite says they do it in "Can multiple
applications or multiple instances of the same application access a
single database file at the same time?" at http://www.sqlite.org/faq.html .

I could put the builds in different user accounts so that the buildbot
wouldn't unintentionally continue to be hit with this bug. We could also
make a test case that starts multiple processes simultaneously using
subprocess to exercise the bug and mark it as known failing -- that way
we at least don't forget that it's an issue.

All that being said -- I don't mind the occasional buildbot failure
message -- it tells me that the buildbot is running and testing stuff.
One can always quickly re-fire the failed test manually from the
buildbot webpage to determine if this was the problem.

-Andrew