[matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Manuel Metz]

   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

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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

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


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

Re: [matplotlib-devel] using new in axes.hist

[Manuel Metz]

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

Re: [matplotlib-devel] using new in axes.hist

[Manuel Metz]

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

Re: [matplotlib-devel] using new in axes.hist

[Michael Droettboom]

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

Re: [matplotlib-devel] 98.4 maintenance branch

[Michael Droettboom]

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"  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  wrote:
>>> On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom 
>>>  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
>>>


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

Re: [matplotlib-devel] git questions

[Michael Droettboom]

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

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Darren Dale]

On Wed, Dec 10, 2008 at 11:10 PM, John Hunter  wrote:

>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale  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?
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[Michael Droettboom]

Darren Dale wrote:
>
>
> On Wed, Dec 10, 2008 at 11:10 PM, John Hunter  > wrote:
>
>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale  > 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


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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Manuel Metz]

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


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

Re: [matplotlib-devel] using new in axes.hist

[Manuel Metz]

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  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" 
> 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 
>> 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
>>> Matplotlib-devel@lists.sourceforge.net
>>> 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
 Matplotlib-devel@lists.sourceforge.net
 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
>>> Matplotlib-devel@lists.sourceforge.net
>>> 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
>> Matplotlib-devel@lists.sourceforge.net
>> 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;135

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

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


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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Manuel Metz]

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
> 

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

[matplotlib-devel] ANN: matplotlib-0.98.5

[Michael Droettboom]

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


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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Darren Dale]

On Fri, Dec 12, 2008 at 9:46 AM, 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.
>
> 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] scatter and alpha

[Gregor Thalhammer]

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
Index: axes.py
===
--- axes.py (revision 6590)
+++ axes.py (working copy)


@@ -4873,7 +4872,7 @@
 medians=medians, fliers=fliers)
 
 def scatter(self, x, y, s=20, c='b', marker='o', cmap=None, norm=None,
-vmin=None, vmax=None, alpha=1.0, linewidths=None,
+vmin=None, vmax=None, alpha=None, linewidths=None,
 faceted=True, verts=None,
 **kwargs):
 """
@@ -5136,7 +5135,8 @@
 transOffset = self.transData,
 )
 collection.set_transform(mtransforms.IdentityTransform())
-collection.set_alpha(alpha)
+if alpha is not None:
+collection.set_alpha(alpha)
 collection.update(kwargs)
 
 if colors is None:
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
> On Fri, Dec 12, 2008 at 9:46 AM, 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.
>
> 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


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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Darren Dale]

On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom  wrote:

> Darren Dale wrote:
>
>  On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom > md...@stsci.edu>> 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).
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git questions

[Andrew Straw]

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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
> On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom  > wrote:
>
> Darren Dale wrote:
>
> On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom
> mailto:md...@stsci.edu>
> >> 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 $.
That's always worked and still worked -- that's not the bug at hand. 
> I think it was unwise to accept $ for $ in mathtext in the first 
> place, since mathtext uses tex markup anyway.
I'm not proposing that at all.  I think we're running into a 
misunderstanding about what I mean by "mathtext" and the scope of the 
proposed change.  By mathtext, I mean "the text between a pair of $ $ 
when usetex is off".  mathtext aims to be TeX-compatible (for a 
subset).  Regular text does not (and in fact has no markup whatsoever).  
That last point, I believe, is the root of this problem and why 
reconciling usetex with non-usetex may be a losing battle, as you're 
starting to convince me.  usetex is simply not the same thing as regular 
matplotlib text.

I'll clarify anyway -- but I'm starting to think that unless there is 
someone doing financial plots with usetex that is dying for this 
feature, I'll just leave it.

The bug at hand deals with regular text, not math text.  There has been 
a test in the non-usetex code path for a long time to determine if there 
is any math in the string (by looking for an even number of non-escaped 
$) and allow the simple monetary case to work without needing to escape 
the $.  It used to be impossible to interleave math and regular text in 
the same string and I needed a way to add support for interleaving 
without breaking existing usage, and without requiring an explicit flag 
saying "my string has math".  It's not perfect -- if you want to

Re: [matplotlib-devel] git questions

[Michael Droettboom]

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 

[matplotlib-devel] error installing matplotlib-0.98.5

[Neal Becker]

sudo easy_install -U matplotlib
Searching for matplotlib
Reading http://pypi.python.org/simple/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading 
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
Reading 
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading http://sourceforge.net/project/showfiles.php?group_id=80706
Best match: matplotlib 0.98.5
Downloading 
http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtime=1229034572&big_mirror=0
Processing matplotlib-0.98.5.tar.gz
Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir 
/tmp/easy_install-CC1jw7/matplotlib-0.98.5/egg-dist-tmp-NSNvcC

BUILDING MATPLOTLIB
matplotlib: 0.98.5
python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03)  [GCC
4.3.2 20080917 (Red Hat 4.3.2-4)]
  platform: linux2

REQUIRED DEPENDENCIES
 numpy: 1.2.0
 freetype2: 9.18.3

OPTIONAL BACKEND DEPENDENCIES
libpng: 1.2.33
   Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5
* Guessing the library and include directories for
* Tcl and Tk because the tclConfig.sh and
* tkConfig.sh could not be found and/or parsed.
  wxPython: 2.8.9.1
* WxAgg extension not required for wxPython >= 2.8
  Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0,
pygobject: 2.15.4
   Mac OS X native: no
Qt: Qt: 3.3.8, PyQt: 3.17.4
   Qt4: Qt: 4.4.1, PyQt4: 4.4.3
 Cairo: 1.4.12

OPTIONAL DATE/TIMEZONE DEPENDENCIES
  datetime: present, version unknown
  dateutil: 1.4
  pytz: 2006p

OPTIONAL USETEX DEPENDENCIES
dvipng: 1.11
   ghostscript: 8.63
 latex: 3.141592

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.5.2
  enthought.traits: no

[Edit setup.cfg to suppress the above messages]

error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or 
directory
Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') 
in > ignored
Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') 
in > ignored
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/backend_gdk.c') in > ignored
Exception exceptions.OSError: (2, 'No such file or directory', 
'src/backend_agg.cpp') in > ignored



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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Darren Dale]

On Fri, Dec 12, 2008 at 2:22 PM, Michael Droettboom  wrote:

> Darren Dale wrote:
>
>> On Fri, Dec 12, 2008 at 1:06 PM, Michael Droettboom > md...@stsci.edu>> wrote:
>>
>>Darren Dale wrote:
>>
>>On Fri, Dec 12, 2008 at 9:46 AM, Michael Droettboom
>>mailto:md...@stsci.edu>
>>>> 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 $.
>>
> That's always worked and still worked -- that's not the bug at hand.
>
>> I think it was unwise to accept $ for $ in mathtext in the first place,
>> since mathtext uses tex markup anyway.
>>
> I'm not proposing that at all.  I think we're running into a
> misunderstanding about what I mean by "mathtext" and the scope of the
> proposed change.  By mathtext, I mean "the text between a pair of $ $ when
> usetex is off".  mathtext aims to be TeX-compatible (for a subset).  Regular
> text does not (and in fact has no markup whatsoever).  That last point, I
> believe, is the root of this problem and why reconciling usetex with
> non-usetex may be a losing battle, as you're starting to convince me.
>  usetex is simply not the same thing as regular matplotlib text.
>
> I'll clarify anyway -- but I'm starting to think that unless there is
> someone doing financial plots with usetex that is dying for this feature,
> I'll just leave it.
>
> The bug at hand deals with regular text, not math text.  There has been a
> test in the non-usetex code path for a long time to determine if there is
> any math in the string (by looking for an even number of non-escaped $) and
> allow the simple monetary case to work without needing to escape the $.


Right. I'm not criticizing the work you did on mathtext, which I think is
amazing and could not have done myself. And I forgot that because mathtext
used to be an all

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[John Hunter]

On Fri, Dec 12, 2008 at 2:41 PM, Darren Dale  wrote:

> What I would prefer is to raise a deprecation warning when an odd number of
> dollar signs are encountered, giving people time to learn to escape their $
> and modify their code. I wonder how disruptive this would be to people using
> mpl for finance?

Well, we used to need lots of dollar signs, but with the market crash
and credit crunch, we will probably get by with fewer going forward


This is fine with me -- I suspect it is a very rare corner case.

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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Michael Droettboom]

Darren Dale wrote:
>
> And I forgot that because mathtext used to be an all-or-nothing 
> enterprise, there was no reason to escape the $ in regular text. Once 
> you made it possible to embed mathtext in a regular string, I think it 
> would have been better in the long run to require \$, but the powerful 
> financial interests and their fat-cat lobbyists won the day.
lol ... I'm ready for my payout now... :)
>  
>
> What I would prefer is to raise a deprecation warning when an odd 
> number of dollar signs are encountered, giving people time to learn to 
> escape their $ and modify their code. I wonder how disruptive this 
> would be to people using mpl for finance? If that is unacceptable, I 
> guess the best solution is as you propose, but maybe usetex should 
> issue a warning that it has modified the string rather than strictly 
> interpret it.
That sounds like a good solution going forward.
>
> Do you know if there are any other inconsistencies between the 
> text/mathtext markup and latex?
>
Doh!  That's actually a very illuminating question...  One which, had I 
thought of it earlier, I might have never thought of dealing with $ at 
all... ;)

Basically anything that is meaningful markup in TeX would have to be 
escaped for usetex, but not for regular text.  In that sense, $ is just 
one of many.  Think of "{brackets}", for instance.  You get "{brackets}" 
with regular text, and "brackets" with usetex.  I'm sure the list of 
these things is fairly long.  We don't want to start implicitly escaping 
those for usetex.  All this supports the theory that perhaps the gap 
between regular text and usetex is too wide to reasonably bridge.

While originally this morning thought "let's just fix the 
inconsistencies", I'm now leaning to just adding a note to the docs that 
"regular text and usetex is fundamentally incompatible in a lot of ways" 
and leaving it at that.

Mike

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


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

Re: [matplotlib-devel] Different behaviour of mathtext and LaTeX rendering

[Darren Dale]

On Fri, Dec 12, 2008 at 3:55 PM, Michael Droettboom  wrote:

> 
>
> Darren Dale wrote:
>
>>
>> And I forgot that because mathtext used to be an all-or-nothing
>> enterprise, there was no reason to escape the $ in regular text. Once you
>> made it possible to embed mathtext in a regular string, I think it would
>> have been better in the long run to require \$, but the powerful financial
>> interests and their fat-cat lobbyists won the day.
>>
> lol ... I'm ready for my payout now... :)
>
>>
>> What I would prefer is to raise a deprecation warning when an odd number
>> of dollar signs are encountered, giving people time to learn to escape their
>> $ and modify their code. I wonder how disruptive this would be to people
>> using mpl for finance? If that is unacceptable, I guess the best solution is
>> as you propose, but maybe usetex should issue a warning that it has modified
>> the string rather than strictly interpret it.
>>
> That sounds like a good solution going forward.
>
>>
>> Do you know if there are any other inconsistencies between the
>> text/mathtext markup and latex?
>>
>>  Doh!  That's actually a very illuminating question...  One which, had I
> thought of it earlier, I might have never thought of dealing with $ at
> all... ;)
>
> Basically anything that is meaningful markup in TeX would have to be
> escaped for usetex, but not for regular text.  In that sense, $ is just one
> of many.  Think of "{brackets}", for instance.  You get "{brackets}" with
> regular text, and "brackets" with usetex.  I'm sure the list of these things
> is fairly long.


What else is there that is likely to cause problems going from mpltext to
usetex? math: \( \). displaymath (which is not supported in mathtext and
strongly discouraged in usetex): \[ \], $$ $$ . \( \) are probably so rarely
used in regular text that they could be made to mean the same thing in
mathtext as they do in usetex. displaymath could raise an error in both
usetex and mathtext. ^ and _ render in regular text but raises an error
outside of mathmode with usetex (my installation of texlive actually
attempts to do the right thing and insert the missing mathmode characters in
the case of ^ and _.) %. ~ (nonbreaking space). #. Unicode? Ugh.


> We don't want to start implicitly escaping those for usetex.  All this
> supports the theory that perhaps the gap between regular text and usetex is
> too wide to reasonably bridge.
>
> While originally this morning thought "let's just fix the inconsistencies",
> I'm now leaning to just adding a note to the docs that "regular text and
> usetex is fundamentally incompatible in a lot of ways" and leaving it at
> that.
>


I think it would be worth stating in the docs that # $ % & ~ _ ^ \ { } \( \)
\[ \] have special meaning in latex but not in regular mpl text, so buyer
beware. It might be nice if mpl regular text rendered the escaped version of
all these characters the same way latex does, that would make it easier to
go from text to usetex.

Speaking of implicitly doing the right thing, last night I was in the middle
of working through a difficult bug when Windows Vista *kicked me out without
asking or issuing a warning*, installed updates, and rebooted. I'm still
mumbling under my breath about it. Friggin jerks.
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] error installing matplotlib-0.98.5

[Charlie Moad]

I'm not seeing this on OSX.  Is anyone else experiencing this issue?

- Charlie

On Fri, Dec 12, 2008 at 2:39 PM, Neal Becker  wrote:
> sudo easy_install -U matplotlib
> Searching for matplotlib
> Reading http://pypi.python.org/simple/matplotlib/
> Reading http://matplotlib.sourceforge.net
> Reading 
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> Reading 
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
> Reading http://sourceforge.net/project/showfiles.php?group_id=80706
> Best match: matplotlib 0.98.5
> Downloading 
> http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.5.tar.gz?modtime=1229034572&big_mirror=0
> Processing matplotlib-0.98.5.tar.gz
> Running matplotlib-0.98.5/setup.py -q bdist_egg --dist-dir 
> /tmp/easy_install-CC1jw7/matplotlib-0.98.5/egg-dist-tmp-NSNvcC
> 
> BUILDING MATPLOTLIB
>matplotlib: 0.98.5
>python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03)  [GCC
>4.3.2 20080917 (Red Hat 4.3.2-4)]
>  platform: linux2
>
> REQUIRED DEPENDENCIES
> numpy: 1.2.0
> freetype2: 9.18.3
>
> OPTIONAL BACKEND DEPENDENCIES
>libpng: 1.2.33
>   Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5
>* Guessing the library and include directories for
>* Tcl and Tk because the tclConfig.sh and
>* tkConfig.sh could not be found and/or parsed.
>  wxPython: 2.8.9.1
>* WxAgg extension not required for wxPython >= 2.8
>  Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0,
>pygobject: 2.15.4
>   Mac OS X native: no
>Qt: Qt: 3.3.8, PyQt: 3.17.4
>   Qt4: Qt: 4.4.1, PyQt4: 4.4.3
> Cairo: 1.4.12
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>  datetime: present, version unknown
>  dateutil: 1.4
>  pytz: 2006p
>
> OPTIONAL USETEX DEPENDENCIES
>dvipng: 1.11
>   ghostscript: 8.63
> latex: 3.141592
>
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
> configobj: 4.5.2
>  enthought.traits: no
>
> [Edit setup.cfg to suppress the above messages]
> 
> error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or 
> directory
> Exception exceptions.OSError: (2, 'No such file or directory', 
> 'src/image.cpp') in  > ignored
> Exception exceptions.OSError: (2, 'No such file or directory', 
> 'src/path.cpp') in  instance at 0x7fc85b3c4638>> ignored
> Exception exceptions.OSError: (2, 'No such file or directory', 
> 'src/backend_gdk.c') in  > ignored
> Exception exceptions.OSError: (2, 'No such file or directory', 
> 'src/backend_agg.cpp') in  > ignored
>
>
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] how much is dvipng needed?

[Sandro Tosi]

Hello guys,
since I'm going to update debian matplotlib pkg to 0.98.5 I'd like to
know how much dvipng lib is needed to let matplotlib work.

This is because adding a strong dependency on it (so that it's
installed everytime you install mpl) will take in even texlive, and
all its dependency, amounting in more than 200mb of space (an issue
presents even in ubuntu).

If dvipng (+texlive) is only needed for some "not-so-common"
situations (for example only to print complex math expression) then we
can move it to a wicker dependency, so that it's installed only if
expressly requested by the user (we'll inform users about this
change).

Thanks for the attention,
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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

Re: [matplotlib-devel] error installing matplotlib-0.98.5

[Neal Becker]

Charlie Moad wrote:

> I'm not seeing this on OSX.  Is anyone else experiencing this issue?
> 
> - Charlie
Please see
http://permalink.gmane.org/gmane.comp.python.matplotlib.general/15425



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

Re: [matplotlib-devel] how much is dvipng needed?

[John Hunter]

On Fri, Dec 12, 2008 at 6:21 PM, Sandro Tosi  wrote:
> Hello guys,
> since I'm going to update debian matplotlib pkg to 0.98.5 I'd like to
> know how much dvipng lib is needed to let matplotlib work.

It's strictly optional, for the "usetex" mode, which is not turned on
by default.  Our native mathtext is good enough for most use cases,
and those who want tex rendering can "apt-get install dvipng"

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