matplotlib-devel Mailing List for matplotlib (Page 4)

On Tue, Mar 8, 2011 at 1:18 PM, Eric Firing <ef...@ha...> wrote:

> On 03/08/2011 08:08 AM, Benjamin Root wrote:
> > Hello all,
> >
> > I have a free day today, so I am going through some of the documentation
> > and giving it a good polish.  I came across one particular part that is
> > sorely outdated:
> >
> > http://matplotlib.sourceforge.net/faq/howto_faq.html#use-show
> >
> > This is in regards to the show() function and tells users that it can
> > only be used once in a script.  By and large, this is no longer true,
> > but I want to make sure that I don't give bad information here.  Is
> > there someplace else in the docs where this information is current that
> > I can use for revising this section?
>
> Not that I know of.
>
> Because readers of the docs online may be running any of a range of mpl
> versions, you will need note how show() usage and behavior have evolved.
>  The advantage of the old faq, outdated though it is, is that it won't
> mislead users of old mpl versions, and following its advice will still
> work for users of the current version.
>
>
Good point.  I hadn't thought of that.


> New behavior, or at last the target: show() starts a GUI mainloop if it
> is not already running, and draws everything.  If mpl is in
> non-interactive mode, it then blocks until the newly opened windows have
> been closed; if it is in interactive mode, it does not block.  (The
> macosx backend does not have a non-interactive mode.)  In either case,
> when things are working right, there is no restriction on multiple calls
> within a script or a shell session.
>
> Note: Michiel deHoon is working on changes to master (code and docs) so
> that mpl will come up in interactive mode by default, instead of the
> present non-interactive default.  The code change is trivial; the larger
> challenge is how to explain everything in the docs, while not confusing
> users of older versions.
>

The whole gui situation, with all the possible combinations of
> environment (ipython in its different versions, idle, etc.), mpl
> backend, other packages that might be used in conjunction with mpl (e.g.
> mayavi) and platform, is still unsettled.  The big change was from the
> 0.9x series to 1.x series; some problems were sorted out between 1.0 and
> 1.0.1.  More work in this area will be needed now and then.
>
> All of this raises a question: can we move to clear versioning of the
> online docs, as with python itself, so that a user of 0.99.x won't be
> frustrated by an example or explanation that applies only to 1.0.x?  Or
> can we be sufficiently careful to keep explanations of version
> differences in the evolving docs?  These are not mutually exclusive, and
> the latter is particularly useful.  For example, when using python 2.6
> it is nice to be able to look at the docs and see that a feature was
> introduced in that version, so it won't be available on one's machines
> running 2.5.  I think we now need to follow that practice in the mpl
> docs, or at least try to do so.
>
>
I have personally had to field several questions from users of older mpl who
tried the new way of creating 3d axes on their systems.  Unfortunately, when
I created the documentation, I completely removed all traces of the old
method, forgetting that some users will have difficulty with those
instructions.

Today, my goal is mostly polishing work.  I will try and see if I could make
some explanations more version-agnostic or to specifically point out
differences in versions.

I personally see a lot of value in providing multiple versions of the docs
(maybe supported - 1 releases back?).


> And on the topic of the docs, if anyone has time for a bigger project:
> it would be nice if the gallery could be *organized* in some systematic
> way, so that a user could more easily use it to find a needed feature.
> And as always, it would be nice to have the gallery examples cleaned up
> with respect to code and comment style, and edited to remove things that
> really are no longer of interest and to more clearly demonstrate features.
>
>
I can see about doing some of this tomorrow if it turns out I have another
free day...

Ben Root

On 03/08/2011 08:08 AM, Benjamin Root wrote:
> Hello all,
>
> I have a free day today, so I am going through some of the documentation
> and giving it a good polish.  I came across one particular part that is
> sorely outdated:
>
> http://matplotlib.sourceforge.net/faq/howto_faq.html#use-show
>
> This is in regards to the show() function and tells users that it can
> only be used once in a script.  By and large, this is no longer true,
> but I want to make sure that I don't give bad information here.  Is
> there someplace else in the docs where this information is current that
> I can use for revising this section?

Not that I know of.

Because readers of the docs online may be running any of a range of mpl 
versions, you will need note how show() usage and behavior have evolved. 
  The advantage of the old faq, outdated though it is, is that it won't 
mislead users of old mpl versions, and following its advice will still 
work for users of the current version.

New behavior, or at last the target: show() starts a GUI mainloop if it 
is not already running, and draws everything.  If mpl is in 
non-interactive mode, it then blocks until the newly opened windows have 
been closed; if it is in interactive mode, it does not block.  (The 
macosx backend does not have a non-interactive mode.)  In either case, 
when things are working right, there is no restriction on multiple calls 
within a script or a shell session.

Note: Michiel deHoon is working on changes to master (code and docs) so 
that mpl will come up in interactive mode by default, instead of the 
present non-interactive default.  The code change is trivial; the larger 
challenge is how to explain everything in the docs, while not confusing 
users of older versions.

The whole gui situation, with all the possible combinations of 
environment (ipython in its different versions, idle, etc.), mpl 
backend, other packages that might be used in conjunction with mpl (e.g. 
mayavi) and platform, is still unsettled.  The big change was from the 
0.9x series to 1.x series; some problems were sorted out between 1.0 and 
1.0.1.  More work in this area will be needed now and then.

All of this raises a question: can we move to clear versioning of the 
online docs, as with python itself, so that a user of 0.99.x won't be 
frustrated by an example or explanation that applies only to 1.0.x?  Or 
can we be sufficiently careful to keep explanations of version 
differences in the evolving docs?  These are not mutually exclusive, and 
the latter is particularly useful.  For example, when using python 2.6 
it is nice to be able to look at the docs and see that a feature was 
introduced in that version, so it won't be available on one's machines 
running 2.5.  I think we now need to follow that practice in the mpl 
docs, or at least try to do so.

And on the topic of the docs, if anyone has time for a bigger project: 
it would be nice if the gallery could be *organized* in some systematic 
way, so that a user could more easily use it to find a needed feature. 
And as always, it would be nice to have the gallery examples cleaned up 
with respect to code and comment style, and edited to remove things that 
really are no longer of interest and to more clearly demonstrate features.

Eric


>
> Thanks,
> Ben Root

Hello all,

I have a free day today, so I am going through some of the documentation and
giving it a good polish.  I came across one particular part that is sorely
outdated:

http://matplotlib.sourceforge.net/faq/howto_faq.html#use-show

This is in regards to the show() function and tells users that it can only
be used once in a script.  By and large, this is no longer true, but I want
to make sure that I don't give bad information here.  Is there someplace
else in the docs where this information is current that I can use for
revising this section?

Thanks,
Ben Root

On 8 March 2011 09:40, Paul Hobson <pmh...@gm...> wrote:
> Is it in git or svn? I just cloned and installed from git using:
> git clone git://github.com/astraw/matplotlib.git
> cd matplotlib
> sudo python setupegg.py develop
>
> Starting ipython, and importing matplotlib, I get:
> In [2]: matplotlib.__version__
> Out[2]: '1.0.0'
>
> I thought v1.0.1 was available. Should I install from svn?

The main repository is at https://github.com/matplotlib/matplotlib you
cloned a forked copy by mistake.

> As an aside, I first tried the proceedure outlined here:
> http://matplotlib.sourceforge.net/devel/coding_guide.html#using-git
> and got a public key error.

That doc appears to be out of date. The repository move was quite recent.

Cheers,
Scott

Is it in git or svn? I just cloned and installed from git using:
git clone git://github.com/astraw/matplotlib.git
cd matplotlib
sudo python setupegg.py develop

Starting ipython, and importing matplotlib, I get:
In [2]: matplotlib.__version__
Out[2]: '1.0.0'

I thought v1.0.1 was available. Should I install from svn?

As an aside, I first tried the proceedure outlined here:
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-git
and got a public key error.

Thanks,
-paul

Eric Firing <ef...@ha...> writes:

>> https://github.com/matplotlib/matplotlib/pull/17
>
> This brings up something that confuses me, together with related 
> questions, and so might be another topic for this part of the docs:
>
> 1) How is it that you were able to add commits to a branch of someone 
> else's fork?

I sent Fernando a pull request:

https://github.com/fgb/matplotlib/pull/1

He merged my commits to his branch, and his pull request was
automatically updated.

> 2) How should it be decided who merges a pull request, and when?

I think John called for not too much bureaucracy - before git we were
committing things without any review. On the other hand, with git there
is less urgency to get things into master, since if you need someone's
bugfix or feature to continue developing your own stuff, you can pull
from their branch into your own. I think we can depend on everyone's
good judgment.

If we need a guideline, my suggestion is that if someone other than the
author reviews the code and says it is good, or if no-one raises any
issues for some time, it can be merged.

If there are merge conflicts, usually the person who wrote the code is
in the best position to resolve them.

> 3) Under what circumstances, if any, should a pull request involving 
> multiple commits be collapsed into a single changeset prior to being 
> merged and pushed?

If we had a strict policy that tests must pass for every revision (which
I don't think we have had) it would make sense to squash multiple
commits into one if the intermediate commits don't pass the test
suite. Squashing is an instance of a rebase operation, so it should be
avoided for any commits on which someone may have based further work.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Mon, Mar 7, 2011 at 10:39 AM, Darren Dale <dsd...@gm...> wrote:

> On Mon, Mar 7, 2011 at 11:24 AM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Mon, Mar 7, 2011 at 10:20 AM, Darren Dale <dsd...@gm...> wrote:
> >>
> >> On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root <ben...@ou...> wrote:
> >> >
> >> >
> >> > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann
> >> > <lkb...@gm...>
> >> > wrote:
> >> >>
> >> >> Hi Ben, Hi list,
> >> >>
> >> >> > Exactly.  That's all I found too.  Nothing indicates that we need
> to
> >> >> > change anything.  We are throwing away the second part of the tuple
> >> >> > which has the returned filter.  The only reason I see for the new
> >> >> > function is so the coder can get back the filter string, which we
> >> >> > don't seem to use.
> >> >>
> >> >> It took me a while to see the problem, too. The point is: there is
> one
> >> >> parameter
> >> >> missing in the new API of getSaveFileName, called selectedFilter,
> >> >> which we use, and
> >> >> given that it is missing, python takes it to be the next parameter,
> >> >> which
> >> >> must be an int, and you get a TypeError. I discussed this with
> >> >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
> >> >> (see
> >> >>
> >> >>
> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
> >> >> and he told me to use getSaveFileNameAndFilter.
> >> >>
> >> >> The other option would be to change PyQt4, dunno which is best.
> >> >>
> >> >> Greetings
> >> >>
> >> >> Martin
> >> >>
> >> >
> >> > Martin, thanks for the explanation.  That made a lot more sense.  I
> will
> >> > go
> >> > ahead with the patch.
> >>
> >> getSaveFileNameAndFilter was only added in pyqt-4.6.
> >
> >
> > oy!  Why the heck did qt4 change their API like this?
>
> To make it more pythonic for python-3. You can set the api to v2 with
> python-2, but it is not the default.
>
> > What should we do?
>
> I think the change being discussed is only necessary when the QString
> api is set to v2. So, we should be able to do something along the
> lines of:
>
>
> import sip
>
> try:
>   if sip.getapi("QString") > 1:
>       # support the new api
>   else:
>       # support the old api
> except (AttributeError, KeyError): # call to getapi may fail with
> older versions of sip
>   # support the old api
>
> > I also assume that some sort of fix should be applied to the v1.0.x?
>
> I think it should be, if the fix does not break backward compatibility
> with <PyQt4-4.6.
>
> Darren
>
>
My attempt at this can be found in pull request 33:

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

Ben Root

On 03/07/2011 10:30 AM, Jouni K. Seppänen wrote:

>>> 5. v1.0.x doesn't merge cleanly into master
>>
>> What do you mean by this?  What is the symptom?
>
> A merge conflict or (probably much less often) a test failure, because
> v1.0.x and master have diverged in the relevant part. An example is pull
> request #17, which modifies make.osx:
>
> https://github.com/matplotlib/matplotlib/pull/17

This brings up something that confuses me, together with related 
questions, and so might be another topic for this part of the docs:

1) How is it that you were able to add commits to a branch of someone 
else's fork?

2) How should it be decided who merges a pull request, and when?

3) Under what circumstances, if any, should a pull request involving 
multiple commits be collapsed into a single changeset prior to being 
merged and pushed?

Eric


>
> But make.osx has changed in master, so while merging this request will
> not have a merge conflict (at least with current v1.0.x), merging to
> master will. I created another pull request that includes this one and
> resolves the merge conflict:
>
> https://github.com/matplotlib/matplotlib/pull/30
>
> So when #17 is merged into v1.0.x, #30 should be merged into master.
>

Eric Firing <ef...@ha...> writes:

>>      git pull --ff-only upstream v1.0.x
>>
>> (This assumes an "upstream" remote pointing to
>> `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull
>
> By default, however, if you have cloned from 
> gi...@gi...:matplotlib/matplotlib.git then instead of "upstream" the 
> remote will be "origin".
>
> Are you recommending and assuming that we clone *only* from our 
> individual github forks, and then add the "upstream" remote to point to 
> the official repo?

I was assuming that, based on the github instructions:

http://help.github.com/fork-a-repo/

But of course there are many ways to do it. We'll have to decide what we
like best and stick to it in the manual; I personally don't have any
strong opinions on what to call the various repositories. Perhaps
"origin" for the central repository and "public" for your own github
repo (as in the public counterpart of your private development repo)?

>> If everything is fine, push:
>>
>>      git push gi...@gi...:matplotlib/matplotlib.git v1.0.x
>
> Can't this be simplified by using "origin" or "upstream" in place of the 
> url?

Yes, if that's the read-write address. If you cloned from the read-only
address, you can't push to it.

>> 2. the merge has conflicts
>
> I encountered that last night.  The conflict was a simple one that will 
> occur often: the CHANGELOG needed to have the new entry prepended,

Oh, of course. That's going to occur a lot.

>> 5. v1.0.x doesn't merge cleanly into master
>
> What do you mean by this?  What is the symptom?

A merge conflict or (probably much less often) a test failure, because
v1.0.x and master have diverged in the relevant part. An example is pull
request #17, which modifies make.osx:

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

But make.osx has changed in master, so while merging this request will
not have a merge conflict (at least with current v1.0.x), merging to
master will. I created another pull request that includes this one and
resolves the merge conflict:

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

So when #17 is merged into v1.0.x, #30 should be merged into master.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Mon, Mar 7, 2011 at 3:14 PM, Eric Firing <ef...@ha...> wrote:
> On 03/07/2011 09:36 AM, Jouni K. Seppänen wrote:
>> I just wrote this as a response to a question on
>> https://github.com/matplotlib/matplotlib/pull/32
>> about how to merge to v1.0.x and master.
>>
>> Please feel free to comment or ask for details.
>>
>> ------------------------------------------------------------------------------
>> First make sure your v1.0.x branch is fresh:
>>
>>      git checkout v1.0.x
>>      git pull --ff-only upstream v1.0.x
>>
>> (This assumes an "upstream" remote pointing to
>> `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull
>
> By default, however, if you have cloned from
> gi...@gi...:matplotlib/matplotlib.git then instead of "upstream" the
> remote will be "origin".
>
> Are you recommending and assuming that we clone *only* from our
> individual github forks, and then add the "upstream" remote to point to
> the official repo?

No, I don't think there is such an assumption. Remotes can be named
whatever you want. I've ditched the "origin/upstream" convention for
naming remotes entirely, and instead use "matplotlib", "darrendale",
etc. I think Jouni was clear: "This assumes an "upstream" remote
pointing to ..."

>> request and run the test suite (I don't know if this should be
>> mandatory):
>>
>>      git merge bugfix/legend_windowcall # replace by whatever you are merging
>>      python setup.py install # or however you compile things to run the tests
>>      ./tests.py # all new test runner script!
>>
>> If everything is fine, push:
>>
>>      git push gi...@gi...:matplotlib/matplotlib.git v1.0.x
>
> Can't this be simplified by using "origin" or "upstream" in place of the
> url?

I think it can.

>>
>> Next do the same with master, this time merging v1.0.x:
>>
>>      git checkout master
>>      git pull --ff-only upstream master
>>      git merge v1.0.x
>>      python setup.py install
>>      ./tests.py
>>      git push gi...@gi...:matplotlib/matplotlib.git master
>> ------------------------------------------------------------------------------
>>
>> There are multiple ways things could go wrong, which will need
>> instructions in the devel docs. These are the cases I can think of:
>>
>> 1. git pull --ff-only fails because fast-forward is impossible
>>     (you have commits on an integration branch that don't belong there)
>> 2. the merge has conflicts
>
> I encountered that last night.  The conflict was a simple one that will
> occur often: the CHANGELOG needed to have the new entry prepended, so as
> to be at the top of the file, above new entries that were in master but
> not in v1.0.x.  Instructions for simplest case:
>
> Edit the conflicted files, remembering to remove the conflict markers;
> test as needed; use "git add" to add the resolved files (and any other
> files that needed to be changed to make the merge work) to the index, e.g.
>
>     git add CHANGELOG
>
> Then commit; a merge commit message will be generated, and can be edited
> as needed:
>
>     git commit
>
> Now you are ready to push.
>
>> 3. the tests fail (also a kind of merge conflict, assuming the tests
>>     passed before)
>> 4. the push fails because fast-forward is impossible (someone has
>>     pushed in the meantime)
>> 5. v1.0.x doesn't merge cleanly into master
>
> What do you mean by this?  What is the symptom?

The master branch may have changed such that the same lines of code
have been edited in different ways along the master and v1.0.x
branches of development.

Darren

Hi Jouni,

Thanks for doing this...

On Mon, Mar 7, 2011 at 2:36 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> I just wrote this as a response to a question on
> https://github.com/matplotlib/matplotlib/pull/32
> about how to merge to v1.0.x and master.
>
> Please feel free to comment or ask for details.
>
> ------------------------------------------------------------------------------
> First make sure your v1.0.x branch is fresh:
>
>    git checkout v1.0.x
>    git pull --ff-only upstream v1.0.x
>
> (This assumes an "upstream" remote pointing to
> `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull
> request and run the test suite (I don't know if this should be
> mandatory):
>
>    git merge bugfix/legend_windowcall # replace by whatever you are merging
>    python setup.py install # or however you compile things to run the tests
>    ./tests.py # all new test runner script!
>
> If everything is fine, push:
>
>    git push gi...@gi...:matplotlib/matplotlib.git v1.0.x
>
> Next do the same with master, this time merging v1.0.x:
>
>    git checkout master
>    git pull --ff-only upstream master
>    git merge v1.0.x
>    python setup.py install
>    ./tests.py
>    git push gi...@gi...:matplotlib/matplotlib.git master

We might also want to mention the special case of what needs to be
done for a change not intended for merging into master.

> ------------------------------------------------------------------------------

No comments, it's just the way I would have recommended it.

> There are multiple ways things could go wrong, which will need
> instructions in the devel docs. These are the cases I can think of:
>
> 1. git pull --ff-only fails because fast-forward is impossible
>   (you have commits on an integration branch that don't belong there)

Right, and we should emphasize that integration branches (like master
and v1.0.x) in your local repo should only ever get ahead of the
remote repo for the few moments between merging a branch and pushing
back up to the remote.

> 2. the merge has conflicts
> 3. the tests fail (also a kind of merge conflict, assuming the tests
>   passed before)
> 4. the push fails because fast-forward is impossible (someone has
>   pushed in the meantime)
> 5. v1.0.x doesn't merge cleanly into master

Nicely summarized.

Darren

On 03/07/2011 09:36 AM, Jouni K. Seppänen wrote:
> I just wrote this as a response to a question on
> https://github.com/matplotlib/matplotlib/pull/32
> about how to merge to v1.0.x and master.
>
> Please feel free to comment or ask for details.
>
> ------------------------------------------------------------------------------
> First make sure your v1.0.x branch is fresh:
>
>      git checkout v1.0.x
>      git pull --ff-only upstream v1.0.x
>
> (This assumes an "upstream" remote pointing to
> `git://github.com/matplotlib/matplotlib.git`.) Then merge your pull

By default, however, if you have cloned from 
gi...@gi...:matplotlib/matplotlib.git then instead of "upstream" the 
remote will be "origin".

Are you recommending and assuming that we clone *only* from our 
individual github forks, and then add the "upstream" remote to point to 
the official repo?

> request and run the test suite (I don't know if this should be
> mandatory):
>
>      git merge bugfix/legend_windowcall # replace by whatever you are merging
>      python setup.py install # or however you compile things to run the tests
>      ./tests.py # all new test runner script!
>
> If everything is fine, push:
>
>      git push gi...@gi...:matplotlib/matplotlib.git v1.0.x

Can't this be simplified by using "origin" or "upstream" in place of the 
url?

>
> Next do the same with master, this time merging v1.0.x:
>
>      git checkout master
>      git pull --ff-only upstream master
>      git merge v1.0.x
>      python setup.py install
>      ./tests.py
>      git push gi...@gi...:matplotlib/matplotlib.git master
> ------------------------------------------------------------------------------
>
> There are multiple ways things could go wrong, which will need
> instructions in the devel docs. These are the cases I can think of:
>
> 1. git pull --ff-only fails because fast-forward is impossible
>     (you have commits on an integration branch that don't belong there)
> 2. the merge has conflicts

I encountered that last night.  The conflict was a simple one that will 
occur often: the CHANGELOG needed to have the new entry prepended, so as 
to be at the top of the file, above new entries that were in master but 
not in v1.0.x.  Instructions for simplest case:

Edit the conflicted files, remembering to remove the conflict markers;
test as needed; use "git add" to add the resolved files (and any other 
files that needed to be changed to make the merge work) to the index, e.g.

     git add CHANGELOG

Then commit; a merge commit message will be generated, and can be edited 
as needed:

     git commit

Now you are ready to push.

> 3. the tests fail (also a kind of merge conflict, assuming the tests
>     passed before)
> 4. the push fails because fast-forward is impossible (someone has
>     pushed in the meantime)
> 5. v1.0.x doesn't merge cleanly into master

What do you mean by this?  What is the symptom?

Eric

I just wrote this as a response to a question on
https://github.com/matplotlib/matplotlib/pull/32
about how to merge to v1.0.x and master.

Please feel free to comment or ask for details.

------------------------------------------------------------------------------
First make sure your v1.0.x branch is fresh:

    git checkout v1.0.x
    git pull --ff-only upstream v1.0.x

(This assumes an "upstream" remote pointing to
`git://github.com/matplotlib/matplotlib.git`.) Then merge your pull
request and run the test suite (I don't know if this should be
mandatory):

    git merge bugfix/legend_windowcall # replace by whatever you are merging
    python setup.py install # or however you compile things to run the tests
    ./tests.py # all new test runner script!

If everything is fine, push:

    git push gi...@gi...:matplotlib/matplotlib.git v1.0.x

Next do the same with master, this time merging v1.0.x:

    git checkout master
    git pull --ff-only upstream master
    git merge v1.0.x
    python setup.py install
    ./tests.py
    git push gi...@gi...:matplotlib/matplotlib.git master
------------------------------------------------------------------------------

There are multiple ways things could go wrong, which will need
instructions in the devel docs. These are the cases I can think of:

1. git pull --ff-only fails because fast-forward is impossible
   (you have commits on an integration branch that don't belong there)
2. the merge has conflicts
3. the tests fail (also a kind of merge conflict, assuming the tests
   passed before)
4. the push fails because fast-forward is impossible (someone has 
   pushed in the meantime)
5. v1.0.x doesn't merge cleanly into master

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Mon, Mar 7, 2011 at 11:24 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Mon, Mar 7, 2011 at 10:20 AM, Darren Dale <dsd...@gm...> wrote:
>>
>> On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root <ben...@ou...> wrote:
>> >
>> >
>> > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann
>> > <lkb...@gm...>
>> > wrote:
>> >>
>> >> Hi Ben, Hi list,
>> >>
>> >> > Exactly.  That's all I found too.  Nothing indicates that we need to
>> >> > change anything.  We are throwing away the second part of the tuple
>> >> > which has the returned filter.  The only reason I see for the new
>> >> > function is so the coder can get back the filter string, which we
>> >> > don't seem to use.
>> >>
>> >> It took me a while to see the problem, too. The point is: there is one
>> >> parameter
>> >> missing in the new API of getSaveFileName, called selectedFilter,
>> >> which we use, and
>> >> given that it is missing, python takes it to be the next parameter,
>> >> which
>> >> must be an int, and you get a TypeError. I discussed this with
>> >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
>> >> (see
>> >>
>> >> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
>> >> and he told me to use getSaveFileNameAndFilter.
>> >>
>> >> The other option would be to change PyQt4, dunno which is best.
>> >>
>> >> Greetings
>> >>
>> >> Martin
>> >>
>> >
>> > Martin, thanks for the explanation.  That made a lot more sense.  I will
>> > go
>> > ahead with the patch.
>>
>> getSaveFileNameAndFilter was only added in pyqt-4.6.
>
>
> oy!  Why the heck did qt4 change their API like this?

To make it more pythonic for python-3. You can set the api to v2 with
python-2, but it is not the default.

> What should we do?

I think the change being discussed is only necessary when the QString
api is set to v2. So, we should be able to do something along the
lines of:


import sip

try:
   if sip.getapi("QString") > 1:
       # support the new api
   else:
       # support the old api
except (AttributeError, KeyError): # call to getapi may fail with
older versions of sip
   # support the old api

> I also assume that some sort of fix should be applied to the v1.0.x?

I think it should be, if the fix does not break backward compatibility
with <PyQt4-4.6.

Darren

On Mon, Mar 7, 2011 at 10:20 AM, Darren Dale <dsd...@gm...> wrote:

> On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann <
> lkb...@gm...>
> > wrote:
> >>
> >> Hi Ben, Hi list,
> >>
> >> > Exactly.  That's all I found too.  Nothing indicates that we need to
> >> > change anything.  We are throwing away the second part of the tuple
> >> > which has the returned filter.  The only reason I see for the new
> >> > function is so the coder can get back the filter string, which we
> >> > don't seem to use.
> >>
> >> It took me a while to see the problem, too. The point is: there is one
> >> parameter
> >> missing in the new API of getSaveFileName, called selectedFilter,
> >> which we use, and
> >> given that it is missing, python takes it to be the next parameter,
> which
> >> must be an int, and you get a TypeError. I discussed this with
> >> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
> >> (see
> >> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html
> )
> >> and he told me to use getSaveFileNameAndFilter.
> >>
> >> The other option would be to change PyQt4, dunno which is best.
> >>
> >> Greetings
> >>
> >> Martin
> >>
> >
> > Martin, thanks for the explanation.  That made a lot more sense.  I will
> go
> > ahead with the patch.
>
> getSaveFileNameAndFilter was only added in pyqt-4.6.
>


oy!  Why the heck did qt4 change their API like this?  What should we do?  I
also assume that some sort of fix should be applied to the v1.0.x?

Ben Root

On Mon, Mar 7, 2011 at 11:04 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann <lkb...@gm...>
> wrote:
>>
>> Hi Ben, Hi list,
>>
>> > Exactly.  That's all I found too.  Nothing indicates that we need to
>> > change anything.  We are throwing away the second part of the tuple
>> > which has the returned filter.  The only reason I see for the new
>> > function is so the coder can get back the filter string, which we
>> > don't seem to use.
>>
>> It took me a while to see the problem, too. The point is: there is one
>> parameter
>> missing in the new API of getSaveFileName, called selectedFilter,
>> which we use, and
>> given that it is missing, python takes it to be the next parameter, which
>> must be an int, and you get a TypeError. I discussed this with
>> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
>> (see
>> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
>> and he told me to use getSaveFileNameAndFilter.
>>
>> The other option would be to change PyQt4, dunno which is best.
>>
>> Greetings
>>
>> Martin
>>
>
> Martin, thanks for the explanation.  That made a lot more sense.  I will go
> ahead with the patch.

getSaveFileNameAndFilter was only added in pyqt-4.6.

On Fri, Mar 4, 2011 at 4:23 AM, Martin Teichmann <lkb...@gm...>wrote:

> Hi Ben, Hi list,
>
> > Exactly.  That's all I found too.  Nothing indicates that we need to
> > change anything.  We are throwing away the second part of the tuple
> > which has the returned filter.  The only reason I see for the new
> > function is so the coder can get back the filter string, which we
> > don't seem to use.
>
> It took me a while to see the problem, too. The point is: there is one
> parameter
> missing in the new API of getSaveFileName, called selectedFilter,
> which we use, and
> given that it is missing, python takes it to be the next parameter, which
> must be an int, and you get a TypeError. I discussed this with
> Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
> (see
> http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
> and he told me to use getSaveFileNameAndFilter.
>
> The other option would be to change PyQt4, dunno which is best.
>
> Greetings
>
> Martin
>
>
Martin, thanks for the explanation.  That made a lot more sense.  I will go
ahead with the patch.

Ben Root

On Sun, Mar 6, 2011 at 7:18 AM, Jae-Joon Lee <lee...@gm...> wrote:

> Hi,
>
> According to the legend doc,
>
>    If label is set to '_nolegend_', the item will not be shown in
>    legend.
>
> But I think the documented behavior a bit ambiguous. For example,
> consider the example below.
>
>    l1, = plot([1,2,3], label="_nolegend_")
>    l2, = plot([2,3,1])
>    legend(["my line"])
>
> I suppose the legend should show *l2* with "my line" label. But the
> current master branch shows "l1" with "my line" label.
>
> In other words, in the current implementation, when the legend command
> is called with a single nonkeyword argument (which is interpreted as a
> list of labels), the given labels are applied to all the artists
> regardless whether the artist has a label of "_nolegend_" or not.
>
> While there could be some cases that have relied on this behavior, I'm
> inclined to fix this so that artists w/ "_nolegend_" are ignored.
> However, fixing this requires "hist" command to be modified (there
> could be more commands that need modification).
>
> Unless there is no objection from other developers, I'll go ahead and
> commit the patch to fix this.
>
> Regards,
>
> -JJ
>
>
I agree, the current behavior is buggy.

Ben Root

Eric Firing <ef...@ha...> writes:

> However, I have run nosetests on a build of master on Ubuntu 10.10, with 
> freetype 2.4.2, and I see the same failure that you showed on the 
> font_styles test.  Same test on a build of v1.0.x, same failure.  Fails 
> for png and svg; passes for pdf, but the images being compared are ugly 
> low-res bitmapped things.

The pdf comparison is designed that way: the baseline image and the test
result are rendered at test time with ghostscript without antialiasing,
and while it looks ugly it's both pretty fast and a good comparison,
since the files are rendered by exactly the same version of ghostscript
with the same settings. It's not surprising that the pdf tests pass,
since freetype is used only for finding some font information that needs
to be output into the pdf file, and all font rendering is done by the
pdf engine of the end user.

> The major change between the freetype 2.3 series and 2.4 seems to be "In 
> addition to many bugfixes, the TrueType bytecode interpreter is now 
> enabled by default. All users should upgrade."

It could be that we have inadvertently relied on bugs, or that truetype
hints cause differences that big.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 03/06/2011 02:08 AM, Jouni K. Seppänen wrote:
> Eric Firing<ef...@ha...>  writes:
>
>> Newer versions of the libraries can also be used, although this is not
>> critical.  v1.0.x still needs the 1.2 series of libpng, but master can
>> now handle
>>
>> ZLIBVERSION=1.2.5
>> PNGVERSION=1.5.1
>> FREETYPEVERSION=2.4.4
>
> With the old versions (including freetype 2.3.11) the test suite passes
> for me (163 tests, 50 knownfail because I don't have a working inkscape
> on my Mac), but with the new versions I get 18 failures. All seem to be
> caused by text being rendered in different locations, or with different
> fonts. I'm attaching two examples of this: in the font_styles test, two
> of the styles do not work, and in image_clip the text inside the circle
> is in completely different coordinates.
>
>
>
>
>
> Is this a known problem? Again, with the old libraries all tests pass
> for me, except for the svg images for which I don't have comparison
> tools, so I believe this to be caused by the dependencies, most likely
> freetype.

I have to admit I did not do these tests; I was experimenting with a 
borrowed machine, and I ran out of time.

However, I have run nosetests on a build of master on Ubuntu 10.10, with 
freetype 2.4.2, and I see the same failure that you showed on the 
font_styles test.  Same test on a build of v1.0.x, same failure.  Fails 
for png and svg; passes for pdf, but the images being compared are ugly 
low-res bitmapped things.

The major change between the freetype 2.3 series and 2.4 seems to be "In 
addition to many bugfixes, the TrueType bytecode interpreter is now 
enabled by default. All users should upgrade."

Eric

On Sun, Mar 6, 2011 at 4:46 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Fernando Garcia Bermudez <fg...@ee...> writes:
>
>> Do you know if these changes will trickle to the py3 repo after
>> merging into master?
>
> I don't know if we have a process in place for that. It depends on how
> you view the py3 repo: if it's just another feature branch, it shouldn't
> do any merges from master just for the sake of it, but if it's kind of
> like "next" or "pu" (proposed updates) in some workflows, it makes sense
> for it to be occasionally brought up to date (possibly even by
> rebasing).

I guess the py3 master will not be merged back into the matplotlib
repo until the last maintenance branch supporting python-2.5 and older
has been created (perhaps 1.1.x or 1.2.x). Since it is a long-running
line of development, I think it makes sense to occasionally bring it
up to date with the master branch. I've already done this once or
twice. I don't think we want to deal with rebasing. I rebased the py3
master branch once right after you merged the maintenance branches
with --strategy=ours, since that provided a much improved point of
reference, but it was a headache to coordinate with even one other dev
to deal with any unmerged branches out there effected by the rebase.

Maybe once the osx make binaries issue is resolved and the make.osx
branch is merged into master, someone with a working windows build
environment could test building binaries with python-2.6 and 2.7. If
it looks ok, that might be a good point to merge matplotlib/master
into py3/master.

Darren

Hi,

According to the legend doc,

    If label is set to '_nolegend_', the item will not be shown in
    legend.

But I think the documented behavior a bit ambiguous. For example,
consider the example below.

    l1, = plot([1,2,3], label="_nolegend_")
    l2, = plot([2,3,1])
    legend(["my line"])

I suppose the legend should show *l2* with "my line" label. But the
current master branch shows "l1" with "my line" label.

In other words, in the current implementation, when the legend command
is called with a single nonkeyword argument (which is interpreted as a
list of labels), the given labels are applied to all the artists
regardless whether the artist has a label of "_nolegend_" or not.

While there could be some cases that have relied on this behavior, I'm
inclined to fix this so that artists w/ "_nolegend_" are ignored.
However, fixing this requires "hist" command to be modified (there
could be more commands that need modification).

Unless there is no objection from other developers, I'll go ahead and
commit the patch to fix this.

Regards,

-JJ

Fernando Garcia Bermudez <fg...@ee...> writes:

> Do you know if these changes will trickle to the py3 repo after
> merging into master?

I don't know if we have a process in place for that. It depends on how
you view the py3 repo: if it's just another feature branch, it shouldn't
do any merges from master just for the sake of it, but if it's kind of
like "next" or "pu" (proposed updates) in some workflows, it makes sense
for it to be occasionally brought up to date (possibly even by
rebasing).

But it's fine for even feature branches to merge from master, e.g. if
there is a feature in master that the branch is going to depend on.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Sat, Mar 5, 2011 at 23:52, Jouni K. Seppänen <jk...@ik...> wrote:

> Thanks; pull request #17 is IMHO ready for merging into v1.0.x, but
> let's wait to see if anyone has further comments. I created pull request
> #30 for merging into master; that one also has newer dependency versions
> as suggested by Eric.
>

Do you know if these changes will trickle to the py3 repo after merging into
master? I initially came up with the patch while compiling the old py3k
branch and when I realized it also applied to matplotlib Darren suggested I
submit the pull request there. I'm asking this because there's another tiny
change that pertains to the py3 version of the patch and I wonder whether I
should wait or start the pull process now.

-- Fernando

Fernando Garcia Bermudez
<fg...@ee...> writes:

> I tested your changes (up to mpl_install_std) and merged the pull request.
> Upon solving the binaries issue we could probably close this pull request.
> Or we could open an issue for that particular matter.

Thanks; pull request #17 is IMHO ready for merging into v1.0.x, but
let's wait to see if anyone has further comments. I created pull request
#30 for merging into master; that one also has newer dependency versions
as suggested by Eric.

On master, I was able to almost run "make binaries", except somehow
bdist_mpkg didn't agree with the makefile about all the version numbers
in the mpkg filename, so hdiutil failed due to a missing input file. I
do think that problem is unrelated to these changes.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks