matplotlib-devel Mailing List for matplotlib

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:


    Marcin> And the same about patches?  I like SF tracker.  It has
    Marcin> "Send email on new submission to" option.  Perhaps it
    Marcin> would be a good idea to send e-mail to devel list?

Yes, this is also a good idea.

JDH

>>>>> "Rolf" == Rolf Wester <rol...@il...> writes:

    Rolf> Hi, I have installed matplotlib-0.80 on WinXP and when I run
    Rolf> a Python script that calls pylab.plot several times after a
    Rolf> while the program ends with the error message listed
    Rolf> below. I inserted some print statements into backend_agg.py
    Rolf> and text.py (code snippets see below). As far as I can see
    Rolf> the problem is with the function xy_tup that returns
    Rolf> (70.0555555556, -3509680569.77) when given the input
    Rolf> (-0.030476944389471572, -0.012864052691159839).

It looks like your canvas width and height are really large if I am
reading your traceback properly -- are you sure your figure size and
dpi params are set right?  It would help immensely if you can come up
with a stand-alone script that exposes the bug.  If you can, report it
to the sourceforge bug tracker, along with the output of
--verbose-helpful and your rc file if it is customized and we can
probably track it down.

Absent a script which produces the bug, it is very hard to fix these
problems, even with the nice tracebacks you've provided.  Because many
people use mpl 0.80 on windows XP and haven't reported this problem, I
wonder if there is a bug in the script you are using or in your
configuration file.


Thanks,
JDH

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:

    Marcin> It is attached. There are two comments-questions in the
    Marcin> patch, please delete them after reading.  And at the end
    Marcin> of this patched legend() method there is a line handles =
    Marcin> flatten(handles) If handles are not already flat, I think
    Marcin> something may go wrong earlier in this method (?).

As for the flatten stuff, all I can say is it involves how flatten
works in the presence of generators (the plot code ultimately uses a
generator when building a list of lines) and John Gill and I worked
pretty hard to make this robust and correct at the legend sprint at
pycon.  In the absence of a specific use case that breaks legend, I'm
assuming this code is correct.


    Marcin> Thanks for explaination. I guessed it works like this
    Marcin> after finding what 'hold' is in Matlab. I just meant to
    Marcin> say that such explaination could be helpful in mpl
    Marcin> documentation.

Done.

    Marcin> Yes, I've seen all the examples and they are very
    Marcin> useful. However wxPython demo is more useful than just a
    Marcin> set of examples: examples are grouped in categories, every
    Marcin> example has a detailed documentation about introduced
    Marcin> features. From wx demo overview:

Yes, this would be useful.  Any documentation you would like to add as
header strings to the examples will be most welcome!

JDH

>>>>> "Florent" == Florent Rougon <f.r...@fr...> writes:

    Florent> So, bar() does what I need. There is still one somewhat
    Florent> weird thing, however: barh() (as the barv() I wrote based
    Florent> on barh()) works with the *centers* of the bars
    Florent> (y-coordinates for barh(), x-coordinates for barv())
    Florent> whereas bar() expects the *left* x-coordinates of the
    Florent> bars in its first argument. This is not a drama, but a
    Florent> bit inconsistent.

Yes, this is a historical artifact.  bar was implemented first (and
wrong) and the coords represented left rather than center.  barh came
along later and decided rather than follow bar's mistake lead (a
foolish consistency and all that), it would do it right and bar could
be fixed later in a way that hopefully preserves backward
compatibility (eg an rc param and a warning) for a while.

This would all be fairly trivial except table is based on bar, and the
table layout is pretty complex.  I "fixed" bar but broke table, and
seeing no easy fix, unrolled the changes to bar. And that is where I
left this problem last time I looked.

Would you mind filing a bug report on the sf site, with example code
that shows the different behaviors of bar and barv, including a link
to this discussion.

Thanks,
JDH