matplotlib-devel Mailing List for matplotlib

I'm moving this discussion over to mpl-dev. Its gettin too hairy for the more 
general audience.
On Friday 18 May 2007 12:02:30 pm Alexander Schmolck wrote:
> If I may make another suggestion (I don't have time to volunteer for
> implementing them in the forseeable future, but I might eventually if
> there's interest): Maybe the way configuration is handled could be
> improved:
>
> 1. It seems to me that letting users manipulate some raw dictionary
> (`rcParams`) in order to customize behavior is bad.
>
> Just now, on my first dig into matplotlib I've found a number of bugs
> that result from bad state in rcParams. As a user this has also caused me
> some wasted time, because typos and other illegal param choices are not
> caught early (but are relativley likely, because matplotlib has many and
> complex options).
>
> Using some dedicated class-instance instead of a dict would allow for:
> - automatic conistency checks on setting
> - possibly even change propagation (likely faster and certainly less
> error prone if done right: I'm not sure how many places rcParams dependent
> results apart from the tex-stuff are cached and should be recomputed when
> certain params change, but obviously an push/'event'-based solutin could be
> faster than pull/polling)
> - possibly better performance, because e.g. using immutable values would
> allow identity based checks to see if a rcParam changed and obviate
> the need to copy;
> - convenient doc lookup and searching an display of available
> alternatives (e.g. font-families etc)
> - better factoring of the matplotlibrc parsing and validation see below:
This sounds like a good proposal to me. Some other devs had considered using 
the traits package to address some of these points. Maybe they will comment. 
> 2. It also seems to me that having some custom config file format rather
> than just (a literal-only subset of) python is suboptimal. Why make people
> learn another and more limited syntax when python literals are already
> familiar and both more powerful and easier to use
If someone donated a nickel for every time I have seen this argument on the 
mailing list, we might have enough money to buy John a doughnut.
> (e.g. the latex-preamble 
> setting can't express multiple package options, because param values can't
> contain ',')? 
Thats a pretty big bug. See the disclaimer concerning preamble 
customizations :)
> It would also get rid of the IMO undesirable coupling of 
> string-parsing and type-checking that the validate_* functions do at the
> moment; really setting an rcParam should also do the latter but not the
> former (and guaranteed validation on setting would also avoid the need
> to sprinkle random checks on reading through the code).
>
> IMO it would be much nicer if there was some more declarative way to
> specify options, check their validity on setting and assoicate docs with
> them (sort of like e.g. emcs-custom vars).
>
> Valid files in the old-syntax could be translated automatically quite
> easily, so I don't think it's a compatiblity issue.
These are all good points, most of which have been brought up before. What we 
need is someone with sufficient time and motivation...
Darren

Hi Darren,
I've made the changes you requested and committed it. (I didn't realize
that mpl-data/matplotlibrc was generated from the template -- I actually
already placed a descriptive line of text in the overwritten file.)
I'm attaching a file for the examples/ directory which I'm having
trouble checking in. I'm rushing out the door for a weekend away at the
moment, so if you can check this in, that'd be great, otherwise I'll try
again when I'm back online. I think it might be an issue with the
non-ASCII characters in the file.
I'll also update the wiki page when I get back.
-Andrew
Darren Dale wrote:
> Hi Andrew,
> 
> On Thursday 17 May 2007 10:12:09 pm Andrew Straw wrote:
>> OK, here's the patch! :)
>>
>> Andrew Straw wrote:
>>> Hi All (esp. Darren),
>>>
>>> The attached patch adds unicode support for LaTeX. Given the recent
>>> discussion about adding preambles, I thought I'd run it past here first.
>>> Anyone opposed if I check this in?
> 
> No opposition, but a couple requests. Would you add a commented out line to 
> matplotlibrc.template, with some brief discussion if you think it is 
> appropriate? Also, lets make it a policy that the custom preamble always 
> appears after all other preambles in texmanager amd backend_ps.
> 
>>> Note that I specifically added the rcParam text.latex.unicode to enable
>>> this and a default False value to turn this off by default. I hope this
>>> prevents breakage for folks who don't have the ucs and inputenc latex
>>> packages installed while allowing unicode for those of us that do.
> 
> I have never used unicode with latex, will you add a nugget to 
> http://www.scipy.org/Cookbook/Matplotlib/UsingTex?
> 
> Darren

Excellent, Perry.
Thanks for your help,
Mark
On 5/18/07, Perry Greenfield <pe...@st...> wrote:
>
> We don't have anyone at the moment that can work on it, but I think
> on the order of a month or two we can. We see similar issues too. So
> if someone can deal with it before then, that would be great, but
> we'll tackle it before very long if not.
>
> Perry
>
> On May 18, 2007, at 7:21 AM, Mark Bakker wrote:
>
> > This is a well known problem, reported about a year or so ago.
> > John Hunter tried to get some help on the (TK?) mailinglist, but I
> > don't think anybody responded. I looked into it too, but couldn't find
> > a solution (that doesn't mean much, except for that it is not
> > blatently obvious).
> > It would be great if somebody would know how to fix this.
> > Strangely enough I have written a GUI myself where I use the toolbar,
> > and the save button works fine there.
> > Mark
>
>

Hi Andrew,
On Thursday 17 May 2007 10:12:09 pm Andrew Straw wrote:
> OK, here's the patch! :)
>
> Andrew Straw wrote:
> > Hi All (esp. Darren),
> >
> > The attached patch adds unicode support for LaTeX. Given the recent
> > discussion about adding preambles, I thought I'd run it past here first.
> > Anyone opposed if I check this in?
No opposition, but a couple requests. Would you add a commented out line to 
matplotlibrc.template, with some brief discussion if you think it is 
appropriate? Also, lets make it a policy that the custom preamble always 
appears after all other preambles in texmanager amd backend_ps.
> > Note that I specifically added the rcParam text.latex.unicode to enable
> > this and a default False value to turn this off by default. I hope this
> > prevents breakage for folks who don't have the ucs and inputenc latex
> > packages installed while allowing unicode for those of us that do.
I have never used unicode with latex, will you add a nugget to 
http://www.scipy.org/Cookbook/Matplotlib/UsingTex?
Darren

We don't have anyone at the moment that can work on it, but I think 
on the order of a month or two we can. We see similar issues too. So 
if someone can deal with it before then, that would be great, but 
we'll tackle it before very long if not.
Perry
On May 18, 2007, at 7:21 AM, Mark Bakker wrote:
> This is a well known problem, reported about a year or so ago.
> John Hunter tried to get some help on the (TK?) mailinglist, but I
> don't think anybody responded. I looked into it too, but couldn't find
> a solution (that doesn't mean much, except for that it is not
> blatently obvious).
> It would be great if somebody would know how to fix this.
> Strangely enough I have written a GUI myself where I use the toolbar,
> and the save button works fine there.
> Mark

This is a well known problem, reported about a year or so ago.
John Hunter tried to get some help on the (TK?) mailinglist, but I
don't think anybody responded. I looked into it too, but couldn't find
a solution (that doesn't mean much, except for that it is not
blatently obvious).
It would be great if somebody would know how to fix this.
Strangely enough I have written a GUI myself where I use the toolbar,
and the save button works fine there.
Mark
> Date: 2007年5月10日 13:31:18 -0600
> From: "Urvashi R.V." <urv...@gm...>
>
> Hi,
>
> When the "save" button is used on the matplotlib tkagg toolbar, it
> uses the "Tk" "asksavefilename" object from the "tkFileDialog" class,
> to pop up a little window that allows you to select the name and type
> of file to save. This function internally calls "figure.destroy()".
> and the currently active figure gets destroyed (but it is still visible
> and memory is not freed). The next plot then creates a new figure
> window with the same figure._num as the previous.
>
> see...
> backend_tkagg.py : line 621
> -> class NavigationToolbar2TkAgg :: def save_figure(...)
> (callback for the toolbar.bsave button)
>
> The "asksavefilename" function call, triggers Gcf.destroy(). This can
> be seen by placing a print statement in
> _pylab_helpers.py : line 16
> -> class Gcf :: def destroy(num)

OK, here's the patch! :)
Andrew Straw wrote:
> Hi All (esp. Darren),
>
> The attached patch adds unicode support for LaTeX. Given the recent
> discussion about adding preambles, I thought I'd run it past here first.
> Anyone opposed if I check this in?
>
> Note that I specifically added the rcParam text.latex.unicode to enable
> this and a default False value to turn this off by default. I hope this
> prevents breakage for folks who don't have the ucs and inputenc latex
> packages installed while allowing unicode for those of us that do.
>
> -Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi All (esp. Darren),
The attached patch adds unicode support for LaTeX. Given the recent
discussion about adding preambles, I thought I'd run it past here first.
Anyone opposed if I check this in?
Note that I specifically added the rcParam text.latex.unicode to enable
this and a default False value to turn this off by default. I hope this
prevents breakage for folks who don't have the ucs and inputenc latex
packages installed while allowing unicode for those of us that do.
-Andrew

Pierre GM wrote:
[...]
> 
> David, I wouldn't speak about compatibility, just about bugs: the problem was 
> in the implementation of .max() w/ maskedarray. The origin of the problem was 
> (is still) in umath.maximum.reduce that doesn't accept axis=None, so a numpy 
> problem ;). But I agree: switching may have some subtle consequences in 
> matplotlib (nothing that can't be quickly fiexed, however). What do Eric 
> Firing, John Hunter and the other mpl developer think ?
I think this would be a good time to make the switch. We are going to 
be stripping out the Numeric and numarray support, so let's finalize the 
new ma capabilities at the same time. I think that maskedarray is 
actually closer to being a drop-in replacement for ndarray than ma is, 
and I think it will be easier to work with. I am confident that any 
problems can be solved easily. A 15% speed penalty doesn't bother me; 
presumably it can be reduced later.
> 
> My only request would be for more users ! That's the only way I can find how 
> to improve maskedarray.
Moving maskedarray from the sandbox into svn numpy will make it easier 
for mpl devels to use it while doing and testing the mpl numpification.
(I won't be able to work on this until June.)
I suppose that it will be necessary for mpl to support both for a while, 
unfortunately, but I haven't thought this through carefully.
Eric