matplotlib-devel Mailing List for matplotlib (Page 6)

On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom <md...@st...> wrote:

> Darren Dale wrote:
>
>  On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom <md...@st...<mailto:
>> md...@st...>> wrote:
>>
>>    Manuel Metz wrote:
>>    > Michael Droettboom wrote:
>>    >
>>    >> There was a discussion on this list around a year ago about
>>    this.  The
>>    >> concern was that not rendering $ as $ would break (matplotlib)
>>    backward
>>    >> compatibility with scripts that don't care about math at all
>>    but use a
>>    >> lot of dollar signs (e.g. financial plots).  This is one of the few
>>    >> places where we deliberately broke usetex compatibility in
>>    favour of
>>    >> matplotlib compatibility.
>>    >>
>>    >> That said, it's probably a bug that the escaped dollar sign in
>>    non-math
>>    >> context is not rendered as a dollar sign.
>>    >>
>>    >> As a workaround "$\$%1.2f$" works with usetex on or off, with the
>>    >> proviso that it uses math- rather than text-rendering for the
>>    numbers.
>>    >>
>>    >> Mike
>>    >>
>>    >
>>    > In that case I suggest to note this somewhere in the docs (and User
>>    > Guide) with three exclamation marks (or is it ???).
>>    >
>>    So there's really two sub-bugs here:
>>
>>    1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim
>>    to the non-math text renderer, which is a bug).  This, IMHO, is a
>>    "must-fix".
>>
>>    2) '$8' gives '$8' in mathtext and an error in usetex.  This could be
>>    solved in two ways:
>>
>>    a) document the difference
>>    b) make '$8' give '$8' in usetex as well
>>
>>    I realise b) is technically making usetex accept a string that is not
>>    normally valid TeX -- but it's not like a user would ever enter
>>    '$8' and
>>    *want* to get a TeX error back.  And usetex strings aren't
>>    perfectly TeX
>>    anyway.
>>
>>    Personally, I'm leaning toward b), because it requires less mental
>>    effort for the user turning usetex on/off.  And it doesn't force us to
>>    backtrack on the idea of supporting "$100.00" easily.
>>
>>    But before I commit -- any feedback?
>>
>>  I opposed to b). If we go that route, we can look forward to advertising
>> usetex as "a latex backend, with familiar, standard latex markup, except
>> when it isnt."
>>
> It's not as bad as that.  '\$8' will still work as in LaTeX as it always
> has and as a LaTeX expert would expect it to.  All I'm proposing is that
> '$8', which is currently a LaTeX syntax error, will behave as it does when
> usetex is turned off.  So it's not breaking anything that's already valid.
>
> It's a question of which pain is worse, I guess.
>
> The deeper question is -- should usetex even strive to have any
> compatibility with standard text?  If not, then I can see your point.
>

http://matplotlib.sourceforge.net/users/mathtext.html advertises \$ as
markup for $. I think it was unwise to accept $ for $ in mathtext in the
first place, since mathtext uses tex markup anyway.

If we went with b), how sure are you that you can identify when a dollar
sign is intended and when mathmode is intended? Does "$A-$100+B*$200$" mean
$(A-100+200B) or A-100+200 or ..., I know this is an unlikely example, I'm
just trying to think of the unintended consequences of circumventing one of
the least buggy pieces of software in existence (I mean tex, not latex).

Darren Dale wrote:
> On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     Manuel Metz wrote:
>     > Michael Droettboom wrote:
>     >
>     >> There was a discussion on this list around a year ago about
>     this.  The
>     >> concern was that not rendering $ as $ would break (matplotlib)
>     backward
>     >> compatibility with scripts that don't care about math at all
>     but use a
>     >> lot of dollar signs (e.g. financial plots).  This is one of the few
>     >> places where we deliberately broke usetex compatibility in
>     favour of
>     >> matplotlib compatibility.
>     >>
>     >> That said, it's probably a bug that the escaped dollar sign in
>     non-math
>     >> context is not rendered as a dollar sign.
>     >>
>     >> As a workaround "$\$%1.2f$" works with usetex on or off, with the
>     >> proviso that it uses math- rather than text-rendering for the
>     numbers.
>     >>
>     >> Mike
>     >>
>     >
>     > In that case I suggest to note this somewhere in the docs (and User
>     > Guide) with three exclamation marks (or is it ???).
>     >
>     So there's really two sub-bugs here:
>
>     1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim
>     to the non-math text renderer, which is a bug).  This, IMHO, is a
>     "must-fix".
>
>     2) '$8' gives '$8' in mathtext and an error in usetex.  This could be
>     solved in two ways:
>
>     a) document the difference
>     b) make '$8' give '$8' in usetex as well
>
>     I realise b) is technically making usetex accept a string that is not
>     normally valid TeX -- but it's not like a user would ever enter
>     '$8' and
>     *want* to get a TeX error back.  And usetex strings aren't
>     perfectly TeX
>     anyway.
>
>     Personally, I'm leaning toward b), because it requires less mental
>     effort for the user turning usetex on/off.  And it doesn't force us to
>     backtrack on the idea of supporting "$100.00" easily.
>
>     But before I commit -- any feedback?
>
>  
> I opposed to b). If we go that route, we can look forward to 
> advertising usetex as "a latex backend, with familiar, standard latex 
> markup, except when it isnt."
It's not as bad as that.  '\$8' will still work as in LaTeX as it always 
has and as a LaTeX expert would expect it to.  All I'm proposing is that 
'$8', which is currently a LaTeX syntax error, will behave as it does 
when usetex is turned off.  So it's not breaking anything that's already 
valid.

It's a question of which pain is worse, I guess.

The deeper question is -- should usetex even strive to have any 
compatibility with standard text?  If not, then I can see your point.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I found that in scatter plots the alpha values given by individual 
entries in the color list are ignored. Here an example that shows 
different combinations of color and alpha arguments:

x = [1,2,3]
y = array([1,1,1])

c = [[1,0,0, 0.0],
     [1,0,0, 0.5],
     [1,0,0, 1.0]]

scatter(x, y, s = 200, c = 'r')
scatter(x, y + 1, s = 200, c = c)
scatter(x, y + 2, s = 200, c = c, alpha = 0.5)
scatter(x, y + 3, s = 200, c = 'g', alpha = 0.5)

Looking at the source in axes.py/scatter I found that replacing the 
default value for the alpha keyword argument in the function header of 
scatter from alpha=1.0 to alpha=None fixes this problem. Additionally, I 
had to replace

collection.set_alpha(alpha)

by

if alpha is not None:
    collection.set_alpha(alpha)

See also the attached diff file.
 
Gregor

On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom <md...@st...> wrote:

> Manuel Metz wrote:
> > Michael Droettboom wrote:
> >
> >> There was a discussion on this list around a year ago about this.  The
> >> concern was that not rendering $ as $ would break (matplotlib) backward
> >> compatibility with scripts that don't care about math at all but use a
> >> lot of dollar signs (e.g. financial plots).  This is one of the few
> >> places where we deliberately broke usetex compatibility in favour of
> >> matplotlib compatibility.
> >>
> >> That said, it's probably a bug that the escaped dollar sign in non-math
> >> context is not rendered as a dollar sign.
> >>
> >> As a workaround "$\$%1.2f$" works with usetex on or off, with the
> >> proviso that it uses math- rather than text-rendering for the numbers.
> >>
> >> Mike
> >>
> >
> > In that case I suggest to note this somewhere in the docs (and User
> > Guide) with three exclamation marks (or is it ???).
> >
> So there's really two sub-bugs here:
>
> 1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim
> to the non-math text renderer, which is a bug).  This, IMHO, is a
> "must-fix".
>
> 2) '$8' gives '$8' in mathtext and an error in usetex.  This could be
> solved in two ways:
>
> a) document the difference
> b) make '$8' give '$8' in usetex as well
>
> I realise b) is technically making usetex accept a string that is not
> normally valid TeX -- but it's not like a user would ever enter '$8' and
> *want* to get a TeX error back.  And usetex strings aren't perfectly TeX
> anyway.
>
> Personally, I'm leaning toward b), because it requires less mental
> effort for the user turning usetex on/off.  And it doesn't force us to
> backtrack on the idea of supporting "$100.00" easily.
>
> But before I commit -- any feedback?
>

I opposed to b). If we go that route, we can look forward to advertising
usetex as "a latex backend, with familiar, standard latex markup, except
when it isnt."

Darren

We have just released a new version of matplotlib, available for download at

  
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644

It is a simple bugfix release to fix a number of critical bugs found in 
0.98.4.

These "what's new" release notes, with graphs and links, are available 
in html at

  http://matplotlib.sourceforge.net/users/whats_new.html

Thanks to Charlie Moad for testing and preparing the source release,
including binaries for OS X and Windows for python 2.4 and 2.5 (2.6
and 3.0 will not be available until numpy is available on those
releases).  Thanks to the many developers who contributed to this
release, with contributions from Jae-Joon Lee, Michael Droettboom,
Ryan May, Eric Firing, Manuel Metz, Jouni K. Seppaenen, Jeff Whitaker,
Darren Dale, David Kaplan, Michiel de Hoon and many others who
submitted patches


What's new in 0.98.5
==============================

It's only been a matter of days since 0.98.4, but there were a number of 
critical bugs that warranted a new release.

2008-12-11 Use subprocess.Popen instead of os.popen in dviread
           (Windows problem reported by Jorgen Stenarson) - JKS

2008-12-10 Added Michael's font_manager fix and Jae-Joon's
           figure/subplot fix.  Bumped version number to 0.98.5 - JDH


-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Manuel Metz wrote:
>> Michael Droettboom wrote:
>>  
>>> There was a discussion on this list around a year ago about this.  The
>>> concern was that not rendering $ as $ would break (matplotlib) backward
>>> compatibility with scripts that don't care about math at all but use a
>>> lot of dollar signs (e.g. financial plots).  This is one of the few
>>> places where we deliberately broke usetex compatibility in favour of
>>> matplotlib compatibility.
>>>
>>> That said, it's probably a bug that the escaped dollar sign in non-math
>>> context is not rendered as a dollar sign.
>>>
>>> As a workaround "$\$%1.2f$" works with usetex on or off, with the
>>> proviso that it uses math- rather than text-rendering for the numbers.
>>>
>>> Mike
>>>     
>>
>> In that case I suggest to note this somewhere in the docs (and User
>> Guide) with three exclamation marks (or is it ???).
>>   
> So there's really two sub-bugs here:
> 
> 1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim
> to the non-math text renderer, which is a bug).  This, IMHO, is a
> "must-fix".
> 
> 2) '$8' gives '$8' in mathtext and an error in usetex.  This could be
> solved in two ways:
> 
> a) document the difference
> b) make '$8' give '$8' in usetex as well
> 
> I realise b) is technically making usetex accept a string that is not
> normally valid TeX -- but it's not like a user would ever enter '$8' and
> *want* to get a TeX error back.  And usetex strings aren't perfectly TeX
> anyway.
> 
> Personally, I'm leaning toward b), because it requires less mental
> effort for the user turning usetex on/off.  And it doesn't force us to
> backtrack on the idea of supporting "$100.00" easily.

+1 + docs of this behavior

> But before I commit -- any feedback?
> 
> Mike
> 

Manuel Metz wrote:
> Michael Droettboom wrote:
>   
>> There was a discussion on this list around a year ago about this.  The
>> concern was that not rendering $ as $ would break (matplotlib) backward
>> compatibility with scripts that don't care about math at all but use a
>> lot of dollar signs (e.g. financial plots).  This is one of the few
>> places where we deliberately broke usetex compatibility in favour of
>> matplotlib compatibility.
>>
>> That said, it's probably a bug that the escaped dollar sign in non-math
>> context is not rendered as a dollar sign.
>>
>> As a workaround "$\$%1.2f$" works with usetex on or off, with the
>> proviso that it uses math- rather than text-rendering for the numbers.
>>
>> Mike
>>     
>
> In that case I suggest to note this somewhere in the docs (and User
> Guide) with three exclamation marks (or is it ???).
>   
So there's really two sub-bugs here:

1) '\$8' gives '\$8' in mathtext (well, actually it gets sent verbatim 
to the non-math text renderer, which is a bug).  This, IMHO, is a 
"must-fix".

2) '$8' gives '$8' in mathtext and an error in usetex.  This could be 
solved in two ways:

a) document the difference
b) make '$8' give '$8' in usetex as well

I realise b) is technically making usetex accept a string that is not 
normally valid TeX -- but it's not like a user would ever enter '$8' and 
*want* to get a TeX error back.  And usetex strings aren't perfectly TeX 
anyway.

Personally, I'm leaning toward b), because it requires less mental 
effort for the user turning usetex on/off.  And it doesn't force us to 
backtrack on the idea of supporting "$100.00" easily.

But before I commit -- any feedback?

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Well, if it's any consolation -- I just finished setting up the
> maintenance branch for 0.98.5, so there's a place for this fix to go... ;)
>

Okay, I just applied a patch to the 0.98.5 maintenance branch. Checked
it with numpy 1.2.1 and 1.3.0.dev6139. Both work fine.

mm

> 
> Manuel Metz wrote:
>> Manuel Metz wrote:
>>  
>>> Jae-Joon Lee wrote:
>>>    
>>>> I just committed the change. Although the change is trivial, I didn't
>>>> tested it in the numpy 1.2 or the svn version.
>>>>       
>>> Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
>>> since 0.98.5 is released...
>>>     
>>
>> See here: http://projects.scipy.org/scipy/numpy/ticket/797
>>
>> "08/05/08 10:47:34 changed by dhuard
>>
>>   For version 1.2, I set new=None by default, which triggers the new
>>   semantics and prints a warning. Setting new to True will trigger the
>>   new semantics but won't print a warning. Done in r5611."
>>
>>
>>  
>>>> -JJ
>>>>
>>>>
>>>> On Sun, Dec 7, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
>>>>      
>>>>> I think the version check is a good idea, so people won't get the
>>>>> annoying
>>>>> warning.  Could you add this?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...>
>>>>> wrote:
>>>>>
>>>>>        
>>>>>> I'm currently using numpy 1.1.1 and np.histogram behave differently
>>>>>> depending on the "new" value.
>>>>>> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
>>>>>> this different behavior is still there.
>>>>>> So, as far as we're going to support numpy 1.1 and later, we may
>>>>>> better not to drop the "new" silently.
>>>>>> We may check the version number of the numpy in the hist() function,
>>>>>> and call np.histogram() accordingly.
>>>>>>
>>>>>> -JJ
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...>
>>>>>> wrote:
>>>>>>          
>>>>>>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>>>>>>> deprecation warning with svn numpy.  Anyone have an opinion on
>>>>>>> whether
>>>>>>> this kwarg should be included in the upcoming mpl release?
>>>>>>>
>>>>>>> JDH
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>             
>>>> ------------------------------------------------------------------------------
>>>>
>>>> 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
>>>>       
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> 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
>>>     
>>
>> ------------------------------------------------------------------------------
>>
>> 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 wrote:
> There was a discussion on this list around a year ago about this.  The
> concern was that not rendering $ as $ would break (matplotlib) backward
> compatibility with scripts that don't care about math at all but use a
> lot of dollar signs (e.g. financial plots).  This is one of the few
> places where we deliberately broke usetex compatibility in favour of
> matplotlib compatibility.
> 
> That said, it's probably a bug that the escaped dollar sign in non-math
> context is not rendered as a dollar sign.
> 
> As a workaround "$\$%1.2f$" works with usetex on or off, with the
> proviso that it uses math- rather than text-rendering for the numbers.
> 
> Mike

In that case I suggest to note this somewhere in the docs (and User
Guide) with three exclamation marks (or is it ???).

Manuel

> Manuel Metz wrote:
>>   I just noted that mathtext and LaTeX rendering behave differently
>> when using a single "$" character in a text string. This happened to
>> me when looking at the dollar_ticks example from the docs because I
>> use LaTeX rendering by default. The problem is here:
>>
>> formatter = ticker.FormatStrFormatter('$%1.2f')
>>
>> MathText interprets this as a single "$" character, whereas LaTeX
>> interprets this as starting character of a math expression (and I get
>> an error), i.e. I have to write "\$1.2f" instead, which then, however,
>> is interpreted by MathText as "\$" ... :-(
>>
>> Shouldn't these two behave equally here?
>>
>> mm

Darren Dale wrote:
>
>
> On Wed, Dec 10, 2008 at 11:10 PM, John Hunter <jd...@gm... 
> <mailto:jd...@gm...>> wrote:
>
>
>
>     On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...
>     <mailto:dsd...@gm...>> wrote:
>
>         There has been a report at the bugtracker complaining that
>         matplotlib is overwriting an existing installation of
>         configobj. I had a look at the code and thought the bug report
>         must be a mistake or windows specific, but I just saw similar
>         behavior on my linux system.
>
>
>     Ignoring for a minute the question of whether we can/should flush
>     configobj/traits, it sounds like the real problem is that
>     setup.cfg is not working like we expect it to.  And that is
>     something that should be fixed if is broken.  If mpl is installing
>     configobj or traits even if we are telling it not to via
>     setup.cfg, then we have a problem.   This is worth knowing, since
>     the last mpl release was broken vis-a-vis the default backend on
>     win32, which *could* be explained by a broken setup.cfg.
>
>
>         I would like to simply remove configobj and traits from our
>         repository. They are only used by the long-neglected
>         experimental traited config package, which is only of interest
>         to developers who can easily install them as external
>         dependencies. Is it ok to remove them? If so, should it be
>         done on all the branches?
>
> [...]
>
>
>     You can remove them from the trunk.  They should remain on the
>     0.91 branch as is (with any known bugs fixed and merged) since
>     that is the point of the branch (stability for those who cannot
>     upgrade -- in principle someone might be depending on the traited
>     config, in practice unlikely).
>
>
> I just removed them from the trunk, but not the 0.91 or 0.98.5 
> branches. I was going to add a note to the API_CHANGES log, was it 
> removed?
API_CHANGES was moved to doc/api/api_changes.rst so it gets 
automatically put up on the website.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Dec 10, 2008 at 11:10 PM, John Hunter <jd...@gm...> wrote:

>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...> wrote:
>
>> There has been a report at the bugtracker complaining that matplotlib is
>> overwriting an existing installation of configobj. I had a look at the code
>> and thought the bug report must be a mistake or windows specific, but I just
>> saw similar behavior on my linux system.
>
>
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is not
> working like we expect it to.  And that is something that should be fixed if
> is broken.  If mpl is installing configobj or traits even if we are telling
> it not to via setup.cfg, then we have a problem.   This is worth knowing,
> since the last mpl release was broken vis-a-vis the default backend on
> win32, which *could* be explained by a broken setup.cfg.
>
>
> I would like to simply remove configobj and traits from our repository.
>> They are only used by the long-neglected experimental traited config
>> package, which is only of interest to developers who can easily install them
>> as external dependencies. Is it ok to remove them? If so, should it be done
>> on all the branches?
>>
> [...]

>
> You can remove them from the trunk.  They should remain on the 0.91 branch
> as is (with any known bugs fixed and merged) since that is the point of the
> branch (stability for those who cannot upgrade -- in principle someone might
> be depending on the traited config, in practice unlikely).
>

I just removed them from the trunk, but not the 0.91 or 0.98.5 branches. I
was going to add a note to the API_CHANGES log, was it removed?

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
>>     
>
>   

Done.

I also cleaned up the svnmerge docs in doc/devel/coding_guide.rst

What we don't currently have is a way to merge fixes from 0.91.x to 
0.98.5.  It's been a long time since 0.91.x has seen any love, so I'm 
not too concerned.  Just be aware of it -- bug fixes on 0.91.x may need 
to be manually brought in to 0.98.5 if applicable.

Mike

John Hunter wrote:
> Michael,
>
> Will you create the branch and set up the svn merge properties?
>
> Thanks Charlie,
> JDH
>
> Sent from my iPhone
>
> On Dec 11, 2008, at 7:35 PM, "Charlie Moad" <cw...@gm...> wrote:
>
>> 0.98.5 source and bins are posted.  Please try them out.  John can
>> announce at his convenience.
>>
>> - Charlie
>>
>> On Thu, Dec 11, 2008 at 12:15 PM, John Hunter <jd...@gm...> wrote:
>>> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom 
>>> <md...@st...> wrote:
>>>
>>>>> And I'll try and get the maintenance branch right next time :-)
>>>>
>>>> All of the above sounds good to me.
>>>
>>> I will be traveling to my conference starting at noon, so will be in
>>> sporadic, light email contact for the next few days.  Charlie will
>>> look at fixing the builds tonight -- everyone else, please do what you
>>> can if something comes up because I would love to have a good set of
>>> binaries on line by the time my talk starts at noon tomorrow:
>>>
>>> http://mloss.org/workshop/nips08/
>>>
>>> JDH
>>>

Well, if it's any consolation -- I just finished setting up the 
maintenance branch for 0.98.5, so there's a place for this fix to go... ;)

Mike

Manuel Metz wrote:
> Manuel Metz wrote:
>   
>> Jae-Joon Lee wrote:
>>     
>>> I just committed the change. Although the change is trivial, I didn't
>>> tested it in the numpy 1.2 or the svn version.
>>>       
>> Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
>> since 0.98.5 is released...
>>     
>
> See here: http://projects.scipy.org/scipy/numpy/ticket/797
>
> "08/05/08 10:47:34 changed by dhuard
>
>   For version 1.2, I set new=None by default, which triggers the new
>   semantics and prints a warning. Setting new to True will trigger the
>   new semantics but won't print a warning. Done in r5611."
>
>
>   
>>> -JJ
>>>
>>>
>>> On Sun, Dec 7, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
>>>       
>>>> I think the version check is a good idea, so people won't get the annoying
>>>> warning.  Could you add this?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...> wrote:
>>>>
>>>>         
>>>>> I'm currently using numpy 1.1.1 and np.histogram behave differently
>>>>> depending on the "new" value.
>>>>> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
>>>>> this different behavior is still there.
>>>>> So, as far as we're going to support numpy 1.1 and later, we may
>>>>> better not to drop the "new" silently.
>>>>> We may check the version number of the numpy in the hist() function,
>>>>> and call np.histogram() accordingly.
>>>>>
>>>>> -JJ
>>>>>
>>>>>
>>>>> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...> wrote:
>>>>>           
>>>>>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>>>>>> deprecation warning with svn numpy.  Anyone have an opinion on whether
>>>>>> this kwarg should be included in the upcoming mpl release?
>>>>>>
>>>>>> JDH
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> 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
>>>>>>
>>>>>>             
>>> ------------------------------------------------------------------------------
>>> 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
>>>       
>>
>> ------------------------------------------------------------------------------
>> 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
>>     
>
> ------------------------------------------------------------------------------
> 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
>   

Manuel Metz wrote:
> Jae-Joon Lee wrote:
>> I just committed the change. Although the change is trivial, I didn't
>> tested it in the numpy 1.2 or the svn version.
> 
> Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
> since 0.98.5 is released...

See here: http://projects.scipy.org/scipy/numpy/ticket/797

"08/05/08 10:47:34 changed by dhuard

  For version 1.2, I set new=None by default, which triggers the new
  semantics and prints a warning. Setting new to True will trigger the
  new semantics but won't print a warning. Done in r5611."


> 
>> -JJ
>>
>>
>> On Sun, Dec 7, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
>>> I think the version check is a good idea, so people won't get the annoying
>>> warning.  Could you add this?
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...> wrote:
>>>
>>>> I'm currently using numpy 1.1.1 and np.histogram behave differently
>>>> depending on the "new" value.
>>>> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
>>>> this different behavior is still there.
>>>> So, as far as we're going to support numpy 1.1 and later, we may
>>>> better not to drop the "new" silently.
>>>> We may check the version number of the numpy in the hist() function,
>>>> and call np.histogram() accordingly.
>>>>
>>>> -JJ
>>>>
>>>>
>>>> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...> wrote:
>>>>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>>>>> deprecation warning with svn numpy.  Anyone have an opinion on whether
>>>>> this kwarg should be included in the upcoming mpl release?
>>>>>
>>>>> JDH
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>>
>> ------------------------------------------------------------------------------
>> 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
> 
> 
> 
> ------------------------------------------------------------------------------
> 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

Jae-Joon Lee wrote:
> I just committed the change. Although the change is trivial, I didn't
> tested it in the numpy 1.2 or the svn version.

Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
since 0.98.5 is released...


> -JJ
> 
> 
> On Sun, Dec 7, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
>> I think the version check is a good idea, so people won't get the annoying
>> warning.  Could you add this?
>>
>> Sent from my iPhone
>>
>> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...> wrote:
>>
>>> I'm currently using numpy 1.1.1 and np.histogram behave differently
>>> depending on the "new" value.
>>> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
>>> this different behavior is still there.
>>> So, as far as we're going to support numpy 1.1 and later, we may
>>> better not to drop the "new" silently.
>>> We may check the version number of the numpy in the hist() function,
>>> and call np.histogram() accordingly.
>>>
>>> -JJ
>>>
>>>
>>> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...> wrote:
>>>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>>>> deprecation warning with svn numpy.  Anyone have an opinion on whether
>>>> this kwarg should be included in the upcoming mpl release?
>>>>
>>>> JDH
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>>
> 
> ------------------------------------------------------------------------------
> 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

There was a discussion on this list around a year ago about this.  The 
concern was that not rendering $ as $ would break (matplotlib) backward 
compatibility with scripts that don't care about math at all but use a 
lot of dollar signs (e.g. financial plots).  This is one of the few 
places where we deliberately broke usetex compatibility in favour of 
matplotlib compatibility.

That said, it's probably a bug that the escaped dollar sign in non-math 
context is not rendered as a dollar sign.

As a workaround "$\$%1.2f$" works with usetex on or off, with the 
proviso that it uses math- rather than text-rendering for the numbers.

Mike

Manuel Metz wrote:
>   I just noted that mathtext and LaTeX rendering behave differently 
> when using a single "$" character in a text string. This happened to 
> me when looking at the dollar_ticks example from the docs because I 
> use LaTeX rendering by default. The problem is here:
>
> formatter = ticker.FormatStrFormatter('$%1.2f')
>
> MathText interprets this as a single "$" character, whereas LaTeX 
> interprets this as starting character of a math expression (and I get 
> an error), i.e. I have to write "\$1.2f" instead, which then, however, 
> is interpreted by MathText as "\$" ... :-(
>
> Shouldn't these two behave equally here?
>
> mm

   I just noted that mathtext and LaTeX rendering behave differently 
when using a single "$" character in a text string. This happened to me 
when looking at the dollar_ticks example from the docs because I use 
LaTeX rendering by default. The problem is here:

formatter = ticker.FormatStrFormatter('$%1.2f')

MathText interprets this as a single "$" character, whereas LaTeX 
interprets this as starting character of a math expression (and I get an 
error), i.e. I have to write "\$1.2f" instead, which then, however, is 
interpreted by MathText as "\$" ... :-(

Shouldn't these two behave equally here?

mm

On Thu, 11 Dec 2008 10:33:20 -0800
  Andrew Straw <str...@as...> wrote:
> Hi Nils. I think I fixed the issue causing the traceback 
>with r6563. Can
> you please update and try again with text.usetex 
>enabled?
> 
> My guess is that you don't have dvipng installed, which 
>was causing the
> detection check to throw a traceback rather than return 
>a value
> signifying undetected. So, enabling usetex should again 
>trigger the
> check, but hopefully this time it will fail gracefully 
>rather than crashing.
> 
> -Andrew
  
Hi Andrew,

Thank you very much !
Works for me.

>>> import matplotlib.mlab as mlab
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py:371: 
UserWarning: matplotlibrc text.usetex can not be used with 
*Agg backend unless dvipng-1.5 or later is installed on 
your system
   warnings.warn( 'matplotlibrc text.usetex can not be 
used with *Agg '

Cheers,
             Nils

On Thu, Dec 11, 2008 at 01:37:01PM -0800, Andrew Straw wrote:
> Prabhu Ramachandran has also done similar things for mayavi2 using VTK's
> image comparison (see compare_image_with_saved_image in
> https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtests/mayavi/common.py
> ).

Yeah, and it always fails due to the hardware rendering being slightly
different on different computers :). I think we are giving up on this
approach.

Gaël

I think of artists as having visual properties that persist (e.g.,
filled vs. outlined, a colormap with min and max values) even as data
associated with the artist is changed. In the edge case described
below, this doesn't seem to hold true.

I have code that animates a scatter plot by sub-selecting the data
stored in a collection artist. In cases where some frames contain no
data, the scatter artist's data is temporarily empty. On subsequent
frames (once there is data again) some of the visual properties my
filled point becomes an outlined point, as in the code below.

# Filled single point with no outline
sc = scatter([1],[1],c=[1], edgecolors='none')

# Cache the data
xy=sc.get_offsets()
s=sc.get_array()

sel=s<0
sc.set_offsets(xy[sel,:])
sc.set_array(s[sel])

# No data, so nothing shown. No problem.
sc.figure.canvas.draw()

# Now restore the original data
sc.set_offsets(xy)
sc.set_array(s)

# Outlined single point with no fill
sc.figure.canvas.draw()
sc.get_edgecolors()
sc.get_facecolors()
sc.get_array()

The fix probably has to do with Collection.update_scalarmappable.
When set_array([ ]) happens,
        len(self._facecolors) > 0, therefore
        self._facecolors = to_rgba([  ]),
When set_array([1]) restores data,
        len(self._facecolors) == 0, therefore
        self._edgecolors = self.to_rgba([1])

Should is_filled vs. is_stroked be preserved in this case? If so, is
there a more elegant fix than to add is_filled and is_stroked
properties that are checked by update_scalarmappable?

Thanks,
Eric

Michael,

Will you create the branch and set up the svn merge properties?

Thanks Charlie,
JDH

Sent from my iPhone

On Dec 11, 2008, at 7:35 PM, "Charlie Moad" <cw...@gm...> wrote:

> 0.98.5 source and bins are posted.  Please try them out.  John can
> announce at his convenience.
>
> - Charlie
>
> On Thu, Dec 11, 2008 at 12:15 PM, John Hunter <jd...@gm...>  
> wrote:
>> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom  
>> <md...@st...> wrote:
>>
>>>> And I'll try and get the maintenance branch right next time :-)
>>>
>>> All of the above sounds good to me.
>>
>> I will be traveling to my conference starting at noon, so will be in
>> sporadic, light email contact for the next few days.  Charlie will
>> look at fixing the builds tonight -- everyone else, please do what  
>> you
>> can if something comes up because I would love to have a good set of
>> binaries on line by the time my talk starts at noon tomorrow:
>>
>> http://mloss.org/workshop/nips08/
>>
>> JDH
>>

0.98.5 source and bins are posted.  Please try them out.  John can
announce at his convenience.

- Charlie

On Thu, Dec 11, 2008 at 12:15 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom <md...@st...> wrote:
>
>>> And I'll try and get the maintenance branch right next time :-)
>>
>> All of the above sounds good to me.
>
> I will be traveling to my conference starting at noon, so will be in
> sporadic, light email contact for the next few days.  Charlie will
> look at fixing the builds tonight -- everyone else, please do what you
> can if something comes up because I would love to have a good set of
> binaries on line by the time my talk starts at noon tomorrow:
>
>  http://mloss.org/workshop/nips08/
>
> JDH
>

Andrew Straw wrote:
> Andrew Straw wrote:
>
> I realize I may have ignored an important question.
>
>   
>> Michael Droettboom wrote:
>>     
>
>   
>>> Now I feel stuck.  How do I "undo" the merge from experimental to master?
>>>       
>
> To do that, I actually delete the master branch with "git branch -D
> master" and then re-create a new one with "git checkout -b master
> 028a0df8" (where I've identified commit 028a0df8 as where I want the new
> master to be).
>   
Thanks for the suggestion.  Because I "merged", rather than "rebased" 
from my development branch, changes from the branch are interleaved with 
changes from SVN, so it's not clear to me how to remove only the changes 
that were brought in from the merge.  But that might also be the root 
cause of the problem I'm having.  I tried going back to the first SVN 
change prior to anything on my branch, the "git svn rebase", but that 
didn't solve the issue -- it still requires me to merge changes I know 
nothing about.  I think I'll follow your suggestion of "rebasing" 
development branches -- I can see how that's superior to "merge" anyway, 
since it will hide all my work/mistakes from the central SVN repository.

I'm going to declare bankruptcy at re-clone the whole repository and see 
if things work better.  Wish I understood how I painted myself in this 
corner in the first place, but maybe I'll notice it next time around.

Mike

I have also developed some image-based unit tests to compare MPL output,
and I completely agree that getting something like this into MPL is a
very good idea. As Ted writes, the hard part is defining "close" for
images. Minor changes to, for example, agg pixel alignment, cause the
tests to fail when they have low tolerances. So, such tests are a bit
more interactive than plain old unit tests when something changes, but I
think that's worth the pain.

Prabhu Ramachandran has also done similar things for mayavi2 using VTK's
image comparison (see compare_image_with_saved_image in
https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtests/mayavi/common.py
).

I'm attaching the code I use to compare images as a starting point -- it
currently uses scipy to load the images, but this could surely be worked
around.

-Andrew

Drain, Theodore R wrote:
> John,
> 
> One thing that would help w/ a rapid delivery/response cycle would be
> more comprehensive tests.    They would let other developers try out
> various ideas and see what breaks before you release it.
> 
>  
> 
> We’ve implemented an automated approach where we run an MPL script using
> Agg, save the output image and then compare it against a “good” image
> that someone looked at.  We use PIL to do the compare and if it’s close
> (that’s the hard part), then the test passes.  If it’s not, someone
> looks at the two images to see if the difference is benign.  Something
> similar to this could be done (if you’re not already) for the MPL
> examples to make sure that changes don’t cause plotting problems in
> other areas. 
> 
>  
> 
> Having this kind of system is also a great driver for people to expand
> it.  For example – we really care about unit processing support
> everywhere.  Every once in awhile, we find a change that someone submits
> that breaks unit support.  So once of the tasks we‘re going to work on
> next year is to build a set of automated test cases that try and hit
> every plot function with units which can then run on every release.  If
> there were a simple to use MPL standard test system like this, other
> people might contribute more tests as a way of insuring that the things
> they care about stay working through various changes.
> 
>  
> 
> It would also be nice to have a test system for unit testing of
> components.  A lot of the code that does different transformations,
> symbol and color mapping, etc etc could be unit tested without the need
> for actually drawing anything.  If there was a standard location, style,
> and system, people could slowly add to the tests over time.  You can
> also consider requiring some level of unit test for newly submitted code
> where ever it’s possible.
> 
>  
> 
> Just some thoughts…
> 
> Ted
> 
>  
> 
> *From:* John Hunter [mailto:jd...@gm...]
> *Sent:* Wednesday, December 10, 2008 8:10 PM
> *To:* Darren Dale
> *Cc:* mat...@li...
> *Subject:* Re: [matplotlib-devel] requesting permission to remove traits
> and configobj
> 
>  
> 
>  
> 
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...
> <mailto:dsd...@gm...>> wrote:
> 
> There has been a report at the bugtracker complaining that matplotlib is
> overwriting an existing installation of configobj. I had a look at the
> code and thought the bug report must be a mistake or windows specific,
> but I just saw similar behavior on my linux system.
> 
> 
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is
> not working like we expect it to.  And that is something that should be
> fixed if is broken.  If mpl is installing configobj or traits even if we
> are telling it not to via setup.cfg, then we have a problem.   This is
> worth knowing, since the last mpl release was broken vis-a-vis the
> default backend on win32, which *could* be explained by a broken setup.cfg.
> 
>     I would like to simply remove configobj and traits from our
>     repository. They are only used by the long-neglected experimental
>     traited config package, which is only of interest to developers who
>     can easily install them as external dependencies. Is it ok to remove
>     them? If so, should it be done on all the branches?
> 
>     How long are we going to continue to maintain the different
>     branches? It was so much easier back when we only had to worry about
>     the trunk...
> 
> 
> You can remove them from the trunk.  They should remain on the 0.91
> branch as is (with any known bugs fixed and merged) since that is the
> point of the branch (stability for those who cannot upgrade -- in
> principle someone might be depending on the traited config, in practice
> unlikely).  As for the 0.98 branch, it is slated for destruction so no
> worries.  I share your visceral reaction against branches, but my head
> is starting to override this bodily reaction, as I see the need for them
> in practice.  If we carefully document the best practices and
> motivations in the developerr's guide, we can use them advantageously.  
> 
> We have a lot of people contributing to mpl, and approaching or just
> after release time we need some mechanism for stabilizing the tested
> feature set  of the release candidate while allowing other development
> to proceed, and branches are the natural mechanism for that.  That we
> are starting to use them is a reflection of the fact that we have many
> more active developers than we ever had before (12 developers
> contributed between 98.3 and 98.4, it used to be just 3 or 4 at a
> time).   I wouldn't be advocating branches otherwise, because I am an
> advocate of doing things as simply as possible: "Make everything as
> simple as possible, but not simpler.".  
> 
> In general, I am in favor of the wildest, wooliest, development process
> we can afford.  I would like to have  everyone on the trunk, making
> releases as often as possible (nightly if we can), with an attitude of
> "if you break it, just fix it an rerelease it".  This model worked fine
> for us for years, and I think it would continue to work if we have a
> hyper-active developer or an automated build bot.  In the old days, I
> would release any time I added a new feaure, and if I broke something I
> would have a new release out in hours.  I no longer have the time for
> that, and  we are lucky to have Charlie buildng OS X and win32 binaties
> and eggs for multiple python versions.  When we release broken code,
> Charlie has to go through the entire test/upload/release cycle again,
> building for multiple OSs and python versions while taking care of his
> wife and two babies, so we want to minimize that.  At the same time, we
> have lots of developers pushing code into the mainline.  We need some
> mechanism of balancing the desire of developers to get new code in and
> the need for the packagers and release manangers to get stable code out. 
> 
> I think the right balance for mpl before a release is to test the HEAD,
> sign off on it, branch it, let development proceed on the HEAD, and put
> any release critical bugs and fixes into the branch.  When the next
> release comes up, delete the old branch, and wash-rinse-repeat.  We will
> have in perpetuity one active release branch at a time, which gets
> important bug fixes and nothing else, and in addition (for a while) a
> legacy branch (0.91) which is updated once a month or so.  I am happy to
> get input on this.
> 
> JDH
> 
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.9.16/1841 - Release Date:
> 12/10/2008 6:53 PM
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 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