from:"Phil Elson"

Re: [matplotlib-devel] figure error during python shutdown

2011-05-08 Thread Phil Elson



Michael Droettboom-3 wrote:
> 
> There is a fix in this pull request.
> 
> https://github.com/matplotlib/matplotlib/pull/106
> 
> Can you confirm it works for you?
> 

For me that only moved the problem further a little, I got the error:

AttributeError: FigureManagerGTKAgg instance has no attribute 'toolbar'

Which was solved by changing the line after your fix to be: 

if hasattr(self, 'toolbar') and self.toolbar:

This then seems to run fine.
-- 
View this message in context: 
http://old.nabble.com/figure-error-during-python-shutdown-tp31554255p31565516.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] plt.plot projection kwarg

2011-06-04 Thread Phil Elson


The first line of code on the page
http://matplotlib.sourceforge.net/devel/add_new_projection.html suggests
that it is possible to give the projection directly to mpl.pyplot.plot but
this does not work for me.

Should this functionality exist? I am aware that the pyplot.plot function is
autogenerated by boilerplate.py, but I am a little weary of modifying that.

Any help gratefully received.
-- 
View this message in context: 
http://old.nabble.com/plt.plot-projection-kwarg-tp31772544p31772544.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plt.plot projection kwarg

2011-06-04 Thread Phil Elson


> I think the only case where this would work correctly is if the plot command 
> would also trigger the creation of a new axes object. 
Can't see how this can ever happen given the pyplot.plot code, which creates a 
standard axes without passing through any arguments.

I agree that there are situations when it doesn't make sense to define the 
projection when doing a plt.plot, maybe best to fix the projections 
documentation instead of providing a keyword which is not always valid. Either 
that, or plt.plot with a projection always makes a new axes?

Attempting to pass the projection currently to plot results in an exception:

plt>>> plt.plot(range(10), projection='polar')
...
TypeError: There is no line property "projection"

  --
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Initialising projections in matplotlib

2011-09-15 Thread Phil Elson


Hi, 

I would like the ability to setup a plot projection in MPL that can be defined 
by various parameters and does not need to be serialised as a string and 
registered with matplotlib.projections.register_projection.  For example, an 
extension of /examples/api/custom_projection_example.py might be to add the 
ability to define the central meridian to an arbitrary value rather than the 
current value of 0 - in this case I would expect to define the projection by 
creating an object which can then be turned into a matplotlib axes:

hammer_proj = Hammer(central_meridian=45)
ax = plt.subplot(111, projection=hammer_proj)

I have made a change to matplotlib which would enable this capability, which 
can be found at 
https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e499
 . Any feedback and thoughts would be really appreciated with the ultimate goal 
of getting this functionality into MPL.

Many Thanks,

Philip
  --
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Initialising projections in matplotlib

2011-09-15 Thread Phil Elson

Sorry, that link was bad, it should have read:

https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e4

To: [email protected]
Date: Thu, 15 Sep 2011 18:19:49 +
Subject: [matplotlib-devel] Initialising projections in matplotlib

Hi, 

I would like the ability to setup a plot projection in MPL that can be defined 
by various parameters and does not need to be serialised as a string and 
registered with matplotlib.projections.register_projection.  For example, an 
extension of /examples/api/custom_projection_example.py might be to add the 
ability to define the central meridian to an arbitrary value rather than the 
current value of 0 - in this case I would expect to define the projection by 
creating an object which can then be turned into a matplotlib axes:

hammer_proj = Hammer(central_meridian=45)
ax = plt.subplot(111, projection=hammer_proj)

I have made a change to matplotlib which would enable this capability, which 
can be found at 
https://github.com/PhilipElson/matplotlib/commit/9c7b1b27d0245a752d010bd03ae66dc6c000d8e499
 . Any feedback and thoughts would be really appreciated with the ultimate goal 
of getting this functionality into MPL.

Many Thanks,

Philip

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel   
  --
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Initialising projections in matplotlib

2011-09-16 Thread Phil Elson






>> As a bit of a selfish interest, I think your approach might open up a 
>> possible approach for a long-standing problem 
>> of mine with 3d projections.  Axes3D objects >> want to fill its entire plot 
>> box, but when created through a subplot
>> mechanism, the defaults get over-ridden.  I wonder if this approach with 
>> _init_axes() passing kwargs might 
>> provide me with the hook to fix this.



Yes, having the _init_axes method makes subclassing then initialising an Axes 
much easier, and avoids the need to make an intermediate class for each Axes 
construction.

>> Hmm, interesting idea.  I took a quick look through the code, 
and it touches on some fragile parts of axes.py, so I wouldn't be

>> comfortable with this being in v1.1.0, but I think it is definitely worthy 
>> of further investigation.




I was wondering if you see axes.py changing significantly in the near future?  
If not then it would seem a shame to hold back this relatively small change for 
something not yet in the pipeline.  
Perhaps you could elaborate on what you feel to be the more fragile aspects and 
we could start to look to resolve these as a seperate development activity?

Thanks again,

  --
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Caching the results of Transform.transform_path for non-affine transforms

2012-02-03 Thread Phil Elson

I'm trying to understand how the TransformedPath mechanism is working
with only limited success, and was hoping someone could help.

I have a non-affine transformation defined (subclass of
matplotlib.transforms.Transform) which takes a path and applies an
intensive transformation (path curving & cutting) which can take a
little while, but am able to guarantee that this transformation is a
one off and will never change for this transform instance, therefore
there are obvious caching opportunities.
I am aware that TransformedPath is doing some caching and would really
like to hook into this rather than rolling my own caching mechanism
but can't q
uite figure out (the probably obvious!) way to do it.

To see this problem for yourself I have attached a dummy example of
what I am working on:


import matplotlib.transforms


class SlowNonAffineTransform(matplotlib.transforms.Transform):
input_dims = 2
output_dims = 2
is_separable = False
has_inverse = True

def transform(self, points):
return matplotlib.transforms.IdentityTransform().transform(points)

def transform_path(self, path):
# pretends that it is doing something clever & time consuming,
but really is just sleeping
import time
# take a long time to do something
time.sleep(3)
# return the original path
return matplotlib.transforms.IdentityTransform().transform_path(path)


if __name__ == '__main__':
import matplotlib.pyplot as plt

ax = plt.axes()
ax.plot([0, 10, 20], [1, 3, 2], transform=SlowNonAffineTransform()
+ ax.transData)
plt.show()


When this code is run the initial "show" is slow, which is fine, but a
simple resize/zoom rect/pan/zoom will also take a long time.
How can I tell mpl that I can guarantee that my level of the transform
stack is never invalidated?

Many Thanks,

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Non string projections

2012-02-03 Thread Phil Elson

Some time back I asked about initialising a projection in MPL using generic
objects rather than by class name. I created a pull request associated with
this which was responded to fantastically by leejjoon which (after several
months) I have finally got around to implementing. My changes have been added
to the original pull request, which will eventually be obsoleted, but that
doesn't seem to have notified the devel mailing list, therefore I would like
to draw the list's attention to
https://github.com/matplotlib/matplotlib/pull/470#issuecomment-3743543 on
which I would greatly appreciate feedback & ultimately get onto the mpl master.

The pull request in question would pave the way for non string projections so
I thought I would play with how one might go about specifying the location of
theta_0 in a polar plot (i.e. should it be due east or due north etc.). I have
branched my changeset mentioned in the pull request above and implemented
a couple of ideas, although I am not proposing that these changes go any
further at this stage (I would be happy if someone wants to run with
them though):

Currently, one can set the theta_0 of a polar plot with:

ax = plt.axes(projection='polar')
ax.set_theta_offset(np.pi/2)
ax.plot(np.arange(100)*0.15, np.arange(100))

But internally there are some nasties going on (theta_0 is an attribute on the
axes, the transform is instantiated from within the axes and is given the axes
that is instantiating it, which is all a bit circular). I have made a branch
(https://github.com/PhilipElson/matplotlib/compare/master...polar_fun) which
alleviates the axes attribute issue and would allow something like:

polar_trans = mpl.transforms.Polar.PolarTransform(theta_offset=np.pi/2)
ax = plt.axes(projection=polar_trans)
ax.plot(np.arange(100)*0.15, np.arange(100))

Or, I have added a helper class which also demonstrates the proposed:

non-string change:
ax = plt.axes(projection=Polar(theta0=90))
ax.plot(np.arange(100)*0.15, np.arange(100))

As I said, I am not proposing these changes to the way Polar works at this
stage, but thought it was worth sharing to show what can be done once
something similar to the proposed change gets on to mpl master.

Hope that makes sense.

Many Thanks,

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Non string projections

2012-02-04 Thread Phil Elson

Thanks Mike.

> I'm not quite sure what the above lines are meant to do.
> matplotlib.transforms doesn't have a Polar member --
> matplotlib.projections.polar.Polar does not have a PolarTransform member
> (on master or your polar_fun branch).  Even given that, I think the user
> should be specifying a projection, not a transformation, to create a new
> axes.  There is potential for confusion that some transformations will
> allow getting a projection out and some won't (for some it doesn't even
> really make sense).

That was meant to be
matplotlib.projections.polar.PolarAxes.PolarTransform but your right,
defining the "projection" in the transform could lead to confusion,
yet initialising an Axes as a projection seems like unnecessary
complexity. This suggests that defining a "projection" class which is
neither Transform nor Axes might make the most sense (note, what
follows is pseudo code and does not exist in the branch):

>>> polar_proj = Polar(theta0=np.pi/2)
>>> ax = plt.axes(projection=polar_proj)
>>> print ax.projection
Polar(theta0=1.57)

The PolarAxes would be initialised with the Projection instance, and
the PolarAxes can initialise the PolarTransform with a reference to
that projection. Thus changing the theta0 of the projection in the
Axes would also change the projection which is used in the Transform
instance, i.e.:

ax.projection.theta0 = 3*np.pi/2

Would change the way that the overall axes looked.

Interestingly, the work that I have been doing which requires the
aforementioned pull request is doing precisely this - I have
projection classes, one for each type of projection, but where each
type of projection is parameterised, which, when passed through
plt.axes(projection=) instantiate a generic
"GenericProjectionAxes", which itself instantiates a generic
"GenericProjectionTransform" (names for illustration purposes only)
all the while the original projection is mutable via the
MultiProjectionAxes.projection attribute.

Did you have any feelings on the pull request?

Thanks again for your time,

Phil

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Image transforms

2012-02-10 Thread Phil Elson

In much the same way Basemap can take an image in a Plate Carree map
projection (e.g. blue marble) and transform it onto another projection
in a non-affine way, I would like to be able to apply a non-affine
transformation to an image, only using the proper matplotlib Transform
framework.
To me, this means that I should not have to pre-compute the projected
image before adding it to the axes, instead I should be able to pass
the source image and the Transformation stack should take care of
transforming (warping) it for me (just like I can with a Path).

As far as I can tell, there is no current matplotlib functionality to
do this (as I understand it, some backends can cope with affine image
transformations, but this has not been plumbed-in in the same style as
the Transform of paths and is done in the Image classes themselves).
(note: I am aware that there is some code to do affine transforms in
certain backends -
http://matplotlib.sourceforge.net/examples/api/demo_affine_image.html
- which is currently broken [I have a fix for this], but it doesn't
fit into the Transform framework at present.)

I have code which will do the actual warping for my particular case,
and all I need to do is hook it in nicely...

I was thinking of adding a method to the Transform class which
implements this functionality, psuedo code stubs are included:


class Transform:
...
   def transform_image(self, image):
   return 
self.transform_image_affine(self.transform_image_non_affine(image))

   def transform_image_non_affine(self, image):
   if not self.is_affine:
   raise NotImplementedError('This is the hard part.')
   return image
   ...
   def transform_image_affine(self, image):
# could easily handle scale & translations (by changing the
extent), but not rotations...
raise NotImplementedError("Need to do this. But rule out
rotations completely.")


This could then be used by the Image artist to do something like:

class Image(Artist, ...):
...
def draw(self, renderer, *args, **kwargs):
transform = self.get_transform()
timg = transform.transform_image_non_affine(self)
affine = transform.get_affine()
...
renderer.draw_image(timg, ..., affine)


And the backends could implement:

class Renderer*...
def draw_image(..., img, ..., transform=None):
# transform must be an affine transform
if transform.is_affine and i_can_handle_affines:
   ... # convert the Transform into the backend's transform form
else:
   timage = transform.transform_image(img)



The warping mechanism itself would be fairly simple, in that it
assigns coordinate values to each pixel in the source cs (coordinate
system), transforms those points into the target cs, from which a
bounding box can be identified. The bbox is then treated as the bbox
of the target (warped) image, which is given an arbitrary resolution.
Finally the target image pixel coordinates are computed and their
associated pixel values are calculated by interpolating from the
source image (using target cs pixel values).


As mentioned, I have written the image warping code (for my higher
dimensional coordinate system case using
scipy.interpolate.NearestNDInterpolator) successfully already, so the
main motivations for this mail then, are:
 * To get a feel for whether anyone else would find this functionality
useful? Where else can it be used and in what ways?
 * To get feedback on the proposed change to the Transform class,
whether such a change would be acceptable and what pitfalls lie ahead.
 * To hear alternative approaches to solving the same problem.
 * To make sure I haven't missed a concept that already exists in the
Image module (there are 6 different "image" classes in there, 4 of
which undocumented)
 * To find out if anyone else wants to collaborate in making the
required change.

Thanks in advance for your time,

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Caching the results of Transform.transform_path for non-affine transforms

2012-02-17 Thread Phil Elson

I think this feature was originally intended to work (since
TransformedPath exists)
but it wasn't working [in the way that I was expecting it to].
I made a change which now only invalidates non-affine transformations
if it is really
necessary. This change required a modification to the way
invalidation was passed through the transform stack, since certain transform
subclasses need to override the mechanism. I will try to explain the reason why
this is the case:


Suppose a TransformNode is told that it can no longer store the affine
transformed
path by its child node, then it must pass this message up to its parent nodes,
until eventually a TransformedPath instance is invalidated (triggering
a re-computation).
With Transforms this recursion can simply pass the same invalidation message up,
but for the more complex case of a CompositeTransform, which
represents the combination
of two Transforms, things get harder. I will devise a notation to help me
explain:

Let a composite transform, A, represent an affine transformation (a1)
followed by a
non affine transformation (vc2) [vc stands for very complicated] we
can write this in
the form (a1, vc2). Since non-affine Transform instances are composed of a
non-affine transformation followed by an affine one, we can write (vc2) as
(c2, a2) and the composite can now be written as (a1, c2, a2).

As a bit of background knowledge, computing the non-affine transformation of A
involves computing (a1, c2) and leaves the term (a2) as the affine
component. Additionally, a CompositeTransform which looks like (c1, a1, a2) can
be optimised such that its affine part is (a1, a2).

There are four permutations of CompositeTransforms:

A = (a1, c2, a2)
B = (c1, a1, a2)
C = (c1, a1, c2, a2)
D = (a1, a2)

When a child of a CompositeTransform tells us that its affine part is invalid,
we need to know which child it is that has told us.

This statement is best demonstrated in transform A:

 If the invalid part is a1 then it follows that the non-affine part
(a1, c2) is also
 invalid, hence A must inform its parent that its entire transform is invalid.

 Conversely, if the invalid part is a2 then the non-affine part (a1,
c2) is unchanged and
 therefore can pass on the message that only its affine part is invalid.


The changes can be found in
https://github.com/PhilipElson/matplotlib/compare/path_transform_cache
and I would really appreciate your feedback.

I can make a pull request of this if that makes in-line discussion easier.

Many Thanks,

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Drawing arbitrary Axis on a plot

2012-04-03 Thread Phil Elson

Before I dive too far down a rabbit hole, I wanted to sound out a few
questions related to adding custom Axis & associated gridlines to a
plot.


I want to be able to put an arbitrary axis on top of a plot in some
other projection (a simple, but not necessarily useful example, is a
pair Cartesian axes at the centre of a polar plot).
Some of my requirements are:

 * The Axis should represent a known transform, without the transform
necessarily being transData (a non-affine transformation from the
former to the latter is known).

 * The Axis is likely to be curved, and gridlines will not always
reach the edges of the background patch (I appreciate that the fact
that the gridlines not always crossing the background patch makes it
harder to identify the domain of the required Axis and accept that it
may be necessary to provide some additional information to help this
case).

 * The API should be consistent with standard mpl Axis objects (i.e.
Locators, Formatters, and all the expected control of
colour/visibility/size etc.) although access to the Axis itself is
understandably going to be different (i.e. I do not expect
ax.get_xaxis() to work).

 * Features such as interactive zooming + panning should be supported.

 * The Axis should be happy to live on Axes subclasses (e.g. Polar)
and "clip" the labels in the appropriate place according to the given
Axes/background-patch (in much the same way that AxisArtist can with a
rectilinear plot).

 * For bonus points the Axis should be able to break into multiple
lines/spines after transformation (see example 5 below for an example
of this), although this is very much a nice to have.



As far as I can see the AxisArtist toolkit is my best hope, although I
am concerned that it does not sit well with some of my requirements
(consistency of API; Axes subclass support; using transforms directly;
some bugs with non-rectilinear gridlines;).



I haven't thought about these issues in too much detail so there are
probably a whole host of problems that I have over-simplified/missed.
To aid discussion some concrete examples which demonstrate the kind of
thing that I am trying to achieve:

 #1. Putting a "latitude" (y) axis on a Robinson map
(http://en.wikipedia.org/wiki/Robinson_projection) at -180 degrees
longitude and a "longitude" (x) axis on the same map at 0 degrees
latitude.

 #2. Putting a "longitude" (x) axis on a Robinson map which follows
the top and bottom "edge"/spine.

 #3. Putting a "latitude" (y) axis on an Azimuthal equidistant map
(http://en.wikipedia.org/wiki/Azimuthal_equidistant_projection) at 0
degrees longitude and a "longitude" (x) axis on the equator (0 degrees
latitude). [Note: because of zooming, it is possible that 0 degrees
longitude may never be visible, in which case draw along the nearest
edge to the 0 degrees longitude line]

 #4. Putting a "longitude" (x) axis on the outside edge of an
Azimuthal equidistant map (arbitrary zooming is allowed, hence the
"edge" may be any shape. It is sufficient to imagine it as a half
circle representing the western hemisphere).

 #5. Putting a "longitude" (x) axis on a Goode homolosine map
(http://en.wikipedia.org/wiki/Goode_homolosine_projection) at -60
latitude. (this is an example of the bonus problem of splitting the
axis artists into multiple lines where appropriate!).

It appears to me that these examples are tangible, and I am fairly
confident I could draw them on a piece of paper, which suggests that
they might be achievable programatically.



I guess the questions I'm asking are:

 * Is there a silver bullet which gives me this functionality already?
 * If not, are my requirements so far away from matplotlib.axis.Axis /
AxisArtist that I need to consider implementing my own "Axis" artist?
 * Have I missed something which makes this a far harder problem than
I am describing?


I would like to get a discussion going on this topic, so would really
appreciate posts from anyone with any insight, prior experience,
similar problems or simply general thoughts on the matter.

Many thanks in advance,

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1

2012-05-23 Thread Phil Elson

Make a profit with this strategy. 
http://ponto.kelly-systems.com.br/twitter.news.php?uffriend_id=07a4
  --
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1

2012-05-23 Thread Phil Elson

Please accept my apologies for this spam. I guess its time to get a
better email provider for my mailing lists.

Regards,

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Modification to transform invalidation

2012-06-08 Thread Phil Elson

I have just merged in a rework of the transform invalidation mechanism
onto mpl master.
Throughout development it was clear that these changes can have wide
reaching and unexpected impacts on upstream code, as was highlighted
on more than one occasion when running the mpl unit tests.

Whilst I do not anticipate further issues, I am giving this heads up
just in case strange, possibly transform related, issues arise since
committing #723 (https://github.com/matplotlib/matplotlib/pull/723).
Debugging transform issues can get quite deep, so if you do come
across anything and want to share the burden I would be happy to help
if you can provide code to reproduce the issue.

Thanks,

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Interrupt is fixed

2012-07-18 Thread Phil Elson

Presumably you mean on the qt4 backend? If so, glad to be of some help! :-)

The change came in in PR #851
(https://github.com/matplotlib/matplotlib/pull/851/files#diff-7) and
also allows you to close a figure with ctrl+w and make a qt4 figure
fullscreen with "ctrl+f" (actually, just "f" will do, but I have an
ambition to nuke the non-controled versions by default).


UPDATE: I've just noticed that your traceback is showing your backend
as gtk, for which I cannot take any credit (nor do I know the change
which caused this improvement).



On 18 July 2012 13:06, Neal Becker  wrote:
> One annoyance with mpl in the past is that when running a script, SIGINT would
> not kill it (needed to use C-c C-\ instead).
>
> It seems this is now fixed:
>
> Interrupt now gives me:
>
>   File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_gtk.py", line 77, in mainloop
> gtk.main()
> KeyboardInterrupt
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Interrupt is fixed

2012-07-18 Thread Phil Elson

Ben, actually the PyQt4 backend is responsible for this (a hello world
pyqt4 application doesn't accept sigint). However, I have fixed master
(in the aforementioned PR) so that ctrl+c from the command line
actually closes the figure.

HTH,

On 18 July 2012 20:00, Benjamin Root  wrote:
>
>
> On Wed, Jul 18, 2012 at 1:40 PM, Neal Becker  wrote:
>>
>> OK, my mistake.  I'm using 1.1.1rc2.
>>
>> I was using a new installation without any matplotlibrc, and was defaulted
>> to
>> gtk.
>>
>> If I set:
>> backend : Qt4Agg
>>
>> then the problem has returned.
>>
>
> Usually, the source of such problems is someone using a bare try...except.
> KeyboardInterrupt subclasses BaseException.  There is a subtle difference
> between
>
> try:
>foo()
> except:
>pass
>
> and
>
> try:
> foo()
> except Exception:
> pass
>
> The first will capture Ctrl-C and throw it away, while the latter will not.
> PEP8 recommends against blind usage of bare except clauses.
>
> Happy hunting!
> Ben Root
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ANN: Michael Droettboom, matplotlib lead developer

2012-08-02 Thread Phil Elson

John, I wish all the best you and your family. You have been the hub
of a truly brilliant project for which I can only see its userbase
continuing to expand.

Mike, your appointment is thoroughly deserved and I look forward to
continuing to work closely with you and the rest of the matplotlib
team. Congrats!

Phil



On 2 August 2012 23:06, Benjamin Root  wrote:
>
>
> On Thursday, August 2, 2012, John Hunter wrote:
>>
>> It is a great honor for me to announce that Michael Droettboom has
>> agreed to take on the role of lead developer of matplotlib.  Since
>> Michael joined the project in 2007, he has been responsible for much
>> of the code that brought matplotlib from being an excellent tool to a
>> world class one.  No one in the world understands the code from the
>> inside out like he does, and many of his contributions, while often
>> unseen at the surface, have laid the foundation for matplotlib to
>> reach further into the wild and wonderful things it can now do.
>>
>> To name a few of his contributions: generic, optimized caching
>> transformations; dramatic backend simplification and rationalization;
>> countless optimizations; implementation of Knuth mathtex layouts;
>> python3 support, and dolphins!  I like to tell people Michael codes
>> with the force of ten men, and he's an incredible asset to our team.
>>
>> My role has been significantly diminished of late -- although I have
>> been the nominal lead developer, in practice I have been a release
>> manager.  Unfortunately, I need to take some time to focus on family
>> health issues, but will continue to follow development and make
>> contributions as I can.  We'll be looking for a release manager soon,
>> and if you are interested in stepping up, we'll welcome the effort.
>> We have a wonderful distributed development team using github pull
>> requests, and the line between core developers, project leaders and
>> plain-ole contributers is blurry.  But I think it helps to have
>> someone thinking about the project as a whole, who is willing and able
>> to make decisions when necessary, and no one is better suited to doing
>> this than Michael.
>>
>> I also extend my heartfelt thanks to Perry Greenfield and STScI.  They
>> have been supporting matplotlib since 2004 with ideas, code and
>> developer resources.  They employ Michael currently, and are part of
>> the reason why he is able to take on the leadership of this large
>> project.
>>
>> Michael, many thanks.
>
>
>
> Congrats, Michael!
>
> Ben Root
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib.github.com

2012-08-10 Thread Phil Elson

I wasn't involved at the time, but was it because
matplotlib.github.com is slower?

As far as I can see the github docs are as up-to-date as the
souceforge ones. (although reading the commit log on the docs repo
doesn't seem to agree with that statement)

All in all, sounds promising.

On 10 August 2012 15:26, Michael Droettboom  wrote:
> I know we had experimented with moving the main documentation website to
> matplotlib.github.com a while ago (and in fact there's still an old
> version of the docs sitting there).  I can't remember the reason we
> chose to remain at matplotlib.sourceforge.net and searching the mailing
> list archive isn't helping jog my memory there.
>
> I'd like to move to github's hosting if possible because rsyncing to
> sourceforge is slow as molasses and doesn't always work reliably.
>
> Supporting existing links to matplotlib.sourceforge.net is of course
> very important, and I would put whatever redirects we need to keep those
> working in any event.
>
> Mike
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib.org

2012-08-10 Thread Phil Elson

Great! Are we going to be able to move away from using the sourceforge
mailing list too?

Presumably these infrastructure costs get covered via the donations
that mpl receives rather than coming out of your pocket Michael?

I think getting hold of matplotlib.org is a really good idea. Thanks
for doing that!



On 10 August 2012 15:28, Michael Droettboom  wrote:
> I have registered matplotlib.org.  It currently just points to
> matplotlib.sourceforge.net, but it will allow us to have a consistent
> URL that isn't dependent on any particular host going forward.
>
> Mike
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib.github.com

2012-08-10 Thread Phil Elson

> As far as I can see the github docs are as up-to-date as the
> souceforge ones.

Scrub that statement. My browser cache needed clearing.





On 10 August 2012 15:44, Phil Elson  wrote:
> I wasn't involved at the time, but was it because
> matplotlib.github.com is slower?
>
> As far as I can see the github docs are as up-to-date as the
> souceforge ones. (although reading the commit log on the docs repo
> doesn't seem to agree with that statement)
>
> All in all, sounds promising.
>
> On 10 August 2012 15:26, Michael Droettboom  wrote:
>> I know we had experimented with moving the main documentation website to
>> matplotlib.github.com a while ago (and in fact there's still an old
>> version of the docs sitting there).  I can't remember the reason we
>> chose to remain at matplotlib.sourceforge.net and searching the mailing
>> list archive isn't helping jog my memory there.
>>
>> I'd like to move to github's hosting if possible because rsyncing to
>> sourceforge is slow as molasses and doesn't always work reliably.
>>
>> Supporting existing links to matplotlib.sourceforge.net is of course
>> very important, and I would put whatever redirects we need to keep those
>> working in any event.
>>
>> Mike
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Matplotlib-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Two 1.2 milestones

2012-08-19 Thread Phil Elson

I made the "1.2.x known bugs" milestone. I wanted a way of drawing
attention to them, without bundling them in the 1.2.x milestone. The main
motivation for this was because there is nobody currently working on them,
yet they are confirmed bugs which, unless we address them, will be known
bugs in the release.

I don't envisage the milestone to be a longterm thing, but I do think its
helpful to separate them from things we definitely want to resolve before
taking a 1.2.x cut. I would be happy even if we delete the milestone first
thing after the freeze tomorrow.

Regards,

Phil



On 19 August 2012 18:54, Michael Droettboom  wrote:

> On 08/19/2012 01:38 PM, Damon McDougall wrote:
> > On Sun, Aug 19, 2012 at 12:58:53PM -0400, Michael Droettboom wrote:
> >> There seems to be a new milestone "1.2.x known bugs".  Is there a good
> >> reason to have two milestones for 1.2?  As we enter into the freeze
> >> phase for 1.2, it would be easier to just track a single milestone.
> > According to mpl release calendar, the feature freeze is for 2.0, not
> > 1.2.
> >
> > Is this correct, or am I missing something?
> >
> Thanks for pointing this out.  There was some disagreement/discussion
> about what to call the next release.  In the end, it was decided to call
> it 1.2.There was a 2.0 milestone for a while, and all of those were
> moved to 1.2.   I'll update the calendar.
>
> Mike
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] gca() returns Axes

2012-08-21 Thread Phil Elson

I made a minor change to gca on Monday to address a bug. The PR was
https://github.com/matplotlib/matplotlib/pull/

I can't see that it should be the cause of this though.

Regards,


On 21 August 2012 22:40, Eric Firing  wrote:

> On 2012/08/21 10:21 AM, Eric Firing wrote:
> > I have run into a problem related to tight_layout when building the
> > docs, and the root of it seems to be that plt.gca() returns an Axes, not
> > an AxesSubplot.  This seems odd, since it appears that it should be
> > equivalent to plt.subplot(1,1,1) when there is no pre-existing axes.
> >
> > Does anyone see any problem with ensuring that what plt.gca() returns in
> > this case is an AxesSubplot instance?
> >
> > Eric
>
> Correction: now I can't reproduce what I thought I was seeing; plt.gca()
> is returning an AxesSubplot as it should.  Maybe the problem is in the
> axes_grid1 toolkit.  It is appearing in the last figure of the
> tight_layout tutorial in the docs.
>
> Eric
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Transforms bug

2012-08-27 Thread Phil Elson

>>> right angles are no longer right angles: noob error. Apologies.

Forgiven; on the basis that you provided such an entertainingly colourful
initial report! :-)
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] idea for a matplotlib figure contest (in memoriam John Hunter)

2012-08-30 Thread Phil Elson

What a great idea! Perhaps we could arrange judging at the annual SciPy
conference (or similar) with printouts of all the submissions.
This would be a great opportunity for everybody in the community to see the
broad and diverse usage of matplotlib globally, and an even greater
opportunity to reflect on the amazing work that John did on bringing this
fantastic community together.

Regards,


On 30 August 2012 08:58, Andrew Straw  wrote:

> Hi all,
>
> Shocked by news of John Hunter's untimely severe health problems and now
> death, I have been thinking about what we could do as a community to 1)
> fuel matplotlib to further heights and 2) give everyone, but especially
> John's family, some appreciation for how wide, and ongoing, his impact
> is. To those ends, I envision an MPL figure contest.
>
> I have a lot of ideas about the shape such a contest could take (it
> could be an annual event, have multiple categories, have corporate
> sponsored prizes, and so on). Ultimately, however, I simply don't have
> the time to organize the contest myself. I do see this as an ideal
> project for someone who wants to contribute to the MPL community without
> necessarily requiring in-depth technical skills. Consequently, I'm
> floating this idea here, and I hope someone in the community can run
> with it. You would certainly have figure submissions from my lab!
>
> Best regards,
> Andrew
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] slowdown with big invisible lines

2012-09-13 Thread Phil Elson

> I was just wondering if I should preferably post such messages about a
> possible bug report on matplotlib-users mailing list instead of the
> devel ml

Hi Pierre,

Thanks for bringing this to our attention.

You've posted to the right mailing list - I'm sorry nobody has replied, we
have all been focussing on the latest 1.2 release and this has fallen
through the net.

Your issue looks legit, I have looked through the axes.py Axes.draw method,
and there is no filtering based on the visibility toggle for anything but
images. Seems like it could be a very easy fix, would you be willing to
open an issue on the github tracker?
https://github.com/matplotlib/matplotlib/issues/new

Thanks again for raising this,

All the best,

Phil
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc1 is cut

2012-09-17 Thread Phil Elson

@Sandro: Yes, we merged the two together to simplify our code base and to
reduce dependencies etc.; Hopefully that doesn't cause you too much grief?


Eric/Russell, is there an issue on github for the reported problem?

Based on Christoph's comments, and couple of bugs I have just tracked down,
it sounds like we could do with a RC2 soon-ish.

The calendar states RC2 will be the 8th of October. Is it worth moving that
forward to get some useful testing on Windows under the belt?

Regards,




On 16 September 2012 17:26, Sandro Tosi  wrote:

> Hi Michael,
>
> On Wed, Sep 12, 2012 at 4:44 PM, Michael Droettboom 
> wrote:
> > I have tagged and created a tarball for 1.2.0rc1.  The githash is
> > bda6dd9feab8.  The tarball is on the github download page here:
> >
> > https://github.com/matplotlib/matplotlib/downloads
>
> Awesome! I'll start updating the Debian package asap. Just a couple of
> preliminary questions:
>
> - from now on, the official download place will be github? I'm just
> asking so that we can update our monitoring tools to be notified of
> new upstream releases/RCs and so on.
> - previously, we have 2 tarballs: the "normal" one plus a
> complementary sampledata ones containing the files below; but now it
> seems those files are included in the main tarball: is that correct?
> can I conclude the 2 tarballs are now merged into just one?
>
> mpl_sampledata-1.0.1/
> mpl_sampledata-1.0.1/aapl.npy
> mpl_sampledata-1.0.1/testdir/
> mpl_sampledata-1.0.1/testdir/subdir/
> mpl_sampledata-1.0.1/testdir/subdir/testsub.csv
> mpl_sampledata-1.0.1/AAPL.dat
> mpl_sampledata-1.0.1/Minduka_Present_Blue_Pack.png
> mpl_sampledata-1.0.1/PKG-INFO
> mpl_sampledata-1.0.1/eeg.dat
> mpl_sampledata-1.0.1/testdata.csv
> mpl_sampledata-1.0.1/MANIFEST.in
> mpl_sampledata-1.0.1/setup.py
> mpl_sampledata-1.0.1/lena.jpg
> mpl_sampledata-1.0.1/data_x_x2_x3.csv
> mpl_sampledata-1.0.1/lena.png
> mpl_sampledata-1.0.1/README.txt
> mpl_sampledata-1.0.1/msft.csv
> mpl_sampledata-1.0.1/axes_grid/
> mpl_sampledata-1.0.1/axes_grid/bivariate_normal.npy
> mpl_sampledata-1.0.1/aapl.csv
> mpl_sampledata-1.0.1/msft_nasdaq.npy
> mpl_sampledata-1.0.1/demodata.csv
> mpl_sampledata-1.0.1/s1045.ima
> mpl_sampledata-1.0.1/goog.npy
> mpl_sampledata-1.0.1/logo2.png
> mpl_sampledata-1.0.1/embedding_in_wx3.xrc
> mpl_sampledata-1.0.1/membrane.dat
> mpl_sampledata-1.0.1/INTC.dat
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc1 is cut

2012-09-19 Thread Phil Elson

Russell, I fixed this and it will be in rc2. See
https://github.com/matplotlib/matplotlib/pull/1264.

Thanks,


On 19 September 2012 00:32, Russell Owen  wrote:

>
> On Sep 18, 2012, at 4:05 PM, Paul Hobson wrote:
>
> > On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen  wrote:
> >> In article <[email protected]>,
> >> Michael Droettboom 
> >> wrote:
> >>
> >>> I have tagged and created a tarball for 1.2.0rc1.  The githash is
> >>> bda6dd9feab8.  The tarball is on the github download page here:
> >>>
> >>> https://github.com/matplotlib/matplotlib/downloads
> >>>
> >>> I have created a new branch, v1.2.x, for continuing 1.2.x development.
> >>> The feature freeze on master is now lifted and big experimental changes
> >>> can be merged into master.  Any bugfixes that need to go into 1.2.x
> >>> should be merged into both places.  Please mark any PRs for the 1.2.x
> >>> branch with the 1.2.x milestone so we can verify that things are merged
> >>> in both places.
> >>
> >> It appears that
> >> import matplotlib
> >> no longer imports matplotlib.dates -- that I must do that explicitly:
> >> import matplotlib.dates
> >>
> >> Is that an intentional change? It breaks existing code of mine, which is
> >> easily fixed and perhaps was making unwarranted assumptions. But I
> >> wonder what else will break.
> >
> > Russel,
> >
> > Which version were you on? with MPL v1.1 i get:
> > In [28]: import matplotlib
> >
> > In [29]: matplotlib.dates
> >
> ---
> > AttributeErrorTraceback (most recent call
> last)
> >  in ()
> > > 1 matplotlib.dates
> >
> > AttributeError: 'module' object has no attribute 'dates'
> >
> > In [30]: matplotlib.__version__
> > Out[30]: '1.1.0'
> >
> > In [31]: import matplotlib.dates
> >
> > In [32]: matplotlib.dates
> > Out[32]:  > 'C:\Python27\lib\site-packages\matplotlib\dates.pyc'>
>
> I was using 1.1.1 most recently. I'm not sure when I started using
> matplotlib.dates without explicitly importing it.
>
> In any case, it sounds as if it's not meant to work, so there's no need to
> change anything in matplotlib.
>
> Regards,
>
> -- Russell
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Welcoming new core developers

2012-09-19 Thread Phil Elson

Congrats to the three of you. The hard work that you all put in doesn't go
unnoticed, and is massively appreciated!

Mike, as lead developer, your opening round of beers for mpl devs at
SciPy13 is beginning to look costly. ;-)



On 20 September 2012 03:25, Benjamin Root  wrote:

>
>
> On Wednesday, September 19, 2012, Michael Droettboom wrote:
>
>> Damon McDougall, Christoph Gohlke and Russell Owen have been added to
>> the set of core developers with push rights and the ability to upload
>> files to the github download page.
>>
>> Damon has come recently on the scene, but has provided all kinds of
>> helpful bug triaging and fixing during the 1.2.0 release cycle, as well
>> as cool new features such as 3d trisurfaces and stacked plots, to name
>> only a few.
>>
>> Christoph Gohlke, besides providing tons of support on the mailing list
>> for a long while, has been providing Windows binaries for the past few
>> releases.
>>
>> Russell Owen has been providing Mac OS-X builds for the past few
>> releases and has helped track down some portability problems in the
>> 1.2.0 release.
>>
>> Thanks to everyone on the growing team!
>>
>> Mike
>>
>>
> Welcome aboard!
>
> Ben Root
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

2012-09-21 Thread Phil Elson

@Ben: Presumably your running one of the examples. Probably changed with
https://github.com/matplotlib/matplotlib/pull/921




On 20 September 2012 18:23, Benjamin Root  wrote:

>
>
> On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom wrote:
>
>> I have tagged and created a tarball for 1.2.0rc2.  The githash is
>> 656c88f3e546.  The tarball is on the github download page here:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> This includes a number of important bugfixes, including things required
>> for creating Macintosh and Windows binaries.  The Travis tests are also
>> now passing.
>>
>> I hope it will be easier for the binaries to be created this time. Once
>> they are available at github, I will make an announcement to
>> matplotlib-users and hopefully get some serious testing out of this thing.
>>
>> Thanks for all of the hard work!
>>
>> Mike
>>
>>
> Is it just me, or are colors looking duller?
>
> I attached before (v1.1.x) and after (v1.2.x) images.
>
> Ben Root
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] deprecate and remove original Navigation toolbar?

2012-10-03 Thread Phil Elson

Good question!

It would certainly be a welcome deprecation from my point of view. There is
a fair amount of overhead maintaining it if you make any changes to the way
backends work (as I have done a couple of times recently).

Depending on feedback here, it is something we could potentially deprecate
in 1.2 and then completely remove by 1.3.

Cheers,




On 2 October 2012 20:13, Eric Firing  wrote:

> Is there any good reason to retain the original NavigationToolbar code
> in the backends, and the corresponding "classic" option in
> rcParams['toolbar']?
>
> Eric
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-15 Thread Phil Elson

Firstly, I think you are right to bring this up Eric, we should all agree
what the best course is to take, and then all work together to get us there
with the least amount of disruption possible.

> if we leave PEP8 out of v1.2.x, and decide that once it is released,
v1.2.x will be changed
> only if critical bugs are found, requiring a v1.2.1 release

I agree. I think it is important here to be very clear about what
constitutes a "critical bug". In my opinion, releasing a v1.2.1 would be a
very last resort and I would sooner see us move forward by fixing bugs in a
new feature release (1.3). In order to do this we should have a schedule
for our next release *now*, and ideally it shouldn't be that far away (i.e.
no longer than 8-9 months). Some of my reasons for this assertion include:

   1. We have an amazing community of people who help us build our release
   bundles - so the actual release deployment mechanisms are no longer a
   limiting factor
   2. We have a long period between identification of features, their
   implementation and then seeing those features available in the latest
   release to our users. I would love to see that time shorten to share some
   of the cool new features that are being developed with non-developers
   sooner so that we can get feedback and go through the development cycle
   quicker.
   3. Currently making a release is a massive task which takes many
   developers out of actually being able to focus on new features or bugfixes.
   Having a quicker release cycle should mean we have fewer large changes per
   release and reduce the need we currently have to squeeze as much as we can
   into the next release - ultimately I think it will mean that we need to
   expend fewer developer hours focused on release management and last minute
   code reviewing.

This is not intended to be a criticism of our current system, simply an
observation that I think could help us to be more responsive and agile in
the future. If anybody wants to share their experiences with other
development methodologies I would love to hear about them (I guess if it is
not strictly related to this thread, then perhaps we should start up a new
conversation on the mailing list).

In short, provided we can agree a future matplotlib version schedule, I
agree with Eric. In terms of reverting the already cherry picked commits, I
am less sure. My heart is telling me to draw a line in the sand, accept
what is on the v1.2.x branch currently, and accept the suggested approach
for all future commits.

Finally, I agree with Ben. This is not a criticism of Nelle's PEP8 pull
requests, or of Damon and other's hard work in reviewing and merging them,
it is simply that we should agree the best course to get the best possible
release of v1.2.0 without dragging it out long beyond our original schedule.

Cheers,

Phil

On 15 October 2012 09:08, Damon McDougall  wrote:
> On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux
>  wrote:
>>
>>
>> On 15 October 2012 06:10, Eric Firing  wrote:
>>>
>>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>>> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing 
wrote:
>>> >> All,
>>> >>
>>> >> I think we are in a messy situation, and we need to reach some
>>> >> agreement
>>> >> as to how to proceed.  This has been discussed a bit in this thread:
>>> >>
>>> >>
>>> >>
http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
>>> >>
>>> >> The name of that thread did not reflect the importance of the
>>> >> discussion
>>> >> it prompted, hence the present message.
>>> >>
>>> >> To summarize my view:
>>> >>
>>> >> 1) We have a flood of PEP8 PRs based on master, many of which have
been
>>> >> merged, some by myself--so I have no objection to this aspect of the
>>> >> situation, though I would have preferred a slower pace, a garden hose
>>> >> rather than a fire hose.  I am happy to see continued merging of
these
>>> >> PRs into master.
>>> >>
>>> >> 2) We are also trying to stabilize v1.2.x, getting in the last few
bug
>>> >> fixes and doc updates, so we can get a release out, with a high
>>> >> probability that it will be solid.
>>> >>
>>> >> 3) The potential disagreement is over whether the PEP8 changes should
>>> >> be
>>> >> cherry-picked into v1.2.x, or simply left in master.  I favor the
>>> >> latter
>>> >> course.  First, because massive code churn shortly before a release
>>> >> seems unwise.  Second, because I think we should stick to the
strategy
>>> >> we started with, in which an effort is made to choose the most
>>> >> appropriate target for each PR, frequently merge the maintenance
branch
>>> >> into master, and reserve cherry-picking for occasional corrections.
>>> >>
>>> >> 4) The PEP8 changes will cause some merge problems no matter what we
>>> >> do;
>>> >> but I think that they can be minimal and manageable if we leave PEP8
>>> >> out
>>> >> of v1.2.x, and decide that once it is released, v1.2.x will be
changed
>>> >> only

Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes

2012-10-16 Thread Phil Elson

> In the meantime, PEP8 PRs can be completed on master, after which feature
enhancements can proceed on master.

I think it would be helpful to hold fire on the PEP8 changes until we have
our rc3 and have merged it back onto master for (hopefully) the last time.
That way, we wont have to deal with the conflicts that are inevitable when
merging v1.2.x back to master.

> Any merge conflicts with the PEP8 work will be noted by git and we can
address them as they come.

That is another approach which will work, assuming the master is fairly
up-to-date with v1.2.x now.


> Any strong objections to this?

Nope. Sounds like a good plan.





> In short, provided we can agree a future matplotlib version schedule, I
agree with Eric.

Mike, Ben, Eric & others, there is a new thread relating to scheduling of
releases, it is my opinion that it would be really beneficial to have a
planned release date for v1.3 (and maybe even v1.4/v2.0) that we all agree
on.

Phil






On 15 October 2012 17:59, Michael Droettboom  wrote:

> On 10/15/2012 12:52 PM, Eric Firing wrote:
> > On 2012/10/15 5:50 AM, Michael Droettboom wrote:
> >> Sorry to be jumping in on this late -- I didn't have a chance to catch
> >> up with this over the weekend.
> >>
> >> I think I generally side with Eric here -- the rc candidate cycle is
> >> intended to be quite conservative.  Nelle's pull requests are very
> >> welcome improvements, but they are also quite large and I am concerned
> >> about breakage slipping through the cracks.  To the extent that Nelle is
> >> finding undefined variable bugs etc. with her tool, I think we should
> >> probably try and fix those -- I know we've been doing that already and
> >> that's great.
> >>
> >> I think we should take the 1.2.x milestone off of all of the PEP8
> >> changes and keep all of them on master going forward.  Yes, the merging
> >> may be difficult while we are still in maintaining 1.2.x, but I think
> >> that's trivial compared to all of the additional testing and push back
> >> of the 1.2.0 release that this is currently causing.
> >>
> >> As for backing out things that were already cherry-picked -- that's a
> >> tough call.  I don't want to exacerbate the situation by causing further
> >> risk.  Maybe we just back out everything since the rc2?
> > It looks like that would itself cause a huge amount of additional churn,
> > and more risk than leaving things as they are.  At this point I suggest
> > leaving everything in that is presently in, try to get in the last few
> > bug fixes and tweaks, tag an rc3, and then target a release date,
> > somewhere in in the 2-4 weeks hence range.  In the meantime, PEP8 PRs
> > can be completed on master, after which feature enhancements can proceed
> > on master.
>
> Yeah -- having just looked back at all of the cherry-picks at issue,
> that's where I've come down as well.  Let's leave them in, but not put
> any further PEP8-only fixes on 1.2.x.  I'll remove the 1.2.x issue
> labels on the few PRs in progress.
>
> I also think it's not the end of the world if additional feature
> enhancements go on in master in the meantime.  Any merge conflicts with
> the PEP8 work will be noted by git and we can address them as they come.
>
> Any strong objections to this?
>
> Mike
>
> >
> > Eric
> >
> >> Mike
> >>
> >> On 10/15/2012 12:10 AM, Eric Firing wrote:
> >>> On 2012/10/14 12:44 PM, Damon McDougall wrote:
>  On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing 
> wrote:
> > All,
> >
> > I think we are in a messy situation, and we need to reach some
> agreement
> > as to how to proceed.  This has been discussed a bit in this thread:
> >
> >
> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel
> >
> > The name of that thread did not reflect the importance of the
> discussion
> > it prompted, hence the present message.
> >
> > To summarize my view:
> >
> > 1) We have a flood of PEP8 PRs based on master, many of which have
> been
> > merged, some by myself--so I have no objection to this aspect of the
> > situation, though I would have preferred a slower pace, a garden hose
> > rather than a fire hose.  I am happy to see continued merging of
> these
> > PRs into master.
> >
> > 2) We are also trying to stabilize v1.2.x, getting in the last few
> bug
> > fixes and doc updates, so we can get a release out, with a high
> > probability that it will be solid.
> >
> > 3) The potential disagreement is over whether the PEP8 changes
> should be
> > cherry-picked into v1.2.x, or simply left in master.  I favor the
> latter
> > course.  First, because massive code churn shortly before a release
> > seems unwise.  Second, because I think we should stick to the
> strategy
> > we started with, in which an effort is made to choose the most
> > appropriate target for each PR, frequently merge the maintenance
> branch
>

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

2012-10-30 Thread Phil Elson

Thanks for making this so easy to reproduce. It is so much easier when
there is a small, self contained, correct example!

Initially I was thinking that the problem was some kind of snapping issue
with the ticks, but it turns out, if you change the interpolation scheme to
"none", you get perfect alignment:


import numpy as np
import matplotlib.pyplot as plt

n = 16
fig = plt.figure(figsize=(10,10))

Z = np.zeros((n, n))
Z[::2, ::2] = 1
Z[1::2, 1::2] = 1

# pick the interpolation you want:
interp = 'nearest'
interp = 'none'

plt.imshow(Z, interpolation=interp,
cmap='gray', extent=[0, n, 0, n],
alpha=0.25)

plt.xticks(np.arange(n))
plt.yticks(np.arange(n))
plt.grid(ls='solid')

plt.show()



I haven't considered where to go from this point, but I wanted to let you
know about this option.

Thanks,

Phil



On 30 October 2012 07:10, Nicolas Rougier  wrote:

>
>
> Sorry, I was too fast in my reply.
>
> When I save the figure, the png output is ok while the pdf is displaying
> some kind of interpolation with the image.
>
> import numpy as np
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
>
> n = 16
> fig = plt.figure(figsize=(6,6))
> Z = np.array(([0,1]*(n//2) + [1,0]*(n//2))*(n//2)).reshape(n,n)
> plt.imshow(Z, interpolation='none', cmap=plt.cm.gray, extent=[0,n,0,n],
> alpha=.25)
> plt.xticks(np.arange(0,n), [])
> plt.yticks(np.arange(0,n), [])
> plt.grid(ls='solid')
> plt.savefig('pylab-grid.png')
> plt.savefig('pylab-grid.pdf')
> plt.show()
>
>
>
>
>
> Just for the record, "Skim", "Preview" and "Adobe Reader" on OSX do not
> give the same output on the saved pdf.
> "Adobe Reader" displays the expected result (same as saved png) while
> "Preview" and "Skim" are apparently trying to make some (bad) interpolation
> of the checkboard image.
>
>
> Nicolas
>
>
> On Oct 30, 2012, at 7:52 , Nicolas Rougier wrote:
>
> >
> >
> > You're right. Using 'none' interpolation seems to solve the problem.
> Good to know !
> >
> > One last question, why is the 'none' interpolation restricted to
> Agg/PS/pdf ?
> >
> >
> > Nicolas
> >
> >
> >
> > On Oct 30, 2012, at 6:53 , Jae-Joon Lee wrote:
> >
> >> On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier
> >>  wrote:
> >>>
> >>>
> >>> Thanks for testing.
> >>>
> >>> If I zoom at any line cross, the lines are definitely at the wrong
> place for me.
> >>
> >> As  jules hummon commented, I see lines in right places when I zoom in.
> >>
> >>> As for screen aliasing I'm not sure since both the png and pdf seems
> to be wrong in my case.
> >>
> >> It still can be some aliasing-related issue. Note that with
> >> interpolation="nearest", the images are rasterized with given dpi even
> >> if you save the figure as pdf.
> >> The agg backend tries to adjust the location of lines and images so
> >> that they are well-aligned with the pixels, and the issue seems to be
> >> related with that behavior.
> >>
> >> In my case, using interpolation="none" worked out okay. So give it a
> try.
> >>
> >> Regards,
> >>
> >> -JJ
> >>
> >>
> >>> Weird !
> >>>
> >>>
> >>> Nicolas
> >>>
> >>>
> >>> On Oct 29, 2012, at 15:40 , jules hummon wrote:
> >>>
>  Nicolas
> 
>  I get that too, (with your script and various things in my work).
>  But if you zoom in, the lines are in the right place.   Is it
>  some kind of screen aliasing?
> 
>  Jules
> 
> 
> --
>  The Windows 8 Center - In partnership with Sourceforge
>  Your idea - your app - 30 days.
>  Get started!
>  http://windows8center.sourceforge.net/
> 
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>  ___
>  Matplotlib-devel mailing list
>  [email protected]
>  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>>
> >>>
> >>>
> --
> >>> The Windows 8 Center - In partnership with Sourceforge
> >>> Your idea - your app - 30 days.
> >>> Get started!
> >>> http://windows8center.sourceforge.net/
> >>>
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> >>> ___
> >>> Matplotlib-devel mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> --
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > ___
> > Matplotlib-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>

Re: [matplotlib-devel] Delaying rc3 (again)

2012-10-30 Thread Phil Elson

> Given the severe weather approaching this area, I
won't have a chance to test and get out an 1.2.0rc3 candidate until at
least Thursday.

Very pleased to see that you have weathered the storm and are back
githubbing!

There are no more PRs in the 1.2.x milestone (
https://github.com/matplotlib/matplotlib/issues?milestone=4&page=1&state=open)
so I think we are in a good state to take a cut at any point.
I would be happy enough to spend the afternoon preparing a release
candidate 3 (though other than tagging and running tests on as many
architectures as possible, I'm not familiar with what is involved) if that
would help? If you would rather wait, I don't think it is a big problem,
the important thing to know is that we are on firm ground and the v1.2.x
branch is in a fantastic state for release.

To everyone who has helped us with testing or bug finding/squashing for
this release so far: Thank you for your hard work and commitment - it
really does make the release so much better as a result.

All the best,

Phil

On 29 October 2012 19:10, Michael Droettboom  wrote:

> Just a quick note: Given the severe weather approaching this area, I
> won't have a chance to test and get out an 1.2.0rc3 candidate until at
> least Thursday.
>
> Mike
>
>
> --
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Last call for 1.2.0

2012-11-08 Thread Phil Elson

Just closed the PR which proposes this change against master (in favour of
the one against v1.2.x).

It is very late in the day to be making so many example changes (especially
as we don't have tests for them).
Personally, the balance between the risks vs the benefits doesn't give me
much indication of which way to go (I guess that is partly because I don't
actually prefer the plt.subplots() interface in some situations). I guess
that is a debate for inside the PR (
https://github.com/matplotlib/matplotlib/pull/1462).

Cheers,




On 8 November 2012 09:22, Paul Ivanov  wrote:

> On Wed, Nov 7, 2012 at 6:23 PM, Michael Droettboom 
> wrote:
> > The milestone is clear.  Is there anything we're missing?
> >
> > If not, I plan to cut a final release and update the documentation
> > website tomorrow morning.
>
> I just submitted #1462 against v1.2.x, (which is also pending as #1458
> against master).
>
> "use plt.subplots() in examples as much as possible"
>
> replaces a whole bunch of example code like this:
>
> fig = plt.figure()
> ax = plt.subplot(111) # or plt.add_subplot(111)
>
> to be just this:
>
> fig, ax = plt.subplots()
>
> This is a docs-only update - but I think it'll be worthwhile to start
> to give a more sensible way of creating figures and axes in one call
> for our the folks who'll be looking at matplotlib with fresh eyes
> after the 1.2 release.
>
> But I totally understand if folks feel this is too big of a pill to
> swallow this late in the game.
>
> go, team, go!
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] dead link on matplotlib.org page

2012-11-08 Thread Phil Elson

To raise (built) documentation based problems, I have been creating issues
in https://github.com/matplotlib/matplotlib.github.com .
That seems to work well, but sadly, it always seems to be Michael that ends
up sorting it out... he is a victim of his own success (and speed) ;-)


On 8 November 2012 16:31, Benjamin Root  wrote:

> And I had completely missed that this was taken care of yesterday.
> However, the changelog link from the what's new page is still dead.
>
> Ben
>
>
> On Thu, Nov 8, 2012 at 11:24 AM, Benjamin Root  wrote:
>
>> There is a link to the CHANGELOG (are we even keeping that up to date
>> anymore?) on the main page that is dead.
>>
>> Ben Root
>>
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib 'testing' page link broken

2012-11-22 Thread Phil Elson

Mike working his magic:
https://github.com/matplotlib/matplotlib.github.com/commits/master


On 22 November 2012 03:21, Paul Ivanov  wrote:

>
> On Tue, Nov 20, 2012 at 2:21 PM, Damon McDougall <
> [email protected]> wrote:
>
>> http://matplotlib.org/devel/coding_guide.html
>>
>> Scroll down to 'Testing'. Click 'Testing'. Boom.
>>
>
> seems to have been fixed now. The "Testing" link over at
> http://matplotlib.org/devel/coding_guide.html#testing takes me to
> http://matplotlib.org/devel/testing.html#testing
>
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
> --
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Use of meta on Artist

2012-11-26 Thread Phil Elson

I've just been reviewing a really useful PR (
https://github.com/matplotlib/matplotlib/pull/1531) from Pierre Haessig
which speeds up the drawing of non-visible artists by bringing the
following line to the top of the LineArtist's draw method:

if self.get_visible() is False:
return

This *does* fix the problem (and will fix the problem for all other artists
if applied in the same way), but it relies on a developer remembering the
rule of thumb that they must always start their draw method with these two
(simple) lines. Additionally, testing this functionality is actually quite
hard without resorting to timing the execution.

It made we wonder if there was a better approach to fixing this. Having a
decorator to do this for you is a good idea, except that a developer would
need to remember to decorate their subclass' draw method, so the next level
up is to use a metaclass to *always* wrap the draw method with the "if
visible" lines.

An example of implementing this (apologies if the code doesn't come out
well in the email):


class ArtistMeta(type):
def __new__(cls, classname, bases, class_dict):
# replace the draw method with one which short-circuits if
self.visible is False
draw_method = class_dict['draw']
def draw(self, *args, **kwargs):
if self.visible is False:
print 'draw **not** called with
visible={}'.format(self.visible)
return
else:
return draw_method(self, *args, **kwargs)
class_dict['draw'] = draw

return  type.__new__(cls, classname, bases, class_dict)


class Artist(object):
__metaclass__ = ArtistMeta

def __init__(self, visible=True):
self.visible = visible

def draw(self, renderer=None):
print 'draw called with visible={}'.format(self.visible)
return 'foobar'


class SubArtist(Artist):
def draw(self, renderer=None):
print "subclass' draw method"
return Artist.draw(self, renderer=renderer)




With the following results:


>>> a = Artist().draw('wibble')
draw called with visible=True

>>> b = Artist(False).draw('wibble')
draw **not** called with visible=False

>>> c = SubArtist(True).draw('wibble')
subclass' draw method
draw called with visible=True

>>> d = SubArtist(False).draw('wibble')
draw **not** called with visible=False



In my eyes this makes testing the functionality possible without timing
(and is therefore an improvement), but I wanted to know how others felt
about the approach, and in particular, using more metaclasses in matplotlib
(a simple tutorial which I found useful:
http://www.voidspace.org.uk/python/articles/metaclasses.shtml).


Cheers,

Phil
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Fwd: Mpl mailing list archive and other sourceforge related problems

2012-11-28 Thread Phil Elson

I've just submitted a PR which changes the link we provide for the web
archiving of our mpl mailing lists (
https://github.com/matplotlib/matplotlib/pull/1540) as it appears that the
sourceforge archiving stopped updating in July...

Given that the mailinglists are provided/hosted by sourceforge in the first
place, I find it concerning that the sourceforge archiving is in this
state. Their addition of advertising on our mailinglist posts makes me even
less enamoured with the service we receive.

It makes me wonder whether we should consider alternative service providers
for our mailing lists? I notice the ipython/numpy/scipy mailinglists are
all hosted via scipy.org and wonder if we should consider asking to have
our mpl mailinglists hosted there too?

Thoughts?

Cheers,

Phil
--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

2012-12-11 Thread Phil Elson

> I'm not sure if non-core-developers are allowed to post MEPs, but I just
did

Yes please... The more the merrier!
Aren't you a core dev anyway Tony? :-) You've certainly contributed some
really valuable features, and even if you don't have access to "the big
green button" in my eyes you feedback and input are just as valuable.

The gallery was one of the key features that pulled me into mpl, but it
definitely needs a bit of TLC. The timing is quite convenient for me as I
am about to (in the next month or so) embark on implementing a gallery for
a project I'm working on that makes heavy use of matplotlib (cartopy:
http://scitools.org.uk/cartopy/docs/latest/).

One thing I was considering doing in my implementation was allowing
multiple tags for each example by adding some extra module level
information (in a list called "__tags__" perhaps) rather than focussing on
a directory structure to provide the tag as the current implementation of
the gallery does (and as far as I can see, the MEP recommends this too).

In the past I have also worked on a gallery extension which uses the
docstring of the example to provide a richer explanation of what is going
on (example:
http://scitools.org.uk/iris/docs/latest/examples/graphics/COP_1d_plot.html).
An alternative approach which has worked well for me is the walked through
examples found in scikits-learn (their website is down, but most of the
examples are good in that regard) which could be done via an iPython
notebook for the annotations.

> Do you think that all the work should be done on a parallel branch and
merged in one big PR?

Personally, I'm not in favour of that. We would have to make sure that the
pull requests related to this change don't start to stack up, but I think
we can definitely do this sequentially once the appropriate machinery is in
place.

Thanks for bringing this subject up,

All the best,

Phil

On 10 December 2012 23:00, Tony Yu  wrote:

>
>
> On Mon, Dec 10, 2012 at 5:51 PM, Paul Hobson  wrote:
>
>> On Mon, Dec 10, 2012 at 2:18 PM, Tony Yu  wrote:
>>
>>> Hi all,
>>>
>>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>>> did ;). MEP 12 outlines the reorganization of the example gallery and
>>> subsequent clean up of the examples:
>>>
>>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>>
>>> In my opinion, there are two open questions in the MEP:
>>>
>>> * Section names (may seem trivial to some, but I think it's really
>>> important)
>>> * Guidelines for cleaning up examples
>>>
>>> I've added proposed section names and clean-up guidelines to the MEP,
>>> but I'm sure these will evolve over time.
>>>
>>> Best,
>>> -Tony
>>>
>>>
>> Here here! I've been waiting for a really nasty, cold, and rainy weekend
>> here in Portland to make some PRs at least cleaning up the code contained
>> within the examples. Just hasn't happened yet ;)
>>
>>  Tony, if you make your own branch for this, I'd be happy to contribute.
>> -paul
>>
>
> Awesome! I'm hoping we can quickly converge on some clean-up guidelines
> and section headings.
>
> I was envisioning a single PR that adds new gallery sections. After that
> examples would be updated over a long period of time in multiple PRs that
> change a few examples at a time. Do you think that all the work should be
> done on a parallel branch and merged in one big PR?
>
> Best,
> -Tony
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] PR #1599

2013-01-10 Thread Phil Elson

I agree with getting going on these two. My preference is for the mandrill
image, but the truth is, I don't have a problem with what is already
there... so any of the following outcomes would be fine with me:

 1. We merge mandrill & close #1599
 2. We merge Ada & close #1581
 3. We close #1581 & #1599 and keep Lena

On the front of stacking of pull requests - I agree we have a big problem.
Would it be sensible to arrange a "pull request week" in the next month or
so, where as a development team we seriously focus on closing down as many
of the pull requests as possible?




On 10 January 2013 06:07, Eric Firing  wrote:

> We have too many pull requests stacking up.  As an easy way to deal with
> two of them, does anyone strenuously object to merging #1599 and closing
> #1581?  There are no comments on #1599.
>
> Eric
>
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Requiring numpy requirement to 1.5 on master?

2013-01-15 Thread Phil Elson

@mdboom - that sounds like roaring agreement to me.  :-)
Lets go for it.


On 14 January 2013 20:34, Damon McDougall  wrote:

> On Fri, Jan 11, 2013 at 12:33 PM, Eric Firing  wrote:
> > On 2013/01/11 5:38 AM, Michael Droettboom wrote:
> >> As pointed out in #1650, we have a bug on Python 3.x handling file-like
> >> objects that are UNIX FILEs, but not actual filesystem files, such as
> >> the sockets used for a urllib HTTP request.
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1650
> >>
> >> As Christoph helpfully points out, Numpy has already solved this problem
> >> (since 1.5.0), so it would be easiest to just use their solution.
> >>
> >> For 1.2.x, I think we shouldn't update the Numpy requirement (which is
> >> currently 1.4) -- there, I'll have to port Numpy's compatibility
> >> functions to our code base.  But for master, I'd rather just use Numpy's
> >> stuff so all of the intricacies of this are handled in one place.
> >>
> >> (And as a detail, it isn't until Numpy 1.7 that a "CloseFile" function
> >> is provided, so even on master, we're stuck copying some code over).
> >>
> >> Any objections?
>
> Nope.
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP13 - python containers

2013-01-17 Thread Phil Elson

Hi Todd,

I agree with the principle of properties - it will make much of the mpl
codebase (and user code) more pythonic, so thanks for proposing this.

Would you be able to give an example of how you propose setters such as
Axes.set_xlim might make use of properties. The particular example I have
picked uses keywords to determine the behaviours of the method itself:

def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw):
...

For me, the backwards compatibility issue is the key blocker to this MEP.
Would you mind providing some concrete examples (perhaps using the set_xlim
method as a focus point)?

Cheers,

Phil

On 16 January 2013 21:00, Todd  wrote:

> I have created a very preliminary MEP for the possible move to properties:
>
> https://github.com/matplotlib/matplotlib/wiki/MEP13
>
> Please take a look at it and discuss.  As I said, this is very
> preliminary.  Everything is subject to change.
>
>
> --
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Docs build hitting an ImportError - any guesses?

2013-03-02 Thread Phil Elson

Nothing springs to mind. Perhaps the install is failing due to
https://github.com/matplotlib/matplotlib/pull/1454?

Sounds like you don't have access to the machine to check that

$> python -c "import matplotlib"

Works?




On 2 March 2013 17:25, Thomas Kluyver  wrote:

> The Launchpad daily builds have recently started failing on the docs
> build. I get the error message "Error: matplotlib must be installed before
> building the documentation", which means that there's an ImportError raised
> when it tries to import matplotlib. Unfortunately, it hides any other
> information about the ImportError, and I can't currently replicate it on my
> own computer.
>
> It builds the Python library, then attempts to build the docs with the
> command:
>
> cd doc ; MATPLOTLIBDATA=../lib/matplotlib/mpl-data/ \
> PYTHONPATH=../build/lib.linux-i686-2.7 ./make.py --small all
>
> Does anyone know what might have changed a few days ago to cause this? It
> built successfully on the 26th of February, there was a different problem
> on the 27th, and when I resolved that, this failure started on the 28th.
> I've had a look at the commit log, but nothing jumps out.
>
> Thanks,
> Thomas
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] "Flash" rendering in the Agg backend

2013-03-06 Thread Phil Elson

Smart rendering of adjacent, anti-aliased patches is a question which has
come up a couple of times in various guises in the past.
It is my understanding that the lack of this functionality led us to
disable anti-aliasing for contouring and is the reason the following image
has a white stripe around the circle where there should be just a nice
blend of the two colors:


import matplotlib.pyplot as plt
import numpy as np
import matplotlib.patches as mpatches
import matplotlib.path as mpath
import matplotlib.collections as mcol


# create two paths. One a circle, the other
# a square with the same circle cut out.
x = np.linspace(0, np.pi * 2, 1000)

circle_coords = np.array(zip(*[np.sin(x) * 0.8, np.cos(x) * 0.8]))
pth_circle = mpath.Path(circle_coords)

sqr_codes = np.repeat(mpath.Path.MOVETO, len(circle_coords) + 5)
sqr_codes[1:5] = mpath.Path.LINETO
sqr_codes[6:] = mpath.Path.LINETO
sqr_coords = np.concatenate([[[-1, -1], [-1, 1], [1, 1], [1, -1], [-1,
-1]],
circle_coords[::-1]], axis=0)
sqr_path = mpath.Path(sqr_coords, sqr_codes)


ax = plt.axes()
patches = [mpatches.PathPatch(pth_circle), mpatches.PathPatch(sqr_path)]
col = mcol.PatchCollection(patches,
   antialiaseds=True,
   edgecolors='none',
   facecolors=[(0, 0.0, 0.0, 0.9), (0.1, 0.1, 0.02,
0.9)])
ax.add_collection(col)
ax.set_xlim([-1, 1])
ax.set_ylim([-1, 1])
plt.show()



I know of lots of the workarounds for this (turn off AA, turn on lines,
extend the path slightly, set a dark background color) all of which have
down-sides, so I'm keen to find a final solution to the problem.

When the two patches marry up perfectly with full anti-aliasing, the
antigrain (AGG) community call this "flash" or compound rendering, and this
capability was added to Agg 2.4 (which we already ship with mpl).

In order to make full use of the compound rendering technique I believe the
drawing pipeline in "_backend_agg.cpp" would need to change, which could be
problematic. A less wide-impacting alternative would be to draw all
"patches" of a single Collection in the same rasterization step (i.e. just
change _draw_path_collection_generic), though this does mean that, as it
stands, the result of plt.contourf would not be able to make use of this
new functionality - a MEP which changes the return type of plt.contourf to
a single Collection might be able to fix that.

I've put together a simple example similar to this in C++ using agg (no mpl
changes yet), showing the differences in the code needed between the old
technique vs the "new" compound renderer (attached).


Ok, so the question to those that have knowledge of the _backend_agg.cpp
code (Mike, Eric, JJ + others?):


   - Have you already looked at doing this and determined that this is a
   non-starter?
   - Do you support adding the ability for the agg backend to draw compound
   artists (i.e. Collections) in this way rather than treating them as
   individual primitives in the canvas?
   - Since many of the other backends can't do flash rendering, would we
   even want to make this change?
  - SVG in Firefox 10.0.2 has the same problem, it is discussed
  slightly more in
  http://www.svgopen.org/2002/papers/sorotokin__svg_secrets/
  - Acroread has the same problem with PDFs, only to a much lesser
  extent than in the PNG attached


Thoughts?
<>#include 
#include 
#include 
#include 

#include "agg_rendering_buffer.h"
#include "agg_rasterizer_scanline_aa.h"
#include "agg_pixfmt_rgb.h"
#include "agg_scanline_p.h"
#include "agg_renderer_scanline.h"
#include "agg_color_rgba.h"
#include "agg_array.h"
#include "util/agg_color_conv_rgb8.h"

#include "agg_path_storage.h"


#define PI 3.14159265


bool save_image_file (agg::rendering_buffer& rbuf, const char *fn)
{
  FILE* fd = fopen(fn, "wb");
  if(fd == 0) return false;

  unsigned w = rbuf.width();
  unsigned h = rbuf.height();

  fprintf(fd, "P6\n%d %d\n255\n", w, h);

  unsigned y; 
  agg::pod_array row_buf(w * 3);
  unsigned char *tmp_buf = row_buf.data();

  for(y = 0; y < rbuf.height(); y++)
{
 const unsigned char* src = rbuf.row_ptr(h - 1 - y);
  agg::color_conv_row(tmp_buf, src, w, agg::color_conv_bgr24_to_rgb24());
  fwrite(tmp_buf, 1, w * 3, fd);
}

  fclose(fd);
  return true;
}


int main()
{
  typedef agg::pixfmt_bgr24 pixel_type;
  
  const unsigned w = 500, h = 300;
  int i;
  int x_radius = 240, y_radius = 280, x_offset = 250, y_offset = 5;

  unsigned row_size = pixel_type::pix_width * w;
  unsigned buf_size = row_size * h;
  agg::pod_array img_buf(buf_size);
  
  agg::rendering_buffer rendering_buffer(img_buf.data(), w, h, -row_size);
  pixel_type pixf(rendering_buffer);
  
  typedef agg::renderer_base renderer_base_type;
  typedef agg::renderer_scanline_aa_solid renderer_solid_type;
  renderer_base_type renderer_base(pixf);
  renderer_solid_type renderer_solid(renderer_bas

Re: [matplotlib-devel] "Flash" rendering in the Agg backend

2013-03-07 Thread Phil Elson

> I'm trying to compile your examples, but it seems perhaps you forget to
include a file

Sorry, you can find pixel_formats.h in the examples directory. I have a
mirror of agg here:
https://github.com/pelson/antigrain/tree/master/agg-2.4/examples

My compile steps are:

export AGG_DIR=

g++ -c -O3 -I${AGG_DIR}/include -I${AGG_DIR}/examples -L${AGG_DIR}/src
basic_path.cpp -o basic_path.o
g++ -O3 -I${AGG_DIR}/include -L${AGG_DIR}/src basic_path.o -o basic_path
-lagg


> I had played with the "compound renderer" example in Agg some years ago,
but couldn't really understand how it worked

Agreed. It took the best part of a day to figure out how to do it, given no
prior knowledge of Agg. I intend to submit a couple of simpler (GUI-less)
examples to be included with the agg repo - and perhaps even write some
documentation for this stuff!

> Does it work with alpha < 1?

Yes. I've attached the two images (converted from ppm to png using gimp +
default settings) so that you can see the results. Each shape has an alpha
value of 200.

[image: Inline images 1][image: Inline images 2]

HTH





On 6 March 2013 20:27, Michael Droettboom  wrote:

>  I'm trying to compile your examples, but it seems perhaps you forget to
> include a file -- pixel_formats.hpp?  It's not in the agg24 source tree.
>
> Mike
>
>
> On 03/06/2013 12:06 PM, Phil Elson wrote:
>
>  Smart rendering of adjacent, anti-aliased patches is a question which
> has come up a couple of times in various guises in the past.
> It is my understanding that the lack of this functionality led us to
> disable anti-aliasing for contouring and is the reason the following image
> has a white stripe around the circle where there should be just a nice
> blend of the two colors:
>
>
> import matplotlib.pyplot as plt
> import numpy as np
> import matplotlib.patches as mpatches
> import matplotlib.path as mpath
> import matplotlib.collections as mcol
>
>
> # create two paths. One a circle, the other
> # a square with the same circle cut out.
> x = np.linspace(0, np.pi * 2, 1000)
>
> circle_coords = np.array(zip(*[np.sin(x) * 0.8, np.cos(x) * 0.8]))
> pth_circle = mpath.Path(circle_coords)
>
> sqr_codes = np.repeat(mpath.Path.MOVETO, len(circle_coords) + 5)
> sqr_codes[1:5] = mpath.Path.LINETO
> sqr_codes[6:] = mpath.Path.LINETO
> sqr_coords = np.concatenate([[[-1, -1], [-1, 1], [1, 1], [1, -1], [-1,
> -1]],
> circle_coords[::-1]], axis=0)
> sqr_path = mpath.Path(sqr_coords, sqr_codes)
>
>
> ax = plt.axes()
> patches = [mpatches.PathPatch(pth_circle), mpatches.PathPatch(sqr_path)]
> col = mcol.PatchCollection(patches,
>antialiaseds=True,
>edgecolors='none',
>facecolors=[(0, 0.0, 0.0, 0.9), (0.1, 0.1,
> 0.02, 0.9)])
> ax.add_collection(col)
> ax.set_xlim([-1, 1])
> ax.set_ylim([-1, 1])
> plt.show()
>
>
>
>  I know of lots of the workarounds for this (turn off AA, turn on lines,
> extend the path slightly, set a dark background color) all of which have
> down-sides, so I'm keen to find a final solution to the problem.
>
> When the two patches marry up perfectly with full anti-aliasing, the
> antigrain (AGG) community call this "flash" or compound rendering, and this
> capability was added to Agg 2.4 (which we already ship with mpl).
>
> In order to make full use of the compound rendering technique I believe
> the drawing pipeline in "_backend_agg.cpp" would need to change, which
> could be problematic. A less wide-impacting alternative would be to draw
> all "patches" of a single Collection in the same rasterization step (i.e.
> just change _draw_path_collection_generic), though this does mean that, as
> it stands, the result of plt.contourf would not be able to make use of this
> new functionality - a MEP which changes the return type of plt.contourf to
> a single Collection might be able to fix that.
>
>  I've put together a simple example similar to this in C++ using agg (no
> mpl changes yet), showing the differences in the code needed between the
> old technique vs the "new" compound renderer (attached).
>
>
>  Ok, so the question to those that have knowledge of the _backend_agg.cpp
> code (Mike, Eric, JJ + others?):
>
>
>- Have you already looked at doing this and determined that this is a
>non-starter?
>- Do you support adding the ability for the agg backend to draw
>compound artists (i.e. Collections) in this way rather than treating them
>as individual primitives in the canvas?
>- Since many of the other backends

Re: [matplotlib-devel] [Matplotlib-users] Feedback on an implementation of a matlab-ish "datacursor"

2013-03-13 Thread Phil Elson

Joe,

Do you have any feeling for performance of mpldatacursor? I'm interested to
know if implementing this functionality by default (with an rcParam switch
to disable) on all Axes would have a significant impact on performance?


> If it is something that other people find useful, I'd be happy to submit
a pull request to incorporate it into matplotlib.

Personally, I find this kind of extension better as a completely separate
piece of work which one could "pip install" - it means you can be more
flexible with release cycles, especially in the early days of the code when
regular updates are most likely. Though I should note, I'm not against it
being included in mpl as an extension, if you would prefer that.


Thanks again for sharing!





On 13 March 2013 10:08, Phil Elson  wrote:

> Thanks for this Joe, mpldatacursor looks like an excellent piece of work -
> I for one will be installing and using it regularly.
>
> Thanks for sharing!
>
>
>
>
>
> On 13 March 2013 03:58, Joe Kington  wrote:
>
>> I recently got around to polishing up a snippet I've been using for quite
>> awhile.  https://github.com/joferkington/mpldatacursor/  and I was
>> hoping to get some feeding on the current implementation.
>>
>> "mpldatacursor" allows a user to easily click on an artist and display a
>> customizable, interactive pop-up box displaying information about the
>> selected artist (e.g. x & y, label, z for images and collections, etc).
>> It's a stand-alone module (and in pypi), but you could also just download
>> the examples directory from github and copy the mpldatacursor.py file into
>> it to try things out.
>>
>> A few key questions:
>>
>>1. Is this something that anyone else finds useful?
>>
>>2. Does it seem intuitive?
>>
>>3. Does the implementation seem flexible enough for most needs? (Note
>>that any additional kwargs are passed on to annotate to create the "data
>>cursor", so the appearance of the box is customizable through annotation
>>kwargs.)
>>
>>4. Are there any obvious features missing?
>>
>>5. Any suggestions? (especially better name suggestions...)
>>
>> If it is something that other people find useful, I'd be happy to submit
>> a pull request to incorporate it into matplotlib.  (If I did, it would
>> probably be best to drop the HighlightDataCursor class, as its limited in
>> what it can do.)
>>
>> Thanks a bunch!
>>
>> -Joe
>>
>>
>> --
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> ___
>> Matplotlib-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] label= kwarg for imshow() and other scalarmappable plots

2013-03-25 Thread Phil Elson

In general I like the idea, but I'm not sure what behaviour I would expect
in this case:

plt.imshow(z, label='foobar')
plt.imshow(z, label='wibble')
plt.colorbar()

I suppose it is an analogous problem to:

plt.imshow(z, cmap='hot')
plt.imshow(z, cmap='jet')
plt.colorbar()

Which produces a colorbar for the [current scalar mappable]/gci.

On that basis, I've just convinced myself that your proposal is a good
idea, so +1 from me.





On 25 March 2013 07:03, Eric Firing  wrote:

> On 2013/03/24 12:14 PM, Benjamin Root wrote:
> > So, for plot(), scatter() and other plotting functions, we can provide a
> > label= kwarg so that a legend() can automatically populate the legend,
> > making it extremely easy and convenient for making legends.  But for
> > image-based (scalar mappable) type plotting functions like imshow() and
> > contourf(), the label kwarg doesn't do anything useful, but the
> > colorbar() is sort of analogous to a legend(), but for scalar mappables.
> >
> > Does it make sense to others for the following to be equivalent:
> >
> >  > plt.imshow(z)
> >  > cbar = plt.colorbar()
> >  > cbar.set_label('foobar')
> >
> >  > plt.imshow(z, label='foobar')
> >  > plt.colorbar()
> >
>
> I understand your argument, but it feels a bit odd.  To me it would be
> more natural for colorbar() itself to accept a label kwarg.  I have no
> idea why I didn't do that long ago.
>
> The two ideas are not mutually exclusive.
>
> Eric
>
> >
> > I found that it is a small change to make this work, I just wanted to
> > know if others think this makes sense before putting in the time to add
> > documentation, modify examples and such.
> >
> > Cheers!
> > Ben Root
> >
> >
> >
> --
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_mar
> >
> >
> >
> > ___
> > Matplotlib-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SciPy 2013

2013-03-25 Thread Phil Elson

OOI Is anyone planning to run an advanced matplotlib tutorial this year?

I've added a few ideas to
https://github.com/matplotlib/matplotlib/wiki/Scipy-2013 - some are more
advanced than others and would need a bit of planning should we decide to
run with them.



On 23 March 2013 17:06, Damon McDougall  wrote:

> On Fri, Mar 22, 2013 at 12:11 PM, Nelle Varoquaux
>  wrote:
> >
> >
> >
> > On 22 March 2013 18:06, Michael Droettboom  wrote:
> >>
> >> On 03/22/2013 12:45 PM, Nelle Varoquaux wrote:
> >>
> >>
> >>> I'm hoping to host a matplotlib sprint during the final two days of
> Scipy
> >>> 2013 this year, and I hope to see as many as possible of you there.  I
> think
> >>> it's also really important to bring new developers into sprints,
> because
> >>> it's such an efficient way to get people familiar with the code base.
>
> Awesome idea.  I am for sure in.  In fact, I work in Austin now; it'd
> be great to actually meet some of you in person.  We should share some
> breakfast tacos or interior Mexican food!
>
> >> Being in Europe, it is very unlikely I'll come to Scipy this year, but I
> >> think it is a great idea to organize a sprint during this period.
> >>
> >>
> >> I'll also try to set up some sort of remote communication tool (such as
> >> Google Hangouts, or even just IRC) so that people can "participate" in
> the
> >> sprint remotely.
> >
> >
> > There's a #matplotlib chanel on irc, where a dozen people hang out. That
> > could be a nice place to gather people during the sprint.
>
> Is this on freenode?  I joined it yesterday to scope it out but it was
> pretty quiet.
>
> >
> >>
> >>
> >>
> >>
> >>>
> >>> It might be helpful to start brainstorming now about which projects we
> >>> may want to tackle so that we can have as much in place as possible by
> then
> >>> and hit the ground running.
> >>
> >>
> >> One of the things I think would be great to tackle is the replacement of
> >> the Travis bot. Ideally, I'd like to see a pep8 check of each patch and
> a
> >> daily build of the documentation on master in addition of the tests.
> >>
> >>
> >> Agreed.  That's definitely on my todo list.  We've got some funding
> >> through my employer to pay for continuous integration hosting -- it's
> just
> >> taking a while to work its way through the system.  Once we have some
> sort
> >> of paid hosting system, we should be able to do a lot more than Travis
> >> currently can.
> >>
> >> Mike
> >>
> >>
> >>
> >>>
> >>>
> >>> I've set up a wiki page here:
> >>>
> >>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>
> I have edited the Wiki to confirm my attendance.
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SciPy 2013

2013-03-25 Thread Phil Elson

>I am putting together a beginners tutorial proposal that I will submit soon

That's great to hear! Are you planning on making the tutorial material part
of mpl's docs or using the content that is already out there?



On 25 March 2013 16:16, Benjamin Root  wrote:

> I am putting together a beginners tutorial proposal that I will submit
> soon, depending on the feedback from the Guinea Pigs--- uhm, I mean,
> coworkers tomorrow.
>
> Ben Root
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Planning for 1.3.0

2013-04-11 Thread Phil Elson

Great news! A lot of fantastic work has been done by a whole host of people
to go into this release. It's exciting stuff!

May 27th sounds like a sensible target to me. As you know, I'm an advocate
of releasing often - the more frequently we make a release, the less we
will have the "impending release rush" that can really hamper the whole
release process.

Cheers,




On 11 April 2013 17:38, Michael Droettboom  wrote:

> Congrats to everyone on a successful 1.2.1 -- there was a relatively
> small influx of bug reports following it -- perhaps a sign of improving
> quality?
>
> In any event, as Phil Elson likes to repeatedly point out (), we
> have a great deal of awesome new features in master that it would be
> great to get out.  As for time frame, I think if we aim for a 1.3.0rc1
> of May 27, that's within a good time frame to get something out in time
> for Scipy.  That will put us about 8 months past 1.2.0, which is not far
> off from my eventual goal of 6 month releases once things get
> streamlined.  We can, of course, adjust the date as necessary as we go
> along.
>
> So... let the bug triaging begin!  As there are lot of new features in
> the queue, I think it's important to distinguish the "nice to have" from
> the "must have".  I've created a new milestone "1.3.x blocker" that we
> should use for critical bugs that should hold up the release.  All other
> new features that are looking close to ready for 1.3.x should be
> milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x.
> Simple bugs that apply to 1.2.x as well as master should be milestoned
> as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as
> I still think we should reserve the right to make another 1.2.2 bugfix
> release if necessary.
>
> There are a couple major ongoing projects that I think we'll need to get
> to a steady interim state before we can make another release.
>
>MEP10: Documentation
>
>   We already have a number of improved docstrings, and better
> organization throughout.  I don't think we need to finish all of this
> work before the next release, but we should get it back into shape so
> that the doc build has fewer warnings (#1896) and the LaTeX build works
> again (#1836).
>
>MEP12: Reorganize and cleanup examples
>
>   Again, I think a lot of great work has already been done, and we
> don't necessarily have to wait until it's done.
>
> For both of the above, it would be nice to divide the work up so the
> leaders of those projects are less individually burdened.  Nelle and
> Tony, if you know of any critical blockers or loose ends that should be
> tied up before a release should be made, please make issues for them and
> milestone them as "1.3.x blocker".
>
> Cheers,
> Mike
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Quadmesh with alpha without the nasty edge effects

2013-05-13 Thread Phil Elson

I can't work out if I'm having a brain block or it really can't be done,
but I'm trying to produce a pcolormesh with alpha without the nasty edges
seen in the attached image


[image: Inline images 1]

The code to reproduce:

import matplotlib.pyplot as plt
import numpy.random

d = numpy.random.random([10, 10])
plt.pcolormesh(d, alpha=0.5, vmin=0, vmax=10)
plt.show()


I've tried several things, including:

   - Setting antialiased=False
   - Fiddling with the returned pcolormesh's _is_stroked attribute
   - Rasterizing
   - Setting the edgecolor to 'face'

Pcolorfast is one option, but I was ideally hoping to achieve this with
pcolormesh.

Any thoughts?
<>--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] closing (and opening) the user survey?

2013-07-24 Thread Phil Elson

I'm not quite back to normality here after getting back from over a month
out of the office (Scipy'13 taking a chunk of that time) and didn't manage
to fill in the questionnaire. I guess it doesn't matter too much that I
didn't manage to fill it in (I know my own users, all 250+ of them, pretty
well after all), but I wonder whether there are others in a similar
situation who didn't get a final social nudge to get on and fill in the
questionnaire because time was running out. If we do something similar in
the future I suggest we publish a deadline and push the social media
streams hard up-until that final deadline, just to get those final last
minute-ers (like me). :-)

Anyway, that aside, having quickly glanced at the results of the survey,
I'm really impressed at the quality of the data and how clear some of the
messages in there have come out (i.e. there are backends which are clearly
dead horses). More on that in a separate thread...

Cheers (its good to be back)!

Phil

On 18 July 2013 14:33, Michael Droettboom  wrote:

> I'm fine with that.  I actually had the same idea yesterday.  I don't
> think we'll get many more responses than we already have.
>
> I'll go ahead close the survey and then make an official announcement on
> the usual channels.
>
> Mike
>
> On 07/17/2013 06:12 PM, Paul Ivanov wrote:
> > Hey everyone,
> >
> > I hope this email finds you well. I got a request today from
> > someone wanting to look at the survey results. How do you feel
> > about just sharing the full document? We're at 580 responses
> > right now, and it's been really a slow trickle in last couple of
> > weeks after the initial splash. Or we could do another round on
> > twitter and G+ and say the survey will be closed at the end of
> > the month, and then release the results.
> >
> > Thoughts?
> >
> > best,
>
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP19: Continuous integration virtual meeting

2013-08-02 Thread Phil Elson

Sounds like a good idea to me.

In terms of when - I think the IPython guys have picked a good time (10am
US Pacific time, or 5pm GMT/UTC) to have the meeting to maximise the
attendance from the Americas and Europe, though I appreciate that no time
is perfect for everybody. For instance, I know Eric being in Hawaii–Aleutian
Time Zone that time would mean a 7am start, and for JJ, should he wish to
join in, it would be a 2am meeting... (for a clock of the places that may
need consideration see
http://www.timeanddate.com/worldclock/converted.html?iso=20130802T17&p1=0&p2=1358&p3=235&p4=263&p5=137&p6=103
).

Did you want to put a date on it Mike? How about we go for a week on
Tuesday, say the 2013-08-13 17:00Z (in your time: http://goo.gl/OnWHBq) -
though I'm open to moving it, if that doesn't fit with some of the core
contributors who would like to attend. If anybody who knows they would like
to attend could notify us here (along with their time zone), we could also
try to optimise the time to reduce unsociable hours :-) though we have to
acknowledge that there is no such thing as the perfect time...

Cheers,

On 1 August 2013 19:58, Michael Droettboom  wrote:

>
> (Apologies for cross-posting).
>
> matplotlib has a dire need to improve its continuous integration
> testing.  I've drafted MEP19 and solicited comments, but there hasn't
> been a lot of feedback thus far.
>
> As an alternative to mailing list discussion, where this sort of upfront
> planning can sometimes be difficult, I'm considering holding a Google
> Hangout in the next few weeks on the subject.  It's ok to participate
> even if you don't have the time to work on matplotlib -- I would also
> like feedback from advice from those that have configured similar
> systems for other projects.  matplotlib's needs are somewhat more
> complex in terms of dependencies, cpu, ram and storage, so we're pushing
> things pretty far here.
>
> If there's enough people with an interest in participating in the
> discussion, I'll send around a Doodle poll to find a good time.
>
> Mike
>
>
>
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP19: Continuous integration virtual meeting

2013-08-15 Thread Phil Elson

Just in case anybody who wanted to attend the discussion knows, this
meeting is taking place in ~40 minutes. (See
https://www.google.com/calendar/embed?src=79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com&ctz=America/New_Yorkas
linked from the matplotlib wiki).

Cheers,

Phil


On 5 August 2013 16:18, Michael Droettboom  wrote:

>  Ok -- I've redone it as 2 hour blocks -- we may not need that much time,
> but it seemed like the easiest way to make this work.
>
> Cheers,
> Mike
>
>
> On 08/05/2013 11:11 AM, Michael Droettboom wrote:
>
> Sorry -- bear with me -- I didn't mean to put in really large blocks of
> time like that.  Hold on as I try to fix this.
>
> On 08/05/2013 10:42 AM, Michael Droettboom wrote:
>
> I've set up a Doodle poll to find a good time.
>
> http://doodle.com/4f3yzii4vv7w93ai
>
> Most of the interesting parties are either in North America or Europe
> (sorry, Eric: you're the outlier).
>
> Cheers,
> Mike
>
> On 08/02/2013 10:05 PM, Matt Terry wrote:
>
> I don't have any useful experience with CI services, but it would be nice
> to have the ability to test on macos.
>
> On Aug 2, 2013 6:10 PM, "Benjamin Root"  wrote:
> >
> > +1 for me too
> >
> > Ben
> >
> > On Aug 2, 2013 11:04 AM, "Chris Beaumont"  wrote:
> >>
> >> I'd like to sit in on this if I'm available. Please keep me posted
> >>
> >> Cheers,
> >> Chris
> >>
> >>
> --
> >> Get your SQL database under version control now!
> >> Version control is standard for application code, but databases havent
> >> caught up. So what steps can you take to put your SQL databases under
> >> version control? Why should you start doing it? Read more to find out.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> >> ___
> >> Matplotlib-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >
> >
> --
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> > caught up. So what steps can you take to put your SQL databases under
> > version control? Why should you start doing it? Read more to find out.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > ___
> > Matplotlib-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find 
> out.http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
>
> ___
> Matplotlib-devel mailing 
> [email protected]://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find 
> out.http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
>
> ___
> Matplotlib-devel mailing 
> [email protected]://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find 
> out.http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
>
> ___
> Matplotlib-devel mailing 
> [email protected]://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> --
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>

Re: [matplotlib-devel] cartopy: test suite questions

2013-08-28 Thread Phil Elson

Thanks Andreas,

> I couldn't find any test runner script / method.

There is currently no "python setup.py tests" type runner (which would be
welcomed), but the obvious test runner is to use "nose" - something like
"nosetests cartopy" should do the trick. It'd also be very easy to put a
function in the cartopy.tests module so that one may run the tests with
"import cartopy.tests; cartopy.tests.run_all()" - if that'd encourage you
to run the tests, I'd be supportive of adding it :-)

> the test_img_nest.py script fails on my machine

Hmmm, yes, it makes use of the hardcoded path based on __file__ of cartopy.
It'd be pretty quick to change this to use the cartopy.config['data_dir']
location, which should be writeable. Would you mind opening an issue or if
you're keen a PR?

> Thanks for making cartopy, this is awesome :)

Cool. Glad you like it - there are still some issues to address, but in
principle it is looking very promising IMHO.

Cheers,

Phil



On 27 August 2013 17:22, andreas-h  wrote:

> Hi,
>
> I'm in the progress of packaging cartopy for Ubuntu. Some questions about
> the test suite:
>
> - I couldn't find any test runner script / method. It would be handy to
> have
> a script "run_tests.py" which performs all unit tests, or a method
> cartopy.run_tests(), or both. Otherwise, running the tests is a lot of
> manual work (which means it's less likely to happen).
>
> - the test_img_nest.py script fails on my machine (after installing the
> package), because it tries to write to the directory in which cartopy is
> installed. It would be better if filesystem write access would happen in
> some tempdir (which could be automatically cleaned up after the test).
>
> Thanks for making cartopy, this is awesome :)
>
> Cheers, Andreas.
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/cartopy-test-suite-questions-tp41914.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] master macosx backend broken?

2013-09-18 Thread Phil Elson

Is it time to have the discussion about dropping the MacOS backend?

I know an incredible amount of top quality developer time has gone into it,
but in truth it is not up to the *Agg backends and without another massive
amount of work, never will be. Not to mention the drag that having YAB (yet
another backend) to maintain and support adds.

Deleting the MacOS backend doesn't mean the end of its life - if somebody
cares enough they will probably set up a repo and maintain it themselves,
but I can think of a million and one things I'd sooner have matplotlib
developers working on than getting the MacOS backend upto the *Agg standard.

Thoughts?




On 18 September 2013 08:44, Eric Firing  wrote:

> On 2013/09/17 4:14 PM, Damon McDougall wrote:
> > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall
> >  wrote:
> >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing 
> wrote:
> >>> When I build mpl from master on python.org python 2.7, Mountain Lion,
> >>> and try to plot anything with the macosx backend, I am now getting an
> >>> Apple crash--the plot window flashes up and vanishes, and a big OS X
> >>> crash report window pops up.  Ipython shows "Trace/BPT trap: 5".  I
> have
> >>> never seen anything like this before.  Building from 1.3.0 works fine.
> >>>
> >>> Is anyone else seeing this?
> >>>
> >>> Master is also broken, at least on my machine, with other backends.
>  The
> >>> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431.
> >>>
> >>> Eric
> >>
> >> Building from master produces a broken build of matplotlib for me.
> >> After the build finishes, I get this warning from the linker:
> >>
> >> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was
> >> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0
> >> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the
> >> architecture being linked (i386): /opt/local/lib/libfreetype.dylib
> >>
> >> I don't know why it's compiling with -arch i386.  It's also compiling
> >> with -arch x86_64.
> >>
> >> When I install matplotlib, this is what happens from an ipython
> terminal:
> >>
> >> In [1]: import matplotlib
> >> In [2]: print matplotlib.__version__
> >> 1.4.x
> >> In [3]: matplotlib.use('macosx')
> >> In [4]: import matplotlib.pyplot as plt
> >> In [5]: fig = plt.figure()
> >> In [6]: ax = fig.add_subplot(1, 1, 1)
> >> In [7]: ax.plot([1, 2, 3])
> >> Out[7]: []
> >> In [8]: plt.show()
> >> Trace/BPT trap: 5
> >>
> >> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is
> >> the first bad commit, which you can see the diff of
> >> here<
> https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92
> >.
> >>   That's a pretty big commit so it'll take a while to track down.
> >>
> >> I'm kind of swamped with work right now (a colleague I work with
> >> recently resigned) so I don't have as much time as I'd like to
> >> dedicate to helping out.
> >>
> >> Eric, I hope that helps a little bit.
>
> Damon,
>
> More than a little bit, thank you!
>
> Eric
>
> >>
> >> Best wishes,
> >> Damon
> >>
> >> --
> >> Damon McDougall
> >> http://www.damon-is-a-geek.com
> >> Institute for Computational Engineering Sciences
> >> 201 E. 24th St.
> >> Stop C0200
> >> The University of Texas at Austin
> >> Austin, TX 78712-1229
> >
> > Oh, and I get the linker warning both with last good commit, *and* the
> > first bad commit.  Just as another data point.
> >
>
>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib 1.3.1

2013-09-18 Thread Phil Elson

Sounds good. I'll do what I can to close down some of the bugs too.

Now would also be a good time to announce a v1.4 date IMHO...


On 17 September 2013 22:54, Damon McDougall wrote:

> On Tue, Sep 17, 2013 at 8:03 AM, Michael Droettboom 
> wrote:
> > I think there's enough good bug fixes on 1.3.x now to warrant a 1.3.1
> > release.  We have 6 blocker and 12 known bugs on that branch still.  I
> > hope to devote some time to triaging and closing as many of these as I
> > can this week, and then maybe tagging a 1.3.1 release candidate early
> > next week.  As this is a bugfix release, I'm not feeling extremely
> > strict about closing all known bugs tagged 1.3.x -- it's worth closing
> > those we can, but anything more complex can wait so as not to delay
> > getting out the mass of existing bugfixes already on the branch.
> >
> > Any thoughts?
> >
>
> I like it!
>
> > Mike
> >
> > --
> > _
> > |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> > |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> >
> > http://www.droettboom.com
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.4.0 release schedule

2013-09-18 Thread Phil Elson

Wooho. New year, new release! It's going to be a busy Christmas :-)


On 18 September 2013 16:14, Michael Droettboom  wrote:

> Looking approximately six months after when 1.3.0 was released
> (31-07-2013, after much delay), puts us in the January timeframe for
> release candidates for 1.4.0.  I think that's preferable than to try to
> do anything during December.
>
> I've put the following dates in the calendar:
>
> January 8, 1.4.0rc1
> January 22, 1.4.0rc2
> February 5, 1.4.0final
>
> Does that make sense to everyone as a rough estimate?
>
> (On January 8, I will make a new maintenance branch for 1.4.x, so we
> won't need to "freeze" other work, but we may have a period where PRs
> will need to be manually merged from master into the maintenance branch
> as we put things together.)
>
> Mike
>
> --
> _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib user guide

2013-09-25 Thread Phil Elson

For the record, I've spoken to Mark about this face-to-face in the past,
and I think he has some great ideas about how the user guide should look.

Personally I would agree that the user guide is currently not targeted
enough (it takes 3 pages full of text before getting to a simple plt.plot()
) and even then, I don't think it is sympathetic enough to really new
users. Clearly matplotlib's success shows that the documentation must be
doing something right, but I think the user guide could definitely be
improved.

Mark, from what I remember your changes were along the lines of moving
sections around, and splitting some sections into beginner & advanced
pages. I think detailing a few examples of the types of changes you have in
mind might help us to have a bit more clarity on what you are proposing.

Thanks for getting involved in improving the docs!

On 25 September 2013 09:19, mark  wrote:

> hi matplotlib developers
>
> I have been considering the matplotlib user guide structure and it
> has occured to me that there are two user guides interleaved here:
>   1. Introduction for new users
>   2. Library tour for developers
>
> I think that this structure makes it challenging for new users to
> benefit from the user guide as much as they could.
>
> I would like to see the user guide separated into two sections, with
> the two different audiences in mind.  I feel this would enable new
> users of the library to have a more targeted introduction to some of
> the neat features without getting bogged down in details they are
> unlikely to need (or comprehend).
>
> I am very happy to have a go at this and put up a set of suggested
> changes but I would value input from the community on this approach and
> my category suggestions before I submit a pull request.
>
> many thanks
> mark
>
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] IPython Comm backend

2013-11-15 Thread Phil Elson

Very nice.
Thanks for sharing Jason.


On 15 November 2013 13:18, Jason Grout  wrote:

> On 11/14/13 7:24 PM, Jason Grout wrote:
> > Following a very helpful conversation with Michael this morning in the
> > dev hangout, I got this working with the current master (of matplotlib
> > and ipython).
>
> I also got this initial experimental demo working on the Sage cell server:
>
> http://sagecell.sagemath.org/?q=ilpajg (for a sage plotting example)
>
> http://sagecell.sagemath.org/?q=spadja (for one of the examples from the
> matplotlib docs)
>
> Thanks,
>
> Jason
>
>
>
> --
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] cartopy: Adding Andrew Dawson as a core developer of cartopy

2013-12-05 Thread Phil Elson

I'm very pleased to announce Andrew Dawson as a new core developer on the
cartopy project. As well as making significant contributions to many of the
fundamental components of cartopy, he has taken the time to extend
documentation, review other PRs and help users with issues raised on
github. Of particular note is Andrew's work on the reprojecting,
resampling, and visualisation of vector quantities which is providing a
step change in current cartopy capabilities
http://nbviewer.ipython.org/gist/pelson/7772265 and will inevitably feed
through into richer and more diverse scientific analyses for many
scientists.

Welcome aboard Andrew!
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Major re-write of triangulation in matplotlib

2013-12-20 Thread Phil Elson

Ian Thomas has been working on including some of the functionality from
Qhull into the matplotlib triangulation pipeline (
https://github.com/matplotlib/matplotlib/pull/2504).
After a thorough development and testing cycle this PR has now been merged
onto master, but I just wanted to give a shout-out to anybody who uses
triangulation in earnest so that you can give this new functionality a go
before we cut a release candidate for v1.4 on the 8th of January 2014.

If you encounter any problems, please feel free to open a github issue
which mentions @ianthomas23 .

Cheers,

Phil
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Plot or Not Results Summary

2014-01-27 Thread Phil Elson

I've only just seen this, but thanks for sharing! The blog post was well
thought out and very interesting.

I really liked the "latest" style idea - I think that is something that
gives us a bit of flexibility to change our minds about styles and continue
to keep everybody moving forward with enhanced output. Out of interest,
have you submitted your style to mpl master? I haven't seen anything go by,
and can't see any reason why it can't be included in master, even if it
isn't enabled by default. Essentially, I think Tony Yu et al.'s good work
needs to be stretched in this way to ensure we are making the most of the
new functionality, so please do submit PRs if there is something that can
be improved!

Cheers,

On 13 January 2014 19:58, Chris Beaumont  wrote:

> Hi Everyone,
>
> I found some time to look at the votes from the "Plot or Not?" experiment
> Adrian Price-Whelan and I ran during SciPy last summer. You can take a look
> at my summary at
> http://datarazzi.wordpress.com/2014/01/13/plot-or-not-voting-results/, or
> explore for yourself at http://plotornot.chrisbeaumont.org .
>
> Plot or Not was mostly a tongue-in-cheek idea, but there is nonetheless
> some interesting information about style preferences in these data. I'm
> happy to share the raw vote data if anyone is interested in digging further.
>
> Cheers,
> Chris Beaumont
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pycon 2014

2014-01-27 Thread Phil Elson

Sadly I wont be - it is a bit of a long way for a non-scientific
conference. Hoping to be able to attend SciPy again this year - there was a
strong mpl contingent and we had some really successful introductory
sprints held.

Cheers,


On 10 January 2014 14:49, Federico Ariza  wrote:

> Hello everybody
>
> Is anybody going to pycon 2014 in Montreal.
> Is there a sprint planned for that conference?
>
> Thanks
> Federico
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] "Examples" section misaligned

2014-01-27 Thread Phil Elson

Looks like there could be some white space around that block, as you say. (
https://raw.github.com/matplotlib/matplotlib/master/doc/contents.rst and
https://github.com/matplotlib/matplotlib/blob/master/doc/contents.rst).

Have you ever built the mpl docs? Are you interested in trying to fix this
and submitting a PR? I'd happily review and merge in time for the v1.4
release.

Phil


On 8 January 2014 09:21, Pierre Haessig  wrote:

> Hi,
>
> On the main doc page http://matplotlib.org/contents.html the "Examples"
> section is misaligned (because it gets surrounded by a blockquote tag).
> I guess it relates to the special treatment it gets in content.rst
> (https://raw2.github.com/matplotlib/matplotlib/master/doc/contents.rst).
> I don't know what magic is required to put it right (I always make
> alignment errors myself with Sphinx...). Maybe just add or remove one
> space ?
>
> best,
> Pierre
>
> (beyond this alignment issue, I feel like this small Examples link is a
> bit lost. It may deserve a stronger visual presence)
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP22 doc

2014-01-27 Thread Phil Elson

Hi Federico,

I just wanted to say that I've been a little busy lately, but your MEP is
really shaping up - I really like the concepts that are being proposed and
think it will make a huge difference to people who want to implement custom
UIs.

Keep up the great work, and continue trying to get feedback from all of us
on this!

Thanks,

Phil


On 24 January 2014 18:43, Federico Ariza  wrote:

> Hello everybody
>
> I just added some documentation for the MEP22 new classes and methods.
> Please take a look https://github.com/matplotlib/matplotlib/pull/2759
>
> I ran into some problems, when trying to decide if some methods where
> public or not.
>
> If the method was used only for backend implementation pourposes I put
> it as private (name starts with underscore) but still documented them
> in the Notes section of the class.
> I don't know if this is the correct way to do it, but I couldn't decide.
> If you prefer any other way to do it, please let me know.
>
> Thank you
> Federico
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Interactive matplotlib figures in the IPython notebook

2014-04-24 Thread Phil Elson

Cross posted to IPython-dev and mpl-dev.

Over the Easter holidays I had a chance to take a look at implementing a
new matplotlib backend which would allow interactive figures inline in the
IPython notebook. It's something that has been on the radar for a couple of
years now, with work needed from both projects to make the functionality
possible, so I'm pleased to have been able to submit a PR (
https://github.com/matplotlib/matplotlib/pull/3008) to matplotlib which
finally adds the nbagg backend - the final piece of the jigsaw.

It still needs a lot of polish, both at its core and superficially, but I
think it is at a stage which gives me confidence that the IPython Comm <->
mpl WebAgg approach is going to work to a reasonable degree, and is now at
a stage where it is readily usable by anybody running IPython >=2.0.

I really just wanted to draw your attention to the PR (early testers
welcome), and say thanks to everybody who has been involved in getting to
this stage, particularly Michael Droettboom, Jason Grout and everyone
involved in the IPython Comm interface.

Cheers,

Phil
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] [JOB] Scientific software engineer at the Met Office

2014-05-15 Thread Phil Elson

I just wanted to let you know that there is currently a vacancy for a
full-time developer at the Met Office, the UK's National Weather Service,
within our Analysis, Visualisation and Data (AVD) team.

I'm posting on this list as the Met Office's AVD team are heavily involved
in the development of Python packages to support the work that our
scientists undertake on a daily basis. The vast majority of the AVD team's
time is spent working on our own open source Python packages Iris, cartopy
and biggus as well as working on packages such as numpy, scipy, matplotlib
and IPython; so we don't see this as just a great opportunity to work
within a world class scientific organisation, but a role which will also
deliver real benefits to the wider scientific Python community.

Please see http://goo.gl/3ScFaZ for full details and how to apply, or
contact [email protected] if you have any questions.

Many Thanks,

Phil
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] tk backend broken (somehow?)

2014-11-17 Thread Phil Elson

Mike made some changes to this recently.
https://github.com/matplotlib/matplotlib/pull/3778

May be the cause.

On 16 November 2014 18:12, Benjamin Root  wrote:

> And with my continuing saga of backend-specific things...
>
> I was using conda, but because it does not ship with pygtk support, I had
> to manually install pygtk into the conda environment and then install
> matplotlib from source. All that seemed to work fine when I worked on Wx
> and Gtk examples for my book.
>
> I went back to a (previously working) Tk example to polish it, and I get
> all sorts of errors now. I have tried multiple releases of matplotlib from
> source (doing a git clean -fxd between them), all with similar errors. In
> fact, with master, the error causes a segfault:
>
> ben@tigger:~/Documents/InteractiveMPL$ python chp5/slider_tk.py
> Exception in Tkinter callback
> Traceback (most recent call last):
>   File "/home/ben/miniconda/lib/python2.7/lib-tk/Tkinter.py", line 1486,
> in __call__
> return self.func(*args)
>   File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> line 278, in resize
> self.show()
>   File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> line 350, in draw
> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
>   File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/tkagg.py",
> line 30, in blit
> id(data), colormode, id(bbox_array))
> TclError
> alloc: invalid block: 0x2cfe3b0: 0 0
> Aborted (core dumped)
>
> The line in question is (at least in v1.3.1, it is slightly different in
> more recent versions):
> tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode,
> id(bbox_array))
>
> This happens regardless of what example I use (my own or otherwise). There
> is no blit-specific code in the examples. All of this worked with the
> conda-supplied matplotlib, but never the
> from-source-into-a-conda-environment install.
>
> Thoughts?
> Ben Root
>
>
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend

2014-11-18 Thread Phil Elson

Isn't the XKCD stuff baked into the Agg backend. Is it even possible to
produce XKCD svg or PDFs?

On 18 November 2014 17:01, Jens Nielsen  wrote:

> I can reproduce it with the following traceback. Can you please open a bug
> report on Github for this issue?
>
> ```
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", line
> 59, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/figure.py", line
> 1079, in draw
> func(*args)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", line
> 59, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/axes/_base.py",
> line 2092, in draw
> a.draw(renderer)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", line
> 59, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line
> 712, in draw
> drawFunc(renderer, gc, tpath, affine.frozen())
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line
> 1067, in _draw_lines
> self._lineFunc(renderer, gc, path, trans)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line
> 1107, in _draw_solid
> renderer.draw_path(gc, path, trans)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py",
> line 115, in draw_path
> rgbFace)
>   File "/usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py",
> line 217, in draw_path
> renderer.draw_path(gc, tpath, affine, rgbFace)
>   File
> "/usr/local/lib/python2.7/site-packages/matplotlib/backends/backend_macosx.py",
> line 58, in draw_path
> gc.draw_path(path, transform, linewidth, rgbFace)
> AttributeError: GraphicsContextBase instance has no attribute 'draw_path'
> ```
>
> best
> Jens
>
> On Tue, Nov 18, 2014 at 4:12 PM, Mark Bakker  wrote:
>
>> Sorry, forgot to mention that: 1.4.0
>>
>> On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root  wrote:
>>
>>> Which version of matplotlib are you using?
>>>
>>> On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker  wrote:
>>>
 Hello list,

 I don't seem to get xkcd to work in the MacOSX backend. When I try to
 make a plot I get a nice white figure with nothing on it. Here's what I 
 did:

 import matplotlib.pyplot as plt
 %matplotlib # responds with Using matplotlib backend: MacOSX
 plt.plot([1,2,3])  # gives white figure with nothing on it

 When I do a kernel restart and specify the qt backend it works fine (so
 I have a workaround), but I presume it should work, right?

 Thanks,

 Mark



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration &
 more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 [email protected]
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


>>>
>>
>>
>> --
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> ___
>> Matplotlib-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboard

[matplotlib-devel] Matplotlib's new default colormap

2014-11-21 Thread Phil Elson

Please use this thread to discuss the best choice for a new *default*
matplotlib colormap.

This follows on from a discussion on the matplotlib-devel mailing list
entitled "How to move beyond JET as the default matplotlib colormap".

It is accepted that there can never be a *best* colormap for *all* data, so
some documentation on choosing an appropriate colormap for specific data
should always be sought. Nonetheless, matplotlib does need a default, and
it has been shown just how damaging the Jet (matplotlib's current default)
colormap really is, so we need to come up with a genuine alternative.

To keep this thread as useful as possible please avoid posting "+1" type
messages. If you'd like to suggest a colormap for consideration as
matplotlib's new *default* please try to keep to
reference-able/demonstrable fact.

Thanks,

Phil
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] How to move beyond JET as the default matplotlib colormap

2014-11-21 Thread Phil Elson

Many of you will be aware of there has been an ongoing issue (#875,
http://goo.gl/xLZvuL) which recommends the removal of Jet as the default
colormap in matplotlib.

The argument against Jet is compelling and I think that as a group who care
about high quality visualisation we should be seriously discussing how
matplotlib can move beyond Jet.

There was recently an open letter to the climate science community
 asking for
scientists to "pledge" against using rainbow like colormaps (such as Jet),
and there are similar initiatives in other scientific fields, as well as
there being a plethora of well researched literature on the subject.

As such, it's time to agree on a solution on how matplotlib can reach the
end of the rainbow.


The two major hurdles, AFAICS, to replacing the three little characters
which control the default colormap of matplotlib are:

 * We haven't had a clear (decisive) discussion about what we should
replace Jet with.
 * There are concerns about changing the default as it would change the
existing widespread behaviour.

To address the first point I'll start a new mailinglist thread (entitled
"Matplotlib's new default colormap") where new default colormap suggestions
can be made. The thread should strictly avoid "+1" type comments, and
generally try to stick to reference-able/demonstrable fact, rather than
opinion. There *will* be a difference of opinion, however the final
decision has to come down to the project lead (sorry Mike) who I know will
do whatever is necessary to make the best choice for matplotlib.

The second point is a reasonable response when we consider that matplotlib
as a project has no *clear* statement on backwards compatibility. As a
result, matplotlib is highly change averse between minor releases (to use
semantic versioning terms) and therefore changing the default colormap is
unpalatable in the v1.x release series. As a result I'd like to propose
that the next release of matplotlib be called 2.0, with the *only* major
backwards-incompatible change be the removal of Jet as the default colormap.

As a project matplotlib mustn't get caught up in the trap of shying away
from a major version release when the need arises, and in my opinion
helping our users to avoid using a misleading colormap is a worthy cause
for a v2.0.

Please try to keep this thread on the "how", and not on the "what" of the
replacement default colormap, for which there is a dedicated thread.

Thanks,

Phil

(#endrainbow)
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] How to move beyond JET as the default matplotlib colormap

2014-11-22 Thread Phil Elson

Given the workload that making a release causes, is it necessary to put out
a v1.4.3 at all? On a similar sounding argument, given that the removal of
CXX doesn't break user APIs, and has been on master for several weeks with
fewer than anticipated side-effects, do we even need a v1.5? Essentially,
what is the barrier from moving straight to a v2.0 in Feb?

What I'd like to avoid is this idea of "we're talking about a making a
major release so let's fix everything that was ever broken" - my definition
of a v2.0 release is really just v1.5+new default cmap. If there are other
things that need fixing in a backwards incompatible way then we should
discuss and plan how we are going to do that, and if there is developer
appetite, there is no reason not to talk about releasing a v3.0 in 18-24
months (which is currently ~2 mpl minor release cycles).


On 21 November 2014 18:56, Thomas Caswell  wrote:

> I am a bit wary of doing a 2.0 _just_ to change the color map, but when
> every I try to write out why, they don't sound convincing.  We may end up
> with a 3.0 within a year or so due to the possible plotting API/pyplot work
> that is (hopefully) coming.
>
> If we are going to do this, I think we should do the 1.4.3 release
> (scheduled for Feb 1, RCs in mid January), then put one commit to change
> the color map on top of that, tag 2.0 and then master turns into 2.1.x
> (targeted for right after scipy?).
>
> There is also the thought to get the major c++ refactor work tagged and
> released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
> 2.0 in Feb with 2.0 based off of 1.5 not 1.4.
>
> On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root  wrote:
>
>> As a point of clarification, is this proposed 2.0 release different from
>> the 1.5 release?
>>
>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson 
>> wrote:
>>
>>> Many of you will be aware of there has been an ongoing issue (#875,
>>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the
>>> default colormap in matplotlib.
>>>
>>> The argument against Jet is compelling and I think that as a group who
>>> care about high quality visualisation we should be seriously discussing how
>>> matplotlib can move beyond Jet.
>>>
>>> There was recently an open letter to the climate science community
>>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking for
>>> scientists to "pledge" against using rainbow like colormaps (such as Jet),
>>> and there are similar initiatives in other scientific fields, as well as
>>> there being a plethora of well researched literature on the subject.
>>>
>>> As such, it's time to agree on a solution on how matplotlib can reach
>>> the end of the rainbow.
>>>
>>>
>>> The two major hurdles, AFAICS, to replacing the three little characters
>>> which control the default colormap of matplotlib are:
>>>
>>>  * We haven't had a clear (decisive) discussion about what we should
>>> replace Jet with.
>>>  * There are concerns about changing the default as it would change the
>>> existing widespread behaviour.
>>>
>>> To address the first point I'll start a new mailinglist thread (entitled
>>> "Matplotlib's new default colormap") where new default colormap suggestions
>>> can be made. The thread should strictly avoid "+1" type comments, and
>>> generally try to stick to reference-able/demonstrable fact, rather than
>>> opinion. There *will* be a difference of opinion, however the final
>>> decision has to come down to the project lead (sorry Mike) who I know will
>>> do whatever is necessary to make the best choice for matplotlib.
>>>
>>> The second point is a reasonable response when we consider that
>>> matplotlib as a project has no *clear* statement on backwards
>>> compatibility. As a result, matplotlib is highly change averse between
>>> minor releases (to use semantic versioning terms) and therefore changing
>>> the default colormap is unpalatable in the v1.x release series. As a result
>>> I'd like to propose that the next release of matplotlib be called 2.0, with
>>> the *only* major backwards-incompatible change be the removal of Jet as
>>> the default colormap.
>>>
>>> As a project matplotlib mustn't get caught up in the trap of shying away
>>> from a major version release when the need arises, and in my opinion
>>> helping our users to avoid using a misleading colormap is a worthy cause
>>> for a v2.0.
>

[matplotlib-devel] Bloomberg Open source sprint, London, November 29-30 2014

2014-11-26 Thread Phil Elson

There will be an open source Python sprint, hosted by Bloomberg, this
weekend in London. The event will be attended by core developers of many of
the major scientific Python packages (IPython, numpy, scipy, pandas,
scikit-learn) who will act as mentors to those who would like to get
involved in the development of these important scientific tools.

I will be attending as a mentor for matplotlib (if there are any other core
developers who may be able to attend, the more the merrier!) and am hoping
there will be many attendees who want to get a helping hand getting started
with matplotlib development. We've got lots of room for improvement, from
the obvious documentation enhancements right through to the nitty-gritty of
improving backends such as nbagg.

If you want to come along to the event, please sign-up at
http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/
.

Hope you see some of you there,

Phil
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib's new default colormap

2014-12-22 Thread Phil Elson

Thanks for all the contributions so far. Looks like matplotlib is blessed
with people who are far more knowledgeable than I on the subject, and I'd
say we were pretty much at a consensus on requirements.

Given these requirements, what we need is some proposed colormaps - Max's
approach of generating an optimal solution in LAB space sounds interesting,
as do the other approaches of minimising some parameters of existing
colormaps.

To facilitate this discussion, do we need a repository of proposed
colormaps so that we can compare like with like? I notice that Mike Bostock
has an interesting post to show various color spaces in d3.js which may be
of interest http://bl.ocks.org/mbostock/3014589.



On 4 December 2014 at 14:38, Maximilian Albert 
wrote:

> Hi all,
>
> I had a discussion with Phil Elson about this last weekend during the
> Bloomberg Open Source Day. I don't consider myself an expert on colormaps
> by any means, but I started digging into them a while ago when I was
> looking for a way of generating a perceptually linear *cyclic* colormap in
> order to represent phase angle values. (I've been meaning to discuss this
> issue on this list for a while but will do so in a different thread once I
> get around to tidying up my results so far.) Phil encouraged me to reply to
> this thread because he said that even non-expert views would be very
> welcome, so here you go.
>
> Basically, I agree with most of what Nathaniel Smith suggested in his
> email from November 21. I'm going to comment on some of his points inline
> below and will finally suggest a way of designing a new colormap at the end.
>
>
> Nathaniel Smith wrote:
>
> > it should be a sequential colormap [...]
>
> Agreed.
>
> > it should be perceptually uniform
>
> Agreed.
>
> > There's lots of research on how to measure perceptual distance --
> > a colleague and I happen to have recently implemented a
> > state-of-the-art model of this for another project, in case anyone
> > wants to play with it [3].
>
> I haven't had time to check this out in detail yet, but it looks pretty
> interesting and will certainly be very useful to assess the quality of any
> suggestions. However, can this help to actually *design* a new colormap?
> The answer might be hidden in the referenced paper [Luo2006], but I haven't
> read it yet.
>
> > or just using good-old-L*a*b* is a reasonable quick-and-dirty
> approximation.
>
> Can you elaborate how "dirty" you think using L*a*b* would be? (See my
> suggestion for finding a new colormap below.)
>
> >- it should have a perceptually uniform luminance ramp, i.e. if you
> > convert to greyscale it should still be uniform.
>
> Agreed. What's unclear to me is how large this luminance ramp should be.
> We certainly can't go all the way to full luminance because this won't be
> visible on a white background. This probably needs experimenting (again see
> below).
>
> > - it should also have some kind of variation in hue, because
> > hue variation is a really helpful additional cue to perception,
> > having two cues is better than one, and there's no reason
> > not to do it.
>
> Agreed.
>
> > - the hue variation should be chosen to produce reasonable results
> > even for viewers with the more common types of colorblindness.
> > (Which rules out things like red-to-green.)
>
> Agreed. Are you aware of any simple ways of avoiding the most common
> issues? Are there any blog posts or papers on designing colormaps that are
> suitable for colorblind people?
>
> > And, for bonus points, it would be nice to choose a hue ramp that
> > still works if you throw away the luminance variation, because then we
> > could use the version with varying luminance for 2d plots, and the
> > version with just hue variation for 3d plots. (In 3d plots you really
> > want to reserve the luminance channel for lighting/shading, because
> > your brain is *really* good at extracting 3d shape from luminance
> > variation. If the 3d surface itself has massively varying luminance
> > then this screws up the ability to see shape.)
>
> Just out of interest, is there currently an easy way in matplotlib of
> producing a 3d plot where luminance is used for lighting/shading as you
> suggest?
>
>
> Now the question is: how do we actually *design* a colormap with these
> requirements? Leon Krischer's notebook [1] looks totally awesome, but if I
> understand correctly the optimisation he uses "only" takes care of
> linearising the luminance value, but this does not necessarily guarantee
> that the hue values are also linear, right? It also feels somewhat c

Re: [matplotlib-devel] Matplotlib's new default colormap

2014-12-22 Thread Phil Elson

P.S. I just found
http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker

On 22 December 2014 at 11:21, Phil Elson  wrote:

> Thanks for all the contributions so far. Looks like matplotlib is blessed
> with people who are far more knowledgeable than I on the subject, and I'd
> say we were pretty much at a consensus on requirements.
>
> Given these requirements, what we need is some proposed colormaps - Max's
> approach of generating an optimal solution in LAB space sounds interesting,
> as do the other approaches of minimising some parameters of existing
> colormaps.
>
> To facilitate this discussion, do we need a repository of proposed
> colormaps so that we can compare like with like? I notice that Mike Bostock
> has an interesting post to show various color spaces in d3.js which may be
> of interest http://bl.ocks.org/mbostock/3014589.
>
>
>
> On 4 December 2014 at 14:38, Maximilian Albert <
> [email protected]> wrote:
>
>> Hi all,
>>
>> I had a discussion with Phil Elson about this last weekend during the
>> Bloomberg Open Source Day. I don't consider myself an expert on colormaps
>> by any means, but I started digging into them a while ago when I was
>> looking for a way of generating a perceptually linear *cyclic* colormap in
>> order to represent phase angle values. (I've been meaning to discuss this
>> issue on this list for a while but will do so in a different thread once I
>> get around to tidying up my results so far.) Phil encouraged me to reply to
>> this thread because he said that even non-expert views would be very
>> welcome, so here you go.
>>
>> Basically, I agree with most of what Nathaniel Smith suggested in his
>> email from November 21. I'm going to comment on some of his points inline
>> below and will finally suggest a way of designing a new colormap at the end.
>>
>>
>> Nathaniel Smith wrote:
>>
>> > it should be a sequential colormap [...]
>>
>> Agreed.
>>
>> > it should be perceptually uniform
>>
>> Agreed.
>>
>> > There's lots of research on how to measure perceptual distance --
>> > a colleague and I happen to have recently implemented a
>> > state-of-the-art model of this for another project, in case anyone
>> > wants to play with it [3].
>>
>> I haven't had time to check this out in detail yet, but it looks pretty
>> interesting and will certainly be very useful to assess the quality of any
>> suggestions. However, can this help to actually *design* a new colormap?
>> The answer might be hidden in the referenced paper [Luo2006], but I haven't
>> read it yet.
>>
>> > or just using good-old-L*a*b* is a reasonable quick-and-dirty
>> approximation.
>>
>> Can you elaborate how "dirty" you think using L*a*b* would be? (See my
>> suggestion for finding a new colormap below.)
>>
>> >- it should have a perceptually uniform luminance ramp, i.e. if you
>> > convert to greyscale it should still be uniform.
>>
>> Agreed. What's unclear to me is how large this luminance ramp should be.
>> We certainly can't go all the way to full luminance because this won't be
>> visible on a white background. This probably needs experimenting (again see
>> below).
>>
>> > - it should also have some kind of variation in hue, because
>> > hue variation is a really helpful additional cue to perception,
>> > having two cues is better than one, and there's no reason
>> > not to do it.
>>
>> Agreed.
>>
>> > - the hue variation should be chosen to produce reasonable results
>> > even for viewers with the more common types of colorblindness.
>> > (Which rules out things like red-to-green.)
>>
>> Agreed. Are you aware of any simple ways of avoiding the most common
>> issues? Are there any blog posts or papers on designing colormaps that are
>> suitable for colorblind people?
>>
>> > And, for bonus points, it would be nice to choose a hue ramp that
>> > still works if you throw away the luminance variation, because then we
>> > could use the version with varying luminance for 2d plots, and the
>> > version with just hue variation for 3d plots. (In 3d plots you really
>> > want to reserve the luminance channel for lighting/shading, because
>> > your brain is *really* good at extracting 3d shape from luminance
>> > variation. If the 3d surface itself has massively varying luminance
>> > then this screws up the ability to see shape.)
>>
>>

[matplotlib-devel] Season's greetings from matplotlib

2014-12-24 Thread Phil Elson

If working on XKCD style plotting for matplotlib taught me anything, it is
that playing with software in a way that it was not originally designed to
do can lead to some excellent discoveries (bugs) and generate new ideas and
generalisations - not to mention it being a lot of fun!

So, in that vein, I wanted to put together a simple Christmas e-card using
matplotlib. My main aim was to re-purpose some of the familiar matplotlib
functionality to generate a simple festive animation.

I decided to go for a snowy scene, with a snow-capped greeting and sprig of
holly. The snow is simply a scatter plot scaled by flake size and animated
to fall in a pleasing way. The text is making use of the path effects
functionality extended in v1.4 to add randomised "snow" around the text
(the same effect employed by XKCD as it happens). And the holly is a nice
demonstration of the power of Paths and vector rendering in matplotlib.

The source can be found at
https://gist.github.com/pelson/ca795a02a420a1b9bfbc, and it requires
matplotlib >= v1.4.

If you're impatient and don't want to run the code (don't do it), the
animation is available on YouTube at
https://www.youtube.com/watch?v=POnAkPpe770.

Finally, to all those taking some time off this festive season, I wish you
a very happy holiday and wish you all the best for the new year.

Phil Elson
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.4.3rc1

2015-02-05 Thread Phil Elson

Awesome work! Full credit to Tom who has driven this release.

The nbagg backend is looking great - some pretty swish new features thanks
to hard work from Steven Silvester and Thomas Caswell!

On 2 February 2015 at 10:58, Jens Nielsen  wrote:

> Thanks Tom,
>
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2
> including the tex and QT4 tests that are skipped on Travis.
> Everything passes as expected.
>
> Jens
>
> Mon Feb 02 2015 at 5:38:32 AM skrev Thomas Caswell :
>
> Evening all,
>>
>> I have tagged the first release candidate for v1.4.3 (https://github.com/
>> matplotlib/matplotlib/releases/tag/v1.4.3rc1).
>>
>> Although this is a bug-fix release, a fair amount of work has gone into
>> making the nbagg (interactive figures in ipython notebooks) feature
>> complete compared to the other interactive backends.
>>
>> Please kick the tires and give it a try!  If there are no major issues,
>> the plan is to target 1.4.3 for next weekend.
>>
>> The mac build has been started and (if I understand how these things
>> work) should be available to install via
>> pip install -f http://wheels.scikit-image.org --pre matplotlib  soon.
>>
>> For linux anaconda users, packages for 2.6/2.7 python  on my binstar
>> channel (conda install -c https://conda.binstar.org/tacaswell
>> matplotlib). The py3k builds have some issue with invalid syntax in pyqt4,
>> if some knows how to build these, please let me know.
>>
>>
>> Tom
>>
>>
>> 
>> --
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> ___
>> Matplotlib-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> --
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] [ANN] Cartopy v0.12 release candidate

2015-03-13 Thread Phil Elson

I'm pleased to announce that cartopy v0.12.0rc1 has been tagged.

This release has focused on improving the geometry projection stability,
improving interfaces for data ingestion, rounding
off Python 3 support, and generally improving the breadth of the gallery.
A full overview of what's new in this release can be found at
http://scitools.org.uk/cartopy/docs/v0.12/whats_new.html.

About cartopy
--

Cartopy is a Python package designed to make drawing maps for data analysis
and visualisation easy.

It features:

   - object-oriented projection definitions
   - point, line, polygon, vector and image transformations between
   projections
   - integration to expose advanced mapping in matplotlib with a simple and
   intuitive interface
   - powerful vector data handling by integrating shapefile reading with
   Shapely capabilities


Installing cartopy
-

Installation of the release candidate and its dependencies with conda:

*conda install cartopy** --channel scitools/channel/dev*

Installing cartopy using pip requires GEOS and proj4 to be installed prior
to running:

*pip install cartopy*

Thanks to everybody who contributed towards this release,

Best,

Phil Elson
(github: @pelson | twitter: @pypelson)
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Fwd: SciPy 2015 CFP Email 2

2015-03-13 Thread Phil Elson

Orchestrating MPL tutorials and talks in this thread would be a good idea.
I'd be happy to help anybody planning on submitting anything relating
specifically to matplotlib, and wonder if we should do a "state of
matplotlib" type talk similar to the one Mike did 2 years ago.

On 13 March 2015 at 02:05, Benjamin Root  wrote:

> Yes, I plan to submit my time-honored, and requested "Anatomy of
> Matplotlib" tutorial. Now, I am not entirely sure I will be able to attend
> the conference this year, so perhaps someone else might be willing to step
> in and give it this year?
>
> Note that my tutorial is geared for beginners. So there is still plenty of
> opportunity for someone else to submit a tutorial for more advanced users!
>
> Cheers!
> Ben Root
>
> On Thu, Mar 12, 2015 at 6:46 PM, Nelle Varoquaux <
> [email protected]> wrote:
>
>> Hi everyone,
>>
>> Is someone submitting a tutorial on matplotlib? The call for tutorial is
>> open, and I think it would be nice to have one on matplotlib.
>>
>> Cheers,
>> N
>>
>> -- Forwarded message --
>> From: SciPy 2015 Organizers 
>> Date: 11 March 2015 at 01:02
>> Subject: SciPy 2015 CFP Email 2
>> To: [email protected]
>>
>>
>>   [image: SciPy 2015 Logo]
>> 
>>
>>Tick-Tock, Tick-Tock:
>> T-Minus 6 Days for Tutorial Submissions
>>  *Due Date: March 16, 2015*
>>
>> The SciPy experience kicks off with two days of tutorials
>> 
>> (July 6-7). These sessions provide extremely affordable access to expert
>> training, and consistently receive fantastic feedback from participants.
>> We're looking for submissions on topics from introductory to advanced -
>> we'll have attendees across the gamut looking to learn. Plus, you can earn
>> an instructor stipend to apply towards your conference participation. Visit
>> the SciPy 2015 website for details
>> 
>> or submit a proposal here
>> 
>> .
>>
>>   Submit a Tutorial Proposal Here
>> 
>>  Talk
>> and Poster Proposals Due April 1st
>>
>> There's always something new and exciting going on in the world of
>> Science + Python, this is your chance to get up and talk about it!
>>
>> *Visit the SciPy 2015 website
>> 
>> for full details or click here to submit a proposal
>> .*
>> Choose a topic in one of the 3 main conference tracks:
>>
>>- Scientific Computing in Python (General track)
>>- Python in Data Science
>>- Quantitative and Computational Social Sciences
>>
>> * And/or submit for one of the 7 domain-specific mini-symposia
>> :*
>>
>>- Astronomy and astrophysics
>>- Computational life and medical sciences
>>- Engineering
>>- Geographic information systems (GIS)
>>- Geophysics
>>- Oceanography and meteorology
>>- Visualization, vision and imaging
>>
>>   Submit a Talk or Poster Proposal Here
>> 
>>Need
>> some inspiration? Follow @SciPy on Twitter
>> 
>> for highlights from previous SciPy conferences and all of the latest 2015
>> updates.
>>
>>- Previous year's conferences with talk information
>>
>> 
>> - SciPy 2014 Talk & Tutorial Video playlist
>>
>> 
>>- SciPy 2013 Talk & Tu

Re: [matplotlib-devel] Colormap survey results

2015-07-06 Thread Phil Elson

For what it is worth, if D were made the default colormap, I would be very
happy.

On 1 July 2015 at 22:35, Thomas Caswell  wrote:

> We would like to tag 1.5 around scipy and it would be nice to get the new
> color maps out, even if they are not yet the default.
>
> On Wed, Jul 1, 2015, 11:13 PM Nathaniel Smith  wrote:
>
>> On Jul 1, 2015 6:31 PM, "Eric Firing"  wrote:
>> >
>> > On 2015/07/01 1:56 PM, Nathaniel Smith wrote:
>> > > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith 
>> wrote:
>> > >
>> > > [...snip discussion of how option D was the favorite of 80% of people
>> > > in the survey...]
>> > >
>> > >> So the next question is where we go from here.
>> >
>> > One thing we need to do is get some of these maps into  _cm.py via PR.
>>
>> We've been a bit distracted getting the software and talk together ahead
>> of scipy, but PR (with names) will follow within the next week or so. The
>> decision part is pretty orthogonal though I think? It's not like matplotlib
>> 2.0 is going to branch between now and scipy :-).
>>
>> > I would prefer not to have them go in as huge tables if they can be made
>> > more compact, either by being function-generated or by using the
>> > LinearSegmentedColormap mechanism with a moderate number of breakpoints.
>> >
>> > Suggestions?
>>
>> Depends on how you define "moderate", but my guess is that linear
>> segmented is the best approach -- the exact colormaps have a pretty terse
>> representation as bezier control points, but using this at runtime would
>> require pulling in the full colorspace apparatus as a dependency. Which I
>> guess has points in its favor for other reasons, but nonetheless.
>>
>> These kinds of details can be worked out in the PR review process,
>> though. The blocking issue is that we need a decision :-).
>>
>> -n
>>
>> --
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> ___
>> Matplotlib-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Dev build on matplotlib with conda

2015-07-22 Thread Phil Elson

Are you wanting to link against anything other than that installed with
conda?
The output of setup.py is normally pretty helpful at letting you know which
library it has found to build against.

On 20 July 2015 at 01:54, Brian Granger  wrote:

> Hi all,
>
> I am trying to get a dev build of matplotlib working with the anaconda
> python.
>
> Any advice on getting matplotlib to detect and use any of the
> libpng/freetypes:
>
> * Those installed with anaconda python.
> * Those from homebrew
> * Those that ship with OS X
>
> Cheers,
>
> Brian
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> [email protected] and [email protected]
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

84 matches

Mail list logo