matplotlib-devel Mailing List for matplotlib (Page 5)

On Tue, Jan 6, 2009 at 3:07 PM, Andrew Straw <str...@as...> wrote:
> Hi Mike, This sounds like good news. I am swamped right now, but I hope
> to get the git mirror on github up-to-date early next week when work is
> a little less busy.
>
> John (or any developer with SF admin capabilities), if we could set up
> some kind of auto-notification on SVN commits, I could possibly set up a
> script to update the git repo. The thing I've seen so far is to go to
> the Sourceforge project page and under "Admin" selection "Subversion"
> then at the bottom in the "Hooks" section, change the entry to
> "ciabot_svn.py - Send commit stats to cia.navi.cx". If you could do
> that, from there I will attempt to take things to auto-update the git
> mirror.
I think you should have the permissions to do this Andrew so give it a
shot and let me know if you encounter any problems.
BTW, hexbin has been really useful to me -- I made a couple of
enhancements (adding the marginal distributions, suppressing cells
where mincnt < some threshold) so check them out with your use cases.
JDH

Hi Mike, This sounds like good news. I am swamped right now, but I hope
to get the git mirror on github up-to-date early next week when work is
a little less busy.
John (or any developer with SF admin capabilities), if we could set up
some kind of auto-notification on SVN commits, I could possibly set up a
script to update the git repo. The thing I've seen so far is to go to
the Sourceforge project page and under "Admin" selection "Subversion"
then at the bottom in the "Hooks" section, change the entry to
"ciabot_svn.py - Send commit stats to cia.navi.cx". If you could do
that, from there I will attempt to take things to auto-update the git
mirror.
-Andrew
Michael Droettboom wrote:
> I have successfully used the git mirror to commit changes to the 
> maintenance branch. I've updated the matplotlib developer docs to 
> describe how to do it (not that bad really), though it takes a while 
> given the v0_98_4 "oops" branch ;) I have yet to figure out all the 
> loop-de-loops required to merge from the maintenance branch to the trunk 
> in git and then push that all back to SVN (should be possible, but may 
> not play well with svnmerge, anyway). The good news is that, as always, 
> svnmerge still works for that purpose.
> 
> Mike
> 
> Michael Droettboom wrote:
>> Thanks. These are really helpful pointers. For me, this is the one 
>> missing piece that would help me use git full-time, particularly with 
>> the way matplotlib and other projects I work on are laid out in SVN. So 
>> I'm pretty motivated to figure this out.
>>
>> I'll certainly share any findings in this regard.
>>
>> Cheers,
>> Mike
>>
>> Andrew Straw wrote:
>> 
>>> Hi Mike,
>>>
>>> I have not imported the branches. ( IIRC, this was there were several
>>> that weren't MPL but other parts of the repo such as py4science,
>>> toolkits and so on). It may be possible to add just the 0.98.5
>>> maintenance branch without the others, but I won't have a chance
>>> immediately to play around with that.
>>>
>>> To add all the branches to your git repo, you might be able to add
>>> something like "branches = branches/*:refs/remotes/branches/*" to the
>>> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
>>> This will grab all the branches over all svn history, which will, I
>>> think, pull in py4science and toolkits branches... And I guess the
>>> download time from svn will be extremely long... In that case it's
>>> probably better to rsync from sourceforge's server to a local disk and
>>> do the git svn checkout that way making a whole new git repo.
>>>
>>> It may be worth attempting to talk to some real git/svn gurus at this
>>> point about tracking (only one or a couple) svn branches with git
>>> branches. So far, I've only dealt with the trunk in my git/svn
>>> interoperation experience.
>>>
>>> -Andrew
>>>
>>> Michael Droettboom wrote:
>>> 
>>> 
>>>> Thanks. I've incorporated your docs into the developer documentation.
>>>>
>>>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>>>> branch with git. SVN tags/* show up as available remote branches, but 
>>>> not branches/*, which leaves me a bit stumped? If you've done this and 
>>>> there's a quick answer, let me know, otherwise I'll do a little digging 
>>>> to see if it's possible.
>>>>
>>>> Mike
>>>>
>>>> Andrew Straw wrote:
>>>> 
>>>> 
>>>>> Hi Michael,
>>>>>
>>>>> The main issue is that we can't use git "normally" because the main
>>>>> history will be kept with svn. Thus, there's going to be a lot of
>>>>> history rewriting going on through the rebase command. (These
>>>>> complications are obviously not the ideal scenario for git newbies...)
>>>>> Rather than answer your questions directly, I'll walk you through how I
>>>>> do things. (This is not tried on the MPL svn repo, but some a private
>>>>> svn repo. I don't see any fundamental differences, though. So this
>>>>> should work.)
>>>>>
>>>>> (Hopefully this will be cut-and-pasteable ReST, which could go in the
>>>>> docs somewhere):
>>>>>
>>>>> Making a git feature branch and committing to svn trunk
>>>>> -------------------------------------------------------
>>>>>
>>>>> Start with a virgin tree in sync with the svn trunk on the git branch
>>>>> "master"::
>>>>>
>>>>> git checkout master
>>>>> git svn rebase
>>>>>
>>>>> To create a new, local branch called "whizbang-branch"::
>>>>>
>>>>> git checkout -b whizbang-branch
>>>>>
>>>>> Do make commits to the local branch::
>>>>>
>>>>> # hack on a bunch of files
>>>>> git add bunch of files
>>>>> git commit -m "modified a bunch of files"
>>>>> # repeat this as necessary
>>>>>
>>>>> Now, go back to the master branch and append the history of your branch
>>>>> to the master branch, which will end up as the svn trunk::
>>>>>
>>>>> git checkout master
>>>>> git svn rebase # Ensure we have most recent svn
>>>>> git rebase whizbang-branch # Append whizbang changes to master branch
>>>>> git svn dcommit -n # Check that this will apply to svn
>>>>> git svn dcommit # Actually apply to svn
>>>>>
>>>>> Finally, you may want to continue working on your whizbang-branch, so
>>>>> rebase it to the new master::
>>>>>
>>>>> git checkout whizbang-branch
>>>>> git rebase master
>>>>>
>>>>> Michael Droettboom wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> This is mostly for Andrew Straw, but thought anyone else experimenting
>>>>>> with git may be interested. I'm going through some real newbie pains
>>>>>> here, and I don't think what I'm doing is all that advanced.
>>>>>>
>>>>>> So, I've had a local git repository cloned from github (as per Andrew's
>>>>>> instructions), made a branch, started hacking, all is well. Now, I
>>>>>> would like to update my master branch from SVN to get some of the recent
>>>>>> changes others have been making.
>>>>>>
>>>>>> Following the instructions in the FAQ,
>>>>>>
>>>>>> git svn rebase
>>>>>>
>>>>>> actually results in a number of conflicts in files I didn't touch. I
>>>>>> shouldn't have to resolve this conflicts, right? 'git status' shows no
>>>>>> local changes, nothing staged -- nothing that should conflict.
>>>>>>
>>>>>> It turns out, if I do
>>>>>>
>>>>>> git pull
>>>>>>
>>>>>> then,
>>>>>>
>>>>>> git svn rebase
>>>>>>
>>>>>> all is well.
>>>>>>
>>>>>> Any idea why? Should I add that to the instructions in the FAQ?
>>>>>>
>>>>>> Now, here's where I'm really stumped. I finished my experimental
>>>>>> branch, and I would like to commit it back to SVN.
>>>>>>
>>>>>> This is what I did, with comments preceded by '#'
>>>>>>
>>>>>> # Go back to the master branch
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> git checkout master
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> # Merge in experimental
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> git merge experimental
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> # Ok -- looks good: experimental new feature is integrated, there were
>>>>>> no conflicts
>>>>>> # However...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> git svn dcommit
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> Committing to
>>>>>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
>>>>>> ...
>>>>>> Merge conflict during commit: File or directory
>>>>>> 'doc/users/whats_new.rst' is out of date; try updating: resource out of
>>>>>> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
>>>>>> # 1) I didn't change that file, why should I care
>>>>>> # 2) I don't know who to update it
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> git pull
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> Already up-to-date.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> git svn rebase
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> First, rewinding head to replay your work on top of it...
>>>>>> Applying: more doc adds
>>>>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
>>>>>> whitespace.
>>>>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace
>>>>>> errors.
>>>>>> Applying: added some docs for linestyles and markers
>>>>>> Applying: Remove trailing whitespace.
>>>>>> Applying: figure/subplot and font_manager bugfixes
>>>>>> Applying: added support for xlwt in exceltools
>>>>>> Applying: fixed a typo in whats_new_98_4_legend.py
>>>>>> Applying: fixed typo in Line2D.set_marker doc.
>>>>>> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
>>>>>> Applying: more doc adds
>>>>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
>>>>>> whitespace.
>>>>>> a lot of new features and bug-fixes. error: patch failed:
>>>>>> doc/users/whats_new.rst:10
>>>>>> error: doc/users/whats_new.rst: patch does not apply
>>>>>> Using index info to reconstruct a base tree...
>>>>>> <stdin>:14: trailing whitespace.
>>>>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace
>>>>>> errors.
>>>>>> Falling back to patching base and 3-way merge...
>>>>>> No changes -- Patch already applied.
>>>>>> Applying: added some docs for linestyles and markers
>>>>>> error: patch failed: doc/devel/coding_guide.rst:62
>>>>>> error: doc/devel/coding_guide.rst: patch does not apply
>>>>>> error: patch failed: doc/matplotlibrc:43
>>>>>> error: doc/matplotlibrc: patch does not apply
>>>>>> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
>>>>>> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
>>>>>> error: patch failed: lib/matplotlib/lines.py:313
>>>>>> error: lib/matplotlib/lines.py: patch does not apply
>>>>>> Using index info to reconstruct a base tree...
>>>>>> Falling back to patching base and 3-way merge...
>>>>>> Auto-merged doc/pyplots/whats_new_98_4_legend.py
>>>>>> CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py
>>>>>> Auto-merged lib/matplotlib/lines.py
>>>>>> Failed to merge in the changes.
>>>>>> Patch failed at 0010.
>>>>>>
>>>>>> When you have resolved this problem run "git rebase --continue".
>>>>>> If you would prefer to skip this patch, instead run "git rebase --skip".
>>>>>> To restore the original branch and stop rebasing run "git rebase --abort".
>>>>>>
>>>>>> rebase refs/remotes/trunk: command returned error: 1
>>>>>> # Ok, I'm back to merging files that don't conflict with my changes! # I
>>>>>> shouldn't have to do that, right?
>>>>>> # And FYI:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> git status
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> doc/pyplots/whats_new_98_4_legend.py: needs merge
>>>>>> # Not currently on any branch.
>>>>>> # Changes to be committed:
>>>>>> # (use "git reset HEAD <file>..." to unstage)
>>>>>> #
>>>>>> # modified: lib/matplotlib/lines.py
>>>>>> #
>>>>>> # Changed but not updated:
>>>>>> # (use "git add <file>..." to update what will be committed)
>>>>>> #
>>>>>> # unmerged: doc/pyplots/whats_new_98_4_legend.py
>>>>>> #
>>>>>> # Untracked files:
>>>>>> # (use "git add <file>..." to include in what will be committed)
>>>>>> #
>>>>>> # lib/matplotlib/mpl-data/matplotlib.conf
>>>>>> # lib/matplotlib/mpl-data/matplotlibrc
>>>>>> # setupext.pyc
>>>>>> # src/backend_agg.cpp~
>>>>>>
>>>>>> Now I feel stuck. How do I "undo" the merge from experimental to master?
>>>>>>
>>>>>> Sorry if these are obvious questions, but I think I've followed the
>>>>>> git-svn instructions -- I must have made a mistake somewhere along the
>>>>>> way, but I'm not sure how to debug and/or fix it.
>>>>>>
>>>>>> Mike
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> ------------------------------------------------------------------------------
>>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
>>>> The future of the web can't happen without you. Join us at MIX09 to help
>>>> pave the way to the Next Web now. Learn more and register at
>>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>> 
>>>> 
>>> 
>>> 
>> 
> 

I have successfully used the git mirror to commit changes to the 
maintenance branch. I've updated the matplotlib developer docs to 
describe how to do it (not that bad really), though it takes a while 
given the v0_98_4 "oops" branch ;) I have yet to figure out all the 
loop-de-loops required to merge from the maintenance branch to the trunk 
in git and then push that all back to SVN (should be possible, but may 
not play well with svnmerge, anyway). The good news is that, as always, 
svnmerge still works for that purpose.
Mike
Michael Droettboom wrote:
> Thanks. These are really helpful pointers. For me, this is the one 
> missing piece that would help me use git full-time, particularly with 
> the way matplotlib and other projects I work on are laid out in SVN. So 
> I'm pretty motivated to figure this out.
>
> I'll certainly share any findings in this regard.
>
> Cheers,
> Mike
>
> Andrew Straw wrote:
> 
>> Hi Mike,
>>
>> I have not imported the branches. ( IIRC, this was there were several
>> that weren't MPL but other parts of the repo such as py4science,
>> toolkits and so on). It may be possible to add just the 0.98.5
>> maintenance branch without the others, but I won't have a chance
>> immediately to play around with that.
>>
>> To add all the branches to your git repo, you might be able to add
>> something like "branches = branches/*:refs/remotes/branches/*" to the
>> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
>> This will grab all the branches over all svn history, which will, I
>> think, pull in py4science and toolkits branches... And I guess the
>> download time from svn will be extremely long... In that case it's
>> probably better to rsync from sourceforge's server to a local disk and
>> do the git svn checkout that way making a whole new git repo.
>>
>> It may be worth attempting to talk to some real git/svn gurus at this
>> point about tracking (only one or a couple) svn branches with git
>> branches. So far, I've only dealt with the trunk in my git/svn
>> interoperation experience.
>>
>> -Andrew
>>
>> Michael Droettboom wrote:
>> 
>> 
>>> Thanks. I've incorporated your docs into the developer documentation.
>>>
>>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>>> branch with git. SVN tags/* show up as available remote branches, but 
>>> not branches/*, which leaves me a bit stumped? If you've done this and 
>>> there's a quick answer, let me know, otherwise I'll do a little digging 
>>> to see if it's possible.
>>>
>>> Mike
>>>
>>> Andrew Straw wrote:
>>> 
>>> 
>>>> Hi Michael,
>>>>
>>>> The main issue is that we can't use git "normally" because the main
>>>> history will be kept with svn. Thus, there's going to be a lot of
>>>> history rewriting going on through the rebase command. (These
>>>> complications are obviously not the ideal scenario for git newbies...)
>>>> Rather than answer your questions directly, I'll walk you through how I
>>>> do things. (This is not tried on the MPL svn repo, but some a private
>>>> svn repo. I don't see any fundamental differences, though. So this
>>>> should work.)
>>>>
>>>> (Hopefully this will be cut-and-pasteable ReST, which could go in the
>>>> docs somewhere):
>>>>
>>>> Making a git feature branch and committing to svn trunk
>>>> -------------------------------------------------------
>>>>
>>>> Start with a virgin tree in sync with the svn trunk on the git branch
>>>> "master"::
>>>>
>>>> git checkout master
>>>> git svn rebase
>>>>
>>>> To create a new, local branch called "whizbang-branch"::
>>>>
>>>> git checkout -b whizbang-branch
>>>>
>>>> Do make commits to the local branch::
>>>>
>>>> # hack on a bunch of files
>>>> git add bunch of files
>>>> git commit -m "modified a bunch of files"
>>>> # repeat this as necessary
>>>>
>>>> Now, go back to the master branch and append the history of your branch
>>>> to the master branch, which will end up as the svn trunk::
>>>>
>>>> git checkout master
>>>> git svn rebase # Ensure we have most recent svn
>>>> git rebase whizbang-branch # Append whizbang changes to master branch
>>>> git svn dcommit -n # Check that this will apply to svn
>>>> git svn dcommit # Actually apply to svn
>>>>
>>>> Finally, you may want to continue working on your whizbang-branch, so
>>>> rebase it to the new master::
>>>>
>>>> git checkout whizbang-branch
>>>> git rebase master
>>>>
>>>> Michael Droettboom wrote:
>>>> 
>>>> 
>>>> 
>>>>> This is mostly for Andrew Straw, but thought anyone else experimenting
>>>>> with git may be interested. I'm going through some real newbie pains
>>>>> here, and I don't think what I'm doing is all that advanced.
>>>>>
>>>>> So, I've had a local git repository cloned from github (as per Andrew's
>>>>> instructions), made a branch, started hacking, all is well. Now, I
>>>>> would like to update my master branch from SVN to get some of the recent
>>>>> changes others have been making.
>>>>>
>>>>> Following the instructions in the FAQ,
>>>>>
>>>>> git svn rebase
>>>>>
>>>>> actually results in a number of conflicts in files I didn't touch. I
>>>>> shouldn't have to resolve this conflicts, right? 'git status' shows no
>>>>> local changes, nothing staged -- nothing that should conflict.
>>>>>
>>>>> It turns out, if I do
>>>>>
>>>>> git pull
>>>>>
>>>>> then,
>>>>>
>>>>> git svn rebase
>>>>>
>>>>> all is well.
>>>>>
>>>>> Any idea why? Should I add that to the instructions in the FAQ?
>>>>>
>>>>> Now, here's where I'm really stumped. I finished my experimental
>>>>> branch, and I would like to commit it back to SVN.
>>>>>
>>>>> This is what I did, with comments preceded by '#'
>>>>>
>>>>> # Go back to the master branch
>>>>> 
>>>>> 
>>>>> 
>>>>>> git checkout master
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> # Merge in experimental
>>>>> 
>>>>> 
>>>>> 
>>>>>> git merge experimental
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> # Ok -- looks good: experimental new feature is integrated, there were
>>>>> no conflicts
>>>>> # However...
>>>>> 
>>>>> 
>>>>> 
>>>>>> git svn dcommit
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> Committing to
>>>>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
>>>>> ...
>>>>> Merge conflict during commit: File or directory
>>>>> 'doc/users/whats_new.rst' is out of date; try updating: resource out of
>>>>> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
>>>>> # 1) I didn't change that file, why should I care
>>>>> # 2) I don't know who to update it
>>>>> 
>>>>> 
>>>>> 
>>>>>> git pull
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> Already up-to-date.
>>>>> 
>>>>> 
>>>>> 
>>>>>> git svn rebase
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> First, rewinding head to replay your work on top of it...
>>>>> Applying: more doc adds
>>>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
>>>>> whitespace.
>>>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace
>>>>> errors.
>>>>> Applying: added some docs for linestyles and markers
>>>>> Applying: Remove trailing whitespace.
>>>>> Applying: figure/subplot and font_manager bugfixes
>>>>> Applying: added support for xlwt in exceltools
>>>>> Applying: fixed a typo in whats_new_98_4_legend.py
>>>>> Applying: fixed typo in Line2D.set_marker doc.
>>>>> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
>>>>> Applying: more doc adds
>>>>> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
>>>>> whitespace.
>>>>> a lot of new features and bug-fixes. error: patch failed:
>>>>> doc/users/whats_new.rst:10
>>>>> error: doc/users/whats_new.rst: patch does not apply
>>>>> Using index info to reconstruct a base tree...
>>>>> <stdin>:14: trailing whitespace.
>>>>> a lot of new features and bug-fixes. warning: 1 line adds whitespace
>>>>> errors.
>>>>> Falling back to patching base and 3-way merge...
>>>>> No changes -- Patch already applied.
>>>>> Applying: added some docs for linestyles and markers
>>>>> error: patch failed: doc/devel/coding_guide.rst:62
>>>>> error: doc/devel/coding_guide.rst: patch does not apply
>>>>> error: patch failed: doc/matplotlibrc:43
>>>>> error: doc/matplotlibrc: patch does not apply
>>>>> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
>>>>> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
>>>>> error: patch failed: lib/matplotlib/lines.py:313
>>>>> error: lib/matplotlib/lines.py: patch does not apply
>>>>> Using index info to reconstruct a base tree...
>>>>> Falling back to patching base and 3-way merge...
>>>>> Auto-merged doc/pyplots/whats_new_98_4_legend.py
>>>>> CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py
>>>>> Auto-merged lib/matplotlib/lines.py
>>>>> Failed to merge in the changes.
>>>>> Patch failed at 0010.
>>>>>
>>>>> When you have resolved this problem run "git rebase --continue".
>>>>> If you would prefer to skip this patch, instead run "git rebase --skip".
>>>>> To restore the original branch and stop rebasing run "git rebase --abort".
>>>>>
>>>>> rebase refs/remotes/trunk: command returned error: 1
>>>>> # Ok, I'm back to merging files that don't conflict with my changes! # I
>>>>> shouldn't have to do that, right?
>>>>> # And FYI:
>>>>> 
>>>>> 
>>>>> 
>>>>>> git status
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> doc/pyplots/whats_new_98_4_legend.py: needs merge
>>>>> # Not currently on any branch.
>>>>> # Changes to be committed:
>>>>> # (use "git reset HEAD <file>..." to unstage)
>>>>> #
>>>>> # modified: lib/matplotlib/lines.py
>>>>> #
>>>>> # Changed but not updated:
>>>>> # (use "git add <file>..." to update what will be committed)
>>>>> #
>>>>> # unmerged: doc/pyplots/whats_new_98_4_legend.py
>>>>> #
>>>>> # Untracked files:
>>>>> # (use "git add <file>..." to include in what will be committed)
>>>>> #
>>>>> # lib/matplotlib/mpl-data/matplotlib.conf
>>>>> # lib/matplotlib/mpl-data/matplotlibrc
>>>>> # setupext.pyc
>>>>> # src/backend_agg.cpp~
>>>>>
>>>>> Now I feel stuck. How do I "undo" the merge from experimental to master?
>>>>>
>>>>> Sorry if these are obvious questions, but I think I've followed the
>>>>> git-svn instructions -- I must have made a mistake somewhere along the
>>>>> way, but I'm not sure how to debug and/or fix it.
>>>>>
>>>>> Mike
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> ------------------------------------------------------------------------------
>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
>>> The future of the web can't happen without you. Join us at MIX09 to help
>>> pave the way to the Next Web now. Learn more and register at
>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> 
>>> 
>> 
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> Manuel Metz wrote:
>> Hi,
>> I just noted a strange behavior of contour(). When a contour plot is
>> created with negative values and using a single color instead of a cmap,
>> contour _always_ uses the contour.negative_linestyle, even if linestyles
>> are specifically provided:
>>
>> x = linspace(-pi,pi,100)
>> X,Y = meshgrid(x,x)
>> Z = cos(X) + 0.5*cos(Y)
>>
>> contour(X,Y,Z, colors='k', linestyles='solid')
>>
>> I would expect the contour.negative_linestyle to be used when
>> linestyles=None, but not if it is explicitly specified. More serious,
>> even in the following case the effect takes place.
>>
>> contour_ls = ['solid']*9
>> contour(X,Y,Z,10, colors='k', linestyles=contour_ls)
>>
>>
>> Should we consider this as a bug and fix it ???
> 
> Fixed. Thank you. Oh, rats. I forgot again--I need to put this in the
> maintenance branch, and your immediately preceding change probably
> should go there, too, so I will take care of both now.
Thanks ...
> Eric

Manuel Metz wrote:
> Hi,
> I just noted a strange behavior of contour(). When a contour plot is
> created with negative values and using a single color instead of a cmap,
> contour _always_ uses the contour.negative_linestyle, even if linestyles
> are specifically provided:
> 
> x = linspace(-pi,pi,100)
> X,Y = meshgrid(x,x)
> Z = cos(X) + 0.5*cos(Y)
> 
> contour(X,Y,Z, colors='k', linestyles='solid')
> 
> I would expect the contour.negative_linestyle to be used when
> linestyles=None, but not if it is explicitly specified. More serious,
> even in the following case the effect takes place.
> 
> contour_ls = ['solid']*9
> contour(X,Y,Z,10, colors='k', linestyles=contour_ls)
> 
> 
> Should we consider this as a bug and fix it ???
Fixed. Thank you. Oh, rats. I forgot again--I need to put this in the 
maintenance branch, and your immediately preceding change probably 
should go there, too, so I will take care of both now.
Eric

Hi,
 I just noted a strange behavior of contour(). When a contour plot is
created with negative values and using a single color instead of a cmap,
contour _always_ uses the contour.negative_linestyle, even if linestyles
are specifically provided:
 x = linspace(-pi,pi,100)
 X,Y = meshgrid(x,x)
 Z = cos(X) + 0.5*cos(Y)
 contour(X,Y,Z, colors='k', linestyles='solid')
I would expect the contour.negative_linestyle to be used when
linestyles=None, but not if it is explicitly specified. More serious,
even in the following case the effect takes place.
 contour_ls = ['solid']*9
 contour(X,Y,Z,10, colors='k', linestyles=contour_ls)
Should we consider this as a bug and fix it ???
mm

On Tue, Jan 6, 2009 at 9:58 AM, Drain, Theodore R
<the...@jp...> wrote:
> OK - nose it is. How do you want to handle the dependency? My opinion is that since tests are development tools, it's not unreasonable to require that nose be installed by the developer and not as an embedded dependency in MPL (or at least that should be an option).
agreed
JDH

OK - nose it is. How do you want to handle the dependency? My opinion is that since tests are development tools, it's not unreasonable to require that nose be installed by the developer and not as an embedded dependency in MPL (or at least that should be an option).
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> Sent: Tuesday, January 06, 2009 7:03 AM
> To: Drain, Theodore R
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] John: Thoughts on a standard test
> system
>
> On Mon, Dec 22, 2008 at 11:45 AM, Drain, Theodore R
> <the...@jp...> wrote:
> > John,
> > Sometime in January, we are going to spend some time fixing a few
> minor MPL bugs we've hit and a probably work on a few enhancements
> (I'll send you a list in Jan before we start anything - it's nothing
> major). We're also going to work on writing a set of tests that try
> various plots w/ units. I was thinking this would be a good time to
> introduce a standard test harness into the MPL CM tree.
>
> Hey Ted -- Sorry I haven't gotten back to you yet. These proposals
> sound good. I have only very limited experience with unit testing and
> you have tons, so I don't have a lot to add to what you've already
> written, but I have a few inline comments below.
>
>
> > I think we should:
> >
> > 1) Select a standard test harness. The two big hitters seem to be
> unittest and nose. unittest has the advantage that it's shipped w/
> Python. nose seems to do better with automatic discovery of test
> cases.
>
> I prefer nose. I've used both a bit and find nose much more intuitive
> and easy to use. The fact that ipython, numpy, and scipy are all
> using nose makes the choice fairly compelling, especially if some of
> your image specific tests could be ported w/o too much headache.
>
>
> > 2) Establish a set of testing requirements. Naming conventions,
> usage conventions, etc. Things like tests should never print anything
> to the screen (i.e. correct behavior is encoded in the test case) or
> rely on a GUI unless that's what is being tested (allows tests to be
> run w/o an X-server). Basically write some documentation for the test
> system that includes how to use it and what's required of people when
> they add tests.
> >
> > 3) Write a test 'template' for people to use. This would define a
> test case and put TODO statements or something like it in place for
> people to fill in. More than one might be good for various classes of
> tests (maybe an image comparison template for testing agg drawing and a
> non-plot template for testing basic computations like transforms?).
> >
> > Some things we do on my project for our Python test systems:
> >
> > We put all unit tests in a 'test' directory inside the python package
> being tested. The disadvantage of this is that potentially large tests
> are inside the code to be delivered (though a nice delivery script can
> easily strip them out). The advantage of this is that it makes
> coverage checking easier. You can run the test case for a package and
> then check the coverage in the module w/o trying to figure out which
> things should be coverage checked or not. If you put the test cases in
> a different directory tree, then it's much harder to identify coverage
> sources. Though in our case we have 100's of python modules - in MPL's
> case, there is really just MPL, projections, backends, and numerix so
> maybe that's not too much of a problem.
> >
> > Automatic coverage isn't something that is must have, but it is
> really nice. I've found that it actually causes developers to write
> more tests because they can run the coverage and get a "score" that
> other people will see. It's also a good way to check a new submission
> to see if the developer has done basic testing of the code.
>
> All of the above sounds reasonable and I don't have strong opinions on
> any of it, so I will defer to those who write the initial framework
> and tests.
>
>
> > For our tests, we require that the test never print anything to the
> screen, clean up any of its output files (i.e. leave the directory in
> the same state it was before), and only report that the test passed or
> failed and if it failed, add some error message. The key thing is that
> the conditions for correctness are encoded into the test itself. We
> have a command line option that gets passed to the test cases to say
> "don't clean up" so that you can examine the output from a failing test
> case w/o modifying the test code. This option is really useful when an
> image comparison fails.
> > We've wrapped the basic python unittest package. It's pretty simple
> and reasonably powerful. I doubt there is anything MPL would be doing
> that it can't handle. The auto-discovery of nose is nice but
> unnecessary in my opinion. As long as people follow a standard way of
> doing things, auto-discovery is fairly easy. Of course if you prefer
> nose and don't mind the additional tool requirement, that's fine too.
> Some things that are probably needed:
> >
> > - command line executable that runs the tests.
> > - support flags for running only some tests
> > - support flags for running only tests that don't need a GUI
> backend
> > (require Agg?). This allows automated testing and visual
> testing to be
> > combined. GUI tests could be placed in identified
> directories and then
> > only run when requested since by their nature they require
> specific backends
> > and user interaction.
> > - nice report on test pass/fail status
> > - hooks to add coverage checking and reporting in the future
> > - test utilities
> > - image comparison tools
> > - ??? basically anything that helps w/ testing and could be
> common across
> > test cases
> >
> > As a first cut, I would suggest is something like this:
> >
> > .../test/run.py
> > mplTest/
> > test_unit/
> > test_transform/
> > test_...
> >
> > The run script would execute all/some of the tests. Any common test
> code would be put in the mplTest directory. Any directory named
> 'test_XXX' is for test cases where 'XXX' is some category name that can
> be used in the run script to run a subset of cases. Inside each
> test_XXX directory, one unittest class per file. The run script would
> find the .py files in the test_XXX directories, import them, find all
> the unittest classes, and run them. The run script also sets up
> sys.path so that the mplTest package is available.
> >
> > Links:
> > http://docs.python.org/library/unittest.html
> > http://somethingaboutorange.com/mrl/projects/nose/
> > http://kbyanc.blogspot.com/2007/06/pythons-unittest-module-aint-that-
> bad.html
> >
> > coverage checking:
> > http://nedbatchelder.com/code/modules/coverage.html
> > http://darcs.idyll.org/~t/projects/figleaf/doc/
> >
> > Thoughts?
> > Ted
> > ps: looking at the current unit directory, it looks like at least one
> test (nose_tests) is using nose even though it's not supplied w/ MPL.
> Most of the tests do something and show a plot but the correct behavior
> is never written into the test.
>
>
> My fault -- I wrote some tests to make sure all the different kwargs
> variants were processed properly, but since we did not have a
> "correctness of output" framework in place, punted on that part. I
> think having coverage of the myriad ways of setting properties is of
> some value.
>
> On the issue of units (not unit testing but unit support which is
> motivating your writing of unit test) I think we may need a new
> approach. The current approach is to put unitized data into the
> artists, and update the converted data at the artist layer. I don't
> know that this is the proper design. For this approach to work, every
> scalar and array quantity must support units at the artist layer, and
> all the calculations that are done at the plotting layer (eg error
> bar) to setup these artists must be careful to preserve unitized data
> throughout. So it is burdensome on the artist layer and on the
> plotting function layer.
>
> The problem is compounded because most of the other developers are not
> really aware of how to use the units interface, which I take
> responsibility for because they have oft asked for a design document,
> which I have yet to provide because I am unhappy with the design. So
> new code tends to break functions that once had unit support. Which
> is why we need unit tests ....
>
> I think everything might be easier if mpl had an intermediate class
> layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we
> already do for Legend. The plotting functions would instantiate these
> objects with the input arguments and track unit data through the
> reference to the axis. These plot objects would contain all the
> artist primitives which would store their data in native floating
> point, which would remove the burden on the artists from handling
> units and put it all in the plot creation/update logic. The objects
> would store references to all of the original inputs, and would update
> the primitive artists on unit changes. The basic problem is that the
> unitized data must live somewhere, and I am not sure that the low
> level primitive artists are the best place for that -- it may be a
> better idea to keep this data at the level of a PlotItem and let the
> primitive artists handle already converted floating point data. This
> is analogous to the current approach of passing transformed data to
> the backends to make it easier to write new backends. I need to chew
> on this some more.
>
>
> But this question aside, by all means fire away on creating the unit
> tests.
>
> JDH

On Tue, Jan 6, 2009 at 10:02 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Dec 22, 2008 at 11:45 AM, Drain, Theodore R
> <the...@jp...> wrote:
> > John,
> > Sometime in January, we are going to spend some time fixing a few minor
> MPL bugs we've hit and a probably work on a few enhancements (I'll send you
> a list in Jan before we start anything - it's nothing major). We're also
> going to work on writing a set of tests that try various plots w/ units. I
> was thinking this would be a good time to introduce a standard test harness
> into the MPL CM tree.
>
> Hey Ted -- Sorry I haven't gotten back to you yet. These proposals
> sound good. I have only very limited experience with unit testing and
> you have tons, so I don't have a lot to add to what you've already
> written, but I have a few inline comments below.
>
>
> > I think we should:
> >
> > 1) Select a standard test harness. The two big hitters seem to be
> unittest and nose. unittest has the advantage that it's shipped w/ Python.
> nose seems to do better with automatic discovery of test cases.
>
> I prefer nose. I've used both a bit and find nose much more intuitive
> and easy to use. The fact that ipython, numpy, and scipy are all
> using nose makes the choice fairly compelling, especially if some of
> your image specific tests could be ported w/o too much headache.
>
I also prefer to use nose. nose can still be used to discover tests written
with unittest.
>
> > 2) Establish a set of testing requirements. Naming conventions, usage
> conventions, etc. Things like tests should never print anything to the
> screen (i.e. correct behavior is encoded in the test case) or rely on a GUI
> unless that's what is being tested (allows tests to be run w/o an X-server).
> Basically write some documentation for the test system that includes how to
> use it and what's required of people when they add tests.
> >
> > 3) Write a test 'template' for people to use. This would define a test
> case and put TODO statements or something like it in place for people to
> fill in. More than one might be good for various classes of tests (maybe an
> image comparison template for testing agg drawing and a non-plot template
> for testing basic computations like transforms?).
> >
> > Some things we do on my project for our Python test systems:
> >
> > We put all unit tests in a 'test' directory inside the python package
> being tested. The disadvantage of this is that potentially large tests are
> inside the code to be delivered (though a nice delivery script can easily
> strip them out). The advantage of this is that it makes coverage checking
> easier. You can run the test case for a package and then check the coverage
> in the module w/o trying to figure out which things should be coverage
> checked or not. If you put the test cases in a different directory tree,
> then it's much harder to identify coverage sources. Though in our case we
> have 100's of python modules - in MPL's case, there is really just MPL,
> projections, backends, and numerix so maybe that's not too much of a
> problem.
> >
> > Automatic coverage isn't something that is must have, but it is really
> nice. I've found that it actually causes developers to write more tests
> because they can run the coverage and get a "score" that other people will
> see. It's also a good way to check a new submission to see if the developer
> has done basic testing of the code.
>
> All of the above sounds reasonable and I don't have strong opinions on
> any of it, so I will defer to those who write the initial framework
> and tests.
>
>
> > For our tests, we require that the test never print anything to the
> screen, clean up any of its output files (i.e. leave the directory in the
> same state it was before), and only report that the test passed or failed
> and if it failed, add some error message. The key thing is that the
> conditions for correctness are encoded into the test itself. We have a
> command line option that gets passed to the test cases to say "don't clean
> up" so that you can examine the output from a failing test case w/o
> modifying the test code. This option is really useful when an image
> comparison fails.
> > We've wrapped the basic python unittest package. It's pretty simple and
> reasonably powerful. I doubt there is anything MPL would be doing that it
> can't handle. The auto-discovery of nose is nice but unnecessary in my
> opinion. As long as people follow a standard way of doing things,
> auto-discovery is fairly easy. Of course if you prefer nose and don't mind
> the additional tool requirement, that's fine too. Some things that are
> probably needed:
> >
> > - command line executable that runs the tests.
> > - support flags for running only some tests
> > - support flags for running only tests that don't need a GUI
> backend
> > (require Agg?). This allows automated testing and visual
> testing to be
> > combined. GUI tests could be placed in identified directories
> and then
> > only run when requested since by their nature they require
> specific backends
> > and user interaction.
> > - nice report on test pass/fail status
> > - hooks to add coverage checking and reporting in the future
> > - test utilities
> > - image comparison tools
> > - ??? basically anything that helps w/ testing and could be common
> across
> > test cases
> >
> > As a first cut, I would suggest is something like this:
> >
> > .../test/run.py
> > mplTest/
> > test_unit/
> > test_transform/
> > test_...
> >
> > The run script would execute all/some of the tests. Any common test code
> would be put in the mplTest directory. Any directory named 'test_XXX' is
> for test cases where 'XXX' is some category name that can be used in the run
> script to run a subset of cases. Inside each test_XXX directory, one
> unittest class per file. The run script would find the .py files in the
> test_XXX directories, import them, find all the unittest classes, and run
> them. The run script also sets up sys.path so that the mplTest package is
> available.
> >
> > Links:
> > http://docs.python.org/library/unittest.html
> > http://somethingaboutorange.com/mrl/projects/nose/
> >
> http://kbyanc.blogspot.com/2007/06/pythons-unittest-module-aint-that-bad.html
> >
> > coverage checking:
> > http://nedbatchelder.com/code/modules/coverage.html
> > http://darcs.idyll.org/~t/projects/figleaf/doc/<http://darcs.idyll.org/%7Et/projects/figleaf/doc/>
> >
> > Thoughts?
> > Ted
> > ps: looking at the current unit directory, it looks like at least one
> test (nose_tests) is using nose even though it's not supplied w/ MPL. Most
> of the tests do something and show a plot but the correct behavior is never
> written into the test.
>
>
> My fault -- I wrote some tests to make sure all the different kwargs
> variants were processed properly, but since we did not have a
> "correctness of output" framework in place, punted on that part. I
> think having coverage of the myriad ways of setting properties is of
> some value.
>
> On the issue of units (not unit testing but unit support which is
> motivating your writing of unit test) I think we may need a new
> approach. The current approach is to put unitized data into the
> artists, and update the converted data at the artist layer. I don't
> know that this is the proper design. For this approach to work, every
> scalar and array quantity must support units at the artist layer, and
> all the calculations that are done at the plotting layer (eg error
> bar) to setup these artists must be careful to preserve unitized data
> throughout. So it is burdensome on the artist layer and on the
> plotting function layer.
>
> The problem is compounded because most of the other developers are not
> really aware of how to use the units interface, which I take
> responsibility for because they have oft asked for a design document,
> which I have yet to provide because I am unhappy with the design. So
> new code tends to break functions that once had unit support. Which
> is why we need unit tests ....
>
I'm not ready to make a proper announcement yet, but I spent most of my free
time over the break continuing development on my Quantities package, which
supports units and unit transformations, and some new support for error
propagation that I just put together yesterday. There is some information at
packages.python.org/quantities , if anyone is interested. Probably the best
place to start is the tutorial in the documentation. I'm planning on
requesting comments and feedback from scipy-dev or numpy-discussion after a
little more development and optimization. The basic interface and
functionality are in place, though. If you guys have a chance to try out the
package and provide some early feedback, I would really appreciate it.
>
> I think everything might be easier if mpl had an intermediate class
> layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we
> already do for Legend. The plotting functions would instantiate these
> objects with the input arguments and track unit data through the
> reference to the axis. These plot objects would contain all the
> artist primitives which would store their data in native floating
> point, which would remove the burden on the artists from handling
> units and put it all in the plot creation/update logic. The objects
> would store references to all of the original inputs, and would update
> the primitive artists on unit changes. The basic problem is that the
> unitized data must live somewhere, and I am not sure that the low
> level primitive artists are the best place for that -- it may be a
> better idea to keep this data at the level of a PlotItem and let the
> primitive artists handle already converted floating point data. This
> is analogous to the current approach of passing transformed data to
> the backends to make it easier to write new backends. I need to chew
> on this some more.
>
>
> But this question aside, by all means fire away on creating the unit tests.
>
> JDH
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Mon, Dec 22, 2008 at 11:45 AM, Drain, Theodore R
<the...@jp...> wrote:
> John,
> Sometime in January, we are going to spend some time fixing a few minor MPL bugs we've hit and a probably work on a few enhancements (I'll send you a list in Jan before we start anything - it's nothing major). We're also going to work on writing a set of tests that try various plots w/ units. I was thinking this would be a good time to introduce a standard test harness into the MPL CM tree.
Hey Ted -- Sorry I haven't gotten back to you yet. These proposals
sound good. I have only very limited experience with unit testing and
you have tons, so I don't have a lot to add to what you've already
written, but I have a few inline comments below.
> I think we should:
>
> 1) Select a standard test harness. The two big hitters seem to be unittest and nose. unittest has the advantage that it's shipped w/ Python. nose seems to do better with automatic discovery of test cases.
I prefer nose. I've used both a bit and find nose much more intuitive
and easy to use. The fact that ipython, numpy, and scipy are all
using nose makes the choice fairly compelling, especially if some of
your image specific tests could be ported w/o too much headache.
> 2) Establish a set of testing requirements. Naming conventions, usage conventions, etc. Things like tests should never print anything to the screen (i.e. correct behavior is encoded in the test case) or rely on a GUI unless that's what is being tested (allows tests to be run w/o an X-server). Basically write some documentation for the test system that includes how to use it and what's required of people when they add tests.
>
> 3) Write a test 'template' for people to use. This would define a test case and put TODO statements or something like it in place for people to fill in. More than one might be good for various classes of tests (maybe an image comparison template for testing agg drawing and a non-plot template for testing basic computations like transforms?).
>
> Some things we do on my project for our Python test systems:
>
> We put all unit tests in a 'test' directory inside the python package being tested. The disadvantage of this is that potentially large tests are inside the code to be delivered (though a nice delivery script can easily strip them out). The advantage of this is that it makes coverage checking easier. You can run the test case for a package and then check the coverage in the module w/o trying to figure out which things should be coverage checked or not. If you put the test cases in a different directory tree, then it's much harder to identify coverage sources. Though in our case we have 100's of python modules - in MPL's case, there is really just MPL, projections, backends, and numerix so maybe that's not too much of a problem.
>
> Automatic coverage isn't something that is must have, but it is really nice. I've found that it actually causes developers to write more tests because they can run the coverage and get a "score" that other people will see. It's also a good way to check a new submission to see if the developer has done basic testing of the code.
All of the above sounds reasonable and I don't have strong opinions on
any of it, so I will defer to those who write the initial framework
and tests.
> For our tests, we require that the test never print anything to the screen, clean up any of its output files (i.e. leave the directory in the same state it was before), and only report that the test passed or failed and if it failed, add some error message. The key thing is that the conditions for correctness are encoded into the test itself. We have a command line option that gets passed to the test cases to say "don't clean up" so that you can examine the output from a failing test case w/o modifying the test code. This option is really useful when an image comparison fails.
> We've wrapped the basic python unittest package. It's pretty simple and reasonably powerful. I doubt there is anything MPL would be doing that it can't handle. The auto-discovery of nose is nice but unnecessary in my opinion. As long as people follow a standard way of doing things, auto-discovery is fairly easy. Of course if you prefer nose and don't mind the additional tool requirement, that's fine too. Some things that are probably needed:
>
> - command line executable that runs the tests.
> - support flags for running only some tests
> - support flags for running only tests that don't need a GUI backend
> (require Agg?). This allows automated testing and visual testing to be
> combined. GUI tests could be placed in identified directories and then
> only run when requested since by their nature they require specific backends
> and user interaction.
> - nice report on test pass/fail status
> - hooks to add coverage checking and reporting in the future
> - test utilities
> - image comparison tools
> - ??? basically anything that helps w/ testing and could be common across
> test cases
>
> As a first cut, I would suggest is something like this:
>
> .../test/run.py
> mplTest/
> test_unit/
> test_transform/
> test_...
>
> The run script would execute all/some of the tests. Any common test code would be put in the mplTest directory. Any directory named 'test_XXX' is for test cases where 'XXX' is some category name that can be used in the run script to run a subset of cases. Inside each test_XXX directory, one unittest class per file. The run script would find the .py files in the test_XXX directories, import them, find all the unittest classes, and run them. The run script also sets up sys.path so that the mplTest package is available.
>
> Links:
> http://docs.python.org/library/unittest.html
> http://somethingaboutorange.com/mrl/projects/nose/
> http://kbyanc.blogspot.com/2007/06/pythons-unittest-module-aint-that-bad.html
>
> coverage checking:
> http://nedbatchelder.com/code/modules/coverage.html
> http://darcs.idyll.org/~t/projects/figleaf/doc/
>
> Thoughts?
> Ted
> ps: looking at the current unit directory, it looks like at least one test (nose_tests) is using nose even though it's not supplied w/ MPL. Most of the tests do something and show a plot but the correct behavior is never written into the test.
My fault -- I wrote some tests to make sure all the different kwargs
variants were processed properly, but since we did not have a
"correctness of output" framework in place, punted on that part. I
think having coverage of the myriad ways of setting properties is of
some value.
On the issue of units (not unit testing but unit support which is
motivating your writing of unit test) I think we may need a new
approach. The current approach is to put unitized data into the
artists, and update the converted data at the artist layer. I don't
know that this is the proper design. For this approach to work, every
scalar and array quantity must support units at the artist layer, and
all the calculations that are done at the plotting layer (eg error
bar) to setup these artists must be careful to preserve unitized data
throughout. So it is burdensome on the artist layer and on the
plotting function layer.
The problem is compounded because most of the other developers are not
really aware of how to use the units interface, which I take
responsibility for because they have oft asked for a design document,
which I have yet to provide because I am unhappy with the design. So
new code tends to break functions that once had unit support. Which
is why we need unit tests ....
I think everything might be easier if mpl had an intermediate class
layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we
already do for Legend. The plotting functions would instantiate these
objects with the input arguments and track unit data through the
reference to the axis. These plot objects would contain all the
artist primitives which would store their data in native floating
point, which would remove the burden on the artists from handling
units and put it all in the plot creation/update logic. The objects
would store references to all of the original inputs, and would update
the primitive artists on unit changes. The basic problem is that the
unitized data must live somewhere, and I am not sure that the low
level primitive artists are the best place for that -- it may be a
better idea to keep this data at the level of a PlotItem and let the
primitive artists handle already converted floating point data. This
is analogous to the current approach of passing transformed data to
the backends to make it easier to write new backends. I need to chew
on this some more.
But this question aside, by all means fire away on creating the unit tests.
JDH

Jouni K. Seppänen <jk...@ik...> writes:
> Or perhaps the user-visible object doesn't need to be the same PdfFile
> that is used internally
I ended up doing this, calling the object PdfPages. I also gave it a
savefig method so you can do pdfpages.savefig(figure) in addition to
figure.savefig(pdfpages, format='pdf').
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hello Russell,
thanks for getting back to me
On Mon, Jan 5, 2009 at 20:29, Russell E. Owen <rowen@u.washington.edu> wrote:
> In article
> <8b2...@ma...>,
> "Sandro Tosi" <mo...@de...> wrote:
>> - what are you using matplotlib for?
>
> Plotting data from a networked Tkinter application.
May I ask you to expand a bit what "networked" is? something like:
read data from a remote server and plot on the client? Just to have an
idea :)
>> - what are the (basic) things that, when you were beginning to use
>> matplotlib, you wanted to see grouped up but couldn't find?
>> - what would you like to see in a book about matplotlib?
>
> I want a user's guide for the class API. So far I've figured it out by
> reading examples, trying to extrapolate from the pylab user's guide
> (which is quite good) and reading the class API reference, but I feel
> that I barely understand what I am doing.
The idea of the book is to start with simple plots, describing the
methods we call and how they work, to go into more details along the
book.
>> - what are the things you'd like to explore of matplotlib and never
>> had time to do?
>
> I'd like to know how best to handle plotting data as it arrives (e.g.
> strip charts and evolving x-y plots). I've got code that works but am
> not convinced I'm doing it in the best fashion.
I already thought about an examples of "plotting with data changing on
time" like plotting the cpu usage or so, so it might be useful to you
that too :)
> Histograms.
If there's something particular interesting for you, it would be
helpful to me to know it :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello Andrew,
thanks for taking the time to reply.
First of all, let me clarify that I received a proposal (and not the
opposite) so some decision were already made about the book format.
On Mon, Jan 5, 2009 at 20:00, Andrew Straw <str...@as...> wrote:
> Hi Sandro,
>
> It's great news that a book may come out on MPL.
>
> Speaking as an aspiring university professor in neuroscience, I would
> like to see something that could be used as a resource for undergraduate
> students just learning Python and MPL.
The cut of the book is for already experienced Python programmers. For
sure, in the "approaching" chapter to mpl, I won't go too much into
deep of python programming, and I suppose they'll be easy to read even
for new comers.
> Due to this perspective, I think
> such a book would cover both numpy and MPL. The emphasis could clearly
> by on MPL, but basic numpy idioms and concepts should also be taught.
Mh, the focus the editor would like to see is about introducing mpl +
integrating into apps. The examples I have in mind for the pratical
part of apps integration already cointains some sort of "introduction"
to gather data and plot them (but I can't go to much on the scientific
side :) ). I will propose a chapter like "Matplotlib for the science"
and here your suggestion on what you'd like to see there is welcome.
> I
> think an example-driven approach would be very useful -- something like
> an undergraduate laboratory experiment where students measure and plot
> raw values and compute histograms and statistics (e.g. mean and std).
> More advanced sections might perform statistical comparisons of
> different treatments (e.g. using chi squared, KS and/or T tests), do
> linear least squares fitting (with np.linalg.lstsq), and possibly
> non-linear curve fitting using something like scipy.optimize.fmin.
That could be a beginning of that chapter contents: more more more ideas :)
> That's my self-serving 0ドル.02, since you asked! :)
And they are very much welcome!!
> You may also want to speak with John Hunter and Fernando Perez about the
> possibility of collaborating -- they've already done some work towards a
> book, too.
I'm sure be happy to hear their voice on this product, but (given the
preamble) I don't know if the editor would be fine with co-authorship;
I'll ask, just to be sure.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello João,
thanks for replying
On Mon, Jan 5, 2009 at 13:40, João Luís Silva <js...@fc...> wrote:
> Sandro Tosi wrote:
>> - what are the (basic) things that, when you were beginning to use
>> matplotlib, you wanted to see grouped up but couldn't find?
>
> I don't know if you consider it basic or not, but I would have liked
> better documentation of the object oriented interface (matplotlib). The
could you be a little more specific on what you mean here?
>> - what would you like to see in a book about matplotlib?
>
> As above, at least a chapter about the object oriented interface showing
> how to embed matplotlib on a application, and outlining the structure of
> the OO interface.
Well, this is part of the purpose of the book: show how to embed mpl
in applications.
>> - what are some those advanced feature that made you yell "WOW!!" ?
>
> I haven't really used matplotlib's advanced features. There are some
> that I like, such as automatic legend placement and mathtext support.
mathtext and latex support will be in the advanced features section
> The number of supported backends is impressive just by itself, making
> matplotlib much more useful. There are some little things such as the
> search order for the matplotlibrc file that make it possible to specify
> different settings for a given directory.
There will be a part even on configuration (of course :) ).
>> - what are the things you'd like to explore of matplotlib and never
>> had time to do?
>
> I never had the time to try the masked arrays although I think they will
> be useful for me. I should also explore how to create custom color maps.
2 points added to the adv featues list (in part because something was
already there, in a different form).
>> Your suggestions are really appreciated :) And wish me good luck!
>
> I was going to! Good luck, I hope you manage to take this project to
> completion.
Eheh, thanks! I really hope I'll be able to handle even this task :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

In article 
<8b2...@ma...>,
 "Sandro Tosi" <mo...@de...> wrote:
> Hello and Happy 2009!
> 
> I received the interesting proposal to author a book on Matplotlib,
> the powerful 2D plotting library for Python.
> 
> While preparing the arguments list, I'd like to hear even your
> opinion, because different points-of-view will lead to a better
> product.
> 
> Some basic question I'd like to ask are:
> 
> - what are you using matplotlib for?
Plotting data from a networked Tkinter application.
> - what are the (basic) things that, when you were beginning to use
> matplotlib, you wanted to see grouped up but couldn't find?
> - what would you like to see in a book about matplotlib?
I want a user's guide for the class API. So far I've figured it out by 
reading examples, trying to extrapolate from the pylab user's guide 
(which is quite good) and reading the class API reference, but I feel 
that I barely understand what I am doing.
> - what are the things you'd like to explore of matplotlib and never
> had time to do?
I'd like to know how best to handle plotting data as it arrives (e.g. 
strip charts and evolving x-y plots). I've got code that works but am 
not convinced I'm doing it in the best fashion.
Histograms.
-- Russell

On Mon, Jan 5, 2009 at 9:06 AM, Michael Droettboom <md...@st...> wrote:
> Also, it seems like the text alignment in the PS output is too low by a
> small constant factor.
I'm not quite sure why this is happening. My guess is that it has
something to with the usage of psfrag in the ps backend, e.g., the
different descent values between the original text and the substituted
text. I personally think it is better (for the ps backend) to use the
dviread module (as in the pdf backend) instead of using the psfrag.
Regards,
-JJ

Hi Sandro,
It's great news that a book may come out on MPL.
Speaking as an aspiring university professor in neuroscience, I would
like to see something that could be used as a resource for undergraduate
students just learning Python and MPL. Due to this perspective, I think
such a book would cover both numpy and MPL. The emphasis could clearly
by on MPL, but basic numpy idioms and concepts should also be taught. I
think an example-driven approach would be very useful -- something like
an undergraduate laboratory experiment where students measure and plot
raw values and compute histograms and statistics (e.g. mean and std).
More advanced sections might perform statistical comparisons of
different treatments (e.g. using chi squared, KS and/or T tests), do
linear least squares fitting (with np.linalg.lstsq), and possibly
non-linear curve fitting using something like scipy.optimize.fmin.
That's my self-serving 0ドル.02, since you asked! :)
You may also want to speak with John Hunter and Fernando Perez about the
possibility of collaborating -- they've already done some work towards a
book, too.
Andrew
Sandro Tosi wrote:
> Hello and Happy 2009!
> 
> I received the interesting proposal to author a book on Matplotlib,
> the powerful 2D plotting library for Python.
> 
> While preparing the arguments list, I'd like to hear even your
> opinion, because different points-of-view will lead to a better
> product.
> 
> Some basic question I'd like to ask are:
> 
> - what are you using matplotlib for?
> - what are the things you like the most of matplotlib, that you want
> to give emphasis to? And why?
> - what are the (basic) things that, when you were beginning to use
> matplotlib, you wanted to see grouped up but couldn't find?
> - what would you like to see in a book about matplotlib?
> - what are some those advanced feature that made you yell "WOW!!" ?
> - what are the things you'd like to explore of matplotlib and never
> had time to do?
> 
> Your suggestions are really appreciated :) And wish me good luck!
> 
> Cheers,

Thanks for the explanation. The TeX install I have is the stock one 
with RHEL4, which is fairly old at this point. I've had a number of 
other problems with it as well (such as it not being compatible with 
Sphinx). 
It's nice to know that matplotlib is at least handling this situation 
without crashing. I think this solution (to warn) is adequate, 
especially given that most newer TeX distributions shouldn't have this 
issue.
Mike
Jouni K. Seppänen wrote:
> Michael Droettboom <md...@st...> writes:
>
> 
>> The output of "python usetex_texteffects.py --verbose-debug" is attached.
>> 
>
> Thanks! The problem seems to be that your TeX configuration (pdftex.map)
> specifies using Helvetica without embedding it into the pdf file. This
> is deprecated in the PDF standard (PDF viewer applications have
> different replacements for the core 14 fonts, and many publishers insist
> that you embed all fonts you use) but I added support for it in 6737,
> with a warning displayed to the user.
>
> Could you see if it works for you now?
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom <md...@st...> writes:
> The output of "python usetex_texteffects.py --verbose-debug" is attached.
Thanks! The problem seems to be that your TeX configuration (pdftex.map)
specifies using Helvetica without embedding it into the pdf file. This
is deprecated in the PDF standard (PDF viewer applications have
different replacements for the core 14 fonts, and many publishers insist
that you embed all fonts you use) but I added support for it in 6737,
with a warning displayed to the user.
Could you see if it works for you now?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Jouni: your latest commit resolves the issue for me. Thanks!
Jae-Joon: Your preview.sty work seems to work great with the PDF backend 
(for me, at least).
Cheers,
Mike
Michael Droettboom wrote:
>
> Jouni K. Seppänen wrote:
>> Michael Droettboom <md...@st...> writes:
>>
>> 
>>> when running usetex_fonteffects.py [...]
>>> TypeError: coercing to Unicode: need string or buffer, NoneType found
>>> -> file = open(input, 'rb')
>>> 
>>
>> Perhaps your TeX installation doesn't have the font. If you run
>> "kpsewhich utmr8a.pfb", what do you get? If it does return something,
>> could you run the example with --verbose-debug?
>>
>> 
> > kpsewhich utmr8a.pfb
> /usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb
>
>
> The output of "python usetex_texteffects.py --verbose-debug" is attached.
>
> Mike
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jouni K. Seppänen wrote:
> Michael Droettboom <md...@st...> writes:
>
> 
>> when running usetex_fonteffects.py [...]
>> TypeError: coercing to Unicode: need string or buffer, NoneType found
>> -> file = open(input, 'rb')
>> 
>
> Perhaps your TeX installation doesn't have the font. If you run
> "kpsewhich utmr8a.pfb", what do you get? If it does return something,
> could you run the example with --verbose-debug?
>
> 
 > kpsewhich utmr8a.pfb
/usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb
The output of "python usetex_texteffects.py --verbose-debug" is attached.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom <md...@st...> writes:
> when running usetex_fonteffects.py [...]
> TypeError: coercing to Unicode: need string or buffer, NoneType found
> -> file = open(input, 'rb')
Perhaps your TeX installation doesn't have the font. If you run
"kpsewhich utmr8a.pfb", what do you get? If it does return something,
could you run the example with --verbose-debug?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Sorry about the wild good chase. I had fixed up an earlier exception 
which was simply a problem with formatting a verbose message. That 
gives this, when running usetex_fonteffects.py (with all rcParams at 
defaults):
Traceback (most recent call last):
 File "usetex_fonteffects.py", line 22, in <module>
 pylab.savefig('usetex_fonteffects.pdf')
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
 **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
 return pdf.print_pdf(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 1911, in print_pdf
 file.close()
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 440, in close
 self.writeFonts()
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 521, in writeFonts
 fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 550, in embedType1
 ' and effects ' + `fontinfo.effects`,
TypeError: cannot concatenate 'str' and 'NoneType' objects
 > 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py(550)embedType1()
-> ' and effects ' + `fontinfo.effects`,*
*
Do an SVN update (r6736) and try again. Then I get this:
 > python usetex_fonteffects.py
Traceback (most recent call last):
 File "usetex_fonteffects.py", line 22, in <module>
 pylab.savefig('usetex_fonteffects.pdf')
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
 **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
 return pdf.print_pdf(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 1911, in print_pdf
 file.close()
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 440, in close
 self.writeFonts()
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 521, in writeFonts
 fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 553, in embedType1
 t1font = type1font.Type1Font(fontinfo.fontfile)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py", 
line 55, in __init__
 file = open(input, 'rb')
TypeError: coercing to Unicode: need string or buffer, NoneType found
 > 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py(55)__init__()
-> file = open(input, 'rb')
So somehow, input is None, but I haven't had a chance to look any further.
Cheers,
Mike
Jouni K. Seppänen wrote:
> Michael Droettboom <md...@st...> writes:
>
> 
>> I'm currently getting this traceback with the PDF backend, whether 
>> "text.latex.preview" is True or False -- so it may be unrelated to your 
>> change, but I'm unable to test PDF at the moment.
>> 
>
> Based on the traceback, it looks like I have broken something recently --
> but what is the exact exception? I can't replicate the traceback myself.
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom <md...@st...> writes:
> I'm currently getting this traceback with the PDF backend, whether 
> "text.latex.preview" is True or False -- so it may be unrelated to your 
> change, but I'm unable to test PDF at the moment.
Based on the traceback, it looks like I have broken something recently --
but what is the exact exception? I can't replicate the traceback myself.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Very nice!
I'm currently getting this traceback with the PDF backend, whether 
"text.latex.preview" is True or False -- so it may be unrelated to your 
change, but I'm unable to test PDF at the moment.
Traceback (most recent call last):
 File "usetex_baseline_test.py", line 75, in <module>
 plt.savefig("test.pdf")
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
 **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
 return pdf.print_pdf(*args, **kwargs)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 1911, in print_pdf
 file.close()
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 440, in close
 self.writeFonts()
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 521, in writeFonts
 fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py", 
line 553, in embedType1
 t1font = type1font.Type1Font(fontinfo.fontfile)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py", 
line 55, in __init__
 file = open(input, 'rb')
Also, it seems like the text alignment in the PS output is too low by a 
small constant factor.
Assuming those issues can be resolved, is there now any reason to use 
dviread, assuming preview.sty is installed? If the preview.sty approach 
is superior, I wonder if we could:
a) Determine if preview.sty is installed, and if so, use it, otherwise 
fallback to dviread? (Then we could be a default "auto" setting for the 
rcParam).
b) Or better, include preview.sty with matplotlib and use it instead of 
a system installed copy, so that it's always available. (This is both a 
licensing and version-compatibility question, really...)
It would be great to make this new behavior with the proper baseline 
more automatic.
Cheers,
Mike
Jae-Joon Lee wrote:
> Hello,
>
> I committed a patch to optionally use preview.sty with usetex=True.
> This is to support a baseline alignment.
>
> A summary of changes:
>
> * added a get_text_width_height_descent() method in the TexManager
> class, and modified the agg, ps and pdf backends to utilize this
> method.
>
> * added a new rc parameter, 'text.latex.preview'. If True,
> preview.sty is used to generate dvi files and baseline information of
> each dvi file is stored in a separate file.
> TexManager.get_text_width_height_descent() method uses this
> information.
>
> * If text.latex.preview==False,
> TexManager.get_text_width_height_descent() method uses dviread module
> (this is what the pdf backend has been using), but the returned
> descent value of the text is sometimes incorrect.
>
> * added an example ("usetex_baseline_test.py" ). The output is
> attached with this email.
>
> If you have a preview.sty installed, please test this (set
> "text.latex.preview=True" in you rc file) and report any problems.
> Regards,
>
> -JJ
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA