matplotlib-devel Mailing List for matplotlib (Page 2)

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

Very nice addition Michael.
I note that the plt.colormap() line must have gotten lost. It's referred 
to but not there.
I'll add some ideas to John's list:
* Demonstrate the imsave() command.
* Rather than show 50 lines or so of array data, just show a few lines, 
but demonstrate what img.shape is before and after slicing out the B 
channel with img[:,:,0]
* It may be worth mentioning explicitly that img[:,:,0] will give you 
the blue channel for an RGB and an RGBA image.
* Demonstrate the "upper" and "lower" keywords where relevant.
* Add a pointer to the scipy.ndimage module
* Extend the examples with RGB and RGBA images.
* You might like to show how to recarrays and views on the individual 
colour channels. There are examples in the mailing list archives or 
maybe on the scipy website - I can't remember where.
* If you want to get more advanced, talk about higher bit depth images 
than 8 bits per channel.
* If you want to get even more advanced, show how to change the UI to 
probe the pixel value (I wish matplotlib did this by default).
Gary R.
John Hunter wrote:
> On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan<mcs...@uc...> wrote:
>> Here you go. If you can think of anything else to include, I'll work
>> on it. I think the next thing I'll add is something on embedding
>> images in the corners of plots. figimage is the way to do this,
>> right?

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.
Eric
> 
> -Tony
> 
> On Aug 24, 2009, at 5:31 PM, Tony Yu wrote:
> 
>> I noticed that semilogx and semilogy don't check if the linear axis 
>> (y-axis for semilogx; x-axis for semilogy) is actually linear. Thus, 
>> if I call semilogx and then call semilogy *on the same plot*, I end 
>> up with a loglog plot.
>>
>> Below is a simple patch. I'm not sure how useful this fix is since 
>> most people wouldn't want to make these calls on the same plot 
>> (since the second call would override the first)---I was working 
>> interactively in IPython so it did make a difference.
>>
>> Cheers,
>> -Tony
>>
>>
>> Index: lib/matplotlib/axes.py
>> ===================================================================
>> --- lib/matplotlib/axes.py	(revision 7557)
>> +++ lib/matplotlib/axes.py	(working copy)
>> @@ -3615,6 +3615,7 @@
>> }
>>
>> self.set_xscale('log', **d)
>> + self.set_yscale('linear')
>> b = self._hold
>> self._hold = True # we've already processed the hold
>> l = self.plot(*args, **kwargs)
>> @@ -3665,6 +3666,7 @@
>> 'nonposy': kwargs.pop('nonposy', 'mask'),
>> }
>> self.set_yscale('log', **d)
>> + self.set_xscale('linear')
>> b = self._hold
>> self._hold = True # we've already processed the hold
>> l = self.plot(*args, **kwargs)
> 
> 
> ------------------------------------------------------------------------------
> 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

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.
In any case, any comments on the patch?
-Tony
On Aug 24, 2009, at 5:31 PM, Tony Yu wrote:
> I noticed that semilogx and semilogy don't check if the linear axis 
> (y-axis for semilogx; x-axis for semilogy) is actually linear. Thus, 
> if I call semilogx and then call semilogy *on the same plot*, I end 
> up with a loglog plot.
>
> Below is a simple patch. I'm not sure how useful this fix is since 
> most people wouldn't want to make these calls on the same plot 
> (since the second call would override the first)---I was working 
> interactively in IPython so it did make a difference.
>
> Cheers,
> -Tony
>
>
> Index: lib/matplotlib/axes.py
> ===================================================================
> --- lib/matplotlib/axes.py	(revision 7557)
> +++ lib/matplotlib/axes.py	(working copy)
> @@ -3615,6 +3615,7 @@
> }
>
> self.set_xscale('log', **d)
> + self.set_yscale('linear')
> b = self._hold
> self._hold = True # we've already processed the hold
> l = self.plot(*args, **kwargs)
> @@ -3665,6 +3666,7 @@
> 'nonposy': kwargs.pop('nonposy', 'mask'),
> }
> self.set_yscale('log', **d)
> + self.set_xscale('linear')
> b = self._hold
> self._hold = True # we've already processed the hold
> l = self.plot(*args, **kwargs)

On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan<mcs...@uc...> wrote:
> Here you go. If you can think of anything else to include, I'll work
> on it. I think the next thing I'll add is something on embedding
> images in the corners of plots. figimage is the way to do this,
> right?
It depends on exactly what you are trying to do -- figimage is a pure
pixel dump, so it doesn't scale with DPI. It is good for people who
want to put raw data into a figure, but not for much else. You can
also use the "extent" argument to a regular image to
> The image is on that I took, so don't worry about licensing on it. My
> images are licensed under Creative Commons.
Great -- I've pushed this out to the website. Thanks a lot. You can
see the fruits of your labors at
http://matplotlib.sourceforge.net/users/image_tutorial.html
If you want to make any more enhancements, the easiest way for me is
to submit a diff against the 0.99 release branch
 > svn co https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint
mpl99
 # make your edits
 > svn diff > imagetut.diff
See also, http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
As for stuff to be added, here is a laundry list after a quick once
over, in no particular order
 * pointers to the matplotlib.colors, matplotlib.cm,
matplotlib.colorbar api docs
 * port the matplotlib.image module to have rest compliant docs,
incorporate them into the api docs, and link to them from the tutorial
 * discuss the image aspect settings with some examples
 * show how to use the matplotlib.cm objects, eg cm.jet, cm.hot in
addition to the strings 'jet', 'hot'
 * adjusting the size of the colorbar so it is the same height as your image
 * show how to create a custom colormap (there are examples for this
you could follow), either using listed colors or writing your own
linear segmented colormap
 * discuss figimage
 * discuss the extent argument
For many of these, if you don't know how to get started, read the doc
strings and then go to the search page and use the codex argument to
search for code examples. Eg a search for "codex imshow extent" will
show image examples that use the extent kwarg
 http://matplotlib.sourceforge.net/search.html
Going forward, if you have further questions or need pointers to docs
or examples, please post to matplotlib-devel and let people know what
you are doing. I sometimes get swallowed by all the stuff I am doing
so cannot always answer promptly, so it is good to have some backup.
I've take the liberty of CC-ing the devel list here in case others
want to jump in with suggestions or contributions to the tutorial
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Thanks a lot for this -- the docs are making a lot of progress and
there is a ton of good stuff in mpl that still has no tutorial on how
to use it, so this is plugging one of those holes.
JDH

On Fri, Aug 28, 2009 at 9:47 PM, <jas...@cr...> wrote:
> Is there any chance someone could add a brief reference and link to the
> online svn repository somewhere on the front page of matplotlib? Maybe
> in the sidebar under "Need help?":
>
> For details on what's new, see the detailed changelog
> <http://matplotlib.sourceforge.net/_static/CHANGELOG> **or browse the
> source code**. Anything that could require changes to your existing
> codes is logged in the api changes
> <http://matplotlib.sourceforge.net/api/api_changes.html> file.
>
Done, though I made the link point to trunk/matplotlib since I think
that is what most people will be interested in.
But bookmarks are helpful too :-)
JDH

Is there any chance someone could add a brief reference and link to the 
online svn repository somewhere on the front page of matplotlib? Maybe 
in the sidebar under "Need help?":
For details on what's new, see the detailed changelog 
<http://matplotlib.sourceforge.net/_static/CHANGELOG> **or browse the 
source code**. Anything that could require changes to your existing 
codes is logged in the api changes 
<http://matplotlib.sourceforge.net/api/api_changes.html> file.
where "source code" links to 
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/
I've run out of fingers and toes for counting how many times I have to 
click around and hunt this down (and I always forget to bookmark it or 
I'm on a new computer!)
Thanks,
Jason
--
Jason Grout

John Hunter <jd...@gm...> writes:
> One of my colleagues want to use PdfPages to create several mpl
> figures in one pdf document. It would be nice to be able to write
> some text in there directly.
So the user interface might look something like this:
pdf = PdfPages('filename.pdf')
fig=figure()
# ...
pdf.savefig(fig)
pdf.annotate(123,456,'my text here',fontsize=12,font='Helvetica')
pdf.close()
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.
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?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks