matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] nxutils

[Benjamin R. <ben...@ou...>]

Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if
I remember right, Path uses that to calculate contains().

Ben Root

On Thursday, November 17, 2011, Eric Firing <ef...@ha...> wrote:
> On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> Most of what was in nxutils has been superseded by things in Numpy, and
>> it makes more sense for it to be over there.
>>
>> In the case of points_inside_poly, you can use the Path object in
>> path.py and the "contains_point" method.
>>
>> Mike
>
> Mike,
>
> This, however, brings us back to the plea by Volker Blum:
>
>
http://www.mail-archive.com/mat...@li.../msg22669.html
>
> There is a real tension between the need to clean things up and simplify
> them, and users' desire for minimal loss of backwards compatibility.
> Personally, my instincts are in the "clean it up" camp, but a good
> balance has to be found.
>
> nxutils was definitely a vestige of an earlier era; but I don't think it
> went through any official, publicized, deprecation process, did it?
> Maybe it didn't need to; I don't know.  Perhaps we need to formulate and
> write down a deprecation policy.
>
> Eric
>
>>
>> On 11/17/2011 12:03 PM, James Evans wrote:
>>>
>>> All,
>>>
>>> I have not touched the code for several months, so it has taken me up
>>> until just now to realize that nxutils has been removed from the build.
>>>
>>> I there any real reason for this? Particularly when you consider that
>>> there are still functions present that use it and now they just fail.
>>>
>>> In particular I am referring to ‘mlab.inside_poly’. In my case I was
>>> using ‘nxutils.points_inside_poly’ directly, but the end result is the
>>> same.
>>>
>>> Thanks,
>>>
>>> --James Evans
>>>
>>>
>>>
>>>
------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>>
------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] nxutils

[Eric F. <ef...@ha...>]

On 11/17/2011 10:19 AM, Michael Droettboom wrote:
> Most of what was in nxutils has been superseded by things in Numpy, and
> it makes more sense for it to be over there.
>
> In the case of points_inside_poly, you can use the Path object in
> path.py and the "contains_point" method.
>
> Mike

Mike,

This, however, brings us back to the plea by Volker Blum:

http://www.mail-archive.com/mat...@li.../msg22669.html

There is a real tension between the need to clean things up and simplify 
them, and users' desire for minimal loss of backwards compatibility. 
Personally, my instincts are in the "clean it up" camp, but a good 
balance has to be found.

nxutils was definitely a vestige of an earlier era; but I don't think it 
went through any official, publicized, deprecation process, did it? 
Maybe it didn't need to; I don't know.  Perhaps we need to formulate and 
write down a deprecation policy.

Eric

>
> On 11/17/2011 12:03 PM, James Evans wrote:
>>
>> All,
>>
>> I have not touched the code for several months, so it has taken me up
>> until just now to realize that nxutils has been removed from the build.
>>
>> I there any real reason for this? Particularly when you consider that
>> there are still functions present that use it and now they just fail.
>>
>> In particular I am referring to ‘mlab.inside_poly’. In my case I was
>> using ‘nxutils.points_inside_poly’ directly, but the end result is the
>> same.
>>
>> Thanks,
>>
>> --James Evans
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] nxutils

[Michael D. <md...@st...>]

Most of what was in nxutils has been superseded by things in Numpy, and 
it makes more sense for it to be over there.

In the case of points_inside_poly, you can use the Path object in 
path.py and the "contains_point" method.

Mike

On 11/17/2011 12:03 PM, James Evans wrote:
>
> All,
>
> I have not touched the code for several months, so it has taken me up 
> until just now to realize that nxutils has been removed from the build.
>
> I there any real reason for this? Particularly when you consider that 
> there are still functions present that use it and now they just fail.
>
> In particular I am referring to 'mlab.inside_poly'.  In my case I was 
> using 'nxutils.points_inside_poly' directly, but the end result is the 
> same.
>
> Thanks,
>
> --James Evans
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] nxutils

[James E. <jre...@ea...>]

All,

 

I have not touched the code for several months, so it has taken me up until
just now to realize that nxutils has been removed from the build.

 

I there any real reason for this? Particularly when you consider that there
are still functions present that use it and now they just fail.

 

In particular I am referring to 'mlab.inside_poly'.  In my case I was using
'nxutils.points_inside_poly' directly, but the end result is the same.

 

Thanks,

--James Evans

 

Re: [matplotlib-devel] Another colormap

[Tony Yu <ts...@gm...>]

On Fri, Sep 23, 2011 at 1:27 AM, Nathaniel Smith <nj...@po...> wrote:

> On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root <ben...@ou...> wrote:
> > On Thursday, September 22, 2011, Tony Yu <ts...@gm...> wrote:
> >> On Thu, Sep 22, 2011 at 5:16 PM, Nathaniel Smith <nj...@po...> wrote:
> >>> I looked at the paper, and the goal was specifically to produce a good
> >>> "default" colormap - not necessarily the best for any situation, but
> good
> >>> overall and certainly better than the rainbow ('jet') colormap in most
> >>> cases. (I agree with the author that jet is pretty terrible and tends
> to
> >>> distort data.)
> >>>
> >>> Should we switch to this as the default matplotlib colormap? I think it
> >>> would be a clear improvement.
> >>
> >> I have absolutely no clout here, but I'd definitely be in favor of
> >> changing the default colormap away from "jet".
> >>
> >> Personally, I'd prefer a two-tone colormap as the default (two-distinct
> >> tones at the limits with a gradient in-between---dubbed "sequential" in
> the
> >> paper) instead of a three-tone colormap (three-distinct tones---dubbed
> >> "diverging" in the paper). (I think this is a more common use case, and
> I
> >> think using a "diverging" colormap effectively requires setting
> vmin/vmax.)
> >> But really, (almost) anything is better than "jet".
>
> For those following along, the article is here:
> http://www.cs.unm.edu/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
> The discussion about whether to use a "sequential" or "diverging" map
> is in section 3.
>
> I had the same gut reaction as you, but found the paper fairly
> convincing. I'm used to diverging maps that really highlight the
> center point, like matplotlib's RdBu colormap, and use them all the
> time for data where the zero point really matters (and set vmin/vmax
> appropriately, like you say). But this colormap is actually really
> different from the ones I'm used to, because it's really designed
> *not* to highlight the center point as being special. The clearest
> example of this is Figure 8 in the paper -- the image on the left is
> the one that you'd get from something like RdBu, and the one on the
> right is what this colormap produces. And, like he says, it gives you
> better detail than a sequential map could.
>
> I actually *wouldn't* want to use this for images that I currently use
> RdBu for. But I'm picky -- the map he suggests would still make a heck
> of a better colormap for those images than jet does, and Rdbu *really*
> isn't appropriate for general use.
>
> On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root <ben...@ou...> wrote:
> > Anyway, this is certainly is worthy of debate, but it certainly won't
> happen
> > for this release.  We should be cutting RC tomorrow.
> >
> > After the release, I encourage you guys to make your cases.  Show us
> plots
> > that have been in "jet" and show them as better in another colormap.
>
> Figure 16 in that paper (page 17) is a good start. In the examples
> given, for both of the top two jet actively distorts the features of
> the data. In row 1, it makes it look like the bars taper off as you
> move towards the top of the image, which they don't (compare to the
> greyscale image for reference). In row 2, it makes it look like the
> "circles" vary in size across the image (which, again, they don't). In
> the bottom two images, jet introduces apparent asymmetries that aren't
> there: in row 3, you have these 5 apparent stripes of unequal width,
> and the yellow is narrower than the cyan. In row 4, well, it's just
> obviously terribly misleading. (This isn't surprising, since 'jet'
> sweeps through the frequencies of visible light; the big band of
> yellow in simulated deuteranope vision corresponds to where they're
> missing one of the spectral sensors that most of us have.)
>
> If you want more examples though I can certainly pull some out of my
> thesis :-).
>
> > As a bit of a challenge to you all, I am not color-blind, but I do wear
> > tinted glasses that make it difficult to tell the difference between
> darker
> > blues and black, and sometimes greens and blues are hard to distinguish.
> >  Furthermore, as a radar meteorologist, I am very accustomed to the
> > colormaps commonly used for radar reflectivies (and is similar to "jet").
>
> No colormap is going to be perfect for everyone, and maybe someone
> else will pop up with a pointer to a map that's even better supported
> than this one. I just think that jet has sufficiently manifest flaws
> that it would be a great favor to science if we could switch to
> *something* better as our default.
>
> -- Nathaniel
>

Continuing with Nathaniel's arguments, I think the article [1] you posted
to the user list [2] recently makes a pretty good argument against using
jet. (Although this isn't really the main point of the article.)

Basically, it suggests that the jet colormap leads to bands of data (i.e.
"incorrectly gives the impression that there are just a few values in the
data"). This reduces visual contrast of data within those bands and
inflates the contrast of data in adjacent bands.

[1] https://www.research.ibm.com/people/l/lloydt/color/color.HTM
[2]
http://old.nabble.com/Visualizing-data-for-scientists-and-engineers-td32852270.html

As a personal pet peeve, it's just not an intuitive color sequence to me.
Sure, I know that the colors in "jet" more-or-less match the color wheel,
but I have to stop and think about the fact that yellow is larger than
green, for example. Plus it's not at all intuitive that green is halfway in
between blue and red (which are the extremes of the colormap).

I'm curious if there are any arguments for using jet/rainbow. I guess
inertia/familiarity would be one. (But even though people are familiar with
it, I doubt most would even know that green is midway between blue and
red.) I guess it also magnifies the intensity range (since it uses 5-ish
distinct colors instead of 2 or 3), but I doubt the noticeable range is
that different than the coolwarm colormap, for example.

Best,
-Tony

P.S. Below is some simple code (mostly ripped from a gallery example) to
compare colormaps. It's pretty easy to the banding effect in the jet plot.

#----
mport numpy as np
import matplotlib.pyplot as plt

X,Y=np.mgrid[-5:5:0.05,-5:5:0.05]
Z=np.sqrt(X**2+Y**2)+np.sin(X**2+Y**2)

for cmap in (plt.cm.jet, plt.cm.coolwarm, plt.cm.BuPu, plt.cm.OrRd,
plt.cm.gray):
    plt.figure()
    plt.imshow(Z, cmap=cmap)

plt.show()

Re: [matplotlib-devel] Heads-up: master badly broken, syntaxerror in setup.py

[Michael D. <md...@st...>]

This should now be fixed.

Mike

On 11/17/2011 02:40 AM, Jens Nielsen wrote:
> It works in python3
>
> The python statement in python2.7 (and 2.6) does not support the end argument.
> Adding a "from __future__ import print_function" to the beginning of
> setup.py seems to fix it.
>
> Greetings Jens
>
> On Thu, Nov 17, 2011 at 5:03 AM, Fernando Perez<fpe...@gm...>  wrote:
>> (master)longs[matplotlib]>  python setup.py
>>   File "setup.py", line 281
>>     (float(i) / len(filtered) * 100.0), end='\r')
>>                                            ^
>> SyntaxError: invalid syntax
>>
>>
>> Sorry, can't debug it right now...
>>
>> f
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] colorbar extension size

