matplotlib-devel Mailing List for matplotlib

In article <51E...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:

> On 07/22/2013 05:59 PM, Russell E. Owen wrote:
> > In article <51E...@st...>,
> >   Michael Droettboom <md...@st...>
> >   wrote:
> >
> >> At long last, I have a 1.3.0rc5 tagged.  I really hope to the software
> >> deities that this is the last rc before final.
> >>
> >> If you wouldn't mind creating and posting the binaries, I'll make an
> >> announcment on matplotlib-users, give this a week and then put final out.
> > I have uploaded a binary for MacOS X 10.6 and later.
> >
> >
> > There were a few oddities this time around:
> > - matplotlib now requires pyparsing. I don't remember that being a
> > requirement before -- even for previous 1.3 candidates.
> 
> It's been a requirement for time immemorial, but only in 1.3.0 (all of 
> the release candidates) has it become an external dependency. What error 
> occurred that suggests something changed?

I suspect what changed is you don't include it anymore (but I would have 
expected that change in earlier 1.3.0 prereleases).

>> - I had a lot of trouble with matplotlib complaining that dateutil was
> > not present, even though it was in my site-packages. So I tried to
> > reinstall it using pip install -U dateutil. Unfortunately pip has never
> > heard of "dateutil". After some searching I realized the package name is
> > actually "python-dateutil" (and not dateutils, which is a different
> > package, alas). Even then, I had to install/upgrade it twice -- for some
> > reason matplotlib couldn't find it at first. Very puzzling. I have no
> > idea what was going on, but also didn't want to spend a lot of time
> > trying to debug it.
> 
> Does `python setup.py install` (of matplotlib) not install it 
> automatically?  We are bearing all the pain of setuptools in order for 
> that to happen, so if it's not, that's a real problem.

I am building a binary installer, so I don't use "python setup.py 
install". I use bdist_mpkg, which presumably does something similar to 
"python setup.py build" and packages the results (without installing 
them).

In any case, I need to know which packages matplotlib needs so I can 
warn users to install them in the binary installer's ReadMe file. The 
list is rather long. I miss having this stuff included in matplotlib. At 
this point I know of the following (aside from numpy):
- python-dateutil (unfortunately matplotlib complains about missing 
"dateutil" if it's absent; it would help to give the name of the package 
as known by pip, rather than what is imported)
- pytz
- six
- pyparsing

> > - I get a few unit tests failures, including a slew of
> > DeprecationWarnings about Operator '<<' that I don't remember seeing
> > before. I have appended the test log.
> 
> That's probably related to pyparsing 2.0.1 (released just this week).  
> I'd like to fix those warnings, but then we'd have to *require* 
> pyparsing 2.0.1 (no earlier Python 2.x release of pyparsing includes an 
> alternative syntax).  I think pyparsing moved too quickly on this one, 
> but I'm not sure what we can do about it. It does make me long for the 
> days when we included our dependencies so we have some control over this 
> stuff.

Great. This sounds innocuous.

> > - I first tried building on 10.8 and running on 10.6 (since that's much
> > simpler for me). Unfortunately it doesn't work; on 10.6 it acts as if
> > the unit tests themselves aren't part of the package. I have no idea
> > why. I appended a log snippet showing the basic message, but I haven't
> > looked into it further. This sounds worth spending some time tracking
> > down.
> 
> That's a puzzler.  I've seen that crop up on Travis erratically as well, 
> but not consistently.  It's not clear what's going on here -- will have 
> to think on it.

I'm not sure how to diagnose this, but if you have any ideas, let me 
know. (Though I should probably read the rest of the messages on this 
thread before saying that.)

-- Russell

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

The above issue raises the question of whether the default for aspect 
ratio handling should be "datalim" instead of "box".  The big advantage 
is that this completely avoids the problem described in the issue, where 
setting aspect='equal' can result in an unusable aspect ratio in screen 
coordinates.

For one common use of equal aspect--images--it is essential to have the 
adjustable be "box".  I suspect that in most other use cases, "datalim" 
would be a satisfactory default.

The problem with a change like this is how to make the transition 
without wreaking havoc on existing code.  The typical answer is to use 
an rc parameter, starting with the existing default, and then switching 
it over in some subsequent release.

Any thoughts?  Should we leave all this as it is, or try to change it?

Eric

Great, thanks Paul -- much better conduit solution :)


On Wed, Jul 24, 2013 at 12:44 PM, Paul Ivanov <pi...@be...> wrote:

> Hi David, everyone,
>
> David P. Sanders, on 2013-07-24 08:10,  wrote:
> > Just wanted to say that I am currently at the IPython
> > developers' meeting in case, so I can act as a conduit in case
> > anybody has any suggestions / comments / bugs related to the
> > matplotlib--IPython interaction.
>
> I've been a bit quieter on the Matplotlib side lately, but since
> I'm now full-time on IPython, I wanted to pipe in that I, too,
> can act as a conduit. Not only for the dev meeting, but in
> perpetuity.
>
> I think Fernando's too busy to monitor this list closely, so you
> can think of me as matplotlib mole on the ipython core dev team
> (since I did get my matplotlib commit rights first) :)
>
> best,
> --
>                    _
>                   / \
>                 A*   \^   -
>              ,./   _.`\\ / \
>             / ,--.S    \/   \
>            /  `"~,_     \    \
>      __o           ?
>    _ \<,_         /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
>



-- 
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414, 4o. piso del Depto. de Física

Tel.: +52 55 5622 4965

Hi David, everyone,

David P. Sanders, on 2013-07-24 08:10,  wrote:
> Just wanted to say that I am currently at the IPython
> developers' meeting in case, so I can act as a conduit in case
> anybody has any suggestions / comments / bugs related to the
> matplotlib--IPython interaction.

I've been a bit quieter on the Matplotlib side lately, but since
I'm now full-time on IPython, I wanted to pipe in that I, too,
can act as a conduit. Not only for the dev meeting, but in
perpetuity. 

I think Fernando's too busy to monitor this list closely, so you
can think of me as matplotlib mole on the ipython core dev team
(since I did get my matplotlib commit rights first) :)

best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

On 07/24/2013 11:36 AM, Michiel de Hoon wrote:
> Hi Michael,
>
> > Thanks.  I will address these issues before final.
>
> Thanks.
>
> >None of this is new -- we've gone through 5 release candidates over 
> many weeks.  Why is this just coming to light now?
>
> The output of running "python setup.py build" passes by quickly, and 
> people (including myself) did not notice that the MacOSX backend was 
> not being compiled.
> And then if an older version of matplotlib is already installed, 
> everything seems to be working fine.
> I noticed this problem today only because I was installing matplotlib 
> on a new Macbook.

Ah, that makes sense.  Hopefully as part of doing some automated Mac 
builds we can be testing clean installs etc. and catch this kind of 
thing sooner in the future.

Mike

>
> Best,
> -Michiel.
>
> ------------------------------------------------------------------------
> *From:* Michael Droettboom <md...@st...>
> *To:* Michiel de Hoon <mjl...@ya...>
> *Cc:* Benjamin Root <ben...@ou...>; 
> "mat...@li..." 
> <mat...@li...>
> *Sent:* Wednesday, July 24, 2013 10:36 PM
> *Subject:* Re: [matplotlib-devel] 1.3.0rc5 tagged
>
> Thanks.  I will address these issues before final.
>
> None of this is new -- we've gone through 5 release candidates over 
> many weeks.  Why is this just coming to light now?
>
> Mike
>
> On 07/23/2013 11:16 PM, Michiel de Hoon wrote:
>> I noticed that this release candidate will always skip the Mac OS X 
>> backend,
>> as the .check() method of BackendMacOSX in setupext.py returns None. 
>> Adding
>>     return "darwin"
>> or some other string solves the issue.
>> Also, if I am not mistaken, the files under 
>> lib/matplotlib/backends/Matplotlib.nib (as returned by the 
>> get_package_data() method of BackendMacOSX in setupext.py) are needed 
>> by the cocoaagg backend, not by the MacOSX backend.
>>
>> Best,
>> -Michiel.
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li... 
>> <mailto:Mat...@li...>
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
>

Hi Michael,

> Thanks.  I will address these issues before final.  


Thanks.

> None of this is new -- we've gone through 5 release candidates over many weeks.  Why is this just coming to light now?

The output of running "python setup.py build" passes by quickly, and people (including myself) did not notice that the MacOSX backend was not being compiled.

And then if an older version of matplotlib is already installed, everything seems to be working fine.
I noticed this problem today only because I was installing matplotlib on a new Macbook.

Best,
-Michiel.



________________________________
 From: Michael Droettboom <md...@st...>
To: Michiel de Hoon <mjl...@ya...> 
Cc: Benjamin Root <ben...@ou...>; "mat...@li..." <mat...@li...> 
Sent: Wednesday, July 24, 2013 10:36 PM
Subject: Re: [matplotlib-devel] 1.3.0rc5 tagged
 


Thanks.  I will address these issues before final.  

None of this is new -- we've gone through 5 release candidates
      over many weeks.  Why is this just coming to light now?

Mike

On 07/23/2013 11:16 PM, Michiel de Hoon wrote:

I noticed that this release candidate will always skip the Mac OS X backend,
>as the .check() method of BackendMacOSX in setupext.py returns
        None. Adding
>    return "darwin"
>or some other string solves the issue.
>Also, if I am not mistaken, the files under
        lib/matplotlib/backends/Matplotlib.nib (as returned by the
        get_package_data() method of BackendMacOSX in setupext.py) are
        needed by the cocoaagg backend, not by the MacOSX backend.
>
>Best,
>-Michiel.
>_______________________________________________
>
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>

We could update the makefile so that make clean really cleans up the
installation "junk" before installing a new version. I personnally would
find it very useful, but the makefile needs a bit of love. Typically "make"
would run make clean and make install.
I can work on that if people agree that having a nice makefile would be
useful.

Cheers,
N


On 24 July 2013 16:57, Chris Beaumont <bea...@ha...> wrote:

> Same with me. I had a stale pyparsing.pyc file in the MPL source directory
> (presumably from an old MPL version) whose version # was too old. When mpl
> tried to 'import pyparsing', it found that version, and raised an error. Of
> course, if I tried "import pyparsing; print pyparsing.__version__" from my
> home directory, python found a more recent pyparsing. So the error message
> was a little confusing.
>
> I only think this is going to effect people building from the Git source,
> who have the old pyparsing.pyc file.
>
>
> On Wed, Jul 24, 2013 at 10:45 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>>
>> On Wed, Jul 24, 2013 at 9:39 AM, Michael Droettboom <md...@st...>wrote:
>>
>>>  On 07/23/2013 03:33 PM, Benjamin Root wrote:
>>>
>>>  Just checked out rc5 from git and did an install, and ran into a
>>> pyparsing version check issue.
>>>
>>>
>>> What was the issue?  Is it that you had 2.0.1 which rc5 still considers
>>> to be incompatible with Python 2?  I'd like to know specifically what
>>> happened in case there's a deeper issue.
>>>
>>>
>>>
>> It claimed I didn't meet the minimum pyparsing version needed when I
>> tried importing matplotlib after installing from source. However, importing
>> pyparsing on its own yielded a version slightly above the minimum (I forget
>> the actual numbers).  I had also just came from an build of an older
>> version of matplotlib.
>>
>> Ben
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Jul 24, 2013, at 7:23 AM, Michael Droettboom <md...@st...> wrote:


Part of this is due to the change to setuptools/distribute,


 Even though I was the one who spearheaded the move
to setuptools, I'm wondering whether we shouldn't examine backtracking
on some of this for the 1.4.x release.


I don't think so--in this case the timing was particularly bad, but the
core developers are pretty commited to setup tools/pip as the way of the
future, so these things will settle down.

And just like MPL has issues because many of us wait for "final" to test (
guilty as charged...) the distribution tools need to be tested by complex
packages like MPL in order to get robust and stable.

-CHB



The second issue is more one of process.  When I make a release
candidate, I announce it here, and Cc all of the packagers of the major
Linux distributions, as well as Christoph and Russell who put together
packages for Windows and Mac respectively.  Part of that delegation is
because I don't have installations of all of those platforms, and part
is to spread some of the workload.  And most of the time it works really
well -- a big thanks to everyone involved. However, this cycle there
have been a small number of critical bugs discovered in the fifth
release candidate that existed in the first release candidate, which
doesn't give me a lot of confidence that final won't have critical bugs
either.  I think some of this will be ameliorated over time as we build
out a more effective continuous integration infrastructure (see MEP19:
we could really use some help on this one), but some of it may have to
do with users being unwilling to test a release until it has the word
"final" attached. How can we get more ordinary users (who may have even
more unusual environments) involved?  I also suspect some of it has to
do with the timing in the summer which hits in the middle of vacations
and conference travel for many.  We can certainly avoid the summer
months next time.  But I don't think it's just about building more time
into the schedule.  Let me know if I'm doing something boneheaded ;)

Mike



------------------------------------------------------------------------------
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
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Same with me. I had a stale pyparsing.pyc file in the MPL source directory
(presumably from an old MPL version) whose version # was too old. When mpl
tried to 'import pyparsing', it found that version, and raised an error. Of
course, if I tried "import pyparsing; print pyparsing.__version__" from my
home directory, python found a more recent pyparsing. So the error message
was a little confusing.

I only think this is going to effect people building from the Git source,
who have the old pyparsing.pyc file.


On Wed, Jul 24, 2013 at 10:45 AM, Benjamin Root <ben...@ou...> wrote:

>
>
>
> On Wed, Jul 24, 2013 at 9:39 AM, Michael Droettboom <md...@st...>wrote:
>
>>  On 07/23/2013 03:33 PM, Benjamin Root wrote:
>>
>>  Just checked out rc5 from git and did an install, and ran into a
>> pyparsing version check issue.
>>
>>
>> What was the issue?  Is it that you had 2.0.1 which rc5 still considers
>> to be incompatible with Python 2?  I'd like to know specifically what
>> happened in case there's a deeper issue.
>>
>>
>>
> It claimed I didn't meet the minimum pyparsing version needed when I tried
> importing matplotlib after installing from source. However, importing
> pyparsing on its own yielded a version slightly above the minimum (I forget
> the actual numbers).  I had also just came from an build of an older
> version of matplotlib.
>
> Ben
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************

On Wed, Jul 24, 2013 at 9:39 AM, Michael Droettboom <md...@st...> wrote:

>  On 07/23/2013 03:33 PM, Benjamin Root wrote:
>
>  Just checked out rc5 from git and did an install, and ran into a
> pyparsing version check issue.
>
>
> What was the issue?  Is it that you had 2.0.1 which rc5 still considers to
> be incompatible with Python 2?  I'd like to know specifically what happened
> in case there's a deeper issue.
>
>
>
It claimed I didn't meet the minimum pyparsing version needed when I tried
importing matplotlib after installing from source. However, importing
pyparsing on its own yielded a version slightly above the minimum (I forget
the actual numbers).  I had also just came from an build of an older
version of matplotlib.

Ben

First, I should say out loud that I'm personally embarrassed by how long 
it's taken to go from release candidate to a final release in the 1.3.0 
cycle.  For those that haven't been following along the hold ups have 
all been along the lines of showstoppers like "won't install on platform 
X", so not just an expectation of absolute perfection.  We're still not 
100% of the way there, but I hope we're real close now.

Part of this is due to the change to setuptools/distribute, and part of 
this is due to procedural things not going as well as they should that 
I'd like some help fixing.

To start with setuptools: That brought a lot of changes and kinks that 
needed to be worked out, and I'm not surprised that it created a few new 
wrinkles.  The question in my mind is whether those wrinkles were a 
one-off result of the transition to setuptools or that similar things 
will reappear in the future.  There was the setuptools/distribute 
remerge that IMHO was handled and communicated badly upstream, where by 
following the explicit directions in the documentation we had a package 
that would no longer install.  It was hard to find the magic incantation 
that would work everywhere, but we got there eventually.  Then there was 
the issue with pyparsing's upgrade where there's now a non-contiguous 
range of version numbers that are compatible with Python 2.x (everything 
*but* 2.0.0).  It's somewhat fortunate that these happened during the 
release candidate cycle so that we could address them quickly.  The 
theme here?  These are problems that get created outside of the control 
of the matplotlib team.  All of this was brought about because including 
copies of our dependencies created its own set of headaches, and 
setuptools is the standard solution to that problem, so that `setup.py 
install` and tools like `pip` will install the dependencies 
automatically.  However, in the bad old days, it was at least possible 
to ship with some things that worked together, unfortunately, those who 
wanted their dependencies external (primarily packagers) were left to 
fend for themselves.  Even though I was the one who spearheaded the move 
to setuptools, I'm wondering whether we shouldn't examine backtracking 
on some of this for the 1.4.x release.

The second issue is more one of process.  When I make a release 
candidate, I announce it here, and Cc all of the packagers of the major 
Linux distributions, as well as Christoph and Russell who put together 
packages for Windows and Mac respectively.  Part of that delegation is 
because I don't have installations of all of those platforms, and part 
is to spread some of the workload.  And most of the time it works really 
well -- a big thanks to everyone involved. However, this cycle there 
have been a small number of critical bugs discovered in the fifth 
release candidate that existed in the first release candidate, which 
doesn't give me a lot of confidence that final won't have critical bugs 
either.  I think some of this will be ameliorated over time as we build 
out a more effective continuous integration infrastructure (see MEP19: 
we could really use some help on this one), but some of it may have to 
do with users being unwilling to test a release until it has the word 
"final" attached. How can we get more ordinary users (who may have even 
more unusual environments) involved?  I also suspect some of it has to 
do with the timing in the summer which hits in the middle of vacations 
and conference travel for many.  We can certainly avoid the summer 
months next time.  But I don't think it's just about building more time 
into the schedule.  Let me know if I'm doing something boneheaded ;)

Mike

Would you mind testing https://github.com/matplotlib/matplotlib/pull/2250

On 07/23/2013 11:16 PM, Michiel de Hoon wrote:
> I noticed that this release candidate will always skip the Mac OS X 
> backend,
> as the .check() method of BackendMacOSX in setupext.py returns None. 
> Adding
>     return "darwin"
> or some other string solves the issue.
> Also, if I am not mistaken, the files under 
> lib/matplotlib/backends/Matplotlib.nib (as returned by the 
> get_package_data() method of BackendMacOSX in setupext.py) are needed 
> by the cocoaagg backend, not by the MacOSX backend.

Sorry.  We could have handled that better.  I think we will probably do 
this again in the future, so we'll have an opportunity to be more 
explicit about these things.

Mike

On 07/24/2013 08:37 AM, Phil Elson wrote:
> 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 <md...@st... 
> <mailto:md...@st...>> 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
>     Mat...@li...
>     <mailto:Mat...@li...>
>     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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Thanks, David.  I'll let you know.  I am also planning on coming in by 
Google Hangout on Thursday and possibly parts of Friday.

Mike

On 07/24/2013 09:10 AM, David P. Sanders wrote:
> Hi,
>
> Just wanted to say that I am currently at the IPython developers' 
> meeting in case, so I can act as a conduit in case anybody has any 
> suggestions / comments / bugs related to the matplotlib--IPython 
> interaction.
>
> David.
>
> -- 
> Dr. David P. Sanders
>
> Profesor Titular "A" / Associate Professor
> Departamento de Física, Facultad de Ciencias
> Universidad Nacional Autónoma de México (UNAM)
>
> dps...@ci... <mailto:dps...@ci...>
> http://sistemas.fciencias.unam.mx/~dsanders 
> <http://sistemas.fciencias.unam.mx/%7Edsanders>
>
> Cubículo / office: #414, 4o. piso del Depto. de Física
> Tel.: +52 55 5622 4965
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 07/23/2013 03:33 PM, Benjamin Root wrote:
> Just checked out rc5 from git and did an install, and ran into a 
> pyparsing version check issue.

What was the issue?  Is it that you had 2.0.1 which rc5 still considers 
to be incompatible with Python 2?  I'd like to know specifically what 
happened in case there's a deeper issue.

>   Turns out I completely forgot to do a "git clean -fxd". Doing that 
> fixed the problem.

Interesting.  I guess this would depend on what version you were on 
before the switch to rc5.  If 1.2.x, I'm not surprised (since pyparsing 
was included in the source tree then).  If master, I'm not sure what the 
cause would be.

>   When we officially announce this, perhaps it would be best to 
> mention that command?  In addition, it would probably be a good idea 
> to include this tidbit into the INSTALL?

But that only applies to users of git (in which case this is very often 
an issue), and not users who download the tarball or package. I think it 
makes sense to add it to the developer docs, not the INSTALL docs.

Mike

Thanks.  I will address these issues before final.

None of this is new -- we've gone through 5 release candidates over many 
weeks.  Why is this just coming to light now?

Mike

On 07/23/2013 11:16 PM, Michiel de Hoon wrote:
> I noticed that this release candidate will always skip the Mac OS X 
> backend,
> as the .check() method of BackendMacOSX in setupext.py returns None. 
> Adding
>     return "darwin"
> or some other string solves the issue.
> Also, if I am not mistaken, the files under 
> lib/matplotlib/backends/Matplotlib.nib (as returned by the 
> get_package_data() method of BackendMacOSX in setupext.py) are needed 
> by the cocoaagg backend, not by the MacOSX backend.
>
> Best,
> -Michiel.
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li... 
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi,

Just wanted to say that I am currently at the IPython developers' meeting
in case, so I can act as a conduit in case anybody has any suggestions /
comments / bugs related to the matplotlib--IPython interaction.

David.

-- 
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414, 4o. piso del Depto. de Física

Tel.: +52 55 5622 4965

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 <md...@st...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I noticed that this release candidate will always skip the Mac OS X backend,
as the .check() method of BackendMacOSX in setupext.py returns None. Adding
    return "darwin"
or some other string solves the issue.
Also, if I am not mistaken, the files under lib/matplotlib/backends/Matplotlib.nib (as returned by the get_package_data() method of BackendMacOSX in setupext.py) are needed by the cocoaagg backend, not by the MacOSX backend.

Best,
-Michiel.
_______________________________________________

Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel