matplotlib-devel Mailing List for matplotlib

On Wed, Apr 15, 2009 at 2:04 PM, Reinier Heeres <re...@he...> wrote:
> Hi Fernando,
>
> This is a known issue, and I hope to resolve it soon...
>
> Thanks for reporting though; if you notice any other problems, please
> let me know!

Will do, and I'll be happy to test as needed.

f

Hi Fernando,

This is a known issue, and I hope to resolve it soon...

Thanks for reporting though; if you notice any other problems, please
let me know!

Regards,
Reinier

On Wed, Apr 15, 2009 at 7:01 PM, Fernando Perez <fpe...@gm...> wrote:
> Hi all,
>
> first, a huge thank you for the recent work on mpl 3d. This is really
> fantastic, and will be a great tool to have for the situations where a
> full 3d viz tool like mayavi isn't quite needed.  Much, much
> appreciated.
>
> Minor buglet report:  when running the demo, if you start rotating the
> figure from the attached screenshot, some of the color planes start
> disappearing at certain angles.  To keep this message from growing too
> large I put the other screenies showing the problem here:
>
> https://cirl.berkeley.edu/fperez/tmp/mplot3_bug/
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>



-- 
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands

Tel: +31 6 10852639

Hi Mike,

On Wed, Apr 15, 2009 at 11:26 AM, Michael Droettboom <md...@st...> wrote:
> Multiline equations are not currently supported by the mathtext engine.
>  It's the alignment stuff that makes it more than just a "throw a vbox
> together".  It's a good feature request -- go ahead and add it to the
> tracker if you're really interested in it -- but I don't know if I'll have
> time to do this myself in the near future.  I'm happy to help show someone
> around the code...

Many thanks for the info.  I did file it here, so you guys can track
it for when someone has a chance to tackle it:

https://sourceforge.net/tracker/?func=detail&aid=2766156&group_id=80706&atid=560723

> Of course, in your case, you could also investigate one of the other math
> rendering directives included with Sphinx.

For now, that seems the most prudent course of action for us, since I
don't think we can tackle the mpl code right now.

Best,

f

Multiline equations are not currently supported by the mathtext engine.  
It's the alignment stuff that makes it more than just a "throw a vbox 
together".  It's a good feature request -- go ahead and add it to the 
tracker if you're really interested in it -- but I don't know if I'll 
have time to do this myself in the near future.  I'm happy to help show 
someone around the code...

Of course, in your case, you could also investigate one of the other 
math rendering directives included with Sphinx.

Mike

Fernando Perez wrote:
> Hi all,
>
> in the NIPY documentation, we're heavily taking advantage of mpl's
> math support, and for the most part it's working great. But having it
> in there, we may have gotten a bit carried away... If you look at this
> page:
>
> http://neuroimaging.scipy.org/site/doc/manual/html/users/glm_spec.html
>
> its reST sources here:
>
> http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/glm_spec.txt
>
> Contain text like:
>
> /begin quote
> """
> Typically, the events occur in groups, say odd events are labelled
> *a*, even ones *b*. We might rewrite this as
>
> .. math::
>
>    E = \delta_{(t_1,a)} + \delta_{(t_2,b)} + \delta_{(t_3,a)} + \dots +
>    \delta_{t_{10},b}
>
> This type of experiment can be represented by two counting processes
> :math:`(E_a, E_b)` defined as
>
> .. math::
>
>    \begin{aligned}
>    E_a(t) &= \sum_{t_j, \text{$j$ odd}} 1_{\{t_j \leq t\}} \\
>    E_b(t) &= \sum_{t_j, \text{$j$ even}} 1_{\{t_j \leq t\}}
>    \end{aligned}
>
> These delta-function responses are effectively  events of duration 0
> and infinite height.
>
> """ / end quote
>
> In the final PDF
> (http://neuroimaging.scipy.org/site/doc/manual/nipy.pdf) that all
> renders fine, since it's 'real' latex doing the work.  However, the
> HTML linked above renders the first equation fine, while the multiline
> one doesn't work.
>
> Is this something possible with today's MPL but where we are just not
> making the right calls, or is it a missing feature.  If the latter, is
> it realistic to expect it to be added, or should we rather plan for
> avoiding such type of typesetting in our docs or switching math
> engines for the html docs?  Or is the feature 'almost there' but
> slightly buggy?
>
> Any hints much appreciated, I just wasn't sure whether this would be a
> bug report, feature request or just seeking advice...
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

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

On Wed, Apr 15, 2009 at 11:16 AM, Jouni K. Seppänen <jk...@ik...> wrote:

> One possible reason for weird stuff like this is the way Python searches
> for modules. Say you have been experimenting with calendar stuff, and
> have in your current directory (or somewhere on your search path) a file
> named calendar.py. Then you import matplotlib, and matplotlib imports
> dateutil.rrule, which in turn imports calendar... and your calendar.py
> file gets executed, not the one shipped with Python.

OK, thanks for the info.  I linked to this thread on the bug report,
the OP might track this kind of behavior down with this info.

Cheers,

f

Fernando Perez <fpe...@gm...> writes:

> https://bugs.launchpad.net/ipython/+bug/349634
>
> is a really strange bug report we had from an ipython/pylab user on
> Windows.  I don't have the foggiest idea of how his opening of
> matplotlib with Tk under Windows could open a calendar.  

Wow, that's weird. Matplotlib bundles the dateutil library, which seems
to have some Windows-specific time-zone functionality - perhaps
something it does could trigger opening a calendar window?

One possible reason for weird stuff like this is the way Python searches
for modules. Say you have been experimenting with calendar stuff, and
have in your current directory (or somewhere on your search path) a file
named calendar.py. Then you import matplotlib, and matplotlib imports
dateutil.rrule, which in turn imports calendar... and your calendar.py
file gets executed, not the one shipped with Python.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi all,

in the NIPY documentation, we're heavily taking advantage of mpl's
math support, and for the most part it's working great. But having it
in there, we may have gotten a bit carried away... If you look at this
page:

http://neuroimaging.scipy.org/site/doc/manual/html/users/glm_spec.html

its reST sources here:

http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/glm_spec.txt

Contain text like:

/begin quote
"""
Typically, the events occur in groups, say odd events are labelled
*a*, even ones *b*. We might rewrite this as

.. math::

   E = \delta_{(t_1,a)} + \delta_{(t_2,b)} + \delta_{(t_3,a)} + \dots +
   \delta_{t_{10},b}

This type of experiment can be represented by two counting processes
:math:`(E_a, E_b)` defined as

.. math::

   \begin{aligned}
   E_a(t) &= \sum_{t_j, \text{$j$ odd}} 1_{\{t_j \leq t\}} \\
   E_b(t) &= \sum_{t_j, \text{$j$ even}} 1_{\{t_j \leq t\}}
   \end{aligned}

These delta-function responses are effectively  events of duration 0
and infinite height.

""" / end quote

In the final PDF
(http://neuroimaging.scipy.org/site/doc/manual/nipy.pdf) that all
renders fine, since it's 'real' latex doing the work.  However, the
HTML linked above renders the first equation fine, while the multiline
one doesn't work.

Is this something possible with today's MPL but where we are just not
making the right calls, or is it a missing feature.  If the latter, is
it realistic to expect it to be added, or should we rather plan for
avoiding such type of typesetting in our docs or switching math
engines for the html docs?  Or is the feature 'almost there' but
slightly buggy?

Any hints much appreciated, I just wasn't sure whether this would be a
bug report, feature request or just seeking advice...

Cheers,

f

On Wed, Apr 15, 2009 at 11:03 AM, John Hunter <jd...@gm...> wrote:

> Recently I was trying to diagnose a segfault in Charlie's win32 release
> candidate, and was using dependency walker to step through the _tkagg.pyd
> binary in the egg, and noticed all kinds of funky DLLs that based on their
> name I did not know why they were getting linked in (netapi32.dll,
> dnsapi32.dll, ieframe.dll).  It looks like tk is bringing in a bunch of
> internet related stuff, and maybe one of these is doing something to launch
> the calendar.  Never seen it before though...

Mkay, thanks for the info.  We'll leave this one filed away until some
win32 guru can come to the rescue...

Cheers,

f

Thanks for the report.

As far as I can tell, this has been broken for a long time, at least 
since r3798 (September 2007).  I just hacked at this and arrived at the 
same conclusion John did.

I have an interesting finding about consistency.  For the use case you 
describe, on my machine at least Gtk, Wx and Tk don't add any extension, 
whereas Qt and Qt4 implicitly add an extension.  In all cases, the 
matplotlib backend isn't doing anything to the filename -- it's just 
using the filename handed back from the file dialog.  All of this is 
reasonable, unlike the problem in Fernando's original bug report.  I 
suspect the differences are probably based on differences in HIGs.  This 
wxWidgets bug suggests that not implicitly adding an extension is 
correct behavior for Gtk+.

   http://trac.wxwidgets.org/ticket/9917

Is it worth making this consistent between backends, or is it more 
important for each of the toolkits to feel native in their respective 
worlds.  I'm leaning toward the latter -- mainly because it's less work ;)

These are my versions.  I wonder if different toolkit versions may also 
have different behavior in this regard.
   
wxPython: 2.8.6.1
Gtk+: gtk+: 2.10.9, glib: 2.16.1, pygtk: 2.10.4, pygobject: 2.13.1
Qt: Qt: 3.3.3, PyQt: 3.17.2
Qt4: Qt: 4.3.0, PyQt4: 4.2

Cheers,
Mike

Fernando Perez wrote:
> Howdy.  This is using Tk, svn build from just now:
>
> In [4]: plot([1,2])
> Out[4]: [<matplotlib.lines.Line2D object at 0x31262d0>]
>
> In [5]: savefig('foo')
>
> # Then, click on the 'save' icon in the figure window, and simply type
> 'foo2' in the dialog.  Result:
>
> In [6]: d foo*
> -rw-r--r-- 1 fperez 35100 2009-04-15 10:02 foo2png.png
> -rw-r--r-- 1 fperez 35100 2009-04-15 10:02 foo.png
>
>
> The dialog, instead of adding '.png', is adding 'png.png' to the
> filename.  I'm pretty sure this used to work fine a while ago.
>
> I don't know if the problem exists with all the backends.  Wx at least
> seems to manually add the .png extension in the right place...
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

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

On Wed, Apr 15, 2009 at 12:52 PM, Fernando Perez <fpe...@gm...>wrote:

>
>
> https://bugs.launchpad.net/ipython/+bug/349634
>
> is a really strange bug report we had from an ipython/pylab user on
> Windows.  I don't have the foggiest idea of how his opening of
> matplotlib with Tk under Windows could open a calendar.  I don't have
> windows to test on, but if anyone here has seen this (the problem is
> only seen with MPL) or has any clue, I'd be very grateful for ideas.



Recently I was trying to diagnose a segfault in Charlie's win32 release
candidate, and was using dependency walker to step through the _tkagg.pyd
binary in the egg, and noticed all kinds of funky DLLs that based on their
name I did not know why they were getting linked in (netapi32.dll,
dnsapi32.dll, ieframe.dll).  It looks like tk is bringing in a bunch of
internet related stuff, and maybe one of these is doing something to launch
the calendar.  Never seen it before though...

JDH

On Wed, Apr 15, 2009 at 10:53 AM, John Hunter <jd...@gm...> wrote:

> svn up and give this a test drive under a few different save/extension
> scenarios

Thanks!  So far, looking good...

Take care,

f

On Wed, Apr 15, 2009 at 12:07 PM, Fernando Perez <fpe...@gm...>wrote:

>
>
> The dialog, instead of adding '.png', is adding 'png.png' to the
> filename.  I'm pretty sure this used to work fine a while ago.
>
> I don't know if the problem exists with all the backends.  Wx at least
> seems to manually add the .png extension in the right place...


Hey Fernando,

Thanks for the report.  Apparently there are some longstanding vis-a-vis
extension handling issues with the tk dialog asksaveasfilename that we use.
Eg,

  http://mail.python.org/pipermail/python-list/2002-June/150051.html

I just applied a possible fix which seems to work in my tests -- the fix and
comments are inlined below in case anyone more knowledgeable than tkagg than
I has some feedback::

        # adding a default extension seems to break the
        # asksaveasfilename dialog when you choose various save types
        # from the dropdown.  Passing in the empty string seems to
        # work - JDH
        #defaultextension = self.canvas.get_default_filetype()
        defaultextension = ''
        fname = asksaveasfilename(
            master=self.window,
            title='Save the figure',
            filetypes = tk_filetypes,
            defaultextension = defaultextension
            )

svn up and give this a test drive under a few different save/extension
scenarios

JDH

Hi folks,

this:

https://bugs.launchpad.net/ipython/+bug/349634

is a really strange bug report we had from an ipython/pylab user on
Windows.  I don't have the foggiest idea of how his opening of
matplotlib with Tk under Windows could open a calendar.  I don't have
windows to test on, but if anyone here has seen this (the problem is
only seen with MPL) or has any clue, I'd be very grateful for ideas.

Cheers,

f

Howdy.  This is using Tk, svn build from just now:

In [4]: plot([1,2])
Out[4]: [<matplotlib.lines.Line2D object at 0x31262d0>]

In [5]: savefig('foo')

# Then, click on the 'save' icon in the figure window, and simply type
'foo2' in the dialog.  Result:

In [6]: d foo*
-rw-r--r-- 1 fperez 35100 2009-04-15 10:02 foo2png.png
-rw-r--r-- 1 fperez 35100 2009-04-15 10:02 foo.png


The dialog, instead of adding '.png', is adding 'png.png' to the
filename.  I'm pretty sure this used to work fine a while ago.

I don't know if the problem exists with all the backends.  Wx at least
seems to manually add the .png extension in the right place...

Cheers,

f

Hi all,

first, a huge thank you for the recent work on mpl 3d. This is really
fantastic, and will be a great tool to have for the situations where a
full 3d viz tool like mayavi isn't quite needed.  Much, much
appreciated.

Minor buglet report:  when running the demo, if you start rotating the
figure from the attached screenshot, some of the color planes start
disappearing at certain angles.  To keep this message from growing too
large I put the other screenies showing the problem here:

https://cirl.berkeley.edu/fperez/tmp/mplot3_bug/

Cheers,

f