matplotlib-devel Mailing List for matplotlib (Page 3)

Darren Dale wrote:
[...]
> 
> I'll start working on an option in svn-mpl to turn the new system on and wrap 
> it in an rcParams-like object. Then maybe we can convince a few devs to try 
> using the new system for a while.
I will be happy to take a look and try it out. It certainly sounds like 
a major improvement over the previous system.
Eric

John Hunter wrote:
> On 7/25/07, Michael Droettboom <md...@st...> wrote:
>
>> It's been fun working through this. You may want to check out
>> mathtext_examples.py in my branch for examples that exercise other new
>> features.
>
> Maybe you haven't committed it?
Doh! Try now.
Cheers,
Mike

On 7/25/07, Michael Droettboom <md...@st...> wrote:
> It's been fun working through this. You may want to check out
> mathtext_examples.py in my branch for examples that exercise other new
> features.
Maybe you haven't committed it?
johnh@flag:examples> pwd
/home/titan/johnh/python/svn/matplotlib/mathtext_mgd/examples
johnh@flag:examples> svn up
At revision 3613.
johnh@flag:examples> ls mathtext*.py
mathtext2_demo.py mathtext_demo.py
JDH

John Hunter wrote:
> On 7/25/07, Michael Droettboom <md...@st...> wrote:
>> The new mathtext with an underlying TeX-like box model is passing all
>> unit tests for all backends. I'm now at a point where I'd like to merge
>> this back into the trunk, but I'd like some feedback as to how to best
>> deal with the backward-incompatible change wrt font changes.
>
> This is really, really cool stuff. On a mostly unrelated note, do
> you thing the TeX box layout algorithms could be used to solve more
> general figure layout problems, eg positioning axes and tick labels,
> etc?
That seems like it would be worth some thought, but nothing springs to mind.
>
> I think we should strive for TeX correctness and should not support
> the incorrect usage in a
> compatibility mode. The improvements you've made are sufficiently
> important that mathtext users will gladly accept a little breakage.
> We can put up a news flash on the main site, and note the changes in
> the CHANGELOG and API_CHANGES file, as well as in the mathtext_demo.
Sounds good.
>
> I have a few questions about the mathtext_demo.py. A number of these
> are probably just related to the bakoma fonts, which are just so
> horrific it pains me to look at them (like why is the s in sin so much
> lighter?)
I think that's due to lack of hinting in the font. If you generate a 
.ps and zoom in enough, they do look much better.
>
> * The i in the {i+1} subscript looks too small. It also looks to
> small compared to the j in the \Delta_i^j example. Are the i and j
> coming from the same file, and do you have any idea why it is small?
Hmmm. Both i's look identical here. Perhaps an optical illusion from 
the rotation? I agree, in general, though that there is some tweaking 
to font sizes and positioning that still needs to be done. Since 
mathtext always uses the same glyph outlines regardless of font size, 
unlike TeX which changes the actual shapes in response to font size, 
some compromises had to be made in that regard.
>
> * There is a lot of space between the \prod symbol and the rest of
> the expression and between the \mathcal{R} and the \prod symbol --
> what controls this? It looks like it is being affected by the wide
> \prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
> TeX handles it? Since the subscript is under the prod, it seems like
> it's width should not affect the spacing of the R and the sin
Yes, as others have pointed out, this is normal TeX behavior. The 
subscript affects the width of the entire vertical list. If it didn't, 
it could bump into subscripts before and after. (Think of $R_i 
\prod_{i=\alpha_{i+1} $-- the subscripts would run together). The TeX 
box model only supports a strict hierarchy of boxes within boxes 
(excepting shifting and kerning), and doesn't ever do any checks for 
boxes overlapping boxes with other parents. (It's really a lot less 
smart than many, myself included, assume.) The hacks that Gael and 
Jouni suggest may help, but aren't currently supported by the mathtext 
parser (though they could be fairly easily). Exposing some of the 
low-level commands for TeX gurus might be useful in general, though I 
worry (somewhat abstractly) that since they will probably never behave 
100% like TeX, they will just disappoint.
> * Have you given any thought to the "cross font" kerning problem.
> Eg, if the parens comes from one file, and the 2 from another and the
> \pi from a 3rd, how to we kern "( 2 \pi )?
I haven't looked at how TeX does this yet, though I suspect the job is 
easier there, being that it has its own universe of math fonts that are 
built to work together. The current implementation does kern 
consecutive characters of the same font and fontsize, but that's all. I 
have noticed, though, that TeX kerns a lot less in math mode than one 
might expect. For instance, $AVA$ isn't kerned at all (presumably to 
keep variables looking like separate entities), though $\rm AVA$ is. 
>
> * have you succeeded in get any non bakoma fonts to work, eg with the
> UnicodeFont code?
No, I haven't tried that yet. I've certainly broken the UnicodeFont 
classes by changing the API a little bit. Is there a font you would 
suggest that was known to work with the old mathtext that I should test 
with?
>
> Anyway, this is really great stuff. Thanks!
It's been fun working through this. You may want to check out 
mathtext_examples.py in my branch for examples that exercise other new 
features.
Cheers,
Mike

On 7/25/07, Darren Dale <dd...@co...> wrote:
> Not so much. I just wanted to give thorough feedback (No, I'm not *trying* to
> drive you crazy).
Don't worry, the damage was done long ago :)
More seriously, I do appreciate the feedback. It was very good to
have someone at the other end checking/breaking things (as well as the
conversation with John, to clarify a minimum set of functionality that
could make us all happy).
> > I guess it's now up to you guys (a collective MPL-dev you) to decide
> > if you want to use this system or not. We'll slowly try to replace
> > the ipython config with this, which I'm sure will uncover yet a few
> > more problems. But overall I'm quite happy with what we've got, and
> > I think the system is flexible enough that we should be able to solve
> > whatever remains.
>
> I'll start working on an option in svn-mpl to turn the new system on and wrap
> it in an rcParams-like object. Then maybe we can convince a few devs to try
> using the new system for a while.
Yup. Let me know of anything you need.
Cheers,
f

On Wed, Jul 25, 2007 at 12:09:01PM -0500, John Hunter wrote:
> As for code readability, I'll also add that as a traits newbie, I am
> probably making things harder than necessary. But there are a lot of
> gotchas with traits usage, particularly in the area of instantiation,
> because you can easily get bitten by shared class level data
> structures, especially in the presence of sync_traits.
One thing that is convenient when working with Traits, is that there
already are established coding conventions. The problem when coding with
metaclasses is that it is easy to prduce very beautiful code that is hard
to read for the newcomer (I have fallen in that trap). Traits are nothing
more but a metaclass, they also have this problem. But if they become
wildy used this problem goes away.
Gaël

On 7/24/07, Ken McIvor <mc...@ii...> wrote:
> Since my original comment about traits I have been working hard to
> put my money where my mouth is. Attached is an experimental
> rendering system with an alternative transform architecture that does
> not require attribute change notification. Please let me know what
> you think, everybody.
Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring
you. Real life has made some demands on my time of late, and probably
will until next week, but I was able to download, read through and
test your code. It looks very clean and is an impressive piece of
work. I'll agree with your assessment above that from a code reading
perspective, this looks a bit more digestible that what I have done
using traits. But I don't think that closes the book on the subject
-- for example, I have realized I am introducing too much complexity
and trait forwarding, and I think I know a way to work around this, so
I will be hacking through my version one more time while at the same
time taking a closer look at yours. I also would like to hear more
about the "hard to optimize" part, because that is not intuitively
clear to me.
I confess to being a meta-class ignoramus, so I am intrigued to study
how you handled the canvas primitive cache problem using meta classes.
 How for example, if one modifies a Rectangle object which embodies a
path primitive, would the canvas get the notification to update it's
internal path representation (egg the agg_path_storage)?. With
traits, I use the trait event handling mechanism so that when any of
the box properties (left, width, top, etc...) are modified, the
PathPrimitiveAgg would get a callback. So when the user does
rect.left = 0.1
the agg path knows to update itself. This is pretty cool.
As for code readability, I'll also add that as a traits newbie, I am
probably making things harder than necessary. But there are a lot of
gotchas with traits usage, particularly in the area of instantiation,
because you can easily get bitten by shared class level data
structures, especially in the presence of sync_traits.
vis-a-vis properties vs traits, I second Peter's comment that once
you've written 8,000 setters and getters and manually constructed
properties, you'll probably evolve toward something like traits, w/o
all the features. This is a library that has been bug and performance
vetted in production applications for years, so we should seriously
consider it as a properties alternative. I strongly encourage you to
download Fernando's mplconfig sandbox stuff and try the edit_traits
demo in the presence of a wx enabled traits. He is somewhat blown
away by the fact that he got a sophisticated, nested GUI dialog w/o
writing *any* code. Since you are a committed wx user, you might find
this particularly appealing. But at the end of the day, I think the
*notification* aspect of traits is the killer feature.
I think your approach of working on a display PDF renderer interface
is also a good one, for several reasons. It uses an established
specification instead of a home grown one, and it makes it easier for
us to consider things like integrating with Kiva or Chaco. I am glad
you interpreted my mpl1 sketch in the right vein, as a lab in which
people can advocate ideas as working code. Much more productive than
lots of emails, I think. Hopefully next week we can come to some
consensus and start merging our two lines.
PS: I'm not ignoring you either Peter, but I won't be able to get to
all your questions and comments until a bit later; as you know the
harder problems take longer to address

Gael Varoquaux <gae...@no...>
writes:
> On Wed, Jul 25, 2007 at 11:36:17AM -0500, John Hunter wrote:
>> * There is a lot of space between the \prod symbol and the rest of
>> the expression and between the \mathcal{R} and the \prod symbol --
>> what controls this? It looks like it is being affected by the wide
>> \prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
>> TeX handles it?
>
> AFAIK yes. I correct this with a lot of "\!\!". This is a hack, but it
> gives good results.
Yes, this is how TeX does it. Another hack is to cause the subscript box
to have zero width, which in principle can be done with \makebox[0pt]
(but Google for "mathclap" to find how to make it actually work).
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Michael Droettboom <md...@st...>
writes:
> In the existing mathtext implementation, font style changes affect the
> following group. For example, in $\cal{R} x,ドル only the R will be in
> calligraphic face. In TeX, however, font style markers stay in effect
> until the next font style marker or the end of the enclosing group.
To clarify a little: in Plain TeX people usually write ${\cal R}x,ドル
beginning the group before the font-changing macro. The LaTeX macros
such as \mathcal take an argument: for example, both $\mathcal{R}x$ and
$\mathcal Rx$ cause only R to have the calligraphic font. (The latter is
because of TeX's parsing rules: \mathcal takes one argument, and since
there is no {}-group, the argument consists of the single letter R.)
The old mathtext style font-changing commands behave like the LaTeX
macros but have names like the Plain TeX macros, and the change you
are proposing to merge makes mathtext have both Plain TeX and LaTeX
style commands.
> It's difficult to trap the old 
> case and correct for it, since both are still valid.
Is it easy to detect when a Plain TeX style command is followed by an
opening brace, and output a warning? It is typically not useful to
start a new group right after a font-changing command, so such usage is
more likely to be caused by someone relying on the old behavior.
> Becoming more TeX-like is a good thing, but does breaking existing 
> matplotlib plots warrant some additional care here? Should this be 
> merged into trunk, or onto some other branch where we're going to be 
> breaking a lot of things. It is probably feasible to have a 
> "compatibility" mode for this, but is that (in this particular case) 
> worth the extra maintenance burden?
IMHO this should be merged into trunk, with a warning in case of "\cal{"
if that is feasible, but no other compatibility mode.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Wed, Jul 25, 2007 at 11:36:17AM -0500, John Hunter wrote:
> * There is a lot of space between the \prod symbol and the rest of
> the expression and between the \mathcal{R} and the \prod symbol --
> what controls this? It looks like it is being affected by the wide
> \prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
> TeX handles it?
AFAIK yes. I correct this with a lot of "\!\!". This is a hack, but it
gives good results.
Gaël

On 7/25/07, Michael Droettboom <md...@st...> wrote:
> The new mathtext with an underlying TeX-like box model is passing all
> unit tests for all backends. I'm now at a point where I'd like to merge
> this back into the trunk, but I'd like some feedback as to how to best
> deal with the backward-incompatible change wrt font changes.
This is really, really cool stuff. On a mostly unrelated note, do
you thing the TeX box layout algorithms could be used to solve more
general figure layout problems, eg positioning axes and tick labels,
etc?
> (This was discussed in an earlier thread, but I don't believe a
> conclusion was reached, so I'm summarizing again here.) In the existing
> mathtext implementation, font style changes affect the following group.
> For example, in $\cal{R} x,ドル only the R will be in calligraphic face.
> In TeX, however, font style markers stay in effect until the next font
> style marker or the end of the enclosing group. Therefore, the same
> example would be rendered with both the R and the x in calligraphic
> face. The new mathtext adds LaTeX-style font macros (\mathcal, \mathrm
> etc.) that behave as the old mathtext ones. So the example expression
> could be re-written $\mathcal{R} x$. It's difficult to trap the old
> case and correct for it, since both are still valid.
>
> Becoming more TeX-like is a good thing, but does breaking existing
> matplotlib plots warrant some additional care here? Should this be
> merged into trunk, or onto some other branch where we're going to be
> breaking a lot of things. It is probably feasible to have a
> "compatibility" mode for this, but is that (in this particular case)
> worth the extra maintenance burden?
I think we should strive for TeX correctness and should not support
the incorrect usage in a
compatibility mode. The improvements you've made are sufficiently
important that mathtext users will gladly accept a little breakage.
We can put up a news flash on the main site, and note the changes in
the CHANGELOG and API_CHANGES file, as well as in the mathtext_demo.
I have a few questions about the mathtext_demo.py. A number of these
are probably just related to the bakoma fonts, which are just so
horrific it pains me to look at them (like why is the s in sin so much
lighter?)
 * The i in the {i+1} subscript looks too small. It also looks to
small compared to the j in the \Delta_i^j example. Are the i and j
coming from the same file, and do you have any idea why it is small?
 * There is a lot of space between the \prod symbol and the rest of
the expression and between the \mathcal{R} and the \prod symbol --
what controls this? It looks like it is being affected by the wide
\prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
TeX handles it? Since the subscript is under the prod, it seems like
it's width should not affect the spacing of the R and the sin
 * Have you given any thought to the "cross font" kerning problem.
Eg, if the parens comes from one file, and the 2 from another and the
\pi from a 3rd, how to we kern "( 2 \pi )?
 * have you succeeded in get any non bakoma fonts to work, eg with the
UnicodeFont code?
Anyway, this is really great stuff. Thanks!
JDH

The new mathtext with an underlying TeX-like box model is passing all 
unit tests for all backends. I'm now at a point where I'd like to merge 
this back into the trunk, but I'd like some feedback as to how to best 
deal with the backward-incompatible change wrt font changes.
(This was discussed in an earlier thread, but I don't believe a 
conclusion was reached, so I'm summarizing again here.) In the existing 
mathtext implementation, font style changes affect the following group. 
For example, in $\cal{R} x,ドル only the R will be in calligraphic face. 
In TeX, however, font style markers stay in effect until the next font 
style marker or the end of the enclosing group. Therefore, the same 
example would be rendered with both the R and the x in calligraphic 
face. The new mathtext adds LaTeX-style font macros (\mathcal, \mathrm 
etc.) that behave as the old mathtext ones. So the example expression 
could be re-written $\mathcal{R} x$. It's difficult to trap the old 
case and correct for it, since both are still valid.
Becoming more TeX-like is a good thing, but does breaking existing 
matplotlib plots warrant some additional care here? Should this be 
merged into trunk, or onto some other branch where we're going to be 
breaking a lot of things. It is probably feasible to have a 
"compatibility" mode for this, but is that (in this particular case) 
worth the extra maintenance burden?
Cheers,
Mike

Chris Barker wrote:
> Peter Wang wrote:
> 
>>> Ah! and some good math implementation -- What does Chaco do for 
>>> that?
>>> 
>
> 
>> We've also had this discussion internally a bit. It usually 
>> concludes with us wishing that someone would just port jsmath to 
>> Python, or implement Knuth's TeX layout rules in Python. :)
>> 
>
> It looks like jsmath uses the TeX layout rules, so those are the same 
> thing. If you can do it in JS, you sure should be able to do it in Python!
I currently have a branch (mathtext_mgd), where I am implementing the 
TeX layout model in Python. It does not attempt to reimplement the 
whole kit-and-kaboodle (especially the parser and macros etc.), just the 
box model and some of the math layout algorithms, so it won't support 
the kind of things Gael is suggesting. But the existing adjacency model 
was becoming somewhat of a dead end wrt implementing new features like 
fractions and radicals. Stay tuned -- the code is already beyond 
feature parity with the old implementation, so I expect to merge this 
back into the trunk soon.
Cheers,
Mike

On Tuesday 24 July 2007 11:17:32 pm Fernando Perez wrote:
> On 7/24/07, Darren Dale <dd...@co...> wrote:
> > On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
> > :) That should be plenty of information. One comment: if you load
> > : mplrc2.conf,
> >
> > which includes an mplrc.conf with a bogus key, the error indicates the
> > bad key is in mplrc2.conf. Is that a concern?
>
> It may be a concern to you, I suppose :)
Not so much. I just wanted to give thorough feedback (No, I'm not *trying* to 
drive you crazy).
> I guess it's now up to you guys (a collective MPL-dev you) to decide
> if you want to use this system or not. We'll slowly try to replace
> the ipython config with this, which I'm sure will uncover yet a few
> more problems. But overall I'm quite happy with what we've got, and
> I think the system is flexible enough that we should be able to solve
> whatever remains.
I'll start working on an option in svn-mpl to turn the new system on and wrap 
it in an rcParams-like object. Then maybe we can convince a few devs to try 
using the new system for a while.
Darren

On Wed, Jul 25, 2007 at 03:25:36PM +0900, Bill Baxter wrote:
> > Well I want TeX. I want to be able to do my TeX hacks on my figures. And
> > I do believe there is a lot of work to be done before you can do better
> > than TeX.
> What kind of TeX hacks do you want to use on figures? My TeX hacks
> include mostly things like using negative vspace to squeeze more text
> into a 6-page paper.
"""
\begin{minipage}{3cm}
Multi line \\ tick marker
\end{minipage}
$ x,円e^{x} \underset{x \rightarrow 0}{\thicksim} x $
% That one probably does not run without \usepackage{amsmath} in the preamble
Velocity [{\small m$\cdot$s$^{-1}$}]
\begin{eqarray}
\Phi(v_z) & = &
\int_{z=0}^l 
\int_{v_r=0}^{v_c} 
\underbrace{v_r ,円n ,円B_T(v_r, v_z)}_{\text{\parbox{17ex}{\tiny
flux per surface element}}} 
\;\times
\underbrace{
\begin{cases}
1 \text{~\small if $z/v_z<\tau$} \\
0 \text{~\small elsewhere}
\end{cases}
\!\!\!\!\!\!
}_{\text{Capture condition}}
\times \; 
\underbrace{2 \pi v_r dv_r}_{\text{\parbox{7ex}{\tiny
polar coord.}}} ,円
\underbrace{2\pi,円 r_c}_{\text{\parbox{11ex}{\tiny 2D-MOT perimeter}}} 
dz
\\
& = & 4\pi^2,円v_c^3,円 r_c \; n ,円
(\pi v_\text{max}^2)^{-\slantfrac{3}{2}} 
e^{-v_z^2 /v_\text{max}^2} \big(
e^{-\Gamma_\text{coll} \tau} - e^{-\Gamma_\text{coll} l/ v_z}
\big)
\frac{v_z}{\Gamma_\text{coll}}
\end{eqnarray}
"""
And many more. As you can see this is mainly advanced math with sometimes
some ugly solutions (the parboxes in the underbraces, hum...), but it
works it LaTeX, and I am happy to have this familiar language at hand
when doing figures.
Gaël

On 7/25/07, Chris Barker <Chr...@no...> wrote:
> Peter Wang wrote:
> > We've also had this discussion internally a bit. It usually
> > concludes with us wishing that someone would just port jsmath to
> > Python, or implement Knuth's TeX layout rules in Python. :)
>
> It looks like jsmath uses the TeX layout rules, so those are the same
> thing. If you can do it in JS, you sure should be able to do it in Python!
I took a look at examples on the jsmath webpage, and it looks like the
square-root
placement is glitchy (Firefox on WinXP). If it really is TeX's rules
I wonder what the problem is. Maybe fonts on my end?
--bb

Peter Wang wrote:
>> Ah! and some good math implementation -- What does Chaco do for 
>> that?
> We've also had this discussion internally a bit. It usually 
> concludes with us wishing that someone would just port jsmath to 
> Python, or implement Knuth's TeX layout rules in Python. :)
It looks like jsmath uses the TeX layout rules, so those are the same 
thing. If you can do it in JS, you sure should be able to do it in Python!
 > Currently Chaco2 doesn't have a math markup mechanism, but it was
> fairly trivial for me to port mpl's mathtext to Chaco1. I didn't 
> bother moving that to Chaco2 because I really wanted to figure out a 
> way to do "real" TeX layout that would still fit into the interactive 
> model.
That would be nice. I agree, the Math-as-bitmap approach really isn't 
the way to go, but it does work OK in the meantime!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 7/25/07, Gael Varoquaux <gae...@no...> wrote:
> On Tue, Jul 24, 2007 at 05:31:17PM -0700, Chris Barker wrote:
> > > output when usetex is enabled.
>
> > Ah! and some good math implementation -- What does Chaco do for that? I
> > know I took part in a discussion about it on a Chaco list a few years
> > back -- at the time I argued that you're never going to do as well at TeX.
>
> Well I want TeX. I want to be able to do my TeX hacks on my figures. And
> I do believe there is a lot of work to be done before you can do better
> than TeX.
What kind of TeX hacks do you want to use on figures? My TeX hacks
include mostly things like using negative vspace to squeeze more text
into a 6-page paper.
--bb

On Tue, Jul 24, 2007 at 05:31:17PM -0700, Chris Barker wrote:
> > output when usetex is enabled.
> Ah! and some good math implementation -- What does Chaco do for that? I 
> know I took part in a discussion about it on a Chaco list a few years 
> back -- at the time I argued that you're never going to do as well at TeX.
Well I want TeX. I want to be able to do my TeX hacks on my figures. And
I do believe there is a lot of work to be done before you can do better
than TeX.
My 2 cents,
Gaël

On 7/24/07, Darren Dale <dd...@co...> wrote:
> On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
> :) That should be plenty of information. One comment: if you load mplrc2.conf,
> which includes an mplrc.conf with a bogus key, the error indicates the bad
> key is in mplrc2.conf. Is that a concern?
It may be a concern to you, I suppose :)
Kidding aside, it's not totally trivial to implement the other
solution, which is why I didn't do it (or at least I couldn't think of
a really simple way to do it). In a sense the message is at least
correct, in that it gives the correct origin for the problem, but
users will have to track the inclusion chain themselves.
I'm sure we'll find more issues with complicated recursive setups as
we use this for 'real', and in the process we might find a nice
solution for this as well. For now, it will stay as is (at least
until you send me a patch that fixes it :)
> > Please update and let me know what happens.
> >
> > > It might be nice to be able to deprecate keys
> [...]
> > when you deprecate a Key, simply change it from
> >
> > class Foo(TConfig):
> > somekey = T.Int
> >
> > to
> >
> > somekey = DeprecatedKey
> >
> > where DeprecatedKey is a Trait you declare, whose handler/validator
> > provides the necessary information to the user, sends warnings, it can
> > even set the proper value in the new form of that information if it
> > makes sense, etc.
>
> Great!
Glad you're happy. Traits are a really cool system.
> > > Raising an error for
> > > unrecognized keys might be too extreme. Maybe TConfig should have a
> > > raiseOnKeyError option, so that bad values can be reported with a warning
> > > instead, and the end user can get up and running without fixing it right
> > > away.
>
> This seemed an important point to me at first. But with well-documented,
> auto-generated examples, creating minimal examples or stubs in
> users .matplotlib or .ipython dirs, and a good mechanism for key deprecation,
> now I dont think it will be a big deal to raise errors on bad keys. It should
> be extremely rare.
OK.
I guess it's now up to you guys (a collective MPL-dev you) to decide
if you want to use this system or not. We'll slowly try to replace
the ipython config with this, which I'm sure will uncover yet a few
more problems. But overall I'm quite happy with what we've got, and
I think the system is flexible enough that we should be able to solve
whatever remains.
Thanks for all your feedback and patience with testing!
Cheers,
f

On Jul 24, 2007, at 7:31 PM, Chris Barker wrote:
>> output when usetex is enabled.
>
> Ah! and some good math implementation -- What does Chaco do for 
> that? I
> know I took part in a discussion about it on a Chaco list a few years
> back -- at the time I argued that you're never going to do as well 
> at TeX.
We've also had this discussion internally a bit. It usually 
concludes with us wishing that someone would just port jsmath to 
Python, or implement Knuth's TeX layout rules in Python. :)
Currently Chaco2 doesn't have a math markup mechanism, but it was 
fairly trivial for me to port mpl's mathtext to Chaco1. I didn't 
bother moving that to Chaco2 because I really wanted to figure out a 
way to do "real" TeX layout that would still fit into the interactive 
model.
-Peter

On Tuesday 24 July 2007 7:28:59 pm Fernando Perez wrote:
> On 7/24/07, Darren Dale <dd...@co...> wrote:
[...]
> > Would it be possible to provide some more context for bad
> > sections or keys? 
[...]
> now the exception message reads:
>
>
> TConfigInvalidKeyError: ConfigObj with filename: 'mplrc.conf'
> Contains the following invalid keys: ['bogus']
> The valid keys for this section are: ['maskedarray', 'datapath',
> 'numerix', 'timezone', 'toolbar', 'interactive']
>
> and similarly for invalid sections. At least with the filename and
> the list of bad/good values, people should be able to fend for
> themselves. If not, let them use matlab :)
:) That should be plenty of information. One comment: if you load mplrc2.conf, 
which includes an mplrc.conf with a bogus key, the error indicates the bad 
key is in mplrc2.conf. Is that a concern? 
> Please update and let me know what happens.
>
> > It might be nice to be able to deprecate keys
[...]
> when you deprecate a Key, simply change it from
>
> class Foo(TConfig):
> somekey = T.Int
>
> to
>
> somekey = DeprecatedKey
>
> where DeprecatedKey is a Trait you declare, whose handler/validator
> provides the necessary information to the user, sends warnings, it can
> even set the proper value in the new form of that information if it
> makes sense, etc.
Great!
> > Raising an error for
> > unrecognized keys might be too extreme. Maybe TConfig should have a
> > raiseOnKeyError option, so that bad values can be reported with a warning
> > instead, and the end user can get up and running without fixing it right
> > away.
This seemed an important point to me at first. But with well-documented, 
auto-generated examples, creating minimal examples or stubs in 
users .matplotlib or .ipython dirs, and a good mechanism for key deprecation, 
now I dont think it will be a big deal to raise errors on bad keys. It should 
be extremely rare.
Darren

