matplotlib-devel Mailing List for matplotlib

Reinier Heeres wrote:
> Eric, all,
> 
> Here's the latest version of my color map patch. I deferred your
> suggestion #4; perhaps we can fix that later.
> 
> Please let me know what you think; if everybody is ok with it I'll
> push to trunk.
> 
> Regards,
> Reinier
Looks good. I haven't tested it--I trust you have taken care of that. I 
suggest one tiny change, then go ahead and commit:
In your change to cm.py, instead of importing and using the copy module, 
just do this:
+ datad[cmapname] = list(cmapspec)
+ datad[cmapname_r] = list(cmapspec)
+ datad[cmapname_r].reverse()
Simpler, more readable, possibly faster (not that speed matters here).
Thanks again.
Eric

John Hunter wrote:
> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter<jd...@gm...> wrote:
>> According to RobK, you can reconfigure your ubuntu system to turn
>> these off. He suggests:
>>
>> To use autohinting, use the hint in this post, or just run the
>> following command:
>>
>> sudo dpkg-reconfigure fontconfig-config
>>
>> then choose "autohinter", then choose "always", then choose "no"
> 
> If that doesn't work, this guy has more involved instructions on how
> to rebuild ubuntu libfreetype and disable the bytecode patch
> 
> http://ubuntuforums.org/showthread.php?t=84359
OK, I disabled all Ubuntu patches to libfreetype and recompiled and
re-installed it. Unfortunately, I'm still getting the same failures.
Then I additionally installed fontconfig-config and did the
dpkg-reconfigure fontconfig-config step, setting everything to "Never".
Same failures.
These font errors make me unhappy. I think we should test some very
simple pure libfreetype C program outputs generated on the various
machines. I've just been playing with ftview, but that doesn't seem to
have a command-line interface to save directly to a file.
-Andrew

John Hunter wrote:
> On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jd...@gm...> wrote:
> 
>> OK, I figured this out. The new failure was on formatter4, not
>> formatter5. I didn't see that when I posted earlier. It turns out
>> when we were working at scipy and I wrote that script to move new
>> saved-results into baseline, I inadvertently moved a bad formatter4
>> image into the baseline, so the baseline image was broken. When I
>> fixed the bug, the unit test caught the difference. I've updated the
>> baseline so now everything should be good for that particular test.
> 
> The empty_datetime continues to mystefy me. The actual had ticks from
> 1..23 and the baseline had ticks from 2..00. The current behavior on
> my box is 1..23 and that seems fine to me, so I re-updated the
> baseline with that file. I'm attaching the actual and baseline from
> the last buildbot before my update. The sage box *should* pass on the
> next build test because I've corrected the two known failures. If
> there is anything I am missing about this empty datetime test, let me
> know
So it sounds like there have been three different behaviors: 0 to 24, 1 
to 23, and 2 to 24. I think what we are seeing here is differences in 
floating point behavior among different platforms, and/or differences in 
datetime implementation from one python version to another. The 
standard python library datetime is being used to generate the floating 
point xlim in days. It looks like (2009, 1, 20) and (2009, 1, 21) can 
end up as floating point numbers a hair above or a hair below the target 
integers, and that difference of a hair is enough to determine whether a 
tick is generated or not.
A side point here is that the precision of the floating point numbers is 
lousy for most applications, because of the choice of "year 1" as the 
origin. This is a case of mpl following a bad choice by Matlab.
One way to get around the first problem--the datetime tick dependence on 
platform--would be to put fudge factors into the autoscaling so that the 
limits would be expanded some small amount. More generally, the 
autoscaling could have margins, which might default to the tiny amount 
necessary to prevent the datetime indeterminacy, but might be put to 
other good uses by the user. Often one really wants the xlim and ylim 
to be a little wider than the data range, so that symbols are plotted 
entirely within the axes, for example. This was suggested a very long 
time ago, and it has resurfaced many times in my mind, but obviously I 
never did anything about it.
Eric

On Sun, Aug 30, 2009 at 4:17 PM, John Hunter<jd...@gm...> wrote:
> According to RobK, you can reconfigure your ubuntu system to turn
> these off. He suggests:
>
> To use autohinting, use the hint in this post, or just run the
> following command:
>
> sudo dpkg-reconfigure fontconfig-config
>
> then choose "autohinter", then choose "always", then choose "no"
If that doesn't work, this guy has more involved instructions on how
to rebuild ubuntu libfreetype and disable the bytecode patch
http://ubuntuforums.org/showthread.php?t=84359
JDH

