matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Release Candidate

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

On 09/10/2012 12:49 PM, Mark Lawrence wrote:
> My offer to test on Windows still holds.  The question is test what?
> Assuming that the intent is to support Python 2.6/7 and 3.1/2/3 then
> different versions of Visual Studio are needed as detailed here
> http://bugs.python.org/issue13210.  I can't see much sense in me trying
> to build and test all that lot while other volunteers are doing exactly
> the same thing at the same time.  Is there a cunning plan somewhere to
> cover this that I've missed?
>

The process is usually that the release is tagged in github, a tarball 
is created, and then various platform specialists create the binary 
releases.  For the last release Christoph Gohlke did the Windows builds, 
and I assume he is able to do that again this time. Perhaps it makes 
sense to coordinate with him to share some of that work?  Anything we 
can do to lessen the burden on any one person is always appreciated.

Even leading up to the tagging of the release candidate, it's always 
helpful to build from github periodically and test on the platform and 
version of Python that's most important to you, and report back into the 
issue tracker any test failures or other glitches.

Mike

Re: [matplotlib-devel] Release Candidate

[Mark L. <bre...@ya...>]

On 10/09/2012 17:00, Michael Droettboom wrote:
> Today is the scheduled day for release candidate 1.2rc1.
>
> We seem to be in really good shape.  Thanks to everyone that has been
> working so hard to squash bugs, particularly ones that turned out to be
> bottomless rabbit holes.
>
> We have a few outstanding issues, which I'll categorize below:
>
> Critical things that need just a little more work:
>
> #1223    dpi= for bitmaps not handled correctly
> #1209    Pass linewidth to Mac context properly
> #786    savefig() renders paths and text differently than show()
> #113    dpi= doesn't seem to have any effect with MacOS X backend
>
> #1208    FAIL: matplotlib.tests.test_text.test_contains.test
> release_critical
> #1176    Reverted a previous change to artist transform setting. Fixes
> legend bug.
>
> Non-critical features that are near completion -- just needing some
> confirmation or testing:
>
> #847    Add stacked kwarg to hist and implement stacked hists for step
> histtype
> #751    Building on osx with python 3.2 OSX
>
> Problems requiring a fix in another project:
>
> #1126    Qt4 save dialog not functional on CentOS-5
>
> Things that are probably too big to fix now, but deserve warnings in the
> release notes:
>
> #854    Bug in Axes.relim when the first line is y_isdata=False and
> possible fix
> #740    plt.pcolormesh and shape mismatch
> #162    twinx and plot_date confirmed
>
> Reminders for the release manager:
>
> #1207    Add contributor and git stats to documentation
> #1070    Use github for downloads
>
> I will write prose for the "too big to fix now" stuff, and I trust the
> other close things will get done by their respective authors. Then we're
> very close to getting a release candidate out.
>
> Congratulations to everyone for a job well done!
>
> 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/
>

My offer to test on Windows still holds.  The question is test what? 
Assuming that the intent is to support Python 2.6/7 and 3.1/2/3 then 
different versions of Visual Studio are needed as detailed here 
http://bugs.python.org/issue13210.  I can't see much sense in me trying 
to build and test all that lot while other volunteers are doing exactly 
the same thing at the same time.  Is there a cunning plan somewhere to 
cover this that I've missed?

-- 
Cheers.

Mark Lawrence.

Re: [matplotlib-devel] Release Candidate

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

I'd certainly like to see that work continue, but I don't know if it's 
worth holding up the release candidate for.  We probably won't get it 
out today given the other critical things yet to go in -- but once the 
release candidate is cut, I'd prefer to be really conservative about 
what changes go in before the final release.  We can continue your great 
PEP8 work on master (after the 1.2.x maintenance branch is created), of 
course.

Mike

On 09/10/2012 12:10 PM, Nelle Varoquaux wrote:
> Hello,
>
> Do you still accept pep8 cleaning up ? I've got a couple of important 
> deadlines coming up soon, but I might be able to clean up the whole code.
>
> Thanks,
> N
>
> On 10 September 2012 18:00, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     Today is the scheduled day for release candidate 1.2rc1.
>
>     We seem to be in really good shape.  Thanks to everyone that has been
>     working so hard to squash bugs, particularly ones that turned out
>     to be
>     bottomless rabbit holes.
>
>     We have a few outstanding issues, which I'll categorize below:
>
>     Critical things that need just a little more work:
>
>     #1223    dpi= for bitmaps not handled correctly
>     #1209    Pass linewidth to Mac context properly
>     #786    savefig() renders paths and text differently than show()
>     #113    dpi= doesn't seem to have any effect with MacOS X backend
>
>     #1208    FAIL: matplotlib.tests.test_text.test_contains.test
>     release_critical
>     #1176    Reverted a previous change to artist transform setting. Fixes
>     legend bug.
>
>     Non-critical features that are near completion -- just needing some
>     confirmation or testing:
>
>     #847    Add stacked kwarg to hist and implement stacked hists for step
>     histtype
>     #751    Building on osx with python 3.2 OSX
>
>     Problems requiring a fix in another project:
>
>     #1126    Qt4 save dialog not functional on CentOS-5
>
>     Things that are probably too big to fix now, but deserve warnings
>     in the
>     release notes:
>
>     #854    Bug in Axes.relim when the first line is y_isdata=False and
>     possible fix
>     #740    plt.pcolormesh and shape mismatch
>     #162    twinx and plot_date confirmed
>
>     Reminders for the release manager:
>
>     #1207    Add contributor and git stats to documentation
>     #1070    Use github for downloads
>
>     I will write prose for the "too big to fix now" stuff, and I trust the
>     other close things will get done by their respective authors. Then
>     we're
>     very close to getting a release candidate out.
>
>     Congratulations to everyone for a job well done!
>
>     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
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Release Candidate

[Nelle V. <nel...@gm...>]

Hello,

Do you still accept pep8 cleaning up ? I've got a couple of important
deadlines coming up soon, but I might be able to clean up the whole code.

Thanks,
N

On 10 September 2012 18:00, Michael Droettboom <md...@st...> wrote:

> Today is the scheduled day for release candidate 1.2rc1.
>
> We seem to be in really good shape.  Thanks to everyone that has been
> working so hard to squash bugs, particularly ones that turned out to be
> bottomless rabbit holes.
>
> We have a few outstanding issues, which I'll categorize below:
>
> Critical things that need just a little more work:
>
> #1223    dpi= for bitmaps not handled correctly
> #1209    Pass linewidth to Mac context properly
> #786    savefig() renders paths and text differently than show()
> #113    dpi= doesn't seem to have any effect with MacOS X backend
>
> #1208    FAIL: matplotlib.tests.test_text.test_contains.test
> release_critical
> #1176    Reverted a previous change to artist transform setting. Fixes
> legend bug.
>
> Non-critical features that are near completion -- just needing some
> confirmation or testing:
>
> #847    Add stacked kwarg to hist and implement stacked hists for step
> histtype
> #751    Building on osx with python 3.2 OSX
>
> Problems requiring a fix in another project:
>
> #1126    Qt4 save dialog not functional on CentOS-5
>
> Things that are probably too big to fix now, but deserve warnings in the
> release notes:
>
> #854    Bug in Axes.relim when the first line is y_isdata=False and
> possible fix
> #740    plt.pcolormesh and shape mismatch
> #162    twinx and plot_date confirmed
>
> Reminders for the release manager:
>
> #1207    Add contributor and git stats to documentation
> #1070    Use github for downloads
>
> I will write prose for the "too big to fix now" stuff, and I trust the
> other close things will get done by their respective authors. Then we're
> very close to getting a release candidate out.
>
> Congratulations to everyone for a job well done!
>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Release Candidate

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

Today is the scheduled day for release candidate 1.2rc1.

We seem to be in really good shape.  Thanks to everyone that has been 
working so hard to squash bugs, particularly ones that turned out to be 
bottomless rabbit holes.

We have a few outstanding issues, which I'll categorize below:

Critical things that need just a little more work:

#1223    dpi= for bitmaps not handled correctly
#1209    Pass linewidth to Mac context properly
#786    savefig() renders paths and text differently than show()
#113    dpi= doesn't seem to have any effect with MacOS X backend

#1208    FAIL: matplotlib.tests.test_text.test_contains.test 
release_critical
#1176    Reverted a previous change to artist transform setting. Fixes 
legend bug.

Non-critical features that are near completion -- just needing some 
confirmation or testing:

#847    Add stacked kwarg to hist and implement stacked hists for step 
histtype
#751    Building on osx with python 3.2 OSX

Problems requiring a fix in another project:

#1126    Qt4 save dialog not functional on CentOS-5

Things that are probably too big to fix now, but deserve warnings in the 
release notes:

#854    Bug in Axes.relim when the first line is y_isdata=False and 
possible fix
#740    plt.pcolormesh and shape mismatch
#162    twinx and plot_date confirmed

Reminders for the release manager:

#1207    Add contributor and git stats to documentation
#1070    Use github for downloads

I will write prose for the "too big to fix now" stuff, and I trust the 
other close things will get done by their respective authors. Then we're 
very close to getting a release candidate out.

Congratulations to everyone for a job well done!

Mike

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

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

On Sun, Sep 9, 2012 at 3:24 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Tue, Apr 17, 2012 at 10:02 AM, Jostein Bø Fløystad <
> jos...@gm...> wrote:
>
>> Ben,
>>
>> That sounds great, especially regarding the test images. I don't know
>> how the image comparison tests work, that's why I kept it very
>> fundamental.
>>
>> Thanks!
>>
>> Jostein.
>>
>>
> Just rediscovered this.  I will go ahead and create the PR so that this
> gets included in v1.2.0.
>
> Ben Root
>


Submitted as PR #1224: https://github.com/matplotlib/matplotlib/pull/1224

Cheers!
Ben Root

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

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

On Tue, Apr 17, 2012 at 10:02 AM, Jostein Bø Fløystad <
jos...@gm...> wrote:

> Ben,
>
> That sounds great, especially regarding the test images. I don't know
> how the image comparison tests work, that's why I kept it very
> fundamental.
>
> Thanks!
>
> Jostein.
>
>
Just rediscovered this.  I will go ahead and create the PR so that this
gets included in v1.2.0.

Ben Root

Re: [matplotlib-devel] Time to delete backend_qt (QT3)?

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

On 2012/09/09 9:01 AM, Benjamin Root wrote:
> Did we remember to put in a deprecation notice for Qt3 support?

I don't think so.  Presumably it should be a deprecation warning upon 
importing backend_qt, and a note in whats_new.

Eric

>
> Ben Root
>
> On Tue, Jul 10, 2012 at 11:44 AM, Darren Dale <dsd...@gm...
> <mailto:dsd...@gm...>> wrote:
>
>     On Tue, Jul 10, 2012 at 8:54 AM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>      >
>      >
>      > On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <ef...@ha...
>     <mailto:ef...@ha...>> wrote:
>      >>
>      >> Is there any good reason *not* to delete support for Qt3 from
>     master?
>      >> Is anyone who is using it likely to be able to upgrade to the
>     next mpl
>      >> release, and yet *not* be able to install Qt4 and its bindings?
>       Note
>      >> that ipython no longer supports Qt3.
>      >>
>      >> Eric
>      >>
>      >
>      > CentOS5 and RHEL5 both have qt3 as part of the stock install
>     (although it
>      > does look like qt4 is available).  CentOS6 and RHEL6 seem to have
>     qt4 as
>      > default, with pyqt as well.
>      >
>      > Personally, I see no real reason to get rid of it quite yet as it
>     doesn't
>      > seem to be much of a support burden -- yet.  If anything, we
>     might want to
>      > consider putting deprecation notices for that backend in the next
>     release.
>
>     I also think its coming up on time to retire the Qt-3 backend, but
>     perhaps a deprecation notice in mpl-1.2 and removal in mpl-1.3 would
>     be appropriate. Then again, if mpl-1.2 supports python3, maybe that
>     would be a good time to delete the Qt3 backend, since there is no
>     python-3 binding for Qt3.
>
>     By the way, Qt-5 is expected in September. Hopefully it won't require
>     a dedicated backend, it sounds like PyQt4 will support Qt5's QtCore
>     and QtGui libraries.
>
>     Darren
>
>

Re: [matplotlib-devel] Time to delete backend_qt (QT3)?

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

Did we remember to put in a deprecation notice for Qt3 support?

Ben Root

On Tue, Jul 10, 2012 at 11:44 AM, Darren Dale <dsd...@gm...> wrote:

> On Tue, Jul 10, 2012 at 8:54 AM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <ef...@ha...> wrote:
> >>
> >> Is there any good reason *not* to delete support for Qt3 from master?
> >> Is anyone who is using it likely to be able to upgrade to the next mpl
> >> release, and yet *not* be able to install Qt4 and its bindings?  Note
> >> that ipython no longer supports Qt3.
> >>
> >> Eric
> >>
> >
> > CentOS5 and RHEL5 both have qt3 as part of the stock install (although it
> > does look like qt4 is available).  CentOS6 and RHEL6 seem to have qt4 as
> > default, with pyqt as well.
> >
> > Personally, I see no real reason to get rid of it quite yet as it doesn't
> > seem to be much of a support burden -- yet.  If anything, we might want
> to
> > consider putting deprecation notices for that backend in the next
> release.
>
> I also think its coming up on time to retire the Qt-3 backend, but
> perhaps a deprecation notice in mpl-1.2 and removal in mpl-1.3 would
> be appropriate. Then again, if mpl-1.2 supports python3, maybe that
> would be a good time to delete the Qt3 backend, since there is no
> python-3 binding for Qt3.
>
> By the way, Qt-5 is expected in September. Hopefully it won't require
> a dedicated backend, it sounds like PyQt4 will support Qt5's QtCore
> and QtGui libraries.
>
> Darren
>

Re: [matplotlib-devel] Is anyone using make.osx?

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

On 2012/09/07 6:56 AM, Daniel Hyams wrote:
> I do, but I'm not wedded to it; I'll use whatever is there.  The
> convenience of it is that it downloaded dependencies and built them for
> you.  Will setup.py do the same?

No, it won't.  The problem with make.osx in that regard is that the 
dependencies and their urls are version-dependent and ever-changing, so 
a single make.osx would need to be much more complex than the present 
one is, and to be maintained, which the present one mostly was not.

Eric

>
> On Fri, Sep 7, 2012 at 12:32 PM, Michael Droettboom <md...@st...
> <mailto:md...@st...>> wrote:
>
>     There is a discussion in a pull request about whether it is still
>     needed.
>
>     https://github.com/matplotlib/matplotlib/issues/751
>
>     It would be nice to have one obvious way to build on OS-X, so it makes
>     sense to remove this file in that case.  However, I thought it might be
>     worth casting this question out before doing so.
>
>     Cheers,
>     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
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> --
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Is anyone using make.osx?

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

I do, but I'm not wedded to it; I'll use whatever is there.  The
convenience of it is that it downloaded dependencies and built them for
you.  Will setup.py do the same?

On Fri, Sep 7, 2012 at 12:32 PM, Michael Droettboom <md...@st...> wrote:

> There is a discussion in a pull request about whether it is still needed.
>
> https://github.com/matplotlib/matplotlib/issues/751
>
> It would be nice to have one obvious way to build on OS-X, so it makes
> sense to remove this file in that case.  However, I thought it might be
> worth casting this question out before doing so.
>
> Cheers,
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



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

[matplotlib-devel] Is anyone using make.osx?

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

There is a discussion in a pull request about whether it is still needed.

https://github.com/matplotlib/matplotlib/issues/751

It would be nice to have one obvious way to build on OS-X, so it makes 
sense to remove this file in that case.  However, I thought it might be 
worth casting this question out before doing so.

Cheers,
Mike

[matplotlib-devel] John Hunter's memorial service

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

Hi all,

I have just received the following information from John's family
regarding the memorial service:

John's memorial service will be held on Monday, October 1, 2012, at
11.a.m. at Rockefeller Chapel at the University of Chicago.  The exact
address is 5850 S. Woodlawn Ave, Chicago, IL 60615.  The service is
open to the public.  The service will be fully planned and scripted
with no room for people to eulogize, however, we will have a reception
after the service, hosted by Tradelink, where people can talk.

Regards,

f

[matplotlib-devel] Fwd: A common name for the scipy stack - pylab?

[Thomas K. <th...@kl...>]

Hi,

(Apologies if you get this twice - I forgot which address I subscribed
to the list with)

As some of you may have seen, there's a discussion underway on the
scipy-user mailing list about developing a common name for the scipy
stack. At present, the discussion is centring on adopting the name
pylab, as it's already familiar to people using
numpy+scipy+matplotlib. If we did use that name, we'd obviously need
to co-ordinate with matplotlib to ensure that there isn't confusion
between the name Pylab and the importable module pylab.

If you want to get involved in the discussion, please head over to the
scipy-user mailing list so we keep it in one place. You can read
through the current thread:
http://article.gmane.org/gmane.comp.python.scientific.user/32487

And the previous thread it refers to:
http://article.gmane.org/gmane.comp.python.scientific.user/32448

Thanks,
Thomas

Re: [matplotlib-devel] wxMPL patch

[Chris B. <chr...@no...>]

On Tue, Sep 4, 2012 at 8:33 PM, Matt Newville
<new...@ca...> wrote:

> Sorry for the delay.... I also haven't done anything about this... yet?   I
> might be more gung-ho to fold this into my wxmplot, which is fairly similar,
> but not exactly 1-to-1,  and has some name overlaps with wxmpl.   To be
> clear, I'm willing to refactor wxmplot to better accommodate  most of  the
> wxmpl interface,

Sounds like a great idea.

> What interfaces are you actually using from wxmpl?  I guess put another way:
> what do we want for a wx interface to matplotlib that's higher level than
> the standard backend.    The PlotPanel and PlotFrames look close enough to
> merge.

Those are what I use -- actually, only the PlotPanel -- I generally
want to customize the Frame.


>   The wxmpl StripCharter seems a little different from what I do with
> wxmplot, but perhaps that and the Channel class are easy enough to emulate.

Those are kind of higher-level stuff that's more suited to wxmplot, I
think -- as I don't use them, I don't care if you break the API -- but
that's just me.

> For how / where to host it, I don't much care.  Github and pypi seem easy
> enough.

I think it would be great to put it in the mpl repo as an mpl_toolkit
-- which means github, yes?


Thanks for taking this on!

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] wxMPL patch

[Matt N. <new...@ca...>]

Hi Carlo,

Sorry for the delay.... I also haven't done anything about this... yet?   I
might be more gung-ho to fold this into my wxmplot, which is fairly
similar, but not exactly 1-to-1,  and has some name overlaps with wxmpl.
To be clear, I'm willing to refactor wxmplot to better accommodate  most
of  the wxmpl interface, but it would take some effort, so maybe it would
be better to have some goals in mind.

What interfaces are you actually using from wxmpl?  I guess put another
way: what do we want for a wx interface to matplotlib that's higher level
than the standard backend.    The PlotPanel and PlotFrames look close
enough to merge.   The wxmpl StripCharter seems a little different from
what I do with wxmplot, but perhaps that and the Channel class are easy
enough to emulate.

For how / where to host it, I don't much care.  Github and pypi seem easy
enough.

--Matt
On Aug 30, 2012 11:22 PM, "Carlo Segre" <se...@ii...> wrote:

>
> Hi Chris:
>
> On Tue, 1 May 2012, Chris Barker wrote:
>
>  On Tue, May 1, 2012 at 9:31 AM, Benjamin Root
>>
>>  AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect
>>> it
>>> would fit best as a mpl_toolkit.
>>>
>>
>> yes -- I figured that was most likely.
>>
>>  P.S. - Of course, you do realize that you are essentially making yourself
>>> the de facto maintainer of it, right?
>>>
>>
>> Well, me or Matt or Carlo -- we'll fight over that among ourselves.
>>
>
> Just a followup.  Has wxmpl been pulled into the toolkit source yet?
>
> Carlo
>
>
> --
> Carlo U. Segre -- Duchossois Leadership Professor of Physics
> Director, Center for Synchrotron Radiation Research and Instrumentation
> Illinois Institute of Technology
> Voice: 312.567.3498            Fax: 312.567.3494
> se...@ii...   http://phys.iit.edu/~segre   se...@de...

Re: [matplotlib-devel] MEP10: Modernizing the documentation

[Thomas K. <th...@kl...>]

On 5 September 2012 00:32, Michael Droettboom <md...@st...> wrote:
> I wonder if there's any possibility of using that on earlier versions (I
> suspect not).

Not easily, I think. You'd have to get introspection tools like
IPython to separately check for a __signature__ attribute, and I
suspect we'd feel that the added complexity outweighs the benefits.

Thomas

Re: [matplotlib-devel] wxMPL patch

[Chris B. <chr...@no...>]

On Thu, Aug 30, 2012 at 9:22 PM, Carlo Segre <se...@ii...> wrote:
> Hi Chris:
>> On Tue, May 1, 2012 at 9:31 AM, Benjamin Root
>>
>>> AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect
>>> it
>>> would fit best as a mpl_toolkit.
>>
>>
>> yes -- I figured that was most likely.

> Just a followup.  Has wxmpl been pulled into the toolkit source yet?
>
> Carlo

I haven't done anything, nor have I heard that anyone else has.

Care to take it on?

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] backend_macosx linewidth bug

[Michiel de H. <mjl...@ya...>]

Hi Eric,

I may be able to look at this over the weekend.

Best,
-Michiel.

--- On Sun, 9/2/12, Eric Firing <ef...@ha...> wrote:

> From: Eric Firing <ef...@ha...>
> Subject: backend_macosx linewidth bug
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "matplotlib development list" <mat...@li...>
> Date: Sunday, September 2, 2012, 10:17 PM
> Michiel,
> 
> In the 4th comment on
> 
> https://github.com/matplotlib/matplotlib/issues/786
> 
> I give a little example illustrating a macosx bug: it seems
> that when drawing a path, the linewidth, which is specified
> in points, is not interpreted correctly unless the
> figure.dpi has exactly the right value.  For a high
> dpi, as in the example I gave, all lines are too thin, but
> text is still scaled correctly, and the general layout is
> correct.
> 
> Will you be able to take a look?  We are trying to get
> out a release soon, so it would be nice to have this fixed.
> 
> Thank you.
> 
> Eric
> 

[matplotlib-devel] clippedline example status

[Pierre H. <pie...@cr...>]

Hello,

I was playing a bit with the clippedline example
(http://matplotlib.org/examples/pylab_examples/clippedline.html) and I
feel it is not working anymore.

From what I understand of the traceback I got, there may be something
evil happening after setting
>>> self._marker = 's'
in the draw method. Maybe using the self.set_marker('s') is safer

Also, by reading some archived emails from this mailing list, it seems
that the purpose of this example became pointless because line clipping
is now implemented directly in matplotlib. Am I right ?

For what it's worth, I modified the clippeline.py example to make it
just serve the purpose of dynamically changing the appearance of the
line when zoom level is changing. I called t "zoom_adaptive_line.py" :
https://gist.github.com/3607993

Would this script be an appropriate replacement for the clippedline
example ?

Best,
Pierre

Re: [matplotlib-devel] MEP10: Modernizing the documentation

[Thomas K. <th...@kl...>]

On 26 August 2012 18:19, Michael Droettboom <md...@st...> wrote:
> I understand the comments about the difficulty of introspection. The
> reason it works the way it does is so that additional parameters can be
> added to the artist layer without needing to update every single
> plotting function.  A real world example of this is when hatching was
> added -- that feature only had to be added in one place and most artists
> were able to use it.  In that sense, I think this approach is very
> beautiful in terms of code maintainability and extensibility.

I'm jumping into this conversation a bit late, but from Python 3.3 it
will be possible to set a __signature__ attribute on a function, using
a Signature object which can be programmatically generated. So it
should be possible, with a bit of legwork, to introspect pass-through
parameters without having to manually declare them at the highest
level.

The details are here:
http://www.python.org/dev/peps/pep-0362/

Thanks,
Thomas

[matplotlib-devel] backend_macosx linewidth bug

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

Michiel,

In the 4th comment on

https://github.com/matplotlib/matplotlib/issues/786

I give a little example illustrating a macosx bug: it seems that when 
drawing a path, the linewidth, which is specified in points, is not 
interpreted correctly unless the figure.dpi has exactly the right value. 
  For a high dpi, as in the example I gave, all lines are too thin, but 
text is still scaled correctly, and the general layout is correct.

Will you be able to take a look?  We are trying to get out a release 
soon, so it would be nice to have this fixed.

Thank you.

Eric

Re: [matplotlib-devel] svg rasterization dpi patch

[Michael W. <miw...@us...>]

Okay, here is the pull request

https://github.com/matplotlib/matplotlib/pull/1185

and the diff

https://github.com/mwelter/matplotlib/compare/master...svg-rasterize-resolution-fix


cheers
Michael

Re: [matplotlib-devel] Fwd: Patch: set capsize of errorbar via matplotlibrc

[Hans D. <han...@ki...>]

: ) Thanks for the response.

On 08/30/2012 08:41 PM, Eric Firing wrote:
> Submitting patches as github pull requests is strongly preferred.  See
> http://matplotlib.sourceforge.net/devel/index.html.
>
> In the svn days, most devel discussions of proposed changes occurred on
> this mailing list, but now attention is much more on github PRs and less
> on the mailing list.

Okay, I will try that then!

>> Please allow me to participate.
>
> We welcome you--but sometimes we are simply overwhelmed and/or
> unorganized, and consequently unresponsive.  There is a random aspect to it!

I can deal with randomness, in fact, the field of statistics is one of 
my special interests : D

> Regarding your patch: this sounds like it might be a good idea, but I
> don't think the rc param should be called lines.capsize because it is
> not a general line property, but something specific to errorbars.
> "lines.*cap*" refer to completely unrelated general line properties.
>
> It would be good to get some thoughts from others as to whether to an
> "errorbar" or similar category should be added to rcParams, with your
> suggestion as the first entry in that category.  Maybe we need some
> policy guideline as to what should go in rcParams and what should not.

You are right, I also thought about that. My first idea was to add an 
errorbar.* category, but then I saw that also the bar plots 
(axes.bar(...), axes.barh(...)) use caps. What I am trying to say is 
that it is not only used by axes.errorbar(...). That's why I put into 
the lines.* category, but that's certainly open for discussion.

Having a policy on what to put into rcParams sounds useful.

Best regards,
Hans

Re: [matplotlib-devel] Fwd: Patch: set capsize of errorbar via matplotlibrc

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

On Thu, Aug 30, 2012 at 5:57 AM, Hans Dembinski <han...@ki...>wrote:

> Dear developers,
>
> I submitted a patch a few weeks ago that I think would be useful to have
> in the matplotlib, but I didn't get any response. I use the library
> extensively for science work and would like to be able to contribute to
> this great project.
>
> Since I didn't get any responses, I would like to know what you want me to
> do in order to get my ideas into the project. I cannot commit much time,
> but I am sure I will find little neat pieces to add every now and then.
>
> Please allow me to participate.
>
>
Sorry for the lack of a response.  We have been absolutely swamped with the
push for v1.2.0, and your email must have gotten lost in the pile.  Note,
repinging us as you have done is the absolutely correct thing to do.

Looking over your patch, the goal is sound, but the name of the rcparam you
choose would likely cause confusion.  "line.capsize" and "line.capstyle",
for instance, are referring to two completely different things that just
happens to have the same name "cap".  There are a lot of kwargs in axes.py
that have yet to be included into the rcparams, and we really need to push
to do this, but in a sensible and structured manner.

Anybody have thoughts on updating the naming scheme of the rc-params?

Ben Root