matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <ef...@ha...> wrote:
>> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the
>> docs. The Latex is failing with output ending in
>>
>> ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
>> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
>> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
>> (/etc/texmf/tex/latex/config/graphics.cfg)))
>> (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
>> ! Extra \fi.
>> l.62 \fi\fi
>>
>>
>> Is anyone else getting this? Is there something else I need to clean
>> out in order to make it work now?
> 
> Try again, and make sure you reinstall mpl from HEAD? There were a
> couple of bugs in the matplotlib.mlab.cohere math string that was
> causing an error on my box
> 
> C_{xy} = \\frac{|P_{xy}|^2}{P_{xx}P_{yy}}
> 
> It looks like I forgot to commit the change (now in r6289).
I did a build and install of mpl from a clean checkout, went to the doc 
subdir, and ran "python make.py". It failed in exactly the same place 
as before (but took quite a while to get there).
Sphinx is installed as Sphinx-0.5dev_20081020-py2.5.egg.
The line Latex is complaining about is in sphinx.sty. I found that by 
typing "E" after the Latex "?" output; I could never have figured it out 
from the actual Latex output preceding the "?".
Changing the \fi\fi to \fi fixes it, at least with respect to building 
mpl docs.
I filed it as bug 4166.
Eric

On Tue, Oct 21, 2008 at 3:31 AM, Manuel Metz <mm...@as...> wrote:
> David Huard wrote:
>> On Mon, Oct 20, 2008 at 10:19 AM, John Hunter <jd...@gm...> wrote:
>>> On Mon, Oct 20, 2008 at 9:01 AM, David Huard <dav...@gm...> wrote:
>>>
>>>> I would oppose any change to histogram calling convention that does not
>>>> fix a critical bug. I agree that using a built-in name as an argument is
>>>> a bug, but I believe it is the lesser evil compared to asking users to
>>>> change their code
>>>> again.
>>
>> It may not have been clear enough, but let me clarify that I was
>> opposing a change to numpy.histogram, not meddling in matplotlib's
>> hist.
>
> David,
>
> the only thing is that *if* we change the keyword in matplotlib, we
> should change it to the same keyword that will (probably) be in numpy.
>
> Put it the other way: I think it would be good to agree on a new keyword
> ("binrange", "cliprange", ...) and then change it gently in both
> projects, numpy and matplotlib, as John suggested (or alternatively
> leave the keyword as is, and use the arange workaround, but I personally
> don't like this idea).
>
> Cheers,
> Manuel
>
Hi Manuel, John and Eric,
What was the time line you had in mind for the change ?
My main concern is to avoid antagonizing the folks who were annoyed by
the semantic change to histogram. Some of them might not be happy to
go back and make another change to histogram in their code so soon
after having dealt with the `new` keyword, even if you are gentle
about it.
My second concern is to avoid breaking the interface in a minor
release. This would mean waiting for NumPy 2.0 before completely
removing the range argument.
David
>> Cheers,
>> David
>>
>>> I think in this case we have to change it, but we can do it gently.
>>> Ie, for a release cycle, if we detect "range" in the kwarg case, we'll
>>> set the correct kwarg, eg "binrange", issue a warning, but not raise
>>> an error. That way users can fairly easily change their code w/o
>>> breakage. Whoever does the deprecation should note the date and
>>> version of the deprecation warning, so we will know when enough time
>>> and releases have passed to remove range entirely.
>>>
>>> JDH
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <ef...@ha...> wrote:
> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the
> docs. The Latex is failing with output ending in
>
> ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
> (/etc/texmf/tex/latex/config/graphics.cfg)))
> (/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
> ! Extra \fi.
> l.62 \fi\fi
>
>
> Is anyone else getting this? Is there something else I need to clean
> out in order to make it work now?
Try again, and make sure you reinstall mpl from HEAD? There were a
couple of bugs in the matplotlib.mlab.cohere math string that was
causing an error on my box
 C_{xy} = \\frac{|P_{xy}|^2}{P_{xx}P_{yy}}
 It looks like I forgot to commit the change (now in r6289).
JDH

I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the 
docs. The Latex is failing with output ending in
) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/etc/texmf/tex/latex/config/graphics.cfg)))
(/usr/share/texmf-texlive/tex/plain/misc/pdfcolor.tex)
! Extra \fi.
l.62 \fi\fi
Is anyone else getting this? Is there something else I need to clean 
out in order to make it work now?
Thanks.
Eric