Andrew, I think I may have a clue how to fix the font discrepancies.
Apple owns patents on some a byte code interpreter for hinting truetype fonts:
 http://freetype.sourceforge.net/patents.html
and freetype can be built with the patented stuff turned on but the
default is off -- freetype has non-patented auto-hinting which is what
is used by default. However, according to a thread I found here (see
the first post by RobK) ubuntu hardy heron, which is what you are
using on the buildbot, has the patented stuff *turned on* by default:
 http://www.howtogeek.com/howto/ubuntu/enable-smooth-fonts-on-ubuntu-linux/
According to RobK, you can reconfigure your ubuntu system to turn
these off. He suggests:
 To use autohinting, use the hint in this post, or just run the
following command:
 sudo dpkg-reconfigure fontconfig-config
 then choose "autohinter", then choose "always", then choose "no"
Give it a test and hopefully we will see both bots go green.
Then we can focus on more tests and nightly builds...
JDH

Eric, all,
Here's the latest version of my color map patch. I deferred your
suggestion #4; perhaps we can fix that later.
Please let me know what you think; if everybody is ok with it I'll
push to trunk.
Regards,
Reinier
On Sun, Aug 16, 2009 at 9:40 PM, Eric Firing<ef...@ha...> wrote:
> Reinier Heeres wrote:
>>
>> Hi Eric, all,
>>
>> I've attached a new patch where I also allow two extra ways to define
>> color maps:
>> - by specifying (value, color) pairs, giving a linearly interpolated map.
>> - by specifying functions (gnuplot default functions are included)
>>
>> I've added a few colormaps: afmhot, bwr, brg, gnuplot, gnuplot2,
>> ocean, rainbow, seismic, terrain
>>
>> I refactored a few others: flag, prism, gist_gray, gist_heat,
>> gist_rainbow, gist_stern, gist_yarg. This saves about ~3000 lines...
>> (And the differences are very minor)
>>
>> You can compare them with the old scales by running
>> examples/pylab_examples/show_colormaps.py both with and without the
>> attached patch.
>>
>> What do you think? If it's ok, shall I push to trunk or v99?
>
> Reinier,
>
> First, this is a feature, not a bugfix, so it should go to the trunk.
>
> Second, before it goes, I have some suggestions:
>
> 1) Avoid using the types module; it is too specific, too restrictive. e.g.
> instead of
>
> +    if type(val) is types.FunctionType:
>
> use
>    if callable(val):
>
> instead of
>
> +  if type(datad[cmapname]) is types.DictType:
>
> you might use
>  cmapspec = datad[cmapname]
>  if 'red' in cmapspec:
>    ....
>  else:
>    ....
>
> In each case, you may need to think about what kinds of arguments might be
> encountered, and what is the simplest and safest way to sort them out.
>
>
> 2) Related to the above, we really don't want to make distinctions among
> types of sequences unless there is no alternative--it is too confusing for
> users to remember that this has to be a tuple but that has to be a list, and
> the other thing has to be an ndarray. (Such distinctions in numpy's
> indexing rules make the indexing very flexible and powerful--but it is also
> very hard to remember exactly what those rules are. For numpy indexing,
> there was probably no alternative; for us there is.)
>
> 3) This statement from LinearSegmentedColormap.from_list
>
>    if len(colors[0]) == 2:
>
> will fail with valid inputs, e.g. ['.2', 'r'] (recall that '.2' is a
> specification for gray on a 0-1 scale.)
>
> What might work for parsing the colors argument is to take advantage of
> numpy's ability to figure out the dimensions of a possibly nested sequence:
>
>  colors = np.asarray(colors)
>  if colors.ndim == 2:
>    ...
>  else: # assume it is 1-D, colors only
>    ...
>
> Turning arguments into ndarrays often simplifies the rest of the code, so
> long as one does not need to change the dimensions subsequently--lists are
> great for appending, deleting, etc. Sequence operations with ndarrays may
> be slower than using lists, tuples, and zip, but this doesn't matter at all
> in this part of the code.
>
> 4) This point could be considered now, or deferred: I originally tacked on
> the from_list method. It might make sense to deprecate it, and simply fold
> the logic into the __init__ method. One might want to keep the logic broken
> out into a method, and call that method to process the segmentdata argument.
> (The code in __init__ methods sometimes gets long and hard to follow;
> readability can be improved by separating parts out into methods, often
> private ones, and calling those in __init__.)
>
> 5) In _cm.py, if the maps you condensed are already identified in comments
> as to their sources, then you should add to those comments a note on how you
> modified them.
>
> Thank you for your work on this.
>
> Eric
>
>
>>
>> Regards,
>> Reinier
>>
>> On Thu, Aug 13, 2009 at 1:16 AM, Eric Firing<ef...@ha...> wrote:
>>>
>>> Reinier Heeres wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I would like to propose the attached patch to be able to use a gamma
>>>> value for color maps. This will make it simple to make your color
>>>> scale more 'sensitive' at the bottom or at the top, as can be seen in
>>>> the attached example. This could in principle also be solved by adding
>>>> a gamma normalizer, but I think that applying it to a color map is
>>>> quite coming practice, so in this case the preferred way.
>>>
>>> Your patch looks reasonable to me.
>>>>
>>>> I'd also like to add a few extra color maps (at least one plain
>>>> blue-white-red and one with darker shades at the high and low ends, as
>>>
>>> Good.
>>>
>>>> in the attachment). I also remember a particular one ('terrain') in a
>>>> measurement program called 'Igor' that would be nice.
>>>
>>> Is there any potential licensing problem? I hope not. I presume you
>>> would
>>> copy the effect, not any particular set of numbers extracted from Igor.
>>>
>>>> Looking at _cm.py, I would guess that could be done a bit more
>>>> efficient than the current 5880 lines as well by just specifying a few
>>>> colors and using LinearSegmentedColormap.from_list(). Is it ok if I
>>>> try to refactor that?
>>>
>>> You mean take the colormaps that have a huge number of color dictionary
>>> entries in _cm.py, and subsample them down to something reasonable?
>>> Please
>>> do! I always hated those blocks of numbers, but never enough to motivate
>>> me
>>> to do something about them other than a little reformatting.
>>>
>>> It sounds like you are talking about going farther than that, which might
>>> be
>>> fine but might make things more complicated. As it is now, all the
>>> built-in
>>> colormaps are associated with color dictionaries for direct use in
>>> LinearSegmentedColormap. If you make two styles, one based on the
>>> dictionaries (which allows discontinuities) and one based on from_list
>>> (which does not), then you need to keep track of which is which. Is it
>>> worth it? I am inclined to stick with the cdict approach.
>>>
>>> It looks like an obvious addition would a function that takes a list of
>>> breakpoints (starting with 0 and ending with 1) and a matching list of
>>> colors and generates the corresponding cdict for continuous mapping.
>>>
>>> Eric
>>>
>>>> Let me know what you think.
>>>>
>>>> Cheers,
>>
>>
>
>
-- 
Reinier Heeres
Tel: +31 6 10852639

On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jd...@gm...> wrote:
> OK, I figured this out. The new failure was on formatter4, not
> formatter5. I didn't see that when I posted earlier. It turns out
> when we were working at scipy and I wrote that script to move new
> saved-results into baseline, I inadvertently moved a bad formatter4
> image into the baseline, so the baseline image was broken. When I
> fixed the bug, the unit test caught the difference. I've updated the
> baseline so now everything should be good for that particular test.
The empty_datetime continues to mystefy me. The actual had ticks from
1..23 and the baseline had ticks from 2..00. The current behavior on
my box is 1..23 and that seems fine to me, so I re-updated the
baseline with that file. I'm attaching the actual and baseline from
the last buildbot before my update. The sage box *should* pass on the
next build test because I've corrected the two known failures. If
there is anything I am missing about this empty datetime test, let me
know

On Sun, Aug 30, 2009 at 11:47 AM, John Hunter<jd...@gm...> wrote:
> Hey this is strage now the baseline image is wrong (it has one line
> and should have two). Earlier didn't the baseline have two and the
> actual have one? Did someone upload the broken one line version as
> the new baseline. I can fix the baseline with the new actual, but I
> am curious how this baseline image got in there.
OK, I figured this out. The new failure was on formatter4, not
formatter5. I didn't see that when I posted earlier. It turns out
when we were working at scipy and I wrote that script to move new
saved-results into baseline, I inadvertently moved a bad formatter4
image into the baseline, so the baseline image was broken. When I
fixed the bug, the unit test caught the difference. I've updated the
baseline so now everything should be good for that particular test.
JDH

On Sun, Aug 30, 2009 at 11:42 AM, John Hunter<jd...@gm...> wrote:
> So now I am getting what looks like a font error on the sage buildbot,
> even though I wasn't getting one before on this image. Is this
> because the new good was generated on linux with a different font
> config, you think? It would be really nice if we could crack this
> font issue.
>
> I tracked down and fixed the unitized tick formatter, and removed the
> known failure decorator from that test, so we hopefully will see that
> error drop out of the next build.
Hey this is strage now the baseline image is wrong (it has one line
and should have two). Earlier didn't the baseline have two and the
actual have one? Did someone upload the broken one line version as
the new baseline. I can fix the baseline with the new actual, but I
am curious how this baseline image got in there.
JDH

On Sun, Aug 30, 2009 at 10:24 AM, Andrew Straw<str...@as...> wrote:
> No, I hadn't considered that it might be non-deterministic. However,
> looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
> this is a totally different failure than we were seeing with Eric's
> patch. I should probably start archiving the results of the failed
> images so we can go back in time looking at these things.
>
> I'm going to ponder this for a while.
So now I am getting what looks like a font error on the sage buildbot,
even though I wasn't getting one before on this image. Is this
because the new good was generated on linux with a different font
config, you think? It would be really nice if we could crack this
font issue.
I tracked down and fixed the unitized tick formatter, and removed the
known failure decorator from that test, so we hopefully will see that
error drop out of the next build.
JDH

Jouni K. Seppänen wrote:
> Eric Firing <ef...@ha...> writes:
>
> 
>> Andrew Straw wrote:
>> 
>>> Eric Firing wrote:
>>> 
>>>>> Specifically, it looks like the farthest left xticklabel is no longer
>>>>> getting displayed. Personally, I think it looks better this way, but now
>>>>> that the test suite is coming online, we will finally start noticing
>>>>> little things like this.
>>>>> 
>>>> I agree that the newer version, without the first label, is better--but
>>>> I can't imagine how the change to semilogx and semilogy could make a
>>>> difference like this. It must be something else.
>>>> 
>>> Well, if you look at
>>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
>>> versus
>>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
>>>
>>> that's where the difference happened, thus leading to my assertion. What
>>> changed between those two builds was r7585. Perhaps something else is
>>> responsible, though...
>>> 
>> 7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
>> trunk, which pulled in earlier changes that had not been merged yet. The 
>> others were just documentation, though, so I am still mystified. Oh, well.
>> 
>
> If I'm reading the waterfall display correctly, it looks like my commit
> 7597 changed the result again. I only touched documentation and
> docstrings... have you tried running the buildbot several times on the
> same sources?
> 
Curiouser and curiouser...
No, I hadn't considered that it might be non-deterministic. However,
looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
this is a totally different failure than we were seeing with Eric's
patch. I should probably start archiving the results of the failed
images so we can go back in time looking at these things.
I'm going to ponder this for a while.
-Andrew

On Sun, Aug 30, 2009 at 5:41 AM, Gael
Varoquaux<gae...@no...> wrote:
> Yes, that did fix the problem. I suspect it might be trivial :). Thanks a
> lot.
This is a common problem, and the first line of defense against builds
or installs that aren't working properly. We even have a FAQ entry:
 http://matplotlib.sourceforge.net/faq/installing_faq.html#source-install
JDH

Eric Firing <ef...@ha...> writes:
> Andrew Straw wrote:
>> Eric Firing wrote:
>>>> Specifically, it looks like the farthest left xticklabel is no longer
>>>> getting displayed. Personally, I think it looks better this way, but now
>>>> that the test suite is coming online, we will finally start noticing
>>>> little things like this.
>>> I agree that the newer version, without the first label, is better--but
>>> I can't imagine how the change to semilogx and semilogy could make a
>>> difference like this. It must be something else.
>> 
>> Well, if you look at
>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
>> versus
>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
>> 
>> that's where the difference happened, thus leading to my assertion. What
>> changed between those two builds was r7585. Perhaps something else is
>> responsible, though...
>
> 7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
> trunk, which pulled in earlier changes that had not been merged yet. The 
> others were just documentation, though, so I am still mystified. Oh, well.
If I'm reading the waterfall display correctly, it looks like my commit
7597 changed the result again. I only touched documentation and
docstrings... have you tried running the buildbot several times on the
same sources?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Jouni K. Seppänen <jk...@ik...> writes:
>> The current interface looks easy enough to use -- it just needs to be
>> advertised better, eg in a FAQ ( I had to read the source to find it,
>> which works well enough for me, but not for everyone). If you want to
>> write one up, I'll add it to the docs.
>
> I seem to recall that the ReST docstring of backend_pdf.PdfPages was
> included in the documentation at some point, but it is missing now from
> <http://matplotlib.sourceforge.net/api/index_backend_api.html>. 
I added some documentation again. Here's what I think probably happened
the previous time: I added doc/api/backend_pdf_api.rst and edited
doc/api/index_backend_api.rst, built the documentation locally to check
that it looks OK, then at some point ran "make.html clean" to debug some
doc problems... which destroyed my uncommitted doc changes by running
svn-clean.
How about changing "make.html clean" to be more careful? After building
the docs, "svn status" shows the following unversioned files:
? build
? examples
? _static/matplotlibrc
? _templates/gallery.html
"svn status --no-ignore" adds a lot of *.pyc files in various
subdirectories. Would removing all of these achieve the expected
cleaning effect?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Sun, Aug 30, 2009 at 01:35:47PM +0300, Jouni K. Seppänen wrote:
> Gael Varoquaux <gae...@no...> writes:
> > ImportError: /home/varoquau/dev/matplotlib/lib/matplotlib/ttconv.so:
> > undefined symbol: _ZN14TTStreamWriter7putcharEi
> > Does anybody know what I am doing wrong?
> I just had a similar problem, and nuking the build directory and
> rebuilding matplotlib fixed it. Have you tried "rm -rf build"?
Hey Jouni,
Yes, that did fix the problem. I suspect it might be trivial :). Thanks a
lot.
Gaël

On Sat, Aug 29, 2009 at 10:45:31PM -0500, John Hunter wrote:
> I've tried to apply your code properly. Because it was not a patch,
> but a simple code file submission (and the original files have changed
> since your submission) and because I did not write the original ginput
> code, it was touch sledding to apply the patch. I think I got it
> right, but I would like people who use ginput and blocking input to
> give it a test drive (I did what basic tests I could, not being a
> power user).
Thank John you for doing the grunt work. It pushed me enough to do the
review that you had asked for. I am attaching a patch correcting a bug,
as well as improving the docs, and fixing a few unecessary imports.
As a side note, you guys should run pyflakes on your codebase every once
in a while. You have a lot of unused imports. Also, there seems to be
bigger problems such as
 finance.py:169: undefined name 'url'
 font_manager.py:221: undefined name 'WindowsError'
 config/checkdep.py:67: undefined name 'verbose'
 cbook.py:787: undefined name '__Full'
 cbook.py:1414: undefined name 'glob'
 cbook.py:1577: undefined name 'x'
 cbook.py:1577: undefined name 'y'
 cbook.py:1577: undefined name 'xi'
 cbook.py:1577: undefined name 'extrap'
And many others that I am passing.
These might be bugs, or might not. I didn't take the time to check.
Cheers,
Gaël

Gael Varoquaux <gae...@no...> writes:
> ImportError: /home/varoquau/dev/matplotlib/lib/matplotlib/ttconv.so:
> undefined symbol: _ZN14TTStreamWriter7putcharEi
>
> Does anybody know what I am doing wrong?
I just had a similar problem, and nuking the build directory and
rebuilding matplotlib fixed it. Have you tried "rm -rf build"?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

It must be me being stupid build MPL under the latest Ubuntu (has it
become harder lately? I have this impression), but I can't save pdfs with
a development version of MPL:
/home/varoquau/dev/matplotlib/lib/matplotlib/backends/backend_pdf.py in
<module>()
 42 from matplotlib.transforms import Affine2D, Bbox, BboxBase,
TransformedPath
 43 from matplotlib.path import Path
---> 44 from matplotlib import ttconv
 45 
 46 # Overview
ImportError: /home/varoquau/dev/matplotlib/lib/matplotlib/ttconv.so:
undefined symbol: _ZN14TTStreamWriter7putcharEi
Does anybody know what I am doing wrong?
Thanks,
Gaël

Andrew Straw wrote:
> Eric Firing wrote:
>>> Specifically, it looks like the farthest left xticklabel is no longer
>>> getting displayed. Personally, I think it looks better this way, but now
>>> that the test suite is coming online, we will finally start noticing
>>> little things like this.
>> I agree that the newer version, without the first label, is better--but
>> I can't imagine how the change to semilogx and semilogy could make a
>> difference like this. It must be something else.
> 
> Well, if you look at
> 
> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
> 
> versus
> 
> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
> 
> that's where the difference happened, thus leading to my assertion. What
> changed between those two builds was r7585. Perhaps something else is
> responsible, though...
7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
trunk, which pulled in earlier changes that had not been merged yet. The 
others were just documentation, though, so I am still mystified. Oh, well.
Eric

Eric Firing wrote:
>> Specifically, it looks like the farthest left xticklabel is no longer
>> getting displayed. Personally, I think it looks better this way, but now
>> that the test suite is coming online, we will finally start noticing
>> little things like this.
> 
> I agree that the newer version, without the first label, is better--but
> I can't imagine how the change to semilogx and semilogy could make a
> difference like this. It must be something else.
Well, if you look at
http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
versus
http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
that's where the difference happened, thus leading to my assertion. What
changed between those two builds was r7585. Perhaps something else is
responsible, though...
>>
>> Eric, if you think the new image is OK, can you download it from
>> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
>>
>> and then check it into
>> test/test_matplotlib/baseline/TestAxes/empty_datetime.png
> 
> Done (with *.png, not actual.gif).
Ahh yes, good catch. Thanks for correcting this.
> 
> Eric
> 
>>
>> In fact, I just checked in a KnownFail test decorator heavily based on
>> numpy's implementation, so once this test starts passing, the Mac OS X
>> buildslave should have all the tests returning success or knownfail.
And look -- a buildslave is not failing!
http://mpl-buildbot.code.astraw.com/waterfall
-Andrew

Andrew Straw wrote:
> Eric Firing wrote:
>> Tony S Yu wrote:
>> 
>>> Did this email ever appear on list? I didn't see it after sending my 
>>> original post, but I found it on the Sourceforge mail archives. I'm 
>>> trying a different email address as an experiment.
>>> 
>> Tony,
>>
>> It did appear the first time, but I guess everyone who saw it figured 
>> someone else would deal with it.
>> 
>>> In any case, any comments on the patch?
>>> 
>> Looks reasonable to me. I will apply it.
>> 
> I think this caused the test_matplotlib.TestAxes.empty_datetime test to
> fail. You can see the result at
> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/overview.html
> 
> Specifically, it looks like the farthest left xticklabel is no longer
> getting displayed. Personally, I think it looks better this way, but now
> that the test suite is coming online, we will finally start noticing
> little things like this.
I agree that the newer version, without the first label, is better--but 
I can't imagine how the change to semilogx and semilogy could make a 
difference like this. It must be something else.
> 
> Eric, if you think the new image is OK, can you download it from
> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
> and then check it into
> test/test_matplotlib/baseline/TestAxes/empty_datetime.png
Done (with *.png, not actual.gif).
Eric
> 
> In fact, I just checked in a KnownFail test decorator heavily based on
> numpy's implementation, so once this test starts passing, the Mac OS X
> buildslave should have all the tests returning success or knownfail.
> 
> Thanks,
> Andrew
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter <jd...@gm...> writes:
> This is a tough call. mpk is not so good at multiline text. Maybe
> the solution is to make mpl good at multiline text, but I was
> wondering if there was an easy way to "dump a paragraph" at the pdf
> level, and have it newline separate the text and make it look
> acceptable.
Ah, so it's about multiline text. Yes, pdf has a "newline" operator 
that could be used to lay out simple paragraphs. I'll take a look later
today to see how complicated it would need to be.
> The current interface looks easy enough to use -- it just needs to be
> advertised better, eg in a FAQ ( I had to read the source to find it,
> which works well enough for me, but not for everyone). If you want to
> write one up, I'll add it to the docs.
I seem to recall that the ReST docstring of backend_pdf.PdfPages was
included in the documentation at some point, but it is missing now from
<http://matplotlib.sourceforge.net/api/index_backend_api.html>. Of
course the "backends" chapter may not get read by many users, so there
could be a pointer to it from some suitable place elsewhere in the
documentation.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Eric Firing wrote:
> Tony S Yu wrote:
> 
>> Did this email ever appear on list? I didn't see it after sending my 
>> original post, but I found it on the Sourceforge mail archives. I'm 
>> trying a different email address as an experiment.
>> 
>
> Tony,
>
> It did appear the first time, but I guess everyone who saw it figured 
> someone else would deal with it.
> 
>> In any case, any comments on the patch?
>> 
>
> Looks reasonable to me. I will apply it.
> 
I think this caused the test_matplotlib.TestAxes.empty_datetime test to
fail. You can see the result at
http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/overview.html
Specifically, it looks like the farthest left xticklabel is no longer
getting displayed. Personally, I think it looks better this way, but now
that the test suite is coming online, we will finally start noticing
little things like this.
Eric, if you think the new image is OK, can you download it from
http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
and then check it into
test/test_matplotlib/baseline/TestAxes/empty_datetime.png
In fact, I just checked in a KnownFail test decorator heavily based on
numpy's implementation, so once this test starts passing, the Mac OS X
buildslave should have all the tests returning success or knownfail.
Thanks,
Andrew

On Mon, Aug 17, 2009 at 11:24 AM, Jack Sankey<jac...@gm...> wrote:
> Hello Gael,
> Okay, I've updated the two files I modified here:
> http://sites.google.com/site/jacksankey/files/matplotlib.zip?attredirects=0
> Sorry I can't figure out how to compile. I wish it was possible to have an
> SVN containing also the windows binaries. Too bad we all can't just run
> Linux.
> Anyway, I tested the pants off this using an imshow() color plot this
> morning, and it works well on windows XP/wxAgg. There are two things worth
> mentioning:
> - For some reason, the enter key does not generate an event for me. I've
> added "escape" as another possible keyboard stop event generator.
> - The backspace key causes the plot to undo a zoom. This confused me for an
> hour. Use delete!
> - I'm fairly certain the mouse numbers are different for windows. I can't
> make the middle mouse button do anything.
> If you don't wind up adding all these changes, in the very least for the
> upcoming release, can you please add "escape" to the list of keys that will
> exit the collection of data points? That would amount to changing one line
> in key_event() from
> elif key == 'enter'
> to
> elif key in ['escape', 'enter']:
> The third point above is the reason I looked into this in the first place; I
> couldn't stop collecting! :) Adding 'escape' would make ginput() functional
> enough. (I also use key = event.key.lower() to be safe.)
> Thanks!
> -Jack
Hi Jack,
I've tried to apply your code properly. Because it was not a patch,
but a simple code file submission (and the original files have changed
since your submission) and because I did not write the original ginput
code, it was touch sledding to apply the patch. I think I got it
right, but I would like people who use ginput and blocking input to
give it a test drive (I did what basic tests I could, not being a
power user).
Thanks for the submission,
JDH

On Fri, Aug 28, 2009 at 4:27 AM, Jouni K. Seppänen<jk...@ik...> wrote:
> Should the coordinates be raw PDF points measured from the bottom left
> corner, or passed through the figure transformation (or something else)?
> What sort of font properties would you expect to be allowed?
>
>> One could use the matplotlib.text.Text
>> and add it to your figure, and maybe this is the way to go,
>
> I think that's what the pdf backend would end up doing internally, at
> least if anything like coordinate transformations or any interesting
> font properties need to be supported. It sounds like a fairly easy
> change.
This is a tough call. mpk is not so good at multiline text. Maybe
the solution is to make mpl good at multiline text, but I was
wondering if there was an easy way to "dump a paragraph" at the pdf
level, and have it newline separate the text and make it look
acceptable. I don't really know enough about the pdf spec to know if
this is sensible. Of course, as soon as you support a little, people
will want you to support more, fonts and sizes and math and
what-have-you. So maybe the better solution is to make mpl multiline
text better.
> While we're discussing multi-page pdf files, would it be useful to have
> pyplot-level support for them? It shouldn't be too hard to have pyplot
> track your currently open pdf file and make, say, savefig with no
> arguments direct the output to that. I personally don't have a use for
> that, but do you think it would be a useful part of pyplot?
The current interface looks easy enough to use -- it just needs to be
advertised better, eg in a FAQ ( I had to read the source to find it,
which works well enough for me, but not for everyone). If you want to
write one up, I'll add it to the docs.
JDH