Darren Dale wrote:
> I need to create plots for qt4 projects at my lab, and I 
> have grown really accustomed to the quality of mpl's eps
So we need QT and EPS.
> output when usetex is enabled.
Ah! and some good math implementation -- What does Chaco do for that? I 
know I took part in a discussion about it on a Chaco list a few years 
back -- at the time I argued that you're never going to do as well at TeX.
These aren't deal-breakers so far -- it sounds like Kiva has at least 
rudimentary QT support -- and I imagine a MPL usetex-like approach could 
be applied to Chaco too (though I'd rather see the DVI parsed and 
rendered by Kiva...)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 7/24/07, Darren Dale <dd...@co...> wrote:
> Thank you for all you have already done, Fernando.
My pleasure. I hope this will be useful for all of us, and that we
can offer to users unified mechanisms for dealing with the various
pieces of the 'scientific python toolkit' puzzle.
> I tried adding a bogus key to mplrc.conf (top level, bogus = 1), and ran the
> mpltest.py script from IPython. The result is posted at the end of this
> message. Would it be possible to provide some more context for bad sections
> or keys? Like the section in which the key is located, the line number, or a
> list of acceptable keys for that section? I think it will be necessary for
> the error to relay the absolute path and file that failed, especially with
> nested configs. We could catch that error, and point to the default conf that
> ships with matplotlib, but a little additional information from tconfig would
> be helpful.
I can't pull line number information from ConfigObj:
http://www.voidspace.org.uk/python/configobj.html#todo
(see last line), but now the exception message reads:
TConfigInvalidKeyError: ConfigObj with filename: 'mplrc.conf'
Contains the following invalid keys: ['bogus']
The valid keys for this section are: ['maskedarray', 'datapath',
'numerix', 'timezone', 'toolbar', 'interactive']
and similarly for invalid sections. At least with the filename and
the list of bad/good values, people should be able to fend for
themselves. If not, let them use matlab :)
Please update and let me know what happens.
> It might be nice to be able to deprecate keys as matplotlib or ipython
> evolves. Even with our current system, when we give a helpful message that a
> key is no longer valid, we will sometimes get questions on the mailing lists
> asking how to fix the problem. Raising an error for unrecognized keys might
> be too extreme. Maybe TConfig should have a raiseOnKeyError option, so that
> bad values can be reported with a warning instead, and the end user can get
> up and running without fixing it right away.
As I told John, you can already do that: when you deprecate a Key,
simply change it from
class Foo(TConfig):
 somekey = T.Int
to
 somekey = DeprecatedKey
where DeprecatedKey is a Trait you declare, whose handler/validator
provides the necessary information to the user, sends warnings, it can
even set the proper value in the new form of that information if it
makes sense, etc.
Use the Traits, Luke :)
Cheers,
f

On Tuesday 24 July 2007 6:43:03 pm Chris Barker wrote:
> Sorry to play devil's advocate here, but the question remains -- MPL
> developers (John, primarily, I suppose):
>
> Why not dump MPL1, and work on a nice pylab-like front end to Chaco,
> while giving the "love" to the Kiva PS, PDF, SVG back-ends (and add GTK
> -- if it's not there)?
>
> Most users, like me, just want something that does the job for us. I
> know I'm going to take a look at Chaco again.
>
> Add the skills of the MPL team to Chaco, and it could really shine!
I could quickly find myself out of my depth on this topic, so I'll just make a 
couple quick points. I need to create plots for qt4 projects at my lab, and I 
have grown really accustomed to the quality of mpl's eps output when usetex 
is enabled.
Darren