[Andrew D. <aj...@gm...>]

I forgot to include the link to the Github compare page in my last message:

http://github.com/ajdawson/matplotlib/compare/master...colorbar-extensions

Andrew

On 16 November 2011 12:19, Andrew Dawson <aj...@gm...> wrote:

> I would like some feedback on a new feature I have developed to control
> the length of colorbar extension triangles. This is a feature I have
> desired for some time, so that the plots I produce with matplotlib can be
> more consistent with those produced from other popular plotting software
> (e.g., IDL). I have added a new keyword argument, extendfrac, to the
> ColorbarBase class. This may be set to a scalar, a two-tuple, the string
> 'auto', or  the string 'default'. The behaviour of this keyword depends on
> the setting of the existing spacing keyword argument.
>
> For spacing='uniform' or spacing='proportional':
>     extendfrac=None - sets the lengths of both the minimum and maximum
> colorbar extension triangles to 0.05 times the interior colorbar length
> (the existing hard-coded setting).
>     extendfrac='default' - same as None.
>     extendfrac=FRACTION - sets the lengths of both the minimum and maximum
> colorbar extension triangles to the given fraction of the interior colorbar
> length.
>
> For spacing='uniform':
>     extendfrac='auto' - sets the lengths of both the minimum and maximum
> colorbar extension triangles to be the same as the length of the interior
> boxes.
>
> For spacing='proportional':
>     extendfrac='auto' - sets the length of the minimum colorbar extension
> triangle to the length of the left/bottom-most interior box, and the length
> of the maximum colorbar extension triangle to the length of the
> right/top-most interior box.
>     extendfrac=(FRACTION1, FRACTION2) - as for FRACTION above but the
> minimum and maximum extension triangles may be different lengths.
>
> This is quite a small modification actually, but it does change the API
> for colorbars. I am wondering if this could be included in matplotlib? I
> have set up a fork of matplotlib on Github to implement this feature, if
> anyone thinks it is worth it...
>
> Andrew
>
>

Re: [matplotlib-devel] Heads-up: master badly broken, syntaxerror in setup.py

[Jens N. <jen...@gm...>]

It works in python3

The python statement in python2.7 (and 2.6) does not support the end argument.
Adding a "from __future__ import print_function" to the beginning of
setup.py seems to fix it.

Greetings Jens

On Thu, Nov 17, 2011 at 5:03 AM, Fernando Perez <fpe...@gm...> wrote:
> (master)longs[matplotlib]> python setup.py
>  File "setup.py", line 281
>    (float(i) / len(filtered) * 100.0), end='\r')
>                                           ^
> SyntaxError: invalid syntax
>
>
> Sorry, can't debug it right now...
>
> f
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Heads-up: master badly broken, syntaxerror in setup.py

[Fernando P. <fpe...@gm...>]

(master)longs[matplotlib]> python setup.py
  File "setup.py", line 281
    (float(i) / len(filtered) * 100.0), end='\r')
                                           ^
SyntaxError: invalid syntax


Sorry, can't debug it right now...

f

[matplotlib-devel] colorbar extension size

[Andrew D. <aj...@gm...>]

I would like some feedback on a new feature I have developed to control the
length of colorbar extension triangles. This is a feature I have desired
for some time, so that the plots I produce with matplotlib can be more
consistent with those produced from other popular plotting software (e.g.,
IDL). I have added a new keyword argument, extendfrac, to the ColorbarBase
class. This may be set to a scalar, a two-tuple, the string 'auto', or  the
string 'default'. The behaviour of this keyword depends on the setting of
the existing spacing keyword argument.

For spacing='uniform' or spacing='proportional':
    extendfrac=None - sets the lengths of both the minimum and maximum
colorbar extension triangles to 0.05 times the interior colorbar length
(the existing hard-coded setting).
    extendfrac='default' - same as None.
    extendfrac=FRACTION - sets the lengths of both the minimum and maximum
colorbar extension triangles to the given fraction of the interior colorbar
length.

For spacing='uniform':
    extendfrac='auto' - sets the lengths of both the minimum and maximum
colorbar extension triangles to be the same as the length of the interior
boxes.

For spacing='proportional':
    extendfrac='auto' - sets the length of the minimum colorbar extension
triangle to the length of the left/bottom-most interior box, and the length
of the maximum colorbar extension triangle to the length of the
right/top-most interior box.
    extendfrac=(FRACTION1, FRACTION2) - as for FRACTION above but the
minimum and maximum extension triangles may be different lengths.

This is quite a small modification actually, but it does change the API for
colorbars. I am wondering if this could be included in matplotlib? I have
set up a fork of matplotlib on Github to implement this feature, if anyone
thinks it is worth it...

Andrew

Re: [matplotlib-devel] GTK3 backend for matplotlib?

[Michael D. <md...@st...>]

Thanks.  I spent about a day last week working on this as well -- I have 
a local branch for it.  When I get the chance, I'll have a look at this 
and compare notes.  Submitting a github pull request would be great if 
you're able.

Mike

On 11/15/2011 11:04 AM, jrj...@gm... wrote:
> Hi
>
> Is anyone working on a Gtk3 backend for matplotlib that use the pygobject API?
>
> I could not find any information about how to use the matplotlib with
> Gtk3, so I started to port the Gtk2 backend to the pygobject API, and
> using the cairo backend for renderering.
>
> I'm attaching a tarboll that contains the backend_gtk3.py file and
> some test scripts for embedding a matplotlib figure in Gtk3
> applications using that backend. I think it works alright for the use
> cases that I've been able to test, so it might be a good starting
> point for a Gtk3 backend if there are no other attempts to create such
> a backend already.
>
> Best regards
> Robert
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

[matplotlib-devel] GTK3 backend for matplotlib?

[<jrj...@gm...>]

Hi

Is anyone working on a Gtk3 backend for matplotlib that use the pygobject API?

I could not find any information about how to use the matplotlib with
Gtk3, so I started to port the Gtk2 backend to the pygobject API, and
using the cairo backend for renderering.

I'm attaching a tarboll that contains the backend_gtk3.py file and
some test scripts for embedding a matplotlib figure in Gtk3
applications using that backend. I think it works alright for the use
cases that I've been able to test, so it might be a good starting
point for a Gtk3 backend if there are no other attempts to create such
a backend already.

Best regards
Robert

[matplotlib-devel] Using a dict for the CallbackRegistry

[Benjamin R. <ben...@ou...>]

A question that was raised while diagnosing an issue with mpl_connect().  A
user wants to attach a function to multiple events.  Apparently, this was
possible in previous versions, but the current version disallows that
through its use of the dictionary that is key'ed by the callback
functions.  Do we want to explicitly disallow this, or should we be keying
the dictionary with (action, callback) tuples?

Ben Root

Re: [matplotlib-devel] tagging releases (v1.1.0 tag missing)

[Benjamin R. <ben...@ou...>]

On Sat, Nov 12, 2011 at 6:56 AM, John Hunter <jd...@gm...> wrote:

>
>
> On Nov 12, 2011, at 2:47 AM, Paul Ivanov <piv...@gm...> wrote:
>
> > On Fri, Nov 11, 2011 at 5:40 PM, Benjamin Root <ben...@ou...> wrote:
> >> On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
> >>>
> >>> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...>
> wrote:
> >>>>
> >>>> Just wanted to re-ping the list, but include John and Ben directly:
> >>>>
> >>>>  can we get the appropriate commit tagged as v1.1.0 in the git repo?
> >>>>
> >>>
> >>> Sure thing.  I will add that tag.
> >>>
> >>> Ben Root
> >>>
> >>
> >> The best I can figure is that commit
> >> 0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the
> release
> >> announcement by John on Oct. 11.  There was subsequently a commit on
> that
> >> day to fix ipython links. I can't remember if that happened before or
> after
> >> (I think after).
> >>
> >> Can anybody concur?
> >
> > On my PR to fix those links, John closed it and said he'd add it to
> > the release branch, and they're up on the site, so I'd say that commit
> > made it in. But I don't know if there were others afterward that made
> > it in
> >
>
>
> My memory is that the ipy pull request came just after the tarball, so I
> think you have it right Ben
>
>
Done!

Ben Root

Re: [matplotlib-devel] [Basemap] Don't recompile nad2bin when running setup.py clean

[Sandro T. <mo...@de...>]

Hi Jeff,

On Mon, Sep 19, 2011 at 17:39, Jeff Whitaker
<Jef...@no...> wrote:
> On 9/18/11 8:49 AM, Sandro Tosi wrote:
>>
>> Hi,
>> when running
>>
>>     python setup.py clean
>>
>> nad2bin is compiled. I've just worked around with the attached patch,
>> so it would be nice if you can integrate it upstream or come up with a
>> better solution.
>>
>> Regards,
>
> Applied your patch to github master.  Will be in 1.0.2, which I will release
> soon.

something happened in the middle, and the setup.py released with 1.0.2
still compile nad2bin in clean target; I've applied the following fix:

-if sys.argv[1] != ['sdist','clean']:
+if sys.argv[1] not in ['sdist','clean']:

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] [sage-devel] Re: OS X 10.6 port

[Friedrich R. <fri...@gm...>]

Hi Ondrej,

Good things last and take time.

2010/4/13 Ondrej Certik <on...@ce...>:
> I am now getting the exact same problem with pylab and FEMhub and Mac.
> I used http://sagemath.org/packages/standard/matplotlib-0.99.1.p4.spkg:

It might a different problem than just architecture mismatch.  But
maybe I'm getting something wrong and misunderstand you.

Michael, notice that 0.99.1 seems to the last version before your
commit af9954d46e5 which introduces versioning of the fontcache.  (It
is not tagged in git, only the commit message reveals it:
8398d9bd2c47.

I cannot see from http://trac.sagemath.org/sage_trac/ticket/7022 what
happened between the sagemath matplotlib-0.99.1.p2.spkg to
matplotlib-0.99.1.p4.spkg (patch 2 => patch 4).  But the last post by
jhpalmieri on that page might be related: "[...] But with my computer,
"uname -r" returns "10.2.0", not "10.0.0". [...]"  On my system it
returns currently 10.8.0 (I think since it's OS X 10.6.8).

> ondrej@bsd:~/repos/femhub-0.9.9.beta3-mac(master)$ ./femhub
> ----------------------------------------------------------------------
> | FEMhub Version 0.9.9.beta2, Release Date: 2010-04-02               |
> | Type lab() for the GUI.                                            |
> ----------------------------------------------------------------------
> In [1]: import pylab
> /Users/ondrej/repos/femhub-0.9.9.beta3-mac/local/lib/python2.6/site-packages/matplotlib/rcsetup.py:117:
> UserWarning: rcParams key "numerix" is obsolete and has no effect;
>  please delete it from your matplotlibrc file
>  warnings.warn('rcParams key "numerix" is obsolete and has no effect;\n'
> /Users/ondrej/repos/femhub-0.9.9.beta3-mac/local/bin/sage-sage: line
> 203: 28516 Abort trap              sage-ipython "$@" -i
>
> It's using the "bsd" Mac machine from William, I guess the same as
> John was using above.
>
> Has anybody figured out a solution? Apparently Sage must work on the
> Mac, so it must be something different than just matplotlib?

Can you please check if you do have /Library/Fonts/NISC18030.ttf on
your system and maybe do a ``stat -f "%c"
/Library/Fonts/NISC18030.ttf`` on it?  For me, this one generates a
Bus error (32bit) / Abort trap (64bit) on importing matplotlib.figure,
for example.  My issue is related to loading that font file I
specified.  It might a different font file for you and it might also
be totally unrelated at all :-/

Or maybe you solved the problem in the meantime?

Do you still have this machine?  William, assumed he's William Stein,
was the one who posted
http://groups.google.com/group/sage-devel/browse_thread/thread/2c538915abc99946
in 2009, and who was able to partly track it down.

>From the page http://trac.sagemath.org/sage_trac/ticket/7022 I see
that exactly that font file was installed on it (probably).

Thanks,
Friedrich

> Some
> other package, that we have in femhub, but not in Sage, or some
> different version of something. Here is a list of packages that I have
> installed:
>
> ondrej@bsd:~/repos/femhub-0.9.9.beta3-mac(master)$ ./femhub -i
> Currently installed packages:
> blas-20070724
> bzip2-1.0.5
> cmake-2.6.2.p1
> configobj-4.5.3
> cython-0.12.1
> dir-0.1
> docutils-0.5.p0
> femhub-lab-97141eb
> fipy-2.1-eb4aacf
> fortran-20071120.p8
> freetype-2.3.5.p2
> gnutls-2.2.1.p3
> hermes2d-9bbfd39
> ipython-bzr1174
> jinja-1.2.p0
> judy-1.0.5.p1
> lapack-20071123.p1
> libfemhub-78c07cb
> libgcrypt-1.4.3.p2
> libgpg_error-1.6.p2
> libpng-1.2.35.p0
> matplotlib-0.99.1.p4
> mayavi-3.3.1.p2
> mesa-7.4.4.p3
> numpy-1.3.0.p2
> pexpect-2.0.p3
> prereq-0.3
> pygments-0.11.1.p0
> pyparsing-1.5.2
> pysparse-1.1-6301cea
> python-2.6.4.p7
> python_gnutls-1.1.4.p7
> readline-6.0
> sage_scripts-3.4.2
> scipy-0.7.p4
> setuptools-0.6c9.p0
> sfepy-2009.3
> sphinx-0.6.3.p4
> swig-1.3.36
> sympy-5d78c29
> termcap-1.3.1.p1
> twisted-9.0.p2
> vtk-cvs-20090316-minimal.p6
> zlib-1.2.3.p5

Looks ok.  But I didn't check it in detail.  I think it might be unrelated.

Re: [matplotlib-devel] trunk rev 8843 crash on Snow Leopard

[Friedrich R. <fri...@gm...>]

2010/12/21 Russell E. Owen <ro...@uw...>:
> I built a binary installer for matplotlib trunk rev 8843 (because it
> leaks memory less than 1.0.0 release). I built it the same way I built
> the 1.0.0 binary
> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> 6).
>
> The binary is available here:
> <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> 843-python.org-py2.6-macosx10.3.dmg>
>
> It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> pylab almost always segfaults (and the few times I've gotten it to work
> on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> running Python again). I've tried it on newly created accounts and it
> segfaults. Another user of Snow Leopard first reported the problem. So
> it's not just me.
>
> I've appended part of a crash log.
>
> I built this binary the same way I built the matplotlib 1.0.0 binary,
> which has no problems.
>
> Any ideas?

Yap; did you make any progress on this?

I found that approximately that time on my machine was the
NISC18030.ttf font installed (I see it from the date of birth) and it
breaks the FontManager of nearly all matplotlibs including the recent
one (from last week).

Friedrich

> -- Russell
>
> Exception Type:  EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   libSystem.B.dylib               0x90e1b176 __kill + 10
> 1   libSystem.B.dylib               0x90e1b168 kill$UNIX2003 + 32
> 2   libSystem.B.dylib               0x90ead89d raise + 26
> 3   libSystem.B.dylib               0x90ec39bc abort + 93
> 4   org.python.python               0x004e3e99 Py_FatalError + 73
> 5   libSystem.B.dylib               0x90e2046b _sigtramp + 43
> 6   ???                             0000000000 0 + 0
> 7   libSystem.B.dylib               0x90e29378
> _Unwind_GetLanguageSpecificData + 24
> 8   libstdc++.6.dylib               0x940c4d86 __gxx_personality_v0 + 120
> 9   libgcc_s.1.dylib                0x0389f476 _Unwind_Backtrace + 278
> 10  libgcc_s.1.dylib                0x0389f890 _Unwind_Resume + 112
> 11  ft2font.so                      0x03d5c3a3
> FT2Font::FT2Font(std::string) + 4385
> 12  ft2font.so                      0x03d5c805
> ft2font_module::new_ft2font(Py::Tuple const&) + 505
> 13  ft2font.so                      0x03dc89c2
> Py::ExtensionModule<ft2font_module>::invoke_method_varargs(void*,
> Py::Tuple const&) + 90
> 14  ft2font.so                      0x03d7170c
> method_varargs_call_handler + 342
> 15  org.python.python               0x004bcd25 PyEval_EvalFrameEx + 19429
> 16  org.python.python               0x004bee9d PyEval_EvalCodeEx + 2109
> 17  org.python.python               0x004bcf0c PyEval_EvalFrameEx + 19916

Michael, here you probably have the traceback you asked for (assumed
I'm right with my assumption above) :-)

Friedrich

Re: [matplotlib-devel] tagging releases (v1.1.0 tag missing)

[John H. <jd...@gm...>]

On Nov 12, 2011, at 2:47 AM, Paul Ivanov <piv...@gm...> wrote:

> On Fri, Nov 11, 2011 at 5:40 PM, Benjamin Root <ben...@ou...> wrote:
>> On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
>>> 
>>> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
>>>> 
>>>> Just wanted to re-ping the list, but include John and Ben directly:
>>>> 
>>>>  can we get the appropriate commit tagged as v1.1.0 in the git repo?
>>>> 
>>> 
>>> Sure thing.  I will add that tag.
>>> 
>>> Ben Root
>>> 
>> 
>> The best I can figure is that commit
>> 0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the release
>> announcement by John on Oct. 11.  There was subsequently a commit on that
>> day to fix ipython links. I can't remember if that happened before or after
>> (I think after).
>> 
>> Can anybody concur?
> 
> On my PR to fix those links, John closed it and said he'd add it to
> the release branch, and they're up on the site, so I'd say that commit
> made it in. But I don't know if there were others afterward that made
> it in
> 


My memory is that the ipy pull request came just after the tarball, so I think you have it right Ben


> 

Re: [matplotlib-devel] tagging releases (v1.1.0 tag missing)

[Paul I. <piv...@gm...>]

On Fri, Nov 11, 2011 at 5:40 PM, Benjamin Root <ben...@ou...> wrote:
> On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:
>>
>> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
>>>
>>> Just wanted to re-ping the list, but include John and Ben directly:
>>>
>>>  can we get the appropriate commit tagged as v1.1.0 in the git repo?
>>>
>>
>> Sure thing.  I will add that tag.
>>
>> Ben Root
>>
>
> The best I can figure is that commit
> 0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the release
> announcement by John on Oct. 11.  There was subsequently a commit on that
> day to fix ipython links. I can't remember if that happened before or after
> (I think after).
>
> Can anybody concur?

On my PR to fix those links, John closed it and said he'd add it to
the release branch, and they're up on the site, so I'd say that commit
made it in. But I don't know if there were others afterward that made
it in



-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Re: [matplotlib-devel] tagging releases (v1.1.0 tag missing)

[Benjamin R. <ben...@ou...>]

On Fri, Nov 11, 2011 at 7:19 PM, Benjamin Root <ben...@ou...> wrote:

> On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:
>
>> Just wanted to re-ping the list, but include John and Ben directly:
>>
>>  can we get the appropriate commit tagged as v1.1.0 in the git repo?
>>
>>
> Sure thing.  I will add that tag.
>
> Ben Root
>
>
The best I can figure is that commit
0fc9830fe946f6221e9ceff2910cd0c2118b0965 was the last one before the
release announcement by John on Oct. 11.  There was subsequently a commit
on that day to fix ipython links. I can't remember if that happened before
or after (I think after).

Can anybody concur?

Ben Root

Re: [matplotlib-devel] tagging releases (v1.1.0 tag missing)

[Benjamin R. <ben...@ou...>]

On Thu, Nov 10, 2011 at 5:52 PM, Paul Ivanov <piv...@gm...> wrote:

> Just wanted to re-ping the list, but include John and Ben directly:
>
>  can we get the appropriate commit tagged as v1.1.0 in the git repo?
>
>
Sure thing.  I will add that tag.

Ben Root

Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix

[Daniel H. <dh...@gm...>]

On this topic, I have a patch that tells BboxImage whether or not to
always apply interpolation (as is the desire when doing data analysis)
or to apply interpolation only when the image is at a non-native
resolution (as is the desire when using an image to annotate
something).

The pull request is here:


Since we cannot attach files on github, I've attached the test script,
image file that I was using, and the before/after here.

And can the max post size be increased on matplotlib-users, so that
when even smallish images are attached, the messages don't go into
moderation?

On Thu, Oct 13, 2011 at 11:40 AM, Daniel Hyams <dh...@gm...> wrote:
> Ah yes, I forget :/  I was focused on images as being "pure" things that
> should be displayed, and forgot about the image processing angle.
> So would the solution be a keyword argument that tells imshow/BboxImage and
> friends not to interpolate when at native resolution, which is set to the
> current behavior as default?
> If that's not an acceptable solution, I can just leave the patch in my own
> personal code and not worry about any further...I thought that I was fixing
> a bug there :)
>
> I guess the main difference is whether the image is treated as sacred and
> should be displayed perfectly when possible, versus the ability to modify
> the picture on purpose via the interpolations, for whatever reason the user
> wants.  Understandably, matplotlib has taken the latter approach, because
> the context has always been (as far as I can tell from the examples)
> displaying the pixels for a scientific purpose.  However, when you want to
> display an image for a annotational type purpose, the former approach should
> be taken, in my opinion.
>
>
> On Thu, Oct 13, 2011 at 11:13 AM, John Hunter <jd...@gm...> wrote:
>>
>> On Thu, Oct 13, 2011 at 10:06 AM, Daniel Hyams <dh...@gm...> wrote:
>>
>> > Isn't the purpose of interpolation to handle situations where the image
>> > is
>> > being displayed at a different size than its native resolution?  It
>> > seems
>>
>> Not solely, it can also be used to do local average of noisy images to
>> get a smoother view, eg bilinear or bicubic averaging of neighboring
>> pixels.
>
>
>
> --
> Daniel Hyams
> dh...@gm...
>



-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] tagging releases (v1.1.0 tag missing)

[Paul I. <piv...@gm...>]

Just wanted to re-ping the list, but include John and Ben directly:

 can we get the appropriate commit tagged as v1.1.0 in the git repo?

On Thu, Nov 3, 2011 at 2:21 PM, Paul Ivanov <piv...@gm...> wrote:
> I added a note to the release docs about tagging the releases - right
> now, there's no clear way inside git to know what ended up in v1.1.0
> final, without grabbing a tarball and poking around. I'm inlining the
> relevant part of that commit here, so that John/Ben can tag the
> release after the fact.
>
> ---
> For each release candidate as well as for the final release version,
> please `git tag` the commit you will use for packaging like so::
>
>    git tag -a v1.1.0rc1
>
> The `-a` flag will allow you to write a message about the tag, and
> affiliate your name with it. A reasonable tag message would be something
> like ``v1.1.0 Release Candidate 1 (September 24, 2011)``. To tag a
> release after the fact, just track down the commit hash, and::
>
>    git tag -a v1.0.1 a9f3f3a50745
>
> Tags allow developers to quickly checkout different releases by name,
> and also provides source download via zip and tarball on github.
> ---


best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Re: [matplotlib-devel] matplotlib-grayscale

[Friedrich R. <fri...@gm...>]

2011/10/22 Eric Firing <ef...@ha...>:
> moved from matplotlib-users:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=CAN06%3DCx2zgh8YrnF2WRaJ%3D0E8i3ROLdYW4VuurtqKrx3mdkeEg%40mail.gmail.com&forum_name=matplotlib-users

OK

> On 10/22/2011 09:31 AM, Friedrich Romstedt wrote:
>>
>> 2011/10/21 Friedrich Romstedt<fri...@gm...>:
>> <snippet>
>> 3)  Providing a dedicated Filter class, that can be fed to
>> set_filter() instead of set_gray().  This I like best.
>> </snippet>
>>
>> So the filter idea was Ben's idea.  I still like idea (3) for the
>> design best.  I will check if it is possible to inject the filter code
>> into the renderer framework, since all colour settings arguments
>> somewhen flow into a call into the renderer.

This is apparently a no-go.  The backends are too tightly bound to the
C extensions moduled, e.g. aggdraw.  E.g. the image drawing method of
the Agg backend is directly assigned in the fashion::

    self.draw_image = self._renderer.draw_image

So no, this will not work this way.

>>  Pro: No rcParams
>> addition necessary, no modification of the peculiar colors.py
>> ColorConverter framework necessary, just leaving those things
>> untouched and hence no worries and headaches about them.

So I'll touch it again.  I will just check my refactor I did a year
ago on ColorConverter, which was pretty decent, but well, it needs
some check.  I would first commit that to my repo, than people who are
interested can test, and then we can go on testing the higher level
functionality.

I think the filters will, instead of signalling colors.colorConveter
via rcParams that some conversion mode is turned on, signal that in
the decorator function simply directly to colors.colorConverter.
There are some open ends, though.

>> No disabling
>> of higher-level caching and at the same time negligible small impact
>> if there is no filter active.  Con: I don't know yet if it works.  I
>> vaguely remember there were some problems when I checked that
>> possibility last time (with pixmaps or something like that).  I think
>> I will find out soon enough.

:-)  Apparently I found out the same thing a year ago.

The methodology will be like this: The Artists can store a stack of
filters, and also provide some easy-appetite-wetter .set_gray()
method.  When their draw method is decorated with a special decorator,
say @filtered, then the filters will be activated upon entering and
deactivated upon exit.  The activation happens via putting the filters
onto the filter stack in the ColorConverter instance.  I'm pretty sure
this will work, somehow at least. ;-)

I've run into some strange Bus error compiling the latest matplotlib,
I'll drop another email on the user list probably (since I'm acting
here as a user, I just want to run the tests).

Friedrich

Re: [matplotlib-devel] Py3 merge

[Christoph G. <cg...@uc...>]

On 11/9/2011 2:00 PM, Arik Raffael Funke wrote:
> Hi Mike,
>
> I managed to get matplotlib to compile and run on Python 3.2.2 on
> Windows though at present there are two problems:
>
> 1. The linker is missing the "/MANIFEST" argument. This means that the
> manifest files are not being created and somehow the module does not
> link the dependencies properly. (Resulting in the problem I described in
> my email earlier today.) Also linking breaks due to the missing manifest
> files.

This is not a matplotlib specific issue. You are using Visual Studio 
2010, which is not officially supported by Python distutils.


>
> I found that a (probably too specific) fix is to modify the function
> "make_extension" in setupext.py: Changing the first line of the function to:
> ext = Extension(*args, extra_link_args=['/MANIFEST'], **kwargs)
>
> I am sure however that the extra arguments must be set depending on the
> compiler chosen - though I do not quite follow the workflow of setup.py...
>
>
> 2. The file containing the visual studio static dependencies
> (http://matplotlib.sourceforge.net/win32_static_vs.tar.gz) still has the
> old tk and tcl versions. It would suffice to add tk85.lib and tcl85.lib
> from a Python3 installation to the package.

I recommend against using that package. It is better to build all 
dependencies with the same compiler and settings that will be used to 
build matplotlib. Up-to-date static libraries for the MS compilers 
supported by Python distutils are at 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>

Christoph


>
> Also, the existence of this package is very poorly advertised. It seems
> to be mentionned only in the code of setupext.py. The wiki-page
> http://matplotlib.sourceforge.net/users/installing.html makes no mention
> of it in the setion "Installing from source". It suggests that it is
> necessary to build each of the dependencies oneself.
>
> Apart from this, on the face of it matplotlib seems to work fine on
> Python 3.2.2 on Windows.
>
> Many thanks!!!
> Arik
>
>
> On 09/11/2011 18:24, Michael Droettboom wrote:
>   >  I just pressed the big green merge button...  :)
>   >
>   >  Master should now have all of the Python 3 portability changes.  It's
>   >  passing all tests, and running all examples, but I still wouldn't be
>   >  surprised if some things broke in the process.  Please kick the tires
>   >  and report bugs.  It would be helpful in the bug reports to know whether
>   >  the bug is only on Python 2 or 3 or both, and whether it is a regression
>   >  from matplotlib 1.1.x.
>   >
>   >  Cheers,
>   >  Mike
>   >
>   >
> ------------------------------------------------------------------------------
>   >  RSA(R) Conference 2012
>   >  Save $700 by Nov 18
>   >  Register now
>   >  http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
>