jd...@us... wrote:
> Revision: 6288
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6288&view=rev
> Author: jdh2358
> Date: 2008年10月21日 15:26:22 +0000 (2008年10月21日)
> 
> Log Message:
> -----------
> restored the support for multiple pyplots that I broke earlier
>
> def set_xlim(self, xmin=None, xmax=None, emit=True, **kwargs):
> """
> @@ -1944,7 +1944,7 @@
> """
> Get the y-axis range [*ymin*, *ymax*]
> """
> - return self.viewLim.intervaly
> + return tuple(self.viewLim.intervaly)
John,
It might be worth adding a comment in the code as to why a tuple is 
needed here.
Eric

John Hunter-4 wrote:
> 
> _validate_standard_backends = ValidateInStrings('backend',
> all_backends, ignorecase=True)
> def validate_backend(s):
> if s.startswith('module://'): return s
> else: return _validate_standard_backends(s)
> 
> 
> Should work...
> 
Thanks. Now matplotlib.use('module://...') works.
(The -d option still doesn't, but I don't need it.)
Jason
-- 
View this message in context: http://www.nabble.com/How-to-add-a-new-backend--tp20089848p20092273.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Tue, Oct 21, 2008 at 9:14 AM, jason_h <had...@ym...> wrote:
> Unfortunately that doesn't work for me. I get a "ValueError: Unrecognized
> backend string "module://mybackend"" in rcsetup.py. Any other suggestions?
> Matplotlib ist version 0.98.3.
Hmm, strangely, the rcsetup function was reverted and as you note, is
broken, I just fixed it in svn to respect the flag, and tested with
the use directive and -d, both of which worked for me. If you don't
want to update to svn HEAD, you can edit rcsetup.py on your system and
replace::
 validate_backend = ValidateInStrings('backend', all_backends,
ignorecase=True)
with::
 _validate_standard_backends = ValidateInStrings('backend',
all_backends, ignorecase=True)
 def validate_backend(s):
 if s.startswith('module://'): return s
 else: return _validate_standard_backends(s)
Should work...
JDH

John Hunter-4 wrote:
> 
> On Tue, Oct 21, 2008 at 8:40 AM, John Hunter <jd...@gm...> wrote:
> import matplotlib
> matplotlib.use('module://my_backend')
> 
Unfortunately that doesn't work for me. I get a "ValueError: Unrecognized
backend string "module://mybackend"" in rcsetup.py. Any other suggestions?
Matplotlib ist version 0.98.3.
Here is the output:
$ python
Python 2.5.1 (r251:54863, Mar 7 2008, 03:41:45) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.use("module://mybackend")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.5/site-packages/matplotlib/__init__.py", line 809,
in use
 rcParams['backend'] = name
 File "/usr/lib/python2.5/site-packages/matplotlib/__init__.py", line 588,
in __setitem__
 cval = self.validate[key](val)
 File "/usr/lib/python2.5/site-packages/matplotlib/rcsetup.py", line 49, in
__call__
 % (self.key, s, self.valid.values()))
ValueError: Unrecognized backend string "module://mybackend": valid strings
are ['ps', 'Qt4Agg', 'FltkAgg', 'GTKAgg', 'agg', 'cairo', 'GTK', 'GTKCairo',
'WXAgg', 'TkAgg', 'QtAgg', 'svg', 'pdf', 'CocoaAgg', 'emf', 'gdk',
'template', 'WX']
>>>
Neither does the -d option work. "python --help" says:
...
-d : debug output from parser (also PYTHONDEBUG=x)
...
How is this option related to plotting backends?
Thanks
Jason
-- 
View this message in context: http://www.nabble.com/How-to-add-a-new-backend--tp20089848p20091178.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Tue, Oct 21, 2008 at 8:40 AM, John Hunter <jd...@gm...> wrote:
> If you set the backend to "module://my_backend" where my_backend.py is
> a backend in your PYTHONPATH, matplotlib will load it and use it.
And yes, I forgot to mention, "use" works as well
 import matplotlib
 matplotlib.use('module://my_backend')
and the syntax for the -d flag was wrong in my last email (it is
"module://" not "file://"), it should read::
 > python simple_ploy.py -d module://my_backend
JDH

On Tue, Oct 21, 2008 at 8:04 AM, jason_h <had...@ym...> wrote:
>
> Hello,
> we want to add a new backend for some specific XML format.
>
> Can I find somewhere a sort of How-To documentation about the required
> steps?
>
> In particular I want to avoid modifying the matplotlib installation which
> resides in system directories which not every user has access to. Is it
> possible to extend the backend base class to a full backend implementation
> located below my home directory, and then have matplotlib use this backend?
>
> How would I tell matplotlib about my new class, and how do I prepare things
> so that a simple
> matplotlib.use('MyXML')
> will plot in our file format?
If you set the backend to "module://my_backend" where my_backend.py is
a backend in your PYTHONPATH, matplotlib will load it and use it.
You can also use the -d flag, eg
 > python simple_ploy.py -d file://my_backend
Let us know how it goes!
JDH

Hello,
we want to add a new backend for some specific XML format.
Can I find somewhere a sort of How-To documentation about the required
steps?
In particular I want to avoid modifying the matplotlib installation which
resides in system directories which not every user has access to. Is it
possible to extend the backend base class to a full backend implementation
located below my home directory, and then have matplotlib use this backend?
How would I tell matplotlib about my new class, and how do I prepare things
so that a simple
matplotlib.use('MyXML')
will plot in our file format?
Thanks
Jason
-- 
View this message in context: http://www.nabble.com/How-to-add-a-new-backend--tp20089848p20089848.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hello list (especially Erik, who can fix this I hope) -
I have had problems with shared axes, especially when one of the axis has an
aspect ratio that is set 'equal'. It has been discussed on the list before
(mostly with Erik Firing), but it hasn't been fixed yet. What I want to do
is have two plots. The top plot has an aspect ratio that is 'equal'. The
idea is to have a contour plot in the top figure, while the bottom figure
gives a cross-sectional picture of what I am plotting. This used to work
well (quite some time ago), including zooming and such. But now I cannot
plot it at all, let alone zoom.
My first problem is when I add a subplot with a shared x-axis, it changes
the limits on the original x-axis. That seems to be a bug:
ax1 = subplot(211)
plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2.
subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1.
After all, the new subplot shares the axis with the existing subplot, so why
doesn't it copy the axis limits from that subplot?
But the bigger problem occurs when I want the aspect ratio of one of the
first axis to be 'equal'.
ax1 = subplot(211,aspect='equal')
plot([1,2,3])
subplot(212,sharex=ax1)
The second subplot is added, but the length of the graph is not the same as
for the first subplot. It also resets the xlimits to go from 0 to 1, as
before, which means the first subplot becomes unreadable (it still enforces
'equal' in the first subplot by changing the limits of the y-axis). When I
now change the limits on the x-axis, the aspect ratio is not equal anymore
ax1.set_xlim(0,2)
draw()
Thanks for your help. I am willing to help in testing any changes.
Best regards, Mark

David Huard wrote:
> On Mon, Oct 20, 2008 at 10:19 AM, John Hunter <jd...@gm...> wrote:
>> On Mon, Oct 20, 2008 at 9:01 AM, David Huard <dav...@gm...> wrote:
>>
>>> I would oppose any change to histogram calling convention that does not
>>> fix a critical bug. I agree that using a built-in name as an argument is
>>> a bug, but I believe it is the lesser evil compared to asking users to
>>> change their code
>>> again.
> 
> It may not have been clear enough, but let me clarify that I was
> opposing a change to numpy.histogram, not meddling in matplotlib's
> hist.
David,
 the only thing is that *if* we change the keyword in matplotlib, we 
should change it to the same keyword that will (probably) be in numpy.
Put it the other way: I think it would be good to agree on a new keyword 
("binrange", "cliprange", ...) and then change it gently in both 
projects, numpy and matplotlib, as John suggested (or alternatively 
leave the keyword as is, and use the arange workaround, but I personally 
don't like this idea).
Cheers,
 Manuel
> Cheers,
> David
> 
>> I think in this case we have to change it, but we can do it gently.
>> Ie, for a release cycle, if we detect "range" in the kwarg case, we'll
>> set the correct kwarg, eg "binrange", issue a warning, but not raise
>> an error. That way users can fairly easily change their code w/o
>> breakage. Whoever does the deprecation should note the date and
>> version of the deprecation warning, so we will know when enough time
>> and releases have passed to remove range entirely.
>>
>> JDH
>>
>