Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Jouni K. Seppänen wrote:

Michael Droettboom  writes:

  

when running usetex_fonteffects.py [...]
TypeError: coercing to Unicode: need string or buffer, NoneType found
-> file = open(input, 'rb')



Perhaps your TeX installation doesn't have the font. If you run
"kpsewhich utmr8a.pfb", what do you get? If it does return something,
could you run the example with --verbose-debug?

  

> kpsewhich utmr8a.pfb
/usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb


The output of "python usetex_texteffects.py --verbose-debug" is attached.

Mike

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

$HOME=/home/mdroe
CONFIGDIR=/home/mdroe/.matplotlib
matplotlib data path 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /home/mdroe/.matplotlib/matplotlibrc
matplotlib version 0.98.6svn
verbose.level debug
interactive is False
units is False
platform is linux2
loaded modules: ['_bisect', 'xml.sax.urlparse', 'distutils', 
'matplotlib.errno', 'matplotlib.matplotlib', 'subprocess', 'xml._xmlplus', 
'gc', 'matplotlib.tempfile', 'distutils.sysconfig', 'ctypes._endian', 
'encodings.encodings', 'matplotlib.colors', 'numpy.core.numerictypes', 
'numpy.testing.sys', 'numpy.core.info', 'xml', 'numpy.fft.types', 
'numpy.ma.operator', 'numpy.ma.cPickle', 'struct', 'numpy.random.info', 
'tempfile', 'pprint', 'numpy.linalg', 'matplotlib.threading', 
'numpy.testing.operator', 'imp', 'numpy.testing', 'collections', 
'numpy.core.umath', 'distutils.types', 'numpy.lib.numpy', 
'numpy.core.scalarmath', 'zipimport', 'string', 'matplotlib.subprocess', 
'numpy.testing.os', 'matplotlib.locale', 'numpy.lib.arraysetops', 
'numpy.testing.unittest', 'numpy.lib.math', 'repr', 'matplotlib.__future__', 
'datetime', 'numpy.testing.re', 'numpy.version', 'numpy.lib.re', 
'distutils.re', 'ctypes.os', 'numpy.core.os', 'numpy.lib.type_check', 
'httplib', 'bisect', 'numpy.core._internal', 'signal', 'cmd', 
'numpy.lib.types', 'numpy.lib._datasource', 'random', 'numpy.ma.extras', 
'token', 'numpy.fft.fftpack_lite', 'matplotlib.cbook', 'ctypes.ctypes', 
'xml.sax.xmlreader', 'numpy.__builtin__', 'dis', 'distutils.version', 
'cStringIO', 'numpy.ma.core', 'numpy.numpy', 'matplotlib.StringIO', 'locale', 
'numpy.add_newdocs', 'numpy.lib.getlimits', 'base64', 'xml.sax.saxlib', 
'matplotlib.numpy', 'numpy.testing.types', 'numpy.lib.sys', 'encodings', 
'numpy.ma.itertools', 'StringIO', 'numpy.lib.io', 'numpy.imp', 'bdb', 
'numpy.testing.decorators', 'matplotlib.warnings', 'rfc822', 
'matplotlib.string', 'urllib', 'matplotlib.sys', 're', 
'numpy.lib._compiled_base', 'threading', 'numpy.random.mtrand', 'math', 
'numpy.fft.helper', 'fcntl', 'numpy.ma.warnings', 'inspect', 
'numpy.ma.inspect', 'UserDict', 'numpy.lib.function_base', 'distutils.os', 
'matplotlib', 'numpy.core.types', 'fnmatch', 'numpy.lib.info', 'ctypes', 
'_xmlplus', 'ctypes.struct', 'codecs', 'numpy.core._sort', 'numpy.os', 
'_locale', 'matplotlib.sre_constants', 'matplotlib.os', 'thread', 
'numpy.lib.ufunclike', 'numpy.core.memmap', 'traceback', 
'numpy.testing.warnings', 'xml.sax.sax2exts', 'weakref', 'itertools', 
'numpy.fft.fftpack', 'opcode', 'numpy.testing.imp', 'numpy.linalg.lapack_lite', 
'distutils.sys', 'os', 'marshal', 'numpy.lib.warnings', 'xml.sax.saxexts', 
'__future__', 'matplotlib.copy', 'xml.sax.types', 'numpy.random.numpy', '_sre', 
'unittest', 'numpy.core.sys', 'numpy.random', 'numpy.li

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Jouni: your latest commit resolves the issue for me.  Thanks!

Jae-Joon: Your preview.sty work seems to work great with the PDF backend 
(for me, at least).

Cheers,
Mike

Michael Droettboom wrote:
>
> Jouni K. Seppänen wrote:
>> Michael Droettboom  writes:
>>
>>  
>>> when running usetex_fonteffects.py [...]
>>> TypeError: coercing to Unicode: need string or buffer, NoneType found
>>> -> file = open(input, 'rb')
>>> 
>>
>> Perhaps your TeX installation doesn't have the font. If you run
>> "kpsewhich utmr8a.pfb", what do you get? If it does return something,
>> could you run the example with --verbose-debug?
>>
>>   
> > kpsewhich utmr8a.pfb
> /usr/share/texmf/fonts/type1/urw/times/utmr8a.pfb
>
>
> The output of "python usetex_texteffects.py --verbose-debug" is attached.
>
> Mike
>
> 
>
> --
> 
>
> ___________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Sorry about the wild good chase.  I had fixed up an earlier exception 
which was simply a problem with formatting a verbose message.  That 
gives this, when running usetex_fonteffects.py (with all rcParams at 
defaults):

Traceback (most recent call last):
  File "usetex_fonteffects.py", line 22, in 
pylab.savefig('usetex_fonteffects.pdf')
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
**kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
return pdf.print_pdf(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 1911, in print_pdf
file.close()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 440, in close
self.writeFonts()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 521, in writeFonts
fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 550, in embedType1
' and effects ' + `fontinfo.effects`,
TypeError: cannot concatenate 'str' and 'NoneType' objects
 > 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py(550)embedType1()
-> ' and effects ' + `fontinfo.effects`,*
*
Do an SVN update (r6736) and try again.  Then I get this:

 > python usetex_fonteffects.py
Traceback (most recent call last):
  File "usetex_fonteffects.py", line 22, in 
pylab.savefig('usetex_fonteffects.pdf')
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
**kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
return pdf.print_pdf(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 1911, in print_pdf
file.close()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 440, in close
self.writeFonts()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 521, in writeFonts
fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 553, in embedType1
t1font = type1font.Type1Font(fontinfo.fontfile)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py", 
line 55, in __init__
file = open(input, 'rb')
TypeError: coercing to Unicode: need string or buffer, NoneType found
 > 
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py(55)__init__()
-> file = open(input, 'rb')

So somehow, input is None, but I haven't had a chance to look any further.

Cheers,
Mike

Jouni K. Seppänen wrote:
> Michael Droettboom  writes:
>
>   
>> I'm currently getting this traceback with the PDF backend, whether 
>> "text.latex.preview" is True or False -- so it may be unrelated to your 
>> change, but I'm unable to test PDF at the moment.
>> 
>
> Based on the traceback, it looks like I have broken something recently --
> but what is the exact exception? I can't replicate the traceback myself.
>
>   

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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Thanks for the explanation.  The TeX install I have is the stock one 
with RHEL4, which is fairly old at this point.  I've had a number of 
other problems with it as well (such as it not being compatible with 
Sphinx). 

It's nice to know that matplotlib is at least handling this situation 
without crashing.  I think this solution (to warn) is adequate, 
especially given that most newer TeX distributions shouldn't have this 
issue.

Mike

Jouni K. Seppänen wrote:
> Michael Droettboom  writes:
>
>   
>> The output of "python usetex_texteffects.py --verbose-debug" is attached.
>> 
>
> Thanks! The problem seems to be that your TeX configuration (pdftex.map)
> specifies using Helvetica without embedding it into the pdf file. This
> is deprecated in the PDF standard (PDF viewer applications have
> different replacements for the core 14 fonts, and many publishers insist
> that you embed all fonts you use) but I added support for it in 6737,
> with a warning displayed to the user.
>
> Could you see if it works for you now?
>
>   

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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] usetex w/ preview.sty

[Michael Droettboom]

Very nice!

I'm currently getting this traceback with the PDF backend, whether 
"text.latex.preview" is True or False -- so it may be unrelated to your 
change, but I'm unable to test PDF at the moment.

Traceback (most recent call last):
  File "usetex_baseline_test.py", line 75, in 
plt.savefig("test.pdf")
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
345, in savefig
return fig.savefig(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
990, in savefig
self.canvas.print_figure(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1429, in print_figure
**kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
line 1323, in print_pdf
return pdf.print_pdf(*args, **kwargs)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 1911, in print_pdf
file.close()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 440, in close
self.writeFonts()
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 521, in writeFonts
fontdictObject = self.embedType1(filename, self.dviFontInfo[filename])
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_pdf.py",
 
line 553, in embedType1
t1font = type1font.Type1Font(fontinfo.fontfile)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/type1font.py", 
line 55, in __init__
file = open(input, 'rb')

Also, it seems like the text alignment in the PS output is too low by a 
small constant factor.

Assuming those issues can be resolved, is there now any reason to use 
dviread, assuming preview.sty is installed?  If the preview.sty approach 
is superior, I wonder if we could:

a) Determine if preview.sty is installed, and if so, use it, otherwise 
fallback to dviread? (Then we could be a default "auto" setting for the 
rcParam).

b) Or better, include preview.sty with matplotlib and use it instead of 
a system installed copy, so that it's always available.  (This is both a 
licensing and version-compatibility question, really...)

It would be great to make this new behavior with the proper baseline 
more automatic.

Cheers,
Mike

Jae-Joon Lee wrote:
> Hello,
>
> I committed a patch to optionally use preview.sty with usetex=True.
> This is to support a baseline alignment.
>
> A summary of changes:
>
>  * added a get_text_width_height_descent() method in the TexManager
> class, and modified the agg, ps and pdf backends to utilize this
> method.
>
>  * added a new rc parameter, 'text.latex.preview'. If True,
> preview.sty is used to generate dvi files and baseline information of
> each dvi file is stored in a separate file.
> TexManager.get_text_width_height_descent() method uses this
> information.
>
>  * If text.latex.preview==False,
> TexManager.get_text_width_height_descent() method uses dviread module
> (this is what the pdf backend has been using), but the returned
> descent value of the text is sometimes incorrect.
>
>  * added an example ("usetex_baseline_test.py" ). The output is
> attached with this email.
>
> If you have a preview.sty installed, please test this (set
> "text.latex.preview=True" in you rc file) and report any problems.
> Regards,
>
> -JJ
>   
>
> 
>
> 
>
> ------
>   
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git questions

[Michael Droettboom]

I have successfully used the git mirror to commit changes to the 
maintenance branch.  I've updated the matplotlib developer docs to 
describe how to do it (not that bad really), though it takes a while 
given the v0_98_4 "oops" branch ;)  I have yet to figure out all the 
loop-de-loops required to merge from the maintenance branch to the trunk 
in git and then push that all back to SVN (should be possible, but may 
not play well with svnmerge, anyway).  The good news is that, as always, 
svnmerge still works for that purpose.

Mike

Michael Droettboom wrote:
> Thanks.  These are really helpful pointers.  For me, this is the one 
> missing piece that would help me use git full-time, particularly with 
> the way matplotlib and other projects I work on are laid out in SVN.  So 
> I'm pretty motivated to figure this out.
>
> I'll certainly share any findings in this regard.
>
> Cheers,
> Mike
>
> Andrew Straw wrote:
>   
>> Hi Mike,
>>
>> I have not imported the branches. ( IIRC, this was there were several
>> that weren't MPL but other parts of the repo such as py4science,
>> toolkits and so on).  It may be possible to add just the 0.98.5
>> maintenance branch without the others, but I won't have a chance
>> immediately to play around with that.
>>
>> To add all the branches to your git repo, you might be able to add
>> something like "branches = branches/*:refs/remotes/branches/*" to the
>> [svn-remote "svn"] section of .git/config and re-do "git svn fetch"...
>> This will grab all the branches over all svn history, which will, I
>> think, pull in py4science and toolkits branches... And I guess the
>> download time from svn will be extremely long... In that case it's
>> probably better to rsync from sourceforge's server to a local disk and
>> do the git svn checkout that way making a whole new git repo.
>>
>> It may be worth attempting to talk to some real git/svn gurus at this
>> point about tracking (only one or a couple) svn branches with git
>> branches. So far, I've only dealt with the trunk in my git/svn
>> interoperation experience.
>>
>> -Andrew
>>
>> Michael Droettboom wrote:
>>   
>> 
>>> Thanks.  I've incorporated your docs into the developer documentation.
>>>
>>> My next experiment will be to see if I can track the 0.98.5 maintenance 
>>> branch with git.  SVN tags/* show up as available remote branches, but 
>>> not branches/*, which leaves me a bit stumped?  If you've done this and 
>>> there's a quick answer, let me know, otherwise I'll do a little digging 
>>> to see if it's possible.
>>>
>>> Mike
>>>
>>> Andrew Straw wrote:
>>> 
>>>   
>>>> Hi Michael,
>>>>
>>>> The main issue is that we can't use git "normally" because the main
>>>> history will be kept with svn. Thus, there's going to be a lot of
>>>> history rewriting going on through the rebase command. (These
>>>> complications are obviously not the ideal scenario for git newbies...)
>>>> Rather than answer your questions directly, I'll walk you through how I
>>>> do things. (This is not tried on the MPL svn repo, but some a private
>>>> svn repo. I don't see any fundamental differences, though. So this
>>>> should work.)
>>>>
>>>> (Hopefully this will be cut-and-pasteable ReST, which could go in the
>>>> docs somewhere):
>>>>
>>>> Making a git feature branch and committing to svn trunk
>>>> ---
>>>>
>>>> Start with a virgin tree in sync with the svn trunk on the git branch
>>>> "master"::
>>>>
>>>>   git checkout master
>>>>   git svn rebase
>>>>
>>>> To create a new, local branch called "whizbang-branch"::
>>>>
>>>>   git checkout -b whizbang-branch
>>>>
>>>> Do make commits to the local branch::
>>>>
>>>>   # hack on a bunch of files
>>>>   git add bunch of files
>>>>   git commit -m "modified a bunch of files"
>>>>   # repeat this as necessary
>>>>
>>>> Now, go back to the master branch and append the history of your branch
>>>> to the master branch, which will end up as the svn trunk::
>>>>
>>>>   git checkout master
>>>>   git svn

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

Since I suspect this change will be a little bit of work, I just wanted 
to put my hand up and say I'm looking into it so we don't duplicate 
effort here.

I think it's a worthwhile experiment, in any case.

Mike

Andrew Hawryluk wrote:
>
> I’m really excited about the new path simplification option for vector 
> output formats. I tried it the first time yesterday and reduced a PDF 
> from 231 kB to 47 kB. Thanks very much for providing this feature!
>
> However, I have noticed that the simplified paths often look more 
> jagged than the original, at least for my data. I can recreate the 
> effect with the following:
>
> [start]
>
> import numpy as np
>
> import matplotlib.pyplot as plt
>
> x = np.arange(-3,3,0.001)
>
> y = np.exp(-x**2) + np.random.normal(scale=0.001,size=x.size)
>
> plt.plot(x,y)
>
> plt.savefig('test.png')
>
> plt.savefig('test.pdf')
>
> [end]
>
> A sample output is attached, and close inspection shows that the PNG 
> is a smooth curve with a small amount of noise while the PDF version 
> has very noticeable changes in direction from one line segment to the 
> next.
>
> <> <>
>
> The simplification algorithm (agg_py_path_iterator.h) does the following:
>
> If line2 is nearly parallel to line1, add the parallel component to 
> the length of line1, leaving it direction unchanged
>
> which results in a new data point, not contained in the original data. 
> Line1 will continue to be lengthened until it has deviated from the 
> data curve enough that the next true data point is considered 
> non-parallel. The cycle then continues. The result is a line that 
> wanders around the data curve, and only the first point is guaranteed 
> to have existed in the original data set.
>
> Instead, could the simplification algorithm do:
>
> If line2 is nearly parallel to line1, combine them by removing the 
> common point, leaving a single line where both end points existed in 
> the original data
>
> Thanks again,
>
> Andrew Hawryluk
>
>
> 
>
> 
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ------------
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] svnmerge broken?

[Michael Droettboom]

You need the '-S' parameter to specify a branch.  Otherwise, any arguments 
after the command name are just paths within the working copy, just like most 
other svn commands.

So you need to do:

> svnmerge.py merge -S v0_98_5_maint

I just tested a change to the branch followed by a merge and everything 
seems to be working fine here.

Eric Firing wrote:
> John Hunter wrote:
>   
> svnmerge init 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_5_maint
>   
That would have no effect without a following commit anyway... but 
please don't do that if you're not sure what you're doing.  That command 
really should only ever be needed once.  It's pretty hard to get into a 
state where it would ever need to be done again for a particular branch.
> but it looks like I was still in the wrong directory when I did that, so 
> I don't know if it had any useful effect.
>
> After getting into the right directory, some combination of svn up and 
> svnmerge merge seemed to get everything straightened out, with a little 
> editing to resolve conflicts along the way.
>   
You can do merges from within subdirectories, and it works just like 
most other svn commands when run from a subdirectory.  Generally, 
though, I like to catch all available merges and run from the root of 
the source tree.
> That was last night, in the misty past.  Now it looks like I am back 
> with the original problem I started with last night, and which you also 
> reported:
>
> efir...@manini:~/programs/py/mpl/mpl_trunk$ svnmerge avail 
> /branches/v0_98_5_maint
> svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory
>   
Again, you're specifying a path that doesn't exist within the source 
tree.  There is no need to specify a path (generally) with the "svnmerge 
avail" command.
> So, I'm baffled again.  It is as if Jae-Joon's commit since mine of last 
> night, and my corresponding "svn up" this morning, wiped out the 
> svnmerge tracking info.
>
> I suspect a brief wave of Mike's magic wand tomorrow morning will clear 
> away the fog.
>   
I think this all comes down to missing the '-S'.  I didn't need to get 
out my wand for this one... ;)

Mike

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

> Thanks for looking into this! The new plot is much improved, and the
> simplified calculations are a pleasant surprise. I was also testing the
> previous algorithm with solid_joinstyle set to "round" as it is the
> default in my matplotlibrc.
>
> I am probably not able to build your patch here, unless building
> matplotlib from source on Windows is easier than I anticipate. May I
> send you some data off the list for you to test?
>   
No problem.  I'd also want testing from others -- there aren't a lot of 
examples in matplotlib itself where simplification even kicks in.

Mike

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

I've checked this change into SVN so others can test it out.

Assuming we don't discover any cases where this is clearly inferior, it 
should make it into the next major release.

Mike

Andrew Hawryluk wrote:
>> -Original Message-
>> From: Michael Droettboom [mailto:md...@stsci.edu]
>> Sent: 16 Jan 2009 1:31 PM
>> To: Andrew Hawryluk
>> Cc: matplotlib-devel@lists.sourceforge.net
>> Subject: Re: [matplotlib-devel] path simplification can decrease the
>> smoothness of data plots
>>
>> Michael Droettboom wrote:
>> 
>
> ...
>
>   
>> I've attached a patch that will only include points from the original
>> data in the simplified path.  I hesitate to commit it to SVN, as these
>> things are very hard to get right -- and just because it appears to
>> work better on this data doesn't mean it doesn't create a regression
>> 
> on
>   
>> something else... ;)  That said, it would be nice to confirm that this
>> solution works, because it has the added benefit of being a little
>> simpler computationally.  Be sure to blitz your build directory when
>> testing the patch -- distutils won't pick it up as a dependency.
>>
>> I've attached two PDFs -- one with the original (current trunk)
>> behavior, and one with the new behavior.  I plotted the unsimplified
>> plot in thick blue behind the simplified plot in green, so you can see
>> how much deviation there is between the original data and the
>> simplified line (you'll want to zoom way in with your PDF viewer to
>> 
> see
>   
>> it.)
>>
>> I've also included a new version of your test script which detects
>> "new"
>> data values in the simplified path, and also seeds the random number
>> generator so that results are comparable.  I also set the
>> solid_joinstyle to "round", as it makes the wiggliness less
>> 
> pronounced.
>   
>> (There was another thread on this list recently about making that the
>> default setting).
>>
>> Cheers,
>> Mike
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>> 
>
> Thanks for looking into this! The new plot is much improved, and the
> simplified calculations are a pleasant surprise. I was also testing the
> previous algorithm with solid_joinstyle set to "round" as it is the
> default in my matplotlibrc.
>
> I am probably not able to build your patch here, unless building
> matplotlib from source on Windows is easier than I anticipate. May I
> send you some data off the list for you to test?
>
> Regards,
> Andrew
>
> NOVA Chemicals Research & Technology Centre
> Calgary, Canada
>   

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots

[Michael Droettboom]

a wrote:
> Michael Droettboom  writes:
>
>   
>> I've checked this change into SVN so others can test it out.
>>
>> Assuming we don't discover any cases where this is clearly inferior, it 
>> should make it into the next major release.
>>
>> Mike
>>
>> 
>
> Hi,
>
> This change looks good- it has the advantage of choosing points that actually
> lie on the curve, which is better visually, and would seem to be a better
> solution for publication quality plots.
>
> The method for simplifying the paths is quite simple and effective, but a bit
> crude- there are other algorithms you might look into for simplifying lines:
>
>   http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm
>
> This one is fairly simple to implement and has the advantage that you have 
> some
> control over the errors- the deviation from your simplified path and the 
> actual
> path.
>   
Thanks for the pointers.

The original simplification code was written by John Hunter (I believe), 
and I don't know if it was designed by him also or is a replication of 
something published elsewhere.  So I take no credit for and have little 
knowledge of its original goals.

However, IMHO the primary purpose of the path simplification in 
matplotlib is to improve interactive performance (and smaller file size 
is just an convenient side effect of that), I would hesitate to use an 
algorithm that is any worse than O(n), since it must be recalculated on 
every pan or zoom since the simplification is related to *pixels* not 
data units.  Even on modern hardware, it is a constant battle keeping 
the inner drawing loop fast enough.  We could, of course, make the 
choice of algorithm user-configurable, or use something more precise 
when using a non-interactive backend, but then we would have two 
separate code paths to keep in sync and bug free --- not a choice I take 
lightly.

The trick with the present algorithm is to keep the error rate at the 
subpixel level through the correct selection of perpdNorm.  It seems to 
me that the more advanced simplification algorithm is only necessary 
when you want to simplify more aggressively than the pixel level.  But 
what hasn't been done is a proper study of the error rate along the 
simplified path of the current approach vs. other possible approaches.  
Even this latest change was verified by just looking at the results 
which seemingly are better on the data I looked at.  So I'm mostly 
speaking from my gut rather than evidence here.
> Also, you might consider to make the path simplification tolerance (perdNorm2)
> an adjustable parameter in the matplotlibrc file:
>
>   #src/agg_py_path_iterator.h
>
> //if the perp vector is less than some number of (squared)
> //pixels in size, then merge the current vector
> if (perpdNorm2 < (1.0 / 9.0))
>   
That sounds like a good idea.  I'll have a look at doing that.

Mike

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in Agg-based backends when yscale == "log"?

[Michael Droettboom]

Thanks for this.

I believe both of these examples illustrate a shortcoming in Agg when 
the distance between two points on either end of a line is too great.

I'll do some digging around and see what may be causing this and if any 
limits can be adjusted -- I may not get to this today, however.

Mike

João Luís Silva wrote:
> Jan Müller wrote:
>   
>> Hi,
>>
>> The simple code snippet at the end of this mail should plot a single line. 
>>
>> 
>
> I can confirm this bug on Ubuntu running matplotlib svn revision 6827. 
> However I think it doesn't have to do with the log-scale but with the 
> big variations on the x-scale and the custom xscale. I've reproduced a 
> similar behavior with the following script (pan and zoom to see the 
> buggy behavior).
> 
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> x = np.array([1.0,2.0,3.0,1.0E5,2.0E5])
> y = np.arange(len(x))
> plt.plot(x,y)
> plt.xlim(xmin=2,xmax=6)
> plt.show()
>
> 
>
> Best Regards,
> João Silva
>
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in Agg-based backends when yscale == "log"?

[Michael Droettboom]

Okay -- I think I've at least narrowed it down to a cause.  Agg uses 
fixed-point arithmetic to render at the low-level -- by default it uses 
24.8 (i.e. 24 integer bits and 8 fractional bits).  Therefore, it can 
only handle pixel coordinates in the range -2^23 to 2^23.  Both of the 
provided examples, after the data has been scaled, draw outside of this 
range, which results in integer overflow, hence things going in the 
wrong direction etc.

We could change the fixed point in agg_basics.h, but I hesitate to do 
so, as it's at the expense of fine detail.  We could possibly move to 
64-bits, but I'm not sure how easy that would be, or what the impact 
might be on 32-bit platforms.


//poly_subpixel_scale_e
// These constants determine the subpixel accuracy, to be more precise,
// the number of bits of the fractional part of the coordinates.
// The possible coordinate capacity in bits can be calculated by 
formula:
// sizeof(int) * 8 - poly_subpixel_shift, i.e, for 32-bit integers and
// 8-bits fractional part the capacity is 24 bits.
enum poly_subpixel_scale_e
{
poly_subpixel_shift = 8,  
//poly_subpixel_shift
poly_subpixel_scale = 1< Thanks for this.
>
> I believe both of these examples illustrate a shortcoming in Agg when 
> the distance between two points on either end of a line is too great.
>
> I'll do some digging around and see what may be causing this and if any 
> limits can be adjusted -- I may not get to this today, however.
>
> Mike
>
> João Luís Silva wrote:
>   
>> Jan Müller wrote:
>>   
>> 
>>> Hi,
>>>
>>> The simple code snippet at the end of this mail should plot a single line. 
>>>
>>> 
>>>   
>> I can confirm this bug on Ubuntu running matplotlib svn revision 6827. 
>> However I think it doesn't have to do with the log-scale but with the 
>> big variations on the x-scale and the custom xscale. I've reproduced a 
>> similar behavior with the following script (pan and zoom to see the 
>> buggy behavior).
>> 
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>>
>> x = np.array([1.0,2.0,3.0,1.0E5,2.0E5])
>> y = np.arange(len(x))
>> plt.plot(x,y)
>> plt.xlim(xmin=2,xmax=6)
>> plt.show()
>>
>> 
>>
>> Best Regards,
>> João Silva
>>
>>
>> --
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> 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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] gtk backend silently ignores all exceptions

[Michael Droettboom]

Sorry.  That was a mistake to commit it -- I did this while I was trying 
to track down a segfault.  I will revert it.

Mike

Jae-Joon Lee wrote:
> Michael,
>
> It seems that the gtk backend in the current svn silently ignores ALL
> exceptions raised during the drawing.
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/backends/backend_gtk.py?r1=6696&r2=6793
>
> Is this necessary? I don't think we want to do this.
>
> Regards,
>
> -JJ
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] online docs updating?

[Michael Droettboom]

Ryan May wrote:
> John Hunter wrote:
>   
>> On Tue, Jan 27, 2009 at 3:33 PM, Ryan May  wrote:
>> 
>>> Hi,
>>>
>>> Do the online docs automatically update themselves from changes in SVN?  I
>>> thought there was a nightly cron.  I made some changes a few days ago (just 
>>> a few
>>> typos) and they haven't shown up online yet.  The changes were to
>>> doc/users/shell.rst.  I'm assuming I should see the corresponding changes on
>>> http://matplotlib.sourceforge.net/users/shell.html.
>>>   
>> I had them in a cron and voluntarily disabled it.  I'm amenable to
>> re-enabling it.  The problem is that as examples become available in
>> svn, they automatically get pushed out to the gallery, but these may
>> not run on the latest released version.  I thought perhaps the site
>> should more closely track the latest released version, so the last few
>> times I've pushed the docs out, I did so from the branch.  So if you
>> want to see doc changes get pushed out sooner, you should patch the
>> branch and merge to the trunk.  I am in general a big fan of
>> encouraging people to use the svn snapshots as much as possible, and
>> updating the gallery and site docs nightly helps this because the new
>> features in the gallery entice them, but in the absence of nightly
>> builds and snapshots I don't think this is too helpful.
>> 
>
> Is there any way to merge changes done on the trunk onto the branch?  Or 
> should I
> just do it manually?
>   
I could set up merging from trunk to branch, but I'd like to discourage 
that in general.  While we generally want all relevant changes merged 
from the branch to the trunk, that is not true in reverse (many things 
on the trunk are too risky to go to the branch).  So, you end up doing a 
lot of manual cherry-picking when going in that direction, making 
svnmerge less helpful anyway.

Generally, if I forget to do something on the branch, I just do an SVN 
diff of what I did to the trunk, use that to patch my working copy of 
the branch, and then commit the branch.

Mike

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Refactoring/bugfixing of path simplification was: Re: Bug in Agg-based backends when yscale == "log"?

[Michael Droettboom]

I just completed some open-heart surgery on the path simplification code 
to resolve this and other issues.  Though the integer overflow bug is on 
the maintenance branch, the proper solution was large enough and risky 
enough that I have only committed it to the development trunk.

Before, the path simplification code jumbled a number of discrete steps 
together in the code:

   1. Nan (nonfinite) handling
   2. Clipping
   3. Quantization
   4. Simplification


This has been rewritten (see path_converters.h) so each step is handled 
by a separate iterator class that can be independently switched on-and-off.

This refactoring made it much easier to rewrite the clipping algorithm 
to actually bisect line segments at the figure boundary, rather than (as 
before) simply removing vertices after crossing outside the boundary.

Additionally, nan-value-handling was formerly handled in both Python and 
C++, which was both double the maintenance and slower in Python.  Now, 
the C++ version of the entire pipeline has been exposed to Python, so we 
have a single (and faster) code path to debug.  (Note that whereas it 
behaves as an iterator in C++, it actually writes to a new array in the 
Python-wrapped version to avoid lots of tiny Python function calls).  
All backends now use this pipeline (through the use of 
Path.iter_segments). 

A side effect of this is that whereas before Python backends were forced 
to get clipping and simplification together, they now have independent 
control.  This fixes two long-standing bugs in non-Agg backends:

   1.   large values would cause integer overflow (causes the lines to
  appear to go in the wrong direction)
   2.   clipping should be turned off for filled regions, but that
  wasn't previously possible without also losing simplification


Lastly, the threshold of angular similarity below which simplification 
will start removing vertices has been exposed to the user as an rcParam 
(path.simplify_threshold).  It can also be set on an individual basis to 
any Path object.

The one remaining major piece is to get the native Cocoa backend to 
support this infrastructure.  Right now, it reimplements its own 
nan-handling and doesn't perform any of the other steps.  This will 
probably require some code compiled in C++ but exported as C to make it 
accessible to Objective-C.  The general roadmap is in "cleanup_path" in 
_path.cpp.  I'm happy to help with this, but without a Mac, it will be 
hard to compile and test these changes.

I've looked through all the backend_driver images, and everything seems 
ok, but let me know if you see any strangely drawn paths etc.

Cheers,
Mike



Michael Droettboom wrote:
> Okay -- I think I've at least narrowed it down to a cause.  Agg uses 
> fixed-point arithmetic to render at the low-level -- by default it uses 
> 24.8 (i.e. 24 integer bits and 8 fractional bits).  Therefore, it can 
> only handle pixel coordinates in the range -2^23 to 2^23.  Both of the 
> provided examples, after the data has been scaled, draw outside of this 
> range, which results in integer overflow, hence things going in the 
> wrong direction etc.
>
> We could change the fixed point in agg_basics.h, but I hesitate to do 
> so, as it's at the expense of fine detail.  We could possibly move to 
> 64-bits, but I'm not sure how easy that would be, or what the impact 
> might be on 32-bit platforms.
>
> 
> //poly_subpixel_scale_e
> // These constants determine the subpixel accuracy, to be more precise,
> // the number of bits of the fractional part of the coordinates.
> // The possible coordinate capacity in bits can be calculated by 
> formula:
> // sizeof(int) * 8 - poly_subpixel_shift, i.e, for 32-bit integers and
> // 8-bits fractional part the capacity is 24 bits.
> enum poly_subpixel_scale_e
> {
> poly_subpixel_shift = 8,  
> //poly_subpixel_shift
> poly_subpixel_scale = 1< //poly_subpixel_scale
> poly_subpixel_mask  = poly_subpixel_scale-1,  
> //poly_subpixel_mask
> };
>
>
> One thing I will look into is whether the line simplification algorithm 
> can be extended to actually clip the lines when they go outside of the 
> image range.  At the moment, it does some work to reduce the number of 
> points outside of the image, but it always draws at least one point 
> outside at its original location.  It looks like Agg has some of the 
> pieces necessary to do this -- whether it's feasible to integrate that 
> into our existing line simplification algorithm remains to be seen.
>
> Mike
>
>
> Michael Droettboom wrote:
>   
>> Thanks for this.
>>
>> I believe both of these examples illustrate a shortcoming in Agg when 

Re: [matplotlib-devel] python make.py html

[Michael Droettboom]

Comments below.

Nils Wagner wrote:
> Hi all,
>
> I tried to build the HTML documentation.
> Here are some failures
>
>
> matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py
> Traceback (most recent call last):
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>  runfile(fullpath)
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>  module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>File "axes_divider.py", line 168
>   rs, as = s.get_size(renderer)
>^
>   SyntaxError: invalid syntax
>
>warnings.warn(s)
> examples/pylab_examples/axes_grid 
> /home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py:190: 
> UserWarning: Exception running plot 
> /home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_grid.py
> Traceback (most recent call last):
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>  runfile(fullpath)
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>  module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>File "axes_grid.py", line 5, in 
>File 
> "/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py",
>  
> line 168
>   rs, as = s.get_size(renderer)
>^
>   SyntaxError: invalid syntax
>   
I can't reproduce this here.  What version of matplotlib are you running?
>warnings.warn(s)
>   Traceback (most recent call last):
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>  runfile(fullpath)
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>  module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>File "geo_demo.py", line 9, in 
>File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/pyplot.py", 
> line 636, in subplot
>  a = fig.add_subplot(*args, **kwargs)
>File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/figure.py", 
> line 690, in add_subplot
>  a = subplot_class_factory(projection_class)(self, 
> *args, **kwargs)
>File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/axes.py", 
> line 7460, in __init__
>  self._axes_class.__init__(self, fig, self.figbox, 
> **kwargs)
>File "custom_projection_example.py", line 35, in 
> __init__
> TypeError: expected string or Unicode object, NoneType 
> found
> oc/sphinxext/plot_directive.py:190: UserWarning: Exception 
> running plot 
> /home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/loadrec.py
> Traceback (most recent call last):
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>  runfile(fullpath)
>File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>  module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>File "loadrec.py", line 14, in 
>File 
> "/home/nwagner/local/lib64/python2.6/site-packages/mpl_toolkits/exceltools.py",
>  
> line 31, in 
>  raise ImportError('You must install xlwt or 
> pyExcelterator to use the exceltools')
> ImportError: You must install xlwt or pyExcelterator to 
> use the exceltools
>   
This is exactly as it says:

"You must install xlwt or pyExcelterator to 
use the exceltools"

Since that particular example uses the exceltools, and you haven't installed 
it's requirements, it can't generate the example.  Worst case, however, it 
should continue to generate the rest of the docs without it.

Mike

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] plotfile_demo.py broken?

[Michael Droettboom]

I noticed plotfile_demo.py has recently broken.  Seems to be units 
related.  Before I look into it further, is there an obvious fix for 
anyone else?

Traceback (most recent call last):
  File "plotfile_demo.py", line 18, in 
plotfile(fname, (0,5,6), plotfuncs={5:'bar'})
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line 
1513, in plotfile
func(x, y, **kwargs)
  File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", 
line 4104, in bar
left = xconv.convert( left, units )
TypeError: convert() takes exactly 3 arguments (2 given)
 > /home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py(4104)bar()
-> left = xconv.convert( left, units )


Mike

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pan and zoom tool makes markers disappear

[Michael Droettboom]

Thanks for narrowing this down.  I have (hopefully) fixed this in r6864.

Cheers,
Mike

João Luís Silva wrote:
> Michael Droettboom wrote:
>> Thanks for the report.  I'm not actually able to reproduce this here 
>> -- though I suspect this could be related to the recent path 
>> simplification changes.
>>
>> Taking a stab in the dark -- have you tried removing the build 
>> directory and rebuilding?  distutils doesn't do dependency-tracking, 
>> so if header files change it often doesn't rebuild enough.
>>
>
> I didn't remove the build subdirectory, but always did a python 
> setup.py clean / remove all mpl stuff from site-packages. Anyway, this 
> time I did remove the build subdirectory but the problem remains. The 
> bug seems to be backend independent and is there since the first 
> support of markevery, on revision 6631. The problem seems to be that 
> the function draw() of Line2D keeps removing the n-th marker for 
> markevery=n, even if it has already done so. I tried to reproduce this 
> on Windows, but the latest release (0.98.5) doesn't support markevery.
>
> My 32-bit Ubuntu installation is pretty standard. I could reproduce 
> this on two different computers with the same Ubuntu 8.10 and mpl svn.
>
> If I run this script, select the pan/zoom tool and just click on the 
> plot (not dragging, just left clicking in place) each click will 
> remove every second marker until there are no markers left.
>
> --
> import matplotlib.pyplot as pl
> import numpy as np
>
> pl.plot(np.arange(100.0),np.arange(100.0),marker="+",markevery=2)
> pl.show()
> --
>
> Best regards,
> João Silva

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pan and zoom tool makes markers disappear

[Michael Droettboom]

There seems to have been an indentation error there.

Please update and try again now.

Thanks,
Mike

João Luís Silva wrote:
> Michael Droettboom wrote:
>> Thanks for narrowing this down.  I have (hopefully) fixed this in r6864.
>>
>
> It did fix my previous examples. However it broke the other form of 
> markevery, a 2-int tuple. From the set_markevery docs:
>
> Set the markevery property to subsample the plot when using
> markers.  Eg if ``markevery=5``, every 5-th marker will be
> plotted.  *every* can be
>
> None
> Every point will be plotted
>
> an integer N
> Every N-th marker will be plotted starting with marker 0
>
> A length-2 tuple of integers
> every=(start, N) will start at point start and plot every 
> N-th marker
>
>
> ACCEPTS: None | integer | (startind, stride)
>
>
> I don't know if the tuple version ever worked, for I couldn't figure 
> it out, but if it is to remain it now breaks mpl with:
>
> [...]
>   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
> 1658, in draw
> a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
> 521, in draw
> markerFunc(renderer, gc, subsampled, affine.frozen())
> UnboundLocalError: local variable 'subsampled' referenced before 
> assignment
>
>
> Example script:
> --
> import matplotlib.pyplot as pl
> import numpy as np
>
> pl.plot(np.arange(100.0),np.arange(100.0),marker="+",markevery=(50,5))
> pl.show()
> --
>
> I don't know what is the purpose and how to make the tuple version 
> work. Maybe John can shed some light into this?
>
> João Silva

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pan and zoom tool makes markers disappear

[Michael Droettboom]

Thanks for the report.  I'm not actually able to reproduce this here -- 
though I suspect this could be related to the recent path simplification 
changes.

Taking a stab in the dark -- have you tried removing the build directory 
and rebuilding?  distutils doesn't do dependency-tracking, so if header 
files change it often doesn't rebuild enough.

Mike

João Luís Silva wrote:
> Hi,
>
> I found a minor bug. Clicking with the pan and zoom tool on a plot with 
> markers and the markevery option makes the markers disappear.
>
> OS: Ubuntu
> Matplotlib svn revision 6861
> Backend: GTKAgg. Didn't test any others.
>
> Example script:
>
> 
> import matplotlib.pyplot as pl
> import numpy as np
>
> pl.plot(np.arange(100.0),np.arange(100.0),marker="+",markevery=5)
> pl.show()
> 
>
> Just left click with the pan and zoom tool, or otherwise use the pan and 
>   zoom tool and the markers will disappear.
>
> Regards,
> João Silva
>
>
>
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] FW: Polar Plot Design Issues

[Michael Droettboom]

You can get this behavior you are asking for by passing "resolution=1" 
to polar.  (This has been there for ages, but unfortunately wasn't 
documented until recently).  We can consider making 1 the default.

There are cases in which the automatic interpolation is useful, but in 
the present implementation the onus is on the user to avoid this "going 
the long way" problem.

Mike

James Evans wrote:
> Michael,
>
> John said you were the one to go to for this one.  I was wondering if you had 
> any comments about the following?
>
> --James Evans
>
>   
>> All,
>>
>> While looking over the polar plot code I came across the following issue:  
>> When plotting something
>> like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line will 
>> actually wrap around the
>> origin of the plot before reaching its destination.  Initially I thought 
>> that this was correct
>> behavior.  The line numerically passed through all angles between 2 and 358 
>> degrees in a linear
>> fashion.  However after consulting several colleagues and text books I 
>> believe that the behavior is
>> actually wrong.
>>
>> It is my understanding that for polar plots there is no linear mapping of 
>> the axes as it is currently
>> implemented.  Rather for a simple two-point line defined in polar 
>> coordinates, the line should
>> essentially take the direct route.  This is highlighted by the two-point 
>> equation of a line for polar
>> plots:
>>
>> r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) )
>>
>> If you were to plug in the two points given above, then increment theta (t) 
>> from 2 degrees to 358
>> degrees, then convert to Cartesian cords, and plot the results, you will get 
>> the correct line that
>> directly crosses the zero degree line and not one that wraps around the 
>> origin.
>>
>> Is the polar plot function implemented this way on purpose?  Which way 
>> should it really be
>> implemented?
>> 
>
>   

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


--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] backends/_tkagg.so: undefined symbol

[Michael Droettboom]

Sorry -- that was caused by my moving of C++ code around yesterday.  
Please update and try again.  You may need to remove your build 
directory and do a full rebuild.

Cheers,
Mike

Nils Wagner wrote:
> Hi all,
>
> I am using latest svn.
> My script worked until last week. If I run it now
>
> matplotlib version 0.98.6svn
> verbose.level helpful
> interactive is False
> units is False
> platform is linux2
> Using fontManager instance from 
> /data/home/nwagner/.matplotlib/fontList.cache
> Traceback (most recent call last):
>File "read_csv.py", line 2, in 
>  from pylab import plot, show,subplot, xlabel, ylabel, 
> savefig, legend, connect, close
>File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/pylab.py", 
> line 1, in 
>  from matplotlib.pylab import *
>File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
> line 253, in 
>  from matplotlib.pyplot import *
>File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyplot.py", 
> line 75, in 
>  new_figure_manager, draw_if_interactive, show = 
> pylab_setup()
>File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/__init__.py",
>  
> line 25, in pylab_setup
>  globals(),locals(),[backend_name])
>File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
>  
> line 8, in 
>  import tkagg # Paint image to Tk 
> photo blitter extension
>File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/tkagg.py",
>  
> line 1, in 
>  import _tkagg
> ImportError: 
> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/_tkagg.so:
>  
> undefined symbol: _Z15py_convert_bboxP7_objectRdS1_S1_S1_
>
> Any idea ?
>
> Nils
>
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in latex with \dots

[Michael Droettboom]

There was both a parser bug (where accents were taking precedence over 
symbols), and a mapping bug (where ldots was mapped to the wrong Unicode 
code point).  Both of these should now be fixed on the branch and 
trunk.  Let me know if you see any further problems.

Mike

Fernando Perez wrote:
> Howdy,
>
> the attached screenshot shows the output in matplotlib of:
>
> In [18]: plot([1,2])
> Out[18]: []
>
> In [19]: title(r'$a+b+\dots+\dot{s}+\ldots$')
> Out[19]: 
>
> along with the PostScript that Latex produces for the same equation.
> There are two bugs, I think:
>
> - \dots --> \dot{s} by matplotlib
> - \ldots rendered by MPL centered vertically, while in latex those are
> 'lower' dots.
>
> Should I open an SF ticket for this, or is it  a quick fix?
>
> Cheers,
>
> f
>   
>
> 
>
> 
>
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] status update on using git to interact with MPL svn repo

[Michael Droettboom]

Andrew Straw wrote:
> For the past month or two, I've been experimenting with using git to
> interact with the MPL subversion repository. The bottom line is that I I
> haven't been able to create any kind of one-to-one mapping between git
> branches and svnmerge.py branches. As we're using svnmerge.py on top of
> subversion to manage the trunk and release branches, I see this as a
> pretty fatal flaw.
>   
I basically agree with Andrew, but I want to elaborate on this point for 
those who haven't been trying this stuff out for themselves.

I documented how to use svn maintenance branches from git, and this is 
in the matplotlib source, but doesn't seem to have pushed out to the 
sourceforge site.  This might be due to the automatic doc updating being 
turned off recently -- I haven't followed that thread closely.  Because 
of this, I don't know if Andrew's comments aren't taking that into 
account... he could have reached the same conclusion either way... :)

It is possible to work on maintenance branches from git, but I haven't 
figured out a way to do the merging without svnmerge.py.  I've worked 
this way for a while, and yes it's kludgy, but not too bad.  I just keep 
a SVN checkout of the trunk around specifically for running 
svnmerge.py.  So there is a one-to-one mapping between svn branches and 
git branches, it's just not a bidirectional one-to-one mapping, and 
unfortunately any advantages to git's merging tools are useless in that 
situation.  But, honestly, I haven't really missed them.
> So, while I can use git to interact with the trunk (and create and use
> my own feature branches locally using git), and while using git is very
> nice for browsing history or bisecting the revision in which a bug
> cropped up, I think I've reached a point where I don't think interaction
> with svnmerge.py's branches is going to work without investing more time
> than I'm willing to give into understanding (and possibly improving)
> git-svn.
>   
My own gut feeling is that while a pure DVCS environment might be nice 
someday, the compromises of git-svn makes the whole thing sort of +0 for 
me.  I can't say that I've felt much more productive using it over raw 
svn/svnmerge.py with matplotlib.  So I, too, am giving it a pass for 
now, but for slightly different reasons.
> So, therefore, I'd say the issue of using a distributed version control
> system for MPL has not reached any real conclusion. Thus, we may want to
> visit this issue at some point. Perhaps once Python and/or numpy have
> made decisions. The Python-dev team seems to be working this out right
> now: http://www.python.org/dev/peps/pep-0374/
>   
I like the approach the PEP (Brett Cannon) is taking.  I think it makes 
a lot of sense to let those dedicated and smart core Python folks do 
some trailblazing for us :)

Mike

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


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Build Failure on Windows using Python25

[Michael Droettboom]

Just getting to this thread now -- I think this was introduced in my 
recent changes.  I'm used to being on platforms where this is defined, 
so I forgot that it's not always there.

In this specific case "unsigned char" is probably equivalent everywhere 
we run, so we might as well just do that.  If a Windows user can verify 
that fix works, I'll fix it in SVN.

Mike

Michael Abshoff wrote:
> On Fri, Feb 6, 2009 at 3:03 PM, Ryan May  wrote:
>   
>> On Fri, Feb 6, 2009 at 4:48 PM, Andrew Straw  wrote:
>> 
>>> Ryan May wrote:
>>>   
 On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw >>> > wrote:

 Patrick,

 Can you see if adding "#include " at the top of
 src/path.cpp
 will do the job?

 I'm not super-optimistic, though -- I think this is defined by the
 C99
 standard, which I'm not sure Microsoft supports.


 Well, we're also talking about C++ here and not C, so C99 does not
 apply.  A quick googling around seems to indicate that some of the
 open source compilers support such a type, but it not standardized by
 C++.
 
>>> There is no  or the type is not defined in stdint.h?
>>>
>>> Maybe as a workaround you could use mingw...
>>>   
>> I meant that uint8_t is not a standardized C++ type.  If that's the case,
>> wouldn't it be better to tweak the code to use something standard rather
>> than just use a compiler that supports the non-standard type?  Especially
>> given that the official Python 2.5 build uses this compiler?
>> 
>
> Please stick with standard types.
>
> And MSVC 2005 and higher do have C99 support, it is just unfortunate
> that it is not complete.
>
>   
>> Ryan
>> 
>
> Cheers,
>
> Michael
>
>   
>> --
>> Ryan May
>> Graduate Research Assistant
>> School of Meteorology
>> University of Oklahoma
>>
>> --
>> Create and Deploy Rich Internet Apps outside the browser with
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code
>> to
>> build responsive, highly engaging applications that combine the power of
>> local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> 
>
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updated (URLs) matplotlibrc files

[Michael Droettboom]

Thanks for the patch.  I've committed this to the branch and trunk so it 
should make it into the next bugfix release.

For future reference, lib/matplotlib/mpl-data/matplotlibrc is built from 
matplotlibrc.template which is under version control, so you can always 
just send an svn diff against that if you find further errors.

Cheers,
Mike

Sandro Tosi wrote:
> Hello,
> I've updated lib/matplotlib/mpl-data/matplotlibrc to use new URLs on
> matplotlib.sf.net (there's just one I'm not sure marked with '(** NOT
> SURE**)').
>
> Sadly, that file is not under SVN so I don't have a "svn diff" to
> propose, but the whole updated file, here attached; if it might be
> easier, here is the sed cli I used (all on a single line):
>
> sed 
> 's|http://matplotlib.sourceforge.net/interactive.html|http://matplotlib.sourceforge.net/users/shell.html
> \(\*\*NOT SURE\*\*\)|;
> s|http://matplotlib.sourceforge.net/matplotlib.lines.html|http://matplotlib.sourceforge.net/api/artist_api.html\#module-matplotlib.lines|;
> s|http://matplotlib.sourceforge.net/matplotlib.patches.html|http://matplotlib.sourceforge.net/api/artist_api.html\#module-matplotlib.patches|;
> s|http://matplotlib.sourceforge.net/matplotlib.font_manager.html|http://matplotlib.sourceforge.net/api/font_manager_api.html|;
> s|http://matplotlib.sourceforge.net/matplotlib.text.html|http://matplotlib.sourceforge.net/api/artist_api.html\#module-matplotlib.text|;
> s|http://matplotlib.sourceforge.net/matplotlib.axes.html\#Axes|http://matplotlib.sourceforge.net/api/axes_api.html\#module-matplotlib.axes|;
> s|http://matplotlib.sourceforge.net/matplotlib.axis.html\#Ticks|http://matplotlib.sourceforge.net/api/axis_api.html\#matplotlib.axis.Tick|;
> s|http://matplotlib.sourceforge.net/matplotlib.figure.html\#Figure|http://matplotlib.sourceforge.net/api/figure_api.html#matplotlib.figure.Figure|'
> lib/matplotlib/mpl-data/matplotlibrc
>
> Please consider add this to the upcoming .3 release.
>
> Regards,
>   
> 
>
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> 
>
> ___________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Build Failure on Windows using Python25

[Michael Droettboom]

Thanks for the report.  I'll make the change in SVN. 

[For those planning the next bugfix release: this only affects the trunk.]

Mike

Patrick Marsh wrote:
> I just tried this fix and was able to build on Windows Vista.
>
> -Patrick
>
>
>
>
> On Fri, Feb 6, 2009 at 6:08 PM, Michael Droettboom  wrote:
>   
>> Just getting to this thread now -- I think this was introduced in my
>> recent changes.  I'm used to being on platforms where this is defined,
>> so I forgot that it's not always there.
>>
>> In this specific case "unsigned char" is probably equivalent everywhere
>> we run, so we might as well just do that.  If a Windows user can verify
>> that fix works, I'll fix it in SVN.
>>
>> Mike
>>
>> Michael Abshoff wrote:
>> 
>>> On Fri, Feb 6, 2009 at 3:03 PM, Ryan May  wrote:
>>>
>>>   
>>>> On Fri, Feb 6, 2009 at 4:48 PM, Andrew Straw  wrote:
>>>>
>>>> 
>>>>> Ryan May wrote:
>>>>>
>>>>>   
>>>>>> On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw >>>>> <mailto:straw...@astraw.com>> wrote:
>>>>>>
>>>>>> Patrick,
>>>>>>
>>>>>> Can you see if adding "#include " at the top of
>>>>>> src/path.cpp
>>>>>> will do the job?
>>>>>>
>>>>>> I'm not super-optimistic, though -- I think this is defined by the
>>>>>> C99
>>>>>> standard, which I'm not sure Microsoft supports.
>>>>>>
>>>>>>
>>>>>> Well, we're also talking about C++ here and not C, so C99 does not
>>>>>> apply.  A quick googling around seems to indicate that some of the
>>>>>> open source compilers support such a type, but it not standardized by
>>>>>> C++.
>>>>>>
>>>>>> 
>>>>> There is no  or the type is not defined in stdint.h?
>>>>>
>>>>> Maybe as a workaround you could use mingw...
>>>>>
>>>>>   
>>>> I meant that uint8_t is not a standardized C++ type.  If that's the case,
>>>> wouldn't it be better to tweak the code to use something standard rather
>>>> than just use a compiler that supports the non-standard type?  Especially
>>>> given that the official Python 2.5 build uses this compiler?
>>>>
>>>> 
>>> Please stick with standard types.
>>>
>>> And MSVC 2005 and higher do have C99 support, it is just unfortunate
>>> that it is not complete.
>>>
>>>
>>>   
>>>> Ryan
>>>>
>>>> 
>>> Cheers,
>>>
>>> Michael
>>>
>>>
>>>   
>>>> --
>>>> Ryan May
>>>> Graduate Research Assistant
>>>> School of Meteorology
>>>> University of Oklahoma
>>>>
>>>> --
>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>> Adobe(R)AIR(TM)
>>>> software. With Adobe AIR, Ajax developers can use existing skills and code
>>>> to
>>>> build responsive, highly engaging applications that combine the power of
>>>> local
>>>> resources and data with the reach of the web. Download the Adobe AIR SDK 
>>>> and
>>>> Ajax docs to start building applications 
>>>> today-http://p.sf.net/sfu/adobe-com
>>>> ___
>>>> Matplotlib-devel mailing list
>>>> Matplotlib-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>>
>>>> 
>>> --
>>> Create and Deploy Rich Internet Apps outside the browser with 
>>> Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills and code 
>>> to
>>> build responsive, highly engaging applications that combine the power of 
>>> local
>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com

Re: [matplotlib-devel] svnmerge other files?

[Michael Droettboom]

I don't know why -- but what is different about those files is that they 
were added on the branch since the branch was created.  I couldn't find 
any others that were.  Perhaps svnmerge.py doesn't track adds completely 
correctly.

In any case, it doesn't in fact change the content of these files (only 
touches them), so I consider that only a minor nuisance.

Mike

Ryan May wrote:
> Hi,
>
> Can anyone explain why everytime I go to merge changes from the 
> maintainance branch, it wants to tweak these files (besides the ones I 
> actually changed)?
>
> doc/pyplots/README
> doc/sphinxext/gen_gallery.py
> doc/sphinxext/gen_rst.py
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> Sent from: Norman Oklahoma United States.
> 
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Sphinx custom extension mess, and patches

[Michael Droettboom]

Gael,

You raise a very good point about the duplication of code around.  As a 
case in point, the patches you provided no longer apply to the 
"canonical" (or at least original) versions of the plugins that began 
life in matplotlib.  Recent versions of Sphinx have a proper extension 
API, so that "try ... except" importing is no longer necessary.

For mathmpl.py --- I will move that into the matplotlib installed code 
tree, so, as you suggest, "from matplotlib.sphinxext import mathmpl" 
will work.  Obviously, that won't really provide traction until the next 
release of matplotlib.  And it relies on only_directive.py, so I will 
probably have to put that in matplotlib as well for now, though that is 
a reasonable candidate for inclusion in Sphinx.

I have submitted inheritance_diagram.py to Sphinx already.  There didn't 
seem to be much interest, and there were some details (particularly how 
it deals with files), that weren't "the Sphinx way", and there few 
documents and/or examples etc. at the time about how to do it right.  
Someone else ended up re-engineering it to use pygraphviz which felt 
pretty heavy weight to me.  So the thing kind of stalled.  But it's 
probably worth another push.

Mike

Gael Varoquaux wrote:
> Hi all,
>
> Sorry for the multiple posting, this concerns various groups, and I'd
> rather the information not be lost.
>
> While working on getting our in-lab library ready to be merged with NiPy,
> I ran into some sort of 'sphinx extension mess' where various sphinx
> extension would have side effects on each other, and most important, the
> extensions did not work with sphinx trunk.
>
> I got the side effects to be limited by cleaning up the generated code
> from autosummary before each run: I added the following code in my
> sphinx conf.py:
>
> 
> # Hack: run the autosummary generation script 
> import shutil
> if os.path.exists('generated'):
> shutil.rmtree('generated')
> os.system('%s sphinxext/autosummary_generate.py -o generated *.rst' %
> sys.executable)
> 
>
> I am attaching a diff of all the modifications I made to get the various
> extensions to work. I hope you can use it to get your various extensions
> working on sphinx trunk quicker. For the NiPy guys, I will be committing
> these changes in the fff2 tree soon, and we can go over this at the
> sprint.
>
> This does raise a problem: this extension code is all over the place, in
> various repository. Some of the code cannot live in the sphinx repo, as
> it introduces dependencies. However, as the extensions are not importable
> from Python (I can't do 'from matplotlib.sphinxext import mathmpl'), the
> different projects using them end up copying them in their repo, and thus
> there are several versions floating around not updated. Some of the
> extensions would do not add externa dependencies to sphinx. These should
> be pushed into sphinx, with tests. That way as sphinx evolves, they do
> not break.
>
> Gaël
>   
> 
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ----
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot directive in reST tutorials

[Michael Droettboom]

Has anyone else had a chance to look at this?  It seems fairly 
straightforward and I may have a go at this this morning if no one else 
has already.

Mike

Fernando Perez wrote:
> Howdy,
>
> recently, Matthew Brett pointed out that reST supports a mode that's
> very handy for writing tutorial-like documents that contain code
> blocks including their output, and they can even be run as tests.
> Here's a simple example with its corresponding source:
>
> http://neuroimaging.scipy.org/site/doc/manual/html/users/analysis_pipeline.html
> http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/analysis_pipeline.txt
>
> and they can even use the MPL math support, as seen here:
>
> http://neuroimaging.scipy.org/site/doc/manual/html/users/glm_spec.html
> http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/glm_spec.txt
>
> But we were thinking it would be great to have also plot support for
> this, without being forced to use standalone scripts like in mpl's
> current form of the plot directive.  I unfortunately have to go now
> and will be mostly offline for a week, but I just had a chat about
> this with John, so I want to leave some context in here in case this
> is of interest to you guys.  If there's a discussion on the API, I'll
> do my best to keep up, but I'm also cc'ing the nipy list so those
> interested can pitch in (though we should keep the conversation to the
> MPL list, where the plot machinery is implemented).
>
> Cheers,
>
> f
>
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot directive in reST tutorials

[Michael Droettboom]

A preliminary version of this is committed on the branch and trunk.

You can now do:

.. plot::

 from matplotlib.pyplot import *
 plot([1,2,3])

One open API question is whether to implicitly "from matplotlib.pyplot 
import *" or "from matplotlib import pyplot as plt" or nothing.  I 
generally don't like "import *" or implicit things, so I've decided to 
do none of the above.  But I could see how it might be nice to reduce 
the verbosity of these little code examples to import something be 
default.  Let me know if you feel strongly about changing it.

It has also been moved to the installed source directory, so other 
projects no longer need to copy it.  Just change the entry in the 
extensions list in the Sphinx conf.py from 'plot_directive' to 
'matplotlib.sphinxext.plot_directive' and remove your local copy of the 
extension.

Mike

Michael Droettboom wrote:
> Has anyone else had a chance to look at this?  It seems fairly 
> straightforward and I may have a go at this this morning if no one else 
> has already.
>
> Mike
>
> Fernando Perez wrote:
>   
>> Howdy,
>>
>> recently, Matthew Brett pointed out that reST supports a mode that's
>> very handy for writing tutorial-like documents that contain code
>> blocks including their output, and they can even be run as tests.
>> Here's a simple example with its corresponding source:
>>
>> http://neuroimaging.scipy.org/site/doc/manual/html/users/analysis_pipeline.html
>> http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/analysis_pipeline.txt
>>
>> and they can even use the MPL math support, as seen here:
>>
>> http://neuroimaging.scipy.org/site/doc/manual/html/users/glm_spec.html
>> http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/glm_spec.txt
>>
>> But we were thinking it would be great to have also plot support for
>> this, without being forced to use standalone scripts like in mpl's
>> current form of the plot directive.  I unfortunately have to go now
>> and will be mostly offline for a week, but I just had a chat about
>> this with John, so I want to leave some context in here in case this
>> is of interest to you guys.  If there's a discussion on the API, I'll
>> do my best to keep up, but I'm also cc'ing the nipy list so those
>> interested can pitch in (though we should keep the conversation to the
>> MPL list, where the plot machinery is implemented).
>>
>> Cheers,
>>
>> f
>>
>> --
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of 
>> local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot directive in reST tutorials

[Michael Droettboom]

Pauli Virtanen wrote:
> Mon, 16 Feb 2009 10:30:47 -0500, Michael Droettboom wrote:
>
>   
>> A preliminary version of this is committed on the branch and trunk.
>>
>> You can now do:
>>
>> .. plot::
>>
>>  from matplotlib.pyplot import *
>>  plot([1,2,3])
>>
>> One open API question is whether to implicitly "from matplotlib.pyplot
>> import *" or "from matplotlib import pyplot as plt" or nothing.  I
>> generally don't like "import *" or implicit things, so I've decided to
>> do none of the above.  But I could see how it might be nice to reduce
>> the verbosity of these little code examples to import something be
>> default.  Let me know if you feel strongly about changing it.
>>
>> It has also been moved to the installed source directory, so other
>> projects no longer need to copy it.  Just change the entry in the
>> extensions list in the Sphinx conf.py from 'plot_directive' to
>> 'matplotlib.sphinxext.plot_directive' and remove your local copy of the
>> extension.
>> 
>
> Scipy's plot directive has had this feature for some time:
>   
>   http://svn.scipy.org/svn/numpy/trunk/doc/sphinxext/plot_directive.py
>
> plus some extra features. I think it should contain all the features in
> matplotlib's version; but OTOH, I haven't tried to build matplotlib docs
> using it.
> I think we really should merge it back *now*!
> (Re: Gael's thread; sorry, I've been lazy pushing the changes back...)
>   
We've clearly all been bad about forking this stuff all over the place.  
I was completely unaware it was being used for Scipy.  It's unfortunate 
the suggestion to install this stuff as part of matplotlib wasn't made 
earlier. 

Anyway, the current version in matplotlib handles files in a way that 
behaves well with Sphinx (which I see is a TODO list item in the numpy 
version).  It also uses the Sphinx extension API rather than the old and 
brittle way of defining directives etc.  So those things will need to be 
merged with the other changes made on the Numpy side.
> The "official" version of the plot directive should IMO end up either
> in Sphinx or matplotlib repository. It's probably OK to require matplotlib
> SVN version to build Scipy docs for a while...
>   
I think it makes the most sense for this to be part of matplotlib, since 
it fundamentally requires matplotlib -- that prevents Sphinx from 
growing a matplotlib dependency.

Mike

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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot directive in reST tutorials

[Michael Droettboom]

Pauli Virtanen wrote:
> Mon, 16 Feb 2009 13:26:40 -0500, Michael Droettboom wrote:
> [clip]
>   
>> Anyway, the current version in matplotlib handles files in a way that
>> behaves well with Sphinx (which I see is a TODO list item in the numpy
>> version).  It also uses the Sphinx extension API rather than the old and
>> brittle way of defining directives etc.  So those things will need to be
>> merged with the other changes made on the Numpy side.
>> 
>
> Ok, I'll try to get these merged now, starting from the Scipy
> version.
>
> What was new:
>
> * Detect doctest format automatically.
> * Matplotlib rcparameters settable in conf.py
> * :include-source: also as conf.py option
> * Preamble code in conf.py, to run in every plot
> * Used Sphinx API to register the directive.
> * Slightly modified template for the inserted RST, to make multiple
>   output figures floatable side-by-side in HTML.
>
> So I think what needs to be merged is the output file handling,
> and to check that the output is similar as previously for the matplotlib
> docs.
>   
Those all look like great features to have.

Thanks for volunteering to do the merge.

I would also add that it should be ported to the Sphinx extension API 
(basically the stuff in the last section in the file).  It's a lot 
easier now, and should be more stable between docutils/Sphinx versions:

http://sphinx.pocoo.org/ext/appapi.html

Cheers,
Mike

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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot directive in reST tutorials

[Michael Droettboom]

Sorry -- Ignore my last comment.  I see the Scipy version already has 
the covered -- it's just in a different place.  No problem.

Cheers,
Mike

Michael Droettboom wrote:
> Pauli Virtanen wrote:
>   
>> Mon, 16 Feb 2009 13:26:40 -0500, Michael Droettboom wrote:
>> [clip]
>>   
>> 
>>> Anyway, the current version in matplotlib handles files in a way that
>>> behaves well with Sphinx (which I see is a TODO list item in the numpy
>>> version).  It also uses the Sphinx extension API rather than the old and
>>> brittle way of defining directives etc.  So those things will need to be
>>> merged with the other changes made on the Numpy side.
>>> 
>>>   
>> Ok, I'll try to get these merged now, starting from the Scipy
>> version.
>>
>> What was new:
>>
>> * Detect doctest format automatically.
>> * Matplotlib rcparameters settable in conf.py
>> * :include-source: also as conf.py option
>> * Preamble code in conf.py, to run in every plot
>> * Used Sphinx API to register the directive.
>> * Slightly modified template for the inserted RST, to make multiple
>>   output figures floatable side-by-side in HTML.
>>
>> So I think what needs to be merged is the output file handling,
>> and to check that the output is similar as previously for the matplotlib
>> docs.
>>   
>> 
> Those all look like great features to have.
>
> Thanks for volunteering to do the merge.
>
> I would also add that it should be ported to the Sphinx extension API 
> (basically the stuff in the last section in the file).  It's a lot 
> easier now, and should be more stable between docutils/Sphinx versions:
>
> http://sphinx.pocoo.org/ext/appapi.html
>
> Cheers,
> Mike
>
>   

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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot directive in reST tutorials

[Michael Droettboom]

That's a great suggestion.  I'm not familiar at all with the doc test 
extension, so the plot directive doesn't do this.  It gets a fresh 
namespace (though not a fresh interpreter) for each plot.

To avoid complicating the merge further, I'd like to wait for Pauli 
Vertanen's merge of the new plot directive features from Numpy back into 
matplotlib before looking at implementing this.  It will probably just 
involve inheriting/emulating whatever the doctest extension is doing to 
make that work.  And if the directive is used in the old way (providing 
a filename), we'll just clear any state at that point.

Mike

Matthew Brett wrote:
> Hi guys,
>
>   
>> You can now do:
>>
>> .. plot::
>>
>> from matplotlib.pyplot import *
>> plot([1,2,3])
>> 
>
> This is very nice - thank you for doing that.
>
> But, thinking about the online tutorials, you often want to do
> something as you can do with the sourcecode directive, as in:
>
> .. testcode::
>
>import numpy as np
>print np.inf
>
> Some text then
>
> .. testoutput::
>
>inf
>
> More text
>
> .. testcode::
>
># I still have the context from the blocks above
>print np.nan
>
> More text
>
> .. testoutput::
>
>nan
>
>
> In that way, I can build up a tutorial, setting and calculating
> variables, doing plots as I go, without having to recreate the
> calculations at each step.
>
> Is it possible to make the ..plot directive pick up the context in the same 
> way?
>
> Thanks a lot,
>
> Matthew
>   

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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in xlim or savefig or hist?

[Michael Droettboom]

I see it with 0.98.5.x, but not with SVN trunk.  I'll look into this 
further and see what I can determine.

Mike

Olle Engdegård wrote:
> On Wed, 18 Feb 2009, Joshua Lippai wrote:
>   
>> Interesting. I can't reproduce your result using either the MacOSX or
>> WXAgg backend. Which backend are you using, and does the problem
>> persist if you use a different one?
>> 
>
> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>
> /Olle
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in xlim or savefig or hist?

[Michael Droettboom]

I take this back -- I hadn't read your initial bug very carefully.

If Inkscape is rendering the SVG correctly, but it's PDF output is not 
correct, then that seems like an Inkscape bug or a PDF viewer bug -- 
there's not too much we could do on the matplotlib end.

When you say you see it in WXAgg, WX, GTKAgg etc., do you mean you see 
it in the interactive window, or just this behavior when you save an 
SVG, load it in Inkscape and then output a PDF?  In the latter case, the 
SVG output from all backends (except Cairo) follows the same code path 
so should be identical.

Does directly outputting PDF from matplotlib work for you ? -- (it works 
here)

Mike


Michael Droettboom wrote:
> I see it with 0.98.5.x, but not with SVN trunk.  I'll look into this 
> further and see what I can determine.
>
> Mike
>
> Olle Engdegård wrote:
>   
>> On Wed, 18 Feb 2009, Joshua Lippai wrote:
>>   
>> 
>>> Interesting. I can't reproduce your result using either the MacOSX or
>>> WXAgg backend. Which backend are you using, and does the problem
>>> persist if you use a different one?
>>> 
>>>   
>> Hmm, I see it in at least WXAgg, WX, GTKAgg ...
>>
>> /Olle
>>
>> --
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug in xlim or savefig or hist?

[Michael Droettboom]

Olle Engdegård wrote:
>
> Sorry for not being clear enough.
>
> I see this only when exporting to svg, importing it to Inkscape and 
> then saving as pdf there. Never interactively. And never if exporting 
> directly to pdf from matplotlib.
>
> It could very well be a bug in Inkscape, but matplotlib is still 
> saving data that should not be there, this is what I wanted to point out.
>
> And I take it back that it doesn't show in Inkscape, it was just 
> hidden from view. The extra bars are there.
You were clear -- it was just early in the morning for me here and my 
eyes to brain converter wasn't working properly ;)

The drawing and then clipping is normal behavior.  All of the backend 
formats have the ability to clip out arbitrary regions for drawing, so 
we take advantage of that rather than doing our own geometric clipping 
algorithm.  The latter is a great deal of work to get right.

It sounds like the Inkscape PDF export is not exporting the clipping 
path correctly, which may actually be related to the version of Cairo 
Inkscape is using.  In any case, there's not much we can do here.

Mike

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots a

[Michael Droettboom]

Thanks for the note on this.  It's nice to know who wrote the original 
version. I'll add a note about this in the code comments.

I'm not seeing a noticable change in this regard between 0.98.5 (which 
uses a pretty direct refactoring of your code) to the SVN trunk.  The 
trunk does two things rather differently 1) it only ever returns points 
that exist in the original data, and 2) it clips line segments at the 
boundary of the plot.  The latter is to get around a shortcoming of Agg 
(and Abode Reader, for that matter) when plotting lines to very 
high-valued coordinates.

But, I'd appreciate you having a comparison look yourself, in case 
you're seeing some detail that I'm missing.

Cheers,
Mike

Allan Haldane wrote:
> a writes:
>   
>> Michael Droettboom  writes:
>> 
>>> Thanks for the pointers.
>>>
>>> The original simplification code was written by John Hunter (I believe),
>>> and I don't know if it was designed by him also or is a replication of
>>> something published elsewhere.  So I take no credit for and have little
>>> knowledge of its original goals.
>>>   
>> I'm not sure on everything it does, but it seems to do clipping and removes
>> line segments where the change in slope is less than some limit. There are
>> probably better algorithms out there, but this one works surprisingly well
>> and is fast and simple. I think it should be a requirement that it returns
>> points which are a subset of the original points- with the change you've
>> made it does this, right?
>> 
>
> Oh Hey! I'm the one who originally wrote the path simplification code. I'd
> have thought it would be gone by now, but I am very happy it turned out to
> be useful. I made it up in order to plot a very large set of noisy data I
> had.
>
> The goal was to simplify two types of plots at once: Smooth curves, as
> well as very noisy data where many lines are 'on top' of each other. (eg
> plot(rand(10)) ). I noticed both could be taken care of by checking
> for changes in slope.
>
> An important goal (for me) was making sure that the min/max span of the
> points plotted was preserved. (so that eg plot(rand(1000)) spans from the
> lowest to highest point in the data (ie ~ 0 to 1) for any zoom factor).
> I'm not sure if this property survived...: If you do plot(rand(1000)) with
> the latest matplotlib and gradually zoom out on the x axis, you can see
> the top/bottom tips of the plotted line flickering in height, which is
> what I was trying to avoid. I forget whether I actually got it as I wanted
> it though, maybe I gave up.
>
> Allan
>
>
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Nipy-devel] Sphinx custom extension mess, and patches

[Michael Droettboom]

Thanks, Fernando.  I've applied your patch to matplotlib (branch and trunk).

Mike

Fernando Perez wrote:
> On Mon, Feb 16, 2009 at 3:21 PM, Gael Varoquaux
>  wrote:
>
>   
>> I am not blaming anyone, just pointing out a non ideal situation. It has
>> already improved a lot with the matplotlib guys and the scipy guys
>> merging some changes in extensions and publishing the extensions in an
>> importable part of their source tree.
>> 
>
> In keeping with the spirit of trying to get all of these extension
> changes upstream so that we can all eventually stop carrying our own
> copies, below is a tiny change I just made to the inheritance diagram
> one.  This is needed to ensure that the figure is separated from any
> surrounding text, since otherwise you get hideous off-screen diagrams
> in the rendered PDF.
>
> This has been committed to the nipy trunk already.
>
> Similarly (for the pymvpa crowd), the api autogen code is now a
> module, and it also contains a few small fixes, in particular
> regarding chapter titles.  Feel free to grab and update your copy:
>
> http://bazaar.launchpad.net/~nipy-developers/nipy/trunk/annotate/head%3A/tools/apigen.py
>
> I've been told the gods of numpy/sphinx don't like auto-generated
> docs, but I think there's a valid use case for these tools, so
> hopefully in the future it will be possible to include them upstream
> for us lesser mortals to use.  If not, I guess we'll just continue to
> carry our copies around :)
>
> Cheers,
>
> f
>
> # diff, inline because it's so trivial:
>
> === modified file 'doc/sphinxext/inheritance_diagram.py'
> --- doc/sphinxext/inheritance_diagram.py  2009-01-30 02:00:57 +
> +++ doc/sphinxext/inheritance_diagram.py  2009-02-20 21:11:38 +
> @@ -370,7 +370,7 @@
>
>  graph.run_dot(['-Tpdf', '-o%s' % pdf_path],
>name, parts, graph_options={'size': '"6.0,6.0"'})
> -return '\\includegraphics{%s}' % pdf_path
> +return '\n\\includegraphics{%s}\n\n' % pdf_path
>
>  def visit_inheritance_diagram(inner_func):
>  """
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Making WxMpl a matplotlib toolkit

[Michael Droettboom]

Nice to hear about these plans -- and good luck with your surgery.

All that you suggest looks good.  I'm personally a fan of svnmerge to do 
this sort of maintenance branch/development branch merging.  You can see 
the matplotlib developer docs for instructions on how it's used with 
matplotlib, and you can just adapt the urls for what you're doing.

Mike

Ken McIvor wrote:
> Now that I've got a version of WxMpl that works properly I'd like to  
> transition it over to being a matplotlib toolkit.  From poking around  
> in svn, it looks like the correct thing to do would be to import the  
> source directory into '$(SVNROOT)/trunk/toolkits/wxmpl'.
>
> Is that correct?
>
> I'd like to try to get started on version 2.0 before I have my first  
> carpal tunnel release surgery in later March.  The goals would be:
>
> 1. Optional full support for MPL events
> 2. API for binding user interactions to selection and zoom behavior  
> (e.g. "I want right-click selections to zoom in and the 'u' key to  
> zoom out, like GNUPLOT")
> 3. API for controlling Axes zoom state
>
> What do you all think would be the best way to do this?  Create a  
> branch in '$(SVNROOT)/branches' for 1.3 maintenance?
>
> Ken
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot([], [], drawstyle = 'steps') fails

[Michael Droettboom]

This is now fixed in SVN.  Thanks for the report.

Mike

Gregor Thalhammer wrote:
> Hi all,
>
> sorry, only reporting, no bugfix. I just discovered that an empty plot 
> with drawstyle 'steps', 'steps-pre', 'steps-mid' and 'steps-post' fails. 
> I am using matplotlib 0.98.5.2.
>
> Example
>
> plot([], [], drawstyle = 'steps')
>
> ...
> C:\Python25\lib\site-packages\matplotlib\lines.pyc in 
> _draw_steps_pre(self, renderer, gc, path, trans)
> 784 def _draw_steps_pre(self, renderer, gc, path, trans):
> 785 vertices = self._xy
> --> 786 steps = ma.zeros((2*len(vertices)-1, 2), np.float_)
> 787
> 788 steps[0::2, 0], steps[1::2, 0] = vertices[:, 0], 
> vertices[:-1, 0
> ]
> ...
>
> ValueError: negative dimensions are not allowed
>
> Gregor
>
>
>
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] hashing of FontProperties

[Michael Droettboom]

Jae-Joon Lee wrote:
> The following code show how the FontProperties is currently hashed.
>
>  def __hash__(self):
> l = self.__dict__.items()
> l.sort()
> return hash(repr(l))
>
>
> The hash does not account user's rcParams setting. And due to the font
> caching, findfont(FontProperties()) returns the same font even if user
> changes the rcParams["font.family"] and other parameters.
>
> So, I propose to change it to something like below.
>
> def __hash__(self):
> l = [(k, getattr(self, "get" + k)()) for k in self.__dict__]
> return hash(repr(l))
>   
You'll need to maintain the call to sort in there, since dictionaries 
don't make any guarantee about ordering.  But otherwise, that seems like 
a reasonable solution to the problem.  There was a bug report about this 
on the list recently.
> The other change I want to make is the behavior of the findfont(None).
> As of now, it returns "fontManager.defaultFont" which is set when
> fontManager is initialized. Therefore, it returns same font even if
> user change the rcParams. I prefer to have "findfont(None) ==
> findfont(FontProperties())".
>   
That should be fine.
> Unless others object, I'll commit the changes to the trunk.
>   
Sure.  Just be careful not to change the pickled cache file format if 
possible (it doesn't seem like what you propose will do that) -- but 
that always causes upgrade headaches when that cache format changes.

Mike

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] stixsans + mathtext.default : regular

[Michael Droettboom]

The 'regular' font stuff just isn't very well tested yet.  I think I 
have a fix in SVN now.

Mike

Ryan May wrote:
> Mike (or anyone else),
>
> I've been using the following combination of settings:
>
> mathtext.fontset : stixsans
> mathtext.default : regular
>
> I've noticed this crashes when I run scripts that include mathtext 
> with \rm{} commands.  In fact, I get a massive traceback with this 
> configuration when running the mathtext_examples.py.  Here's the last 
> few lines:
>
>  File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 950, in _parseNoCache
> tokens = fn( instring, tokensStart, retTokens )
>   File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2381, in symbol
> return [Hlist( [self._make_space(0.2),
>   File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2351, in _make_space
> state.font, rcParams['mathtext.default'], 'm', state.fontsize, 
> state.dpi)
>   File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 446, in get_metrics
> info = self._get_info(font, font_class, sym, fontsize, dpi)
>   File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 579, in _get_info
> self._get_glyph(fontname, font_class, sym, fontsize)
>   File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 812, in _get_glyph
> fontname, font_class, uniindex)
>   File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 919, in _map_virtual_font
> mapping = mapping[font_class]
> KeyError: 'regular'
>
> Is this a supported configuration?  I know that I personally like the 
> look of the text with these two settings.  Thoughts?
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> 
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] stixsans + mathtext.default : regular

[Michael Droettboom]

I was rounding where I should have been truncating.  I think this is 
fixed now in SVN.

Mike

Ryan May wrote:
> On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom  <mailto:md...@stsci.edu>> wrote:
>
> The 'regular' font stuff just isn't very well tested yet.  I think
> I have a fix in SVN now.
>
>
> Thanks for the quick fix, it got rid of my errors.  However, I'm 
> seeing a little more of the funky font baseline that you had fixed.  
> My original script doesn't show any problem, but I've attached an 
> image produced with the mathtext_demo.py.  Notice the odd baseline for 
> versus in the title and sin in the equation on the graph.  Thoughts?
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
> 
>
> 
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] interactive property editor

[Michael Droettboom]

We've done some experiments with Enthought Traits at various times to 
address this issue.  There were always various obstacles to making it 
work, but it may be worth another look.  Traits has its nice auto-built 
property editors (that may address your request), but it would also 
address one of my long-standing niggles that properties of graphs are 
often checked far too late and the error messages presented to the user 
are very obscured because of it.

Of course, all that is a major undertaking -- basically rewriting all 
the getters and setters on the artist classes to use traits -- but I 
could see it having quite the payoff in the end.

Mike

João Luís Silva wrote:
> Paul Kienzle wrote:
>   
>> Hi,
>>
>> What's the status of interactive property editors for mpl graphs?
>>
>> I would like something that would allow me to change properties such  
>> as the size and position of the graph, grids, scales, ranges, colors,  
>> symbols, line styles, fonts, etc., and add annotations.  Some of this  
>> already exists, but allowing users to enter specific values will need  
>> an underlying widget toolkit.
>>
>> Does anybody have anything that I can build on for wx?
>>
>> 
>
> I though about making such a program but concluded it would be a major 
> undertaking. I considered using GTK because that's what I use, but 
> otherwise any toolkit will do. I still have some major unresolved design 
> issues to implement such an application:
>
> - How would the state of the editor be saved? In a new file type (in 
> json for example)? Is there any standard format for this? If it was 
> feasible I'd like to import and export small python scripts, but the 
> import capabilities seem unlikely.
>
> - Mpl is very flexible (just look at the gallery). Would the editor be 
> limited to a subset of the capabilities or the objective would be to 
> take mpl to the limit? Including subplots? and heterogeneous graphics? 
> The interface could get very complex very quickly indeed.
>
> - I seem to recall an open source graphics application along these 
> lines, but can't remember its name (maybe SciGraphica).
>
> If someone is working on such a thing, or if you want to make one I 
> could tinker a bit, but I really don't have enough time to start a major 
> application. BTW I'm not a mpl developer, just a satisfied user :)
>
> Regards,
> João Silva
>
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Polar Plot

[Michael Droettboom]

Sherif Ahmed wrote:
>
> Hello all,
>
> I am using matplotlib in order to generate a scientific drawing called 
> “Smith Chart”. It consists of many shifted circles drawn in polar 
> plot. This chart is widely used in electrical engineering field.
>
> I am facing a problem now with the new version of matplotlib. After 
> trying around I figured out that the plot function does not connect 
> the given points in straight lines however by a circle or a circle 
> sector. This causes a very wrong drawing and producing parasitic, 
> false, circles when the points are to cross the theta=180° line.
>
You can turn off this feature by passing "resolution=1" to the polar() 
method. This is the default in SVN versions of matplotlib, and will be 
in the next releases.

You've clearly done a lot of work on the Smith chart plotting already... 
It would be great to package that code into something for general use 
and include in the matplotlib core.

Mike
>
>
> 
>
>
> 
>
> 
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Rendering (clipping?) bug with Cairo backend

[Michael Droettboom]

Thanks for the report.

It seems that the clipping rectangles were applied additively, rather 
than being set and removed for each axes.

This is now fixed in SVN.

Mike

Nathaniel Smith wrote:
> I ran into a very curious bug tonight, where if I
>   -- had multiple axes in a figure
>   -- and they had axison=False
>   -- and there was a patch or line in each axes
>   -- and there was an image in each axes
> Then the image is not rendered (or, after some fiddling with how the
> subplots overlap, is sometimes partially rendered).
>
> It took a few hours to isolate :-(.
>
> I tried the GTKCairo and GTKAgg backends; the Cairo backend shows the
> bug, while the Agg backend renders it correctly.
>
> This is with matplotlib 0.98.5.2, running on Linux x86-64.
>
> Minimal code to reproduce the bug is:
> 
> from matplotlib import patches, pyplot
> def bug():
> f = pyplot.figure()
> a1 = f.add_axes([0, 0, 0.4, 0.9])
> a2 = f.add_axes([0.5, 0, 0.4, 0.9])
> a3 = f.add_axes([0.2, 0.2, 0.4, 0.9])
> for a in [a1, a2, a3]:
> # This shows up in axis 1, but not axis 2, and only partially in axis 
> 3:
> a.imshow(np.arange(100).reshape(10, 10),
>  extent=(-1, 1, 1, -1))
> # If you comment out either of these lines, then it works properly:
> a.axison = False
> a.plot([0, 0], [1, 1])
> pyplot.draw()
> ---
>
> Renders with agg and cairo are attached for comparison. Note that in
> the cairo rendering, axes 1 is drawn correctly, axes 2 is not drawn at
> all, and the only part of axes 3 that is drawn is that part that
> overlaps axes 2.
>
> -- Nathaniel
>   
>
> 
>
>
> 
>
> 
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> 
>
> _______
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Rendering (clipping?) bug with Cairo backend

[Michael Droettboom]

ayer not doing anything to pop (restore) contexts.
> If this is indeed the problem, maybe it's a good idea for matplotlib to save 
> and restore graphics contexts instead of using new_gc? It's easy to implement 
> a save/restore mechanism in backends with a new_gc capability; the reverse is 
> inherently fragile.
>   
I agree.  But that means changing the semantics of the entire program to 
fix a couple of differently-written backend interfaces.  I'd rather just 
fix the backends.

All this is just me 2 cents.  I certainly welcome contrary feedback if 
there's a real advantage to relying on stack-based semantics everywhere 
to justify the work required.

Cheers,
Mike

> --Michiel
>
>
> --- On Thu, 3/19/09, Nathaniel Smith  wrote:
>
>   
>> From: Nathaniel Smith 
>> Subject: [matplotlib-devel] Rendering (clipping?) bug with Cairo backend
>> To: matplotlib-devel@lists.sourceforge.net
>> Date: Thursday, March 19, 2009, 7:13 AM
>> I ran into a very curious bug tonight, where if I
>>   -- had multiple axes in a figure
>>   -- and they had axison=False
>>   -- and there was a patch or line in each axes
>>   -- and there was an image in each axes
>> Then the image is not rendered (or, after some fiddling
>> with how the
>> subplots overlap, is sometimes partially rendered).
>>
>> It took a few hours to isolate :-(.
>>
>> I tried the GTKCairo and GTKAgg backends; the Cairo backend
>> shows the
>> bug, while the Agg backend renders it correctly.
>>
>> This is with matplotlib 0.98.5.2, running on Linux x86-64.
>>
>> Minimal code to reproduce the bug is:
>> 
>> from matplotlib import patches, pyplot
>> def bug():
>> f = pyplot.figure()
>> a1 = f.add_axes([0, 0, 0.4, 0.9])
>> a2 = f.add_axes([0.5, 0, 0.4, 0.9])
>> a3 = f.add_axes([0.2, 0.2, 0.4, 0.9])
>> for a in [a1, a2, a3]:
>> # This shows up in axis 1, but not axis 2, and only
>> partially in axis 3:
>> a.imshow(np.arange(100).reshape(10, 10),
>>  extent=(-1, 1, 1, -1))
>> # If you comment out either of these lines, then it
>> works properly:
>> a.axison = False
>> a.plot([0, 0], [1, 1])
>> pyplot.draw()
>> ---
>>
>> Renders with agg and cairo are attached for comparison.
>> Note that in
>> the cairo rendering, axes 1 is drawn correctly, axes 2 is
>> not drawn at
>> all, and the only part of axes 3 that is drawn is that part
>> that
>> overlaps axes 2.
>>
>> -- Nathaniel
>> --
>> Apps built with the Adobe(R) Flex(R) framework and Flex
>> Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform
>> capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the
>> Eclipse(TM)based development
>> software that enables intelligent coding and step-through
>> debugging.
>> Download the free 60 day trial.
>> http://p.sf.net/sfu/www-adobe-com___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>
>   
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] can't copy 'lib/matplotlib/mathtext.py'

[Michael Droettboom]

Perhaps a merge failed on lib/matplotlib/mathtext.py?  If you know you 
don't have any local changes to that file that you need, you can just 
remove it and "svn up" again.  I can't see a reason why this is a 
repository-side problem... no properties have changed on that file for a 
long time.

Mike

Nils Wagner wrote:
> Hi all,
>
> I cannot install matplotlib from recent svn.
>
> python setup.py install --prefix=$HOME/local
> 
> BUILDING MATPLOTLIB
>  matplotlib: 0.98.6svn
>  python: 2.5.1 (r251:54863, Dec 21 2007, 
> 09:21:07)  [GCC
>  3.4.6 20060404 (Red Hat 3.4.6-3)]
>platform: linux2
>
> REQUIRED DEPENDENCIES
>   numpy: 1.4.0.dev6708
>   freetype2: 9.7.3
>
> OPTIONAL BACKEND DEPENDENCIES
>  libpng: 1.2.7
> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>wxPython: 2.8.9.1
>  * WxAgg extension not required 
> for wxPython >= 2.8
>Gtk+: no
>  * Building for Gtk+ requires 
> pygtk; you must be able
>  * to "import gtk" in your 
> build/install environment
> Mac OS X native: no
>  Qt: no
> Qt4: no
>   Cairo: no
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>datetime: present, version unknown
>dateutil: matplotlib will provide
>pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
>  dvipng: no
> ghostscript: 7.07
>   latex: 3.14159
> pdftops: 3.00
>
> [Edit setup.cfg to suppress the above messages]
> 
> pymods ['pylab']
> packages ['matplotlib', 'matplotlib.backends', 
> 'matplotlib.projections', 'mpl_toolkits', 
> 'matplotlib.sphinxext', 'matplotlib.numerix', 
> 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 
> 'matplotlib.numerix.linear_algebra', 
> 'matplotlib.numerix.random_array', 
> 'matplotlib.numerix.fft', 'matplotlib.delaunay', 
> 'dateutil', 'dateutil/zoneinfo']
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-x86_64-2.5
> copying lib/pylab.py -> build/lib.linux-x86_64-2.5
> creating build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/hatch.py -> 
> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/widgets.py -> 
> build/lib.linux-x86_64-2.5/matplotlib
> error: can't copy 'lib/matplotlib/mathtext.py': doesn't 
> exist or not a regular file
>   
> Nils
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for screenshot.rst - pie

[Michael Droettboom]

I'm definitely not smarter than you, but I had looked at backend_cairo 
more recently :)  I've done the merge.

Cheers,
Mike

Ryan May wrote:
> Checked in on the branch.  I'm seeing some merge conflicts on
> backend_cairo.py at the moment, so I'll let someone smarter than me merge to
> trunk. :)
>
> Good find.
>
> Ryan
>
> On Mon, Mar 23, 2009 at 1:01 PM, Sandro Tosi  wrote:
>
>   
>> Hi all,
>> I found a really nice typo:
>>
>> 
>> $ svn diff
>> Index: doc/users/screenshots.rst
>> ===
>> --- doc/users/screenshots.rst   (revision 7000)
>> +++ doc/users/screenshots.rst   (working copy)
>> @@ -82,7 +82,7 @@
>>  ==
>>
>>  The :func:`~matplotlib.pyplot.pie` command
>> -uses a matlab(TM) compatible syntax to produce py charts.  Optional
>> +uses a matlab(TM) compatible syntax to produce pie charts.  Optional
>>  features include auto-labeling the percentage of area, exploding one
>>  or more wedges out from the center of the pie, and a shadow effect.
>>  Take a close look at the attached code that produced this figure; nine
>> <<<
>>
>> Indeed pronunciation is the same, but the result is quite funny :)
>>
>> Cheers,
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>>
>>
>> --
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> 
>
>
>
>   
> 
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] patches have incorrect alpha values

[Michael Droettboom]

Jouni K. Seppänen wrote:
> Eric Firing  writes:
>   
>> John Hunter wrote:
>> 
>>> One possibility would be to have a facecolor/edgecolor property on
>>> the gc itself, which would be rgba tuples. Since the gc is almost
>>> entirely internal, we can revamp it w/o affecting userland code,
>>> though it would be nice to support legacy methods (eg gc.set_alpha
>>> could warn and then proceed to set the edge and face alpha channel).
>>> Then we would drop the rgbFace argument entirely. Obviously this
>>> would require hacking through a bunch of backend code to fix, but the
>>> changes would be fairly straightforward and of the busy-work variety.
>>>   
>
>   
One open question is whether set_alpha (even if deprecated) should set 
or multiply the alpha of the fill and edge color.  But I think I'm in 
favor of creating "one way to do it", which would be to have alpha as 
the fourth component of any color -- that option also scales well to 
individual colors in a collection, in a way that any of the more global 
options don't.

It strikes me that if none of us find the time for this, this task would 
be a good initial GSoC task...  it's not enough work for an entire 
summer by any means, but it's "busy work" that touches a lot of parts of 
the code, and therefore a good introduction to the code base.  The other 
related task is to create a gc-like object for collections so that the 
arguments to draw_collection don't have to change in every backend every 
time a new feature is added.

> This sounds like a good idea. In the pdf backend, GraphicsContextPdf
> already defines a _fillcolor attribute, and for example draw_path does
>
> def draw_path(self, gc, path, transform, rgbFace=None):
> self.check_gc(gc, rgbFace)
> # ...
>
> where check_gc just temporarily sets gc._fillcolor to the value of
> rgbFace and issues the pdf commands to change the graphics state to
> reflect gc. If rgbFace is absorbed into gc, at least the pdf backend
> should be easy to change accordingly, and should become less complex in
> the process. Currently the same alpha value (gc._alpha) is used for both
> strokes and painting operations, but this too should be easy to change
> if we decide to drop the _alpha attribute from GraphicsContext and use
> the fourth component of the stroke and fill colors for alpha.
>
> By the way, the PDF imaging model has much richer support for
> transparency than just specifying an alpha value for each operation; the
> Transparency chapter takes up 64 pages in the PDF spec¹. One thing that
> I imagine somebody just might want to have support for in matplotlib are
> transparency groups², i.e., blending some objects together and then
> blending the group with the background. But I wonder if that's possible
> in Agg - I guess we will want to stay pretty close to the greatest
> common denominator of Agg, SVG and PDF, and let people with special
> needs use other software such as Illustrator to postprocess the files.
>
> ¹ http://www.adobe.com/devnet/pdf/pdf_reference_archive.html
> ² 
> http://itext.ugent.be/library/com/lowagie/examples/directcontent/colors/transparency.pdf
>
>   
>> Maybe we need an MplColorSpec class.  At present, functions and methods 
>> typically accept colors and/or color arrays in a wide variety of forms. 
>>   This is good.  My thought is that these should then be converted by 
>> the accepting function or method to instances of the new class, and that 
>> instances of the new class should be accepted as color inputs along with 
>> all the old forms.
>> 
>
> replacing the current hack, neat
> as it is, where a string representation of a decimal number means a
> grayscale color, a string beginning with # means a hexadecimal color,
> etc. The pyplot API should of course continue to work as it does now.
>
>   
I really like Eric's suggestion here, as it fits in well with my desire 
to verify arguments early and consistently.  But I don't think we need 
to throw out the convenient string forms of colors to achieve it.  Those 
are really handy, and fairly well known from HTML/CSS/SVG etc., and I 
worry forcing the user to provide an instance of a particular class to 
do something as common as setting a color would be annoying verbosity.  
Of course, they should be free to do so if there's other maintenance 
advantages as you suggested.

Mike


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


--
Apps built with the Adobe(R)

Re: [matplotlib-devel] SF.net SVN: matplotlib:[7016] branches/v0_98_5_maint/lib/matplotlib

[Michael Droettboom]

Thanks.  I just saw that maskedarray.putmask was gone and reached for 
the nearest thing.  I'll update this to what you suggest.

Mike

Eric Firing wrote:
> mdb...@users.sourceforge.net wrote:
>> Revision: 7016
>>   
>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7016&view=rev
>> Author:   mdboom
>> Date: 2009-03-31 15:22:06 + (Tue, 31 Mar 2009)
>>
>
> ...
>
>> Modified: branches/v0_98_5_maint/lib/matplotlib/transforms.py
>> ===
>> --- branches/v0_98_5_maint/lib/matplotlib/transforms.py2009-03-31 
>> 15:13:24 UTC (rev 7015)
>> +++ branches/v0_98_5_maint/lib/matplotlib/transforms.py2009-03-31 
>> 15:22:06 UTC (rev 7016)
>> @@ -975,8 +975,7 @@
>>  if self._invalid:
>>  points = self._transform.transform(self._bbox.get_points())
>>  if ma.isMaskedArray(points):
>> -points.putmask(0.0)
>> -points = np.asarray(points)
>> +np.putmask(points, points.mask, 0.0)
>>  self._points = points
>>  self._invalid = 0
>>  return self._points
>
> Mike,
>
> A cleaner version is this:
>
> points = points.filled(0.0)
>
> Or you can replace the conditional and the assignment with the single 
> line:
>
> points = np.ma.filled(points, 0.0)
>
> Example:
>
> In [6]:np.ma.filled([1,2,3], 0.0)
> Out[6]:array([1, 2, 3])
>
> In [7]:np.ma.filled(np.ma.array([1,2,3], mask=[False,True,False]), 0.0)
> Out[7]:array([1, 0, 3])
>
> The version you have actually can fail:
>
> In [10]:zz = np.ma.ones(5)
>
> In [11]:zz
> Out[11]:
> masked_array(data = [ 1.  1.  1.  1.  1.],
>  mask = False,
>fill_value = 1e+20)
>
>
> In [12]:np.putmask(zz, zz.mask, 0)
> ------- 
>
> ValueErrorTraceback (most recent call 
> last)
>
> /home/efiring/ in ()
>
> ValueError: putmask: mask and data must be the same size
>
>
>
> Eric

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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] python-2.6 compatible matplotlib

[Michael Droettboom]

I did a lot of the initial fixes for Python 2.6 within the first week of 
the 2.6.0 release -- they were mostly of the warning/style nature.  I've 
been running it on 2.6 on and off ever since, so it should be ok.  But 
let us know if you find anything.

Cheers,
Mike

Adam Mercer wrote:
> On Sun, Apr 5, 2009 at 16:01, David Moore  wrote:
>
>   
>> I've had matplotlib running fine on Python 2.6 since shortly after the Python
>> 2.6 release.  I run Arch Linux.  Are you perhaps looking for Windows builds?
>> Or does your distro not have matplotlib compiled for Python 2.6 yet?
>> 
>
> No, I'm looking to package matplotlib for python-2.6 on MacPorts and
> wanted to check that there would be no unexpected surprises, but from
> the above it sounds like all should be good.
>
> Cheers
>
> Adam
>
> --
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] cannot use some fonts on pdf, ps, eps backends

[Michael Droettboom]

Matplotlib only subsets with Type 3 fonts as output.  Type 42 is much 
harder to generate.

We could try generating glyph names when none are available -- anything 
guaranteed to be unique within the font would be fine.  Since I don't 
run Windows, I need to somehow get access to the problematic font file 
for testing, though.

Cheers,
Mike

Jouni K. Seppänen wrote:
> "Andrew Hawryluk"  writes:
>
>   
>>> Does it help if you set ps.fonttype and pdf.fonttype to 42 in
>>> matplotlibrc?
>>>   
>> Yes, that works very well, thanks! However, it now embeds the entire
>> font rather than a subset. This results in a PDF of 14.4 MB with this
>> font. I ran it through ghostscript to get a PDF of 24.2 kB with
>> subsetting, but I'm wondering if I can get subsetting of type 42 fonts
>> directly from matplotlib?
>> 
>
> I'm afraid there's no support for that in the current version, except
> probably in the Cairo backend (every time I try to compile pycairo I run
> into trouble with some of the dependencies, but if you can get it to
> work, it's a very advanced graphics library for producing all sorts of
> formats).
>
>   

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

[Michael Droettboom]

IMHO 0.91 is probably retired at this point.  There are some bugfixes on 
that branch since the last release, but there's been no activity since 
10-05-2008.

Mike

Charlie Moad wrote:
> Sorry, I guess 0.98.5.3 looking at the branch.  No need for a 0.91
> update though?
>
> On Fri, Apr 10, 2009 at 3:06 PM, Charlie Moad  wrote:
>   
>> 0.98.6 only?
>>
>> On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing  wrote:
>> 
>>> Charlie Moad wrote:
>>>   
>>>> I might be able to squeeze some time in this weekend.  I am not
>>>> thrilled about the new visual studio requirements, nor do I have
>>>> access to it.  I know John started a build script for OSX and I have
>>>> been meaning to try something similar for mingw.  Is anyone opposed to
>>>> creating the official releases with mingw?
>>>> 
>>> As long as it works, I would greatly prefer it.  A build script would be
>>>  great.
>>>
>>> Eric
>>>
>>>   
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buglet: fig saving filenames (at least with Tk)

[Michael Droettboom]

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]: []
>
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Multiline equations: misuse in our part or wishlist item for mpl?

[Michael Droettboom]

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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] backend_cairo.py clipping, bug in SVN

[Michael Droettboom]

Yeah -- this looks like a bad merge from the branch.  The branch's 
version of convert_path takes two arguments, the trunk takes three 
because it was updated to support path simplification routines which do 
their own transformation.  The trunk has been updated to use the 
three-argument form consistently (r7069).

Mike

Michiel de Hoon wrote:
> Hi everybody,
>
> I believe a bug was introduced in revision 7002 of backend_cairo.py.
> This code, in two places, now calls RendererCairo.convert_path with two 
> arguments (ctx and tpath), whereas RendererCairo.convert_path expects three 
> arguments. In one other place, RendererCairo.convert_path is called 
> (correctly) with three arguments. One example of the code containing the bug 
> is
>
> tpath, affine = clippath.get_transformed_path_and_affine()
> ctx.new_path()
> affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, self.height)
> tpath = affine.transform_path(tpath)
> RendererCairo.convert_path(ctx, tpath)
>
> Before this revision, the corresponding code was 
>
> tpath, affine = path.get_transformed_path_and_affine()
> ctx.new_path()
> affine = affine + Affine2D().scale(1.0, -1.0).translate(0.0, 
> self.renderer.height)
> RendererCairo.convert_path(ctx, path, affine)  
>
> RendererCairo.convert_path is defined as
>
>@staticmethod
> def convert_path(ctx, path, transform):
>
> so with three arguments. Either the calls to convert_path are incorrect, or 
> convert_path should be updated to handle two arguments.
>
> --Michiel
>
>
>   
>
> --
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Solaris and GCC 4.3.x: error TTStreamWriter has no putc

[Michael Droettboom]

Thanks.  I have committed this to the 0.98.x branch and the trunk, so 
this fix will make it into the next release.

Mike

Dave Peterson wrote:
> When attempting to build matplotlib 0.98.5.2 on Solaris 10 using GCC 
> 4.3.3, I get an error:
>
> ttconv/pprdrv_tt2.cpp: In member function ‘void 
> GlyphToType3::stack(TTStreamWriter&, int)’:
> ttconv/pprdrv_tt2.cpp:107: error: ‘class TTStreamWriter’ has no member 
> named ‘putc’
>
> So I tried invoking GCC with the -E flag to get the output of the 
> preprocessor and I see that line 107 of pprdrv_tt2.cpp gets rewritten to:
> stream.putc(('{'), (&__iob[1]));
> so it seems that something in GCC 4.3.3 on Solaris is defining a 
> putchar macro that is doing this, but not correspondingly being 
> applied to the pprdrv.h.
>
> Searching the list archives, I see that back in July & August, 2008 
> there was a brief thread between Peter Norton and Mike Droettboom 
> about this and a proposal was made to rename TTStreamWriter::putchar 
> to TTStreamWriter:put_char. I just looked at the trunk and it looks 
> like this has never been done. Was there some other work-around that 
> didn't make it into the thread that obviated the need for the 
> mentioned change?
>
> I can confirm that the renaming of putchar to put_char does solve the 
> problem. I've attached a patch file, though it is against 0.98.5.2.
>
>
> -- Dave
>
> 
>
> --
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> 
>
> _______
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo Backend and Subpixel Rendering

[Michael Droettboom]

I'm with Eric on this -- let's try to do the right thing without 
requiring any user intervention.  I actually can't think of a use case 
that would require a subpixel argument on text... am I missing something?

Mike

Eric Firing wrote:
> John Hunter wrote:
>   
>> On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden  
>> wrote:
>> 
>>> Hi all,
>>>
>>> As some of you probably know I am working on the GSoC project to
>>> externalise the Mathtex engine from Matplotlib. Today I have been
>>> toying around with the renderer using various backends.
>>>
>>> One of the interesting things that I discovered was that the Cairo
>>> backend was making use of subpixel rendering. (Or 'ClearType' as
>>> Microsoft call it.) This is not surprising -- by default Cairo will
>>> respect a users fontconfig settings when rendering text. Since I have
>>> subpixel rendering enabled all text rendered by Cairo is subpixel
>>> rendered.
>>>
>>> While this is fantastic for on screen text -- being significantly more
>>> pleasing to look at that the text produced by the AGG backend -- it is
>>> unsuitable for print. Now it is not too difficult to disable this,
>>> Cairo has an API call: cairo_font_options_set_antialias to deal with
>>> this.
>>>
>>> While I could write a quick patch to always disable subpixel rendering
>>> it would be something off a loss to those who either view their graphs
>>> onscreen or export them for the web -- where using subpixel rendering
>>> is now surprisingly common.
>>>
>>> Is it worth looking into adding subpixel rendering as a configuration
>>> option?
>>>   
>> The matplotlib.lines.Line2D objects has an antialiased property -- we
>> could add the same property to matplotlib.text.Text to turn on/off
>> subpixel rendering (which could also be supported as an rc param)
>> 
>
> I haven't poked around, so this may be a stupid question, but: for 
> cairo, can subpixel rendering simply be left on for screen display and 
> automatically turned off when writing to a file via savefig?  If this 
> can be done, it seems like a better solution than requiring to the user 
> to turn the parameter on and off manually, depending on whether show() 
> or savefig() is being called.
>
> Eric
>
>   
>> JDH
>> 
>
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo Backend and Subpixel Rendering

[Michael Droettboom]

That plan makes sense to me. 

The argument I was trying to make was against subpixel rendering as a 
property of each Text object in matplotlib -- but later realised that's 
not really applicable to what you're doing with the external math tool 
anyway.

Cheers,
Mike


Freddie Witherden wrote:
> Hi all,
>
> On 11 May 2009, at 12:43, Michael Droettboom wrote:
>   
>> I'm with Eric on this -- let's try to do the right thing without
>> requiring any user intervention.  I actually can't think of a use case
>> that would require a subpixel argument on text... am I missing  
>> something?
>> 
>
> Cairo has an image backend, which is usually used for both on-screen  
> rendering and which also supports saving to a file. When displaying on- 
> screen the default is most probably fine -- Cairo gets its subpixel  
> rendering settings from the OS (fontconfig on Linux) so all is well.
>
> However, when saving to a file, depending on its intended use one may  
> either want to enable/disable subpixel antialiasing/rendering. If it  
> is intended for print you probably want to disable it, however, for  
> web graphics subpixel rendering is extremely common.
>
> Furthermore Cairo also has provisions for subpixel antialiasing for  
> line art. (So the same techniques which are applied to text are also  
> applied to polygons, curves &c.) While none of the backends currently  
> make use of it, it is quite likely that in the future the image  
> backend will support it. Therefore a general subpixel antialiasing  
> setting might be a better bet.
>
> I would therefore suggest having two options: one for when printing  
> and another for displaying on screen. The default for printing/saving  
> should probably be off, while the displaying should be got from the  
> system.
>
> Regards, Freddie.
>
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> ___________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Michael Droettboom]

That's right, Eric.  I think having resolution be an attribute of the 
artist (and not the projection) is the "path" of least resistance here.  
To clarify, however, the interpolation (more specifically, whether to 
interpolate) should remain a function of the projection, not the path.  
That's the important point that lead to it ending up in the wrong place 
in the first place.  If we aim to keep the generalization that all grid 
lines are the same kind of object regardless of the projection, and 
therefore set a high resolution parameter on all the grid lines, we 
wouldn't want this to slow down the standard rectilinear axes.  As long 
as the standard axes don't obey the parameter, then would should be 
fine.  It's somewhat confusing, but I also am seeing this the resolution 
parameter on artists as more of an implementation detail than a public 
API.  If someone wants to interpolate their data, IMHO that should be 
the user's responsibility, since they know the best way to do it.  This 
functionality isn't really about data points, IMHO.

The more difficult change seems to be being backward compatible about 
the Polar plot accepting a resolution argument.  I'm not even certain 
that it's worth keeping, since as you suggest, it makes more sense for 
it to be a property of the artist.  I'd almost prefer to raise a warning 
if the user provides a resolution argument (other than 1) to Polar 
rather than trying to make it work.  Is anyone actually using it, other 
than to set it to 1 on 0.98.x versions?

I should have some time to work on this today.

Mike

Eric Firing wrote:
> Eric Firing wrote:
>> Jae-Joon Lee wrote:
>>> The default resolution (which is used to interpolate a path in polar
>>> coordinate) has change to 1 at some point. And because of this, a
>>> radial grid becomes a 0-length line. Increasing the resolution will
>>> bring back your gridlines.
>>
>> This is not the right solution, though.  There was a reason for the 
>> change in default resolution to 1--it gives the expected behavior for 
>> plotting a line between two points in polar coordinates--and it is 
>> not going back.  The inability to set resolution on a per-artist 
>> basis is a serious problem that doesn't seem to have a simple 
>> solution.  Until one can be found, some sort of special case handling 
>> will be needed for the radial grid lines.
>>
>> Eric
>
>
> Expanding on this: it looks like a possible solution is to attach a 
> new "resolution" attribute to the Path object.  This would ordinarily 
> be None, but could be set to another value when the Path is created 
> (or later).  Then the PolarTransform.transform_path method (and the 
> same in other curvilinear projections) could use that value, if not 
> None, to control interpolation.  Some additional changes would be 
> needed to apply this to the radial gridlines.
>
> Now it is not clear to me that resolution should be an attribute of 
> the PolarAxes at all--the interpolation is done by a path method, so 
> that method doesn't need a resolution parameter at all if resolution 
> is a Path attribute.  Except for backwards compatibility.  Comments, 
> Mike?
>
> I can't implement it right now, but if no one comes up with a better 
> solution, or wants to implement something like this one, then I can do 
> it in a day or two.
>
> (Of course, I may not be seeing a stumbling block.)
>
> Eric

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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating Circle.radius has no effect (+minor example fix)

[Michael Droettboom]

> but as I look through patches, I notice there are a number of places
> (eg RegularPolygon) where hidden methods w/o docstrings are used.  I
> assume Michael wrote most of these in the transforms refactorring.
> Was this a conscious decision to hide them from the doc proprty
> introspection mechanism?
>   
I don't think so.  IIRC, most of what are now properties were raw 
attributes at one time, and the hidden methods was just to avoid adding 
more things to the public namespace.  But I don't see any compelling 
reason they couldn't be public.

Mike

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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] radial grids broken on polar?

[Michael Droettboom]

Thanks.  Should be fixed now in SVN.

Mike

Andrew Straw wrote:
> Hi Mike, I think you introduced a regression in r7131. I picked this up
> using "python backend_driver.py agg":
>
> examples/api$ python custom_projection_example.py
> Traceback (most recent call last):
>   File "custom_projection_example.py", line 440, in 
> subplot(111, projection="hammer")
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/pyplot.py",
> line 645, in subplot
> a = fig.add_subplot(*args, **kwargs)
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
> line 690, in add_subplot
> a = subplot_class_factory(projection_class)(self, *args, **kwargs)
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 7802, in __init__
> self._axes_class.__init__(self, fig, self.figbox, **kwargs)
>   File "custom_projection_example.py", line 35, in __init__
> Axes.__init__(self, *args, **kwargs)
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 525, in __init__
> self.set_figure(fig)
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 597, in set_figure
> self._set_lim_and_transforms()
>   File "custom_projection_example.py", line 94, in _set_lim_and_transforms
> self.transProjection = self.HammerTransform(self.RESOLUTION)
> TypeError: __init__() takes exactly 1 argument (2 given)
>
>
> Michael Droettboom wrote:
>   
>> That's right, Eric.  I think having resolution be an attribute of the 
>> artist (and not the projection) is the "path" of least resistance here.  
>> To clarify, however, the interpolation (more specifically, whether to 
>> interpolate) should remain a function of the projection, not the path.  
>> That's the important point that lead to it ending up in the wrong place 
>> in the first place.  If we aim to keep the generalization that all grid 
>> lines are the same kind of object regardless of the projection, and 
>> therefore set a high resolution parameter on all the grid lines, we 
>> wouldn't want this to slow down the standard rectilinear axes.  As long 
>> as the standard axes don't obey the parameter, then would should be 
>> fine.  It's somewhat confusing, but I also am seeing this the resolution 
>> parameter on artists as more of an implementation detail than a public 
>> API.  If someone wants to interpolate their data, IMHO that should be 
>> the user's responsibility, since they know the best way to do it.  This 
>> functionality isn't really about data points, IMHO.
>>
>> The more difficult change seems to be being backward compatible about 
>> the Polar plot accepting a resolution argument.  I'm not even certain 
>> that it's worth keeping, since as you suggest, it makes more sense for 
>> it to be a property of the artist.  I'd almost prefer to raise a warning 
>> if the user provides a resolution argument (other than 1) to Polar 
>> rather than trying to make it work.  Is anyone actually using it, other 
>> than to set it to 1 on 0.98.x versions?
>>
>> I should have some time to work on this today.
>>
>> Mike
>>
>> Eric Firing wrote:
>> 
>>> Eric Firing wrote:
>>>   
>>>> Jae-Joon Lee wrote:
>>>> 
>>>>> The default resolution (which is used to interpolate a path in polar
>>>>> coordinate) has change to 1 at some point. And because of this, a
>>>>> radial grid becomes a 0-length line. Increasing the resolution will
>>>>> bring back your gridlines.
>>>>>   
>>>> This is not the right solution, though.  There was a reason for the 
>>>> change in default resolution to 1--it gives the expected behavior for 
>>>> plotting a line between two points in polar coordinates--and it is 
>>>> not going back.  The inability to set resolution on a per-artist 
>>>> basis is a serious problem that doesn't seem to have a simple 
>>>> solution.  Until one can be found, some sort of special case handling 
>>>> will be needed for the radial grid lines.
>>>>
>>>> Eric
>>>> 
>>> Expanding on this: it looks like a possible solution is to attach a 
>>> new "resolution" attribute to the Path object.  This would ordinarily 
>>> be None, but could be set to another value when the Path is created 
>>> (or later).  Then the PolarTransform.transform_path method (and the 

Re: [matplotlib-devel] radial grids broken on polar?

[Michael Droettboom]

Eric Firing wrote:
> Michael Droettboom wrote:
>> That's right, Eric.  I think having resolution be an attribute of the 
>> artist (and not the projection) is the "path" of least resistance 
>> here.  To clarify, however, the interpolation (more specifically, 
>> whether to interpolate) should remain a function of the projection, 
>> not the path.  That's the important point that lead to it ending up 
>> in the wrong place in the first place.  If we aim to keep the 
>> generalization that all grid lines are the same kind of object 
>> regardless of the projection, and therefore set a high resolution 
>> parameter on all the grid lines, we wouldn't want this to slow down 
>> the standard rectilinear axes.  As long as the standard axes don't 
>> obey the parameter, then would should be fine.  It's somewhat 
>> confusing, but I also am seeing this the resolution parameter on 
>> artists as more of an implementation detail than a public API.  If 
>> someone wants to interpolate their data, IMHO that should be the 
>> user's responsibility, since they know the best way to do it.  This 
>> functionality isn't really about data points, IMHO.
>
> Mike,
>
> Thanks for taking care of this so quickly.
>
> Although I agree that _interpolation_steps is a low-level, 
> implementation-dependent attribute (which might not be the right 
> specification if interpolation were changed to take advantage of 
> Bezier curves, for example), I think that some sort of 
> "follow_curvilinear_coordinates" public Artist attribute would be 
> desirable.  For example, one might want to plot a set of arcs, or 
> arc-shaped patches (warped rectangles) on a polar plot.  It would be 
> nice to be able to do this using lines, line collections, rectangle 
> patches, or rectangle collections, by adding a single kwarg to set 
> that attribute.  Then it would be up to each Artist to use that 
> attribute to set _interpolation_steps or whatever implementation 
> mechanism is in place.  Possibly it does not make sense as a general 
> Artist attribute but should be restricted to a subset, but it is 
> probably simpler to put it at the Artist level and then selectively 
> apply it. 
Agreed with all of the above -- all the infrastructure is now in place 
to do this.  I was most concerned with fixing the bug (seeming lack of 
gridlines) first, and then getting this improvement in later (probably 
not till next week).

Cheers,
Mike

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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Arc requires explicitly setting fill=False?

[Michael Droettboom]

Yes -- that is correct.  Arc's are unfillable by design -- such a thing 
might be possible, but it would require some extra work to the code to 
generate rectilinear lines around the edges of the clipped area. 

I think this fix is correct -- the purpose is to warn the user trying to 
fill an Arc that filling is not possible.

Cheers,
Mike

Eric Firing wrote:
> John Hunter wrote:
>   
>> On Sun, May 24, 2009 at 7:20 PM, Eric Firing  wrote:
>> 
>>> Tony S Yu wrote:
>>>   
>>>> Currently, Arc in matplotlib.patches requires that it be called with
>>>> kwarg ``fill=False``. Was this behavior intentional? The code suggests
>>>> that a default value was left out of the kwarg lookup.
>>>>
>>>> I've attached a simple patch to fix this (it still fails when fill set
>>>> to True).
>>>> 
>>> Thanks. I committed a slightly different fix.  I think this handles all
>>> possibilities.
>>>
>>>   
>> Michael can weigh in on this when he has a chance, but my recollection
>> is that Arc was added to satisfy a JPL reported bug when one zooms
>> into a small region of an ellipse -- in that case our 4 spline
>> approximation code was inadequate, and in a heroic burst Michael
>> provided an 8 spline interpolation limited to the viewport.  Ie,
>> instead of getting 4 splines for the entire ellipse, with his Arc
>> class you get 8 for the segment in the viewport.  As part of this, he
>> decided it was mostly impossible to fully support filling, or at least
>> too difficult, so he may have intentionally raised this error.  So we
>> should be careful here, because it may be that simple arcs, those
>> where everything is in the viewport, work ok with filling, but things
>> break down when his zoom optimizations are triggered.
>> 
>
> John,
>
> Yes, Arc is a very special-purpose class, and not really a patch at all. 
>   Actually, according to the docstrings, the Ellipse is calculated with 
> 8 splines, and Arc is calculated with 8 splines for the viewable portion 
> alone.
>
> The change I made merely made it so that Arc works with no fill kwarg at 
> all, or with fill=False, and as before, it raises an error if 
> fill==True.  I suspect this is the behavior Mike intended--I doubt he 
> meant to *require* a kwarg that can take only one value without raising 
> an error--but certainly he can correct me if I am mistaken.
>
> Eric
>
>   
>> JDH
>> 
>
>
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transform question

[Michael Droettboom]

This is off the top of my head. I haven't really been following this 
thread and I wasn't able to determine which was the most current patch 
to apply.

It looks like you don't actually want to apply the axes transform twice 
(which get_xaxis_transform() + mtransforms.ScaledTranslation(0.5, 0, 
self.axes.transAxes) would do). 

What seems to work for me is to transform the input coordinates *before* 
applying the existing axis transform:

mtransforms.Affine2D().translate(0.0, 0.5) + self.get_xaxis_transform()

I would suggest that you could keep two kinds of spine transforms (those 
relative to the axes and those given in points) separate.  Build the 
whole pipeline all the time and then just allow the user to tweak either 
or both, and thus have something like:

transform_by_axes_units + self.get_xaxis_transform() + 
transform_by_points

Using them in combination may be rare, but isn't completely nonsensical.

Hope that helps,
Mike

Andrew Straw wrote:
> Hi MPL transform gurus (aka Mike),
>
> I'm trying to close on this "dropped spine" thing, and I have a question
> I think you could save me some time on.
>
> I need to get a transform that will be combined with the normal xaxis
> transform to shift the spine and associated ticks and tick labels by
> some amount. For my first incarnation, I used something like
>
> mtransforms.ScaledTranslation(offset_x,offset_y,self.figure.dpi_scale_trans)
>
> This is fine when I new the offset in points directly. However, now I'd
> like to support offsetting the spine to the center of the Axes. So, for
> this case, I'd like to calculate the offset transform required to take
> axes coordinate 0 and translate it to 0.5. Thus, I think I need
> something like
>
> mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes)
>
> Unfortunately, that's clearly not working. So, is there a quick fix for
> this?
>
> Note that, as I've implemented things, the easiest path is that the new
> transform is a translation combined with the existing xaxis transform
> (using "get_xaxis_transform() + my_new_transform"). Other methods may be
> possible, but I think they'll be a lot more work.
>
> Thanks,
> Andrew
>   

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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Note: matplotlib book

[Michael Droettboom]

A review of a book primarily on matplotlib, numpy and scipy has hit the 
front page of Slashdot.

http://books.slashdot.org/article.pl?sid=09/05/27/1327255&from=rss

Mike

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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Python-modules-team] Bug#531024: Duplicate version of python-pyparsing included

[Michael Droettboom]

I've found pyparsing rather brittle between revisions in the past, hence 
the desire to have a local copy.  I don't know if recent versions have 
stabilized -- given that we have something that works, I'm not too keen 
on tinkering with it. 

Not knowing much about packaging myself, I think Debian should only go 
forward with using an external dependency if an *exact* version of 
pyparsing can be specified, rather than >=.  Or at the very least, if a 
different version of pyparsing is applied, one needs to make sure that 
the mathtext examples all pass unchanged.

Mike

Sandro Tosi wrote:
> Hi guys,
>
> On Fri, May 29, 2009 at 11:51, Daniel Watkins
>  wrote:
>   
>> Package: python-matplotlib
>> Version: 0.98.3-5
>> Severity: normal
>>
>> python-matplotlib installs its own copy of pyparsing.py when it should
>> in fact be using the copy that is shipped in python-pyparsing.
>> 
>
> We've just receive this bug report about the internal copy of
> pyparsing included in mpl.
>
> The situation in Debian is:
>
> Stable  1.5.0-1
> Testing   1.5.1-2
> Unstable  1.5.2-1
>
> Currently mpl ship:
>
> $ grep "^__version" lib/matplotlib/pyparsing.py
> __version__ = "1.5.0"
> __versionTime__ = "28 May 2008 10:05"
>
> In the changelog I can see:
>
> $ egrep -A2 "2007-11-09.*pyparsing" CHANGELOG
> 2007-11-09 Moved pyparsing back into matplotlib namespace. Don't use
>system pyparsing, API is too variable from one release
>to the next - DSD
>
> So there seems to be a reason for this "private" copy. The question
> is: is this reason still valid nowdays? should we (at least packagers)
> remove the private copy and rely on the system pyparsing (or at least
> introduce a "check if system has pyparsing, if not fallback on
> private" wrap)?
>
> I haven't checked, but maybe you already know the answer :)
>
> Cheers,
>   

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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] gtk versions: drop support for less than 2.4?

[Michael Droettboom]

I'm +1 on dropping support for gtk+ < 2.4 (if even later).  Those 
multiple code paths were a pain, and installing multiple versions of 
gtk+ for testing is also something I'd like to stop doing.

Cheers,
Mike

Eric Firing wrote:
> We still require only gtk 2.2, and consequently carry around some extra 
> chunks of code to support versions before 2.4.  Can we drop this and 
> require 2.4 or later?  Or possibly even a later version?  It looks like 
> 2.4 came out in the fall of 2004.
>
> Eric
>
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Curvelinear grid support

[Michael Droettboom]

Jae-Joon,

I just saw your curvelinear grid support fall into SVN.  Very 
impressive!  We actually may have a use for it here at Space Telescope 
for drawing "World Coordinate System (WCS)" plots.

One quick question though -- it seems that this functionality is 
completely independent of the axes_grid stuff, which is primarily about 
layout out axes within a figure, correct?  Is there a reason why it's 
part of the axes_grid toolkit that I'm missing?

Cheers,
Mike

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


--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] The easiest way to check-out matplotlib source

[Michael Droettboom]

Gökhan SEVER wrote:
> One more question: After svn co completes checking out the main trunk 
> it says:
>
> Checked out revision 7203.
>
> However when I do:
>
> In [1]: matplotlib.__revision__
> Out[1]: '$Revision: 6887 $'
>
> Which one is correct?
The __revision__ in from matplotlib is the revision number on 
matplotlib's __init__.py file, which will always lag behind the revision 
of the most recently-changed file in the source tree (which is what SVN 
tells you).

Mike

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


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Large datasets performance....

[Michael Droettboom]

vehemental wrote:
> Hello,
>
> I'm using matplotlib for various tasks beautifully...but on some occasions,
> I have to visualize large datasets (in the range of 10M data points) (using
> imshow or regular plots)...system start to choke a bit at that point...
>   
The first thing I would check is whether your system becomes starved for 
memory at this point and virtual memory swapping kicks in.

A common technique for faster plotting of image data is to downsample it 
before passing it to matplotlib.  Same with line plots -- they can be 
decimated.  There is newer/faster path simplification code in SVN trunk 
that may help with complex line plots (when the path.simplify rcParam is 
True).  I would suggest starting with that as a baseline to see how much 
performance it already gives over the released version.
> I would like to be consistent somehow and not use different tools for
> basically similar tasks...
> so I'd like some pointers regarding rendering performance...as I would be
> interested to be involved in dev is there is something to be done
>
> To active developers, what's the general feel does matplotlib have room to
> spare in its rendering performance?...
>   
I've spent a lot of time optimizing the Agg backend (which is already 
one of the fastest software-only approaches out there), and I'm out of 
obvious ideas.  But a fresh set of eyes may find new things.  An 
advantage of Agg that shouldn't be overlooked is that is works 
identically everywhere.
> or is it pretty tied down to the speed of Agg right now?
> Is there something to gain from using the multiprocessing module now
> included by default in 2.6?
>   
Probably not.  If the work of rendering were to be divided among cores, 
that would probably be done at the C++ level anyway to see any gains.  
As it is, the problem with plotting many points generally tends to be 
limited by memory bandwidth anyway, not processor speed.
> or even go as far as using something like pyGPU for fast vectorized
> computations...?
>   
Perhaps.  But again, the computation isn't the bottleneck -- it's 
usually a memory bandwidth starvation issue in my experience.  Using a 
GPU may only make matters worse.  Note that I consider that approach 
distinct from just using OpenGL to colormap and render the image as a 
texture.  That approach may bear some fruit -- but only for image 
plots.  Vector graphics acceleration with GPUs is still difficult to do 
in high quality across platforms and chipsets and beat software for speed.
> I've seen around previous discussions about OpenGL being a backend in some
> future...
>   
> would it really stand up compared to the current backends? is there clues
> about that right now?
>
> thanks for any inputs! :D
> bye
>   
Hope this helps,
Mike

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


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Large datasets performance....

[Michael Droettboom]

Ludwig Schwardt wrote:
> Does the new path simplification code use a similar approach to snd?
> I've always wanted something like that in matplotlib... :-)
>
>   
Not knowing the details of what snd is doing, I would say "probably".  
The general idea is to remove points on-the-fly that do not change the 
appearance of the plot at the given resolution.  Spending the time to do 
this at the front speeds up the path stroking immensely as it has fewer 
vertices and therefore fewer self-intersections to compute.  I suspect 
what matplotlib is doing is a little more general, and therefore not 
quite as efficient as snd, because it can't assume a 1-dimensional time 
series.

To give credit where it is due, the path simplification was originally 
written by Allan Haldane and has been in matplotlib for some time.  The 
recent work has been to fix some bugs when dealing with some degenerate 
cases, to improve its performance, greatly improve the clipping 
algorithm and allow the tolerance to be user-configurable.

Mike

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


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Strange bit-depth PNGs

[Michael Droettboom]

I don't ever work with data-in-PNGs, so I won't comment on the use cases 
or API here -- I'll leave that to others.

However, for the patch, I think the reinterpret_cast 
would be safer as reinterpret_cast, since unsigned ints are 
not guaranteed to be 16-bits, and png.h provides a nice convenient 
typedef for us.  Also, why does the code not create an 8-bit numpy array 
for "raw" images that are only 8-bits?

Also a style note: I find assignments inside of ternary operators (... ? 
... : ...) confusing.  I'd rather see that as a proper "if" block.

Cheers,
Mike

Tobias Wood wrote:
> Dear list,
> Back in April I submitted a patch that allowed imread() to correctly 
> read PNGs that have odd bit-depths, ie not 8 or 16 (I actually 
> submitted that to the Users list as I was unsure of protocol). There 
> were a couple of things I left unfinished that I've finally got round 
> to looking at again.
>
> The main remaining issue for me is that PNG specifies that all bit 
> depths should be scaled to have the same maximum brightness, so that a 
> value of 8191 in an 13-bit image is displayed the same as 65535 in a 
> 16-bit image. Unfortunately, the LabView drivers for the 12-bit CCD in 
> our lab do not follow this convention. A higher bit-depth from this 
> setup means the image was brighter in an absolute sense and no scaling 
> takes place. So this is not an error with Matplotlib as such, but more 
> about having a decent way to handle iffy PNGs. It is worth noting that 
> Matlab does not handle these PNGs well either (We have to query the 
> image file using iminfo and then correct it) and PIL ignores anything 
> above 8-bits as far as I can tell.
>
> A simple method, in my mind, and originally suggested by Andrew Straw 
> is to add a keyword argument to imread() that indicates whether a user 
> wants floats scaled between 0 and 1, or the raw byte values which they 
> can then scale as required. This then gets passed to read_png(), which 
> does the scaling if necessary and if not returns an array of UINT16s. 
> I wrote a patch that does this, changing both image.py and _png.cpp. 
> I'm very much open to other suggestions, as I didn't particularly want 
> to fiddle with a core function like imread() and I'm fairly new to 
> Python. In particular I have not changed anything to do with PIL - 
> although it would not be much work to update pil_to_array() to follow 
> the same behaviour as read_png(). I have tested this with the 
> pngsuite.py*, and if desired I can submit an extended version of this 
> that tests the extended bit-depth images from the PNG suite.
>
> Thanks in advance,
> Toby Wood
>
> * My patch also includes a minor change to pngsuite.py which was 
> throwing a deprecation warning about using get_frame() istead of patch
> 
>
> --
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> ----
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Strange bit-depth PNGs

[Michael Droettboom]

Tobias Wood wrote:
> Michael,
> Thanks for the comments, much appreciated. I've attached an updated 
> patch including your suggestions and some more whitespace for 
> readability. There was no reason other than simplicity for not 
> returning a 8-bit numpy array. I actually meant to ask about the 
> ternary blocks - I think I picked up the style from the original code 
> and had continued in the same vein for compactness.
Thanks!
>
> While I was testing this I came across another issue - which variety 
> of FLOAT should the code return? My understanding was that Python 
> floats are C doubles. However the code was previously returning a 
> PyArray_FLOAT, which seems to be a FLOAT32 rather than a FLOAT64. 
> Hence I removed any trace of doubles from my code and have left it all 
> at float precision.
Yes, that's all correct.  I suspect read_png creates arrays of floats 
rather than doubles just for the sake of memory savings -- and the fact 
that doubles would be overkill for even 16-bit integral data.

Thanks for the new patch.  I'll wait a bit to see if there's any 
comments on the functionality itself or the API before committing it.

Cheers,
Mike
>
> Thanks again,
> Toby
>
> On Mon, 22 Jun 2009 15:58:58 +0100, Michael Droettboom 
>  wrote:
>
>> I don't ever work with data-in-PNGs, so I won't comment on the use 
>> cases or API here -- I'll leave that to others.
>>
>> However, for the patch, I think the reinterpret_cast> *> would be safer as reinterpret_cast, since unsigned 
>> ints are not guaranteed to be 16-bits, and png.h provides a nice 
>> convenient typedef for us.  Also, why does the code not create an 
>> 8-bit numpy array for "raw" images that are only 8-bits?
>>
>> Also a style note: I find assignments inside of ternary operators 
>> (... ? ... : ...) confusing.  I'd rather see that as a proper "if" 
>> block.
>>
>> Cheers,
>> Mike
>>
>> Tobias Wood wrote:
>>> Dear list,
>>> Back in April I submitted a patch that allowed imread() to correctly 
>>> read PNGs that have odd bit-depths, ie not 8 or 16 (I actually 
>>> submitted that to the Users list as I was unsure of protocol). There 
>>> were a couple of things I left unfinished that I've finally got 
>>> round to looking at again.
>>>
>>> The main remaining issue for me is that PNG specifies that all bit 
>>> depths should be scaled to have the same maximum brightness, so that 
>>> a value of 8191 in an 13-bit image is displayed the same as 65535 in 
>>> a 16-bit image. Unfortunately, the LabView drivers for the 12-bit 
>>> CCD in our lab do not follow this convention. A higher bit-depth 
>>> from this setup means the image was brighter in an absolute sense 
>>> and no scaling takes place. So this is not an error with Matplotlib 
>>> as such, but more about having a decent way to handle iffy PNGs. It 
>>> is worth noting that Matlab does not handle these PNGs well either 
>>> (We have to query the image file using iminfo and then correct it) 
>>> and PIL ignores anything above 8-bits as far as I can tell.
>>>
>>> A simple method, in my mind, and originally suggested by Andrew 
>>> Straw is to add a keyword argument to imread() that indicates 
>>> whether a user wants floats scaled between 0 and 1, or the raw byte 
>>> values which they can then scale as required. This then gets passed 
>>> to read_png(), which does the scaling if necessary and if not 
>>> returns an array of UINT16s. I wrote a patch that does this, 
>>> changing both image.py and _png.cpp. I'm very much open to other 
>>> suggestions, as I didn't particularly want to fiddle with a core 
>>> function like imread() and I'm fairly new to Python. In particular I 
>>> have not changed anything to do with PIL - although it would not be 
>>> much work to update pil_to_array() to follow the same behaviour as 
>>> read_png(). I have tested this with the pngsuite.py*, and if desired 
>>> I can submit an extended version of this that tests the extended 
>>> bit-depth images from the PNG suite.
>>>
>>> Thanks in advance,
>>> Toby Wood
>>>
>>> * My patch also includes a minor change to pngsuite.py which was 
>>> throwing a deprecation warning about using get_frame() istead of patch
>>>  
>>>
>>>
>>> --
>>>  

Re: [matplotlib-devel] Potential Bug in axes.py

[Michael Droettboom]

What's in there now should work with numpy arrays, but obviously not 
Python lists.  I think the correct solution is actually to coerce width 
and height to arrays rather than lists.  But I'm hoping someone more 
familiar with the bar code can comment.  It should be a simple change to 
"make_iterable"

Cheers,
Mike

Brad Chivari wrote:
> Anyone? Am I way off the mark here?
>
> Thanks,
> Brad
>
> On Thu, 18 Jun 2009 14:41:03 -0300
> Brad Chivari  wrote:
>
>   
>> SUBJECT:
>> Filtering out 0 bar height/width not working
>>
>> FILE:
>> matplotlib/ trunk/ matplotlib/ lib/ matplotlib/ axes.py
>>
>> PROBLEM:
>> xmin = np.amin(width[width!=0]) # filter out the 0 width rects
>> ymin = np.amin(height[height!=0]) # filter out the 0 height rects
>>
>> These aren't using proper python list comprehension and don't work as 
>> expected (for me anyway).
>>
>> SOLUTION:
>> Shouldn't they be something like:
>> xmin = np.amin([w for w in width if w != 0])
>> ymin = np.amin([h for h in height if h != 0])
>>
>> Once I changed them they seem to work properly.
>>
>> Thanks,
>> Brad
>>
>> --
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing 
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
> --
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Does not build on Fedora 11

[Michael Droettboom]

Can you provide the compiler output you were seeing?  Which version of 
matplotlib are you using?

I've been using the SVN trunk on F11 for weeks with no issues, so I just 
want to verify the problem and solution are the correct ones here.

Cheers,
Mike

Andrei Smirnov wrote:
> A possible bug:
>
> I just tried to build matplotlib on Fedora 11 with:
>
> python setup.py build
>
> and it aborted with unresolved referecne to vsprintf
>
> I fixed the problem by including:
>
> #include 
>
> into
>
> src/mplutils.cpp
>
> -- 
> Andrei V. Smirnov, PhD.
> 
>
> --
>   
> 
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."

[Michael Droettboom]

This is a great project and I'm sure we're all looking forward to having 
"just one way to do it".

However, do not overestimate how up-to-date these packages will be, 
particularly in managed environments.  For instance the RHEL4 boxes we 
run at my employer still have pygtk 2.4.  (Yes, that is 4 years old!)  
It would be unfortunate if our users couldn't update matplotlib without 
the pain of recompiling a large part of the gtk stack underneath.

So just a plea to keep the old code paths working -- perhaps surrounded 
in big flashing "REMOVE ME LATER" comments.  I understand that 
maintaining code that fewer and fewer users will be running is like a 
time bomb.  Maybe we could raise a deprecation warning if a user has an 
old version of a toolkit, so at least when the bomb finally goes off the 
user has a first guess as to why.  But I think dropping all support for 
these older versions in one step would be a mistake.

Cheers,
Mike

Brian Granger wrote:
> Hello all,
>
> [sent to mpl-dev, enthought-dev and ipython-dev]
>
> This summer, we are doing some major refactoring of IPython's core.  
> One of the things I am working on is changing how IPython's works with 
> GUI toolkits.  These changes will have a significant impact (hopefully 
> for the better) on your project, so I wanted to open a discussion 
> about this issue.
>
> Here is the current situation:  currently, IPython uses threads to 
> allow GUI event loops.  This code lives in IPython.Shell and is 
> extremely subtle, hard to maintain and fragile.  Fernando and John 
> Hunter have done a fantastic job in developing this code, but in the 
> long run we need a more robust approach.
>
> Here is the proposal:  Python has an obscure hook called 
> PyOS_InputHook.  By using this hook, GUI toolkits can interleave their 
> event loop with a command line program *without threads*.  Even though 
> PyOS_InputHook is not well known, this is how Python's built-in 
> integration with Tk works.  The good news is that other GUI toolkits 
> are starting to support PyOS_InputHook:
>
> * PyGTK 2.15.1 has this.
> * The mpl MacOSX backend works this way
> * Recent versions of PyQT 4 have this.
> * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9
>
> Bottom line: once people are using these recent/upcoming versions of 
> the GUI toolkits, IPython will no longer need to maintain the code in 
> Shell.py and IPython won't need to have -pylab/-wthread/etc options. 
>
> So, how does affect your project?
>
> * People will be able to use your project interactive from the regular 
> python prompt.
> * You will need to make small changes to your GUI toolkits 
> initialization code.
> * All of us will need to coordinate version transitions to make sure 
> that there is a clean transition to this new approach.
> * I need help testing the new approach (especially with wxPython) to 
> make sure that your project actually works with the new approach.
>
> What needs to be done at this point?
>
> * I would like to discuss how the transition should be made in terms 
> of versions.
> * I need help testing this new approach in the various toolkits - 
> especially with wx.
> * I want to see if there are other issues related to this that I am 
> missing.
>
> Cheers,
>
> Brian
> 
>
> --
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> --------
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] examples/widgets/menu.py and mathtex

[Michael Droettboom]

It would be great to restore to_mask to mathtex as it can be useful for 
GUI frameworks that require both an RGB and A buffer (rather than a 
single RGBA buffer).  Its implementation should be pretty 
straightforward, since you already have image buffer output in mathtex.

There may be a way to re-write menu.py to not depend on mathtex -- such 
as using ft2font directly.  But since mathtex will become a hard 
requirement for matplotlib anyway, it may be easiest to just add to_mask 
and update the example to use the new mathtex APIs.

Cheers,
Mike

Freddie Witherden wrote:
> Hi all,
>
> I was grepping the source code today for any remaining uses of  
> matplotlib.mathtext in matplotlib and stumbled upon menu.py -- a menu  
> demo/example.
>
> Although it does use/import mathtex it seems to only use it for  
> rendering plain (non-math) text using the to_mask function. This is  
> something that mathtex has no equivalent of (and appears to be the  
> only use of it).
>
> Can anyone recommend an alternative way of writing menu.py so that it  
> does not depend on mathtex?
>
> Regards, Freddie.
>
> --
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Including mathtex in matplotlib

[Michael Droettboom]

There may be a setuptools solution here, but if there is, I'm not the 
one to know ;)  matplotlib is for the most part ignorant of setuptools, 
and it's probably reasonable to keep it that way.

Anyway, since the mathtex setup infrastructure is based on what 
matplotlib was already doing, there's a common convention we can 
exploit.  Essentially, the matplotlib setup.py builds up a list of 
extension modules (ext_modules) and packages and then passes those lists 
to distutils for building.  So, in theory, all mathtex needs to do is 
provide a function that will add extension modules and packages to those 
lists (basically like all of the build_* methods in setupext.py).  So 
basically, matplotlib's setup.py would import lib/mathtex/setupext.py 
(by filename) and call a method in it.  Lots of details I'm missing, but 
that should provide a general framework.

Another issue this raises is whether to build the FT2Font and png 
modules twice, once as part of matplotlib, and once as part of mathtex.  
Once mathtex is a truly external dependency for matplotlib, I don't see 
a way around this, so maybe we should just pretend we're already there, 
despite the duplication.  If we want to be clever, I could see mathtex 
being smart about imports: try importing its local copies of its 
libraries and failing that import matplotlib's.  I'm not entirely sure 
about that idea, but I sort of feel "hacky-if-you-do, 
hacky-if-you-don't" here ;) 

I see the code maintenance problem of this duplication (i.e. making sure 
bugfixes to FT2Font make it into matplotlib and mathtex) almost as a 
separate issue.  We know the solution to that: break out the freetype 
wrappers into its own project (which then both matplotlib and mathtex 
would rely on) -- but that's probably outside of the scope of this GSoC 
project.

Please try to use svn:externals if you can -- that will make pulling 
updates from mathtex easier.  I've never used it cross-repository like 
this, so there may be unforeseen issues.

It also just occurred to me that we might want to take another step in 
preparation for mathtex as an external dependency: make it optional.  
That is, if importing mathtex fails, be able to render regular text, and 
warn if trying to render math text.

Mike

Freddie Witherden wrote:
> Hi all,
>
> With the integration of mathtex into matplotlib nearing completion  
> (just bug fixes really) I think now is a good time to be considering  
> the best way to include mathtex into matplotlib.
>
> This has already been discussed on the mathtex mailing list, with  
> Michael proposing a few ways of doing this. However, I am not an  
> expert by any means when it comes to Python set-up/configuring. (As  
> anyone who has looked at setup.py in mathtex will have seen.)
>
> While including the source is not difficult (it can be done directly  
> or using svn:external) getting it built/configured is. Lets say that  
> mathtex was dumped into lib/, how would one go about configuring and  
> installing it from setup.py in matplotlib.
>
> Although I am sure that just executing a shell command would do it I  
> am sure there must be a 'better' option for this type of 'package  
> chaining'.
>
> Does anyone have any suggestions or recommendations?
>
> Regards, Freddie.
>
> --
> ___________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Including mathtex in matplotlib

[Michael Droettboom]

I think we need (at least as a transitional stopgap) a single "python 
setup.py install" to install both matplotlib and mathtex.  Once 
distributions catch up (which could take more than a year, depending on 
cycles), we can consider being more loosely coupled.

There are already examples of installing subpackages from matplotlib 
(pytz and dateutil) for example, and each of the extensions 
(_backend_agg etc.) have examples in setupext.py showing how to 
dynamically add extensions and packages to the list of things that 
matplotlib's setup.py will install and build.  Are there fundamental 
differences in how that works vs. how mathtex needs to work that is a 
stumbling block?  I must admit I haven't thought it all the way through, 
but I'm surprised that the existing examples there don't provide a 
template for how to deal with mathtex.  That said, I know that distutils 
can be rather, um, labyrinthine.

Cheers,
Mike

Freddie Witherden wrote:
> Hi,
>
> I was thinking about the problem of including mathtex in matplotlib earlier 
> and came up with an alternative means of 'solving' the problem.
>
> Instead of hacking setup.py to install mathtex on the behalf of matplotlib it 
> may be easier to leave it up to the user/packager to install mathtex.
>
> While simplifying the code (not as many changed are need to the setup files) 
> it 
> also eliminates the problems associated with one package installing another 
> package (matplotlib installing mathtex).
>
> This could be done either through ones distribution package manger, 
> standalone 
> (getting the mathtex source) or just by following the instructions in 
> lib/mathtex/INSTALL. (Checking out matplotlib also checks out the mathtex 
> source into lib/mathtex.)
>
> However, I am interested if this solution is acceptable to the matplotlib 
> developers.
>
> It may also be worth pointing out that mathtex is an optional dependency of 
> matplotlib and is not required for matplotlib to function.
>
> Regards, Freddie.
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] 0.99.x maintenance branch created

[Michael Droettboom]

A 0.99 branch has been created at:

  https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint

This is where the first 0.99.0.rc1 release candidate and binary releases 
will be made from this weekend.

All potentially disruptive or experimental changes should be made only 
to the trunk. 

*All bug fixes should be made to the branch, and then merged into the 
trunk.*  You will need to have svnmerge.py installed.  The workflow for 
this is as follows:

1. Check out the branch, if you haven't already:

  svn co 
https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint mpl99

2. Make/test bugfixes on your working copy of this branch

3. Commit your changes on this branch

4. 'cd' to your working copy of the trunk

5. Merge the changes from the branch into the trunk:

  svnmerge.py merge -S v0_99_maint

6. Resolve any conflicts, install, and test the merge.

7. Commit the merged changes to the trunk:

  svn commit -F svnmerge-commit-message.txt


Let me know if you have any questions.

Mike

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Request For Comment on the mathtex Branch

[Michael Droettboom]

I just did a clean install into a new virtualenv and I get the following 
when running mathtext_demo.py:

/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py:165:
 
UserWarning: matplotlib was compiled without mathtex support. Math will 
not be rendered.
  'Math will not be rendered.')

Is there an additional step to install mathtex?  I thought the goal was 
to make "python setup.py install" work out of the box.

Cheers,
Mike


Freddie Witherden wrote:
> Hi all,
>
> I have just finished going over the mathtex branch and it appears to  
> be totally feature complete. Furthermore, by using the newest version  
> of mathtex it also benefits from the recent rendering improvements.
>
> I am therefore interested to hear peoples comments on it/what can be  
> improved. Furthermore, would it be worthwhile back-porting some of the  
> rendering changes/enhancements I've made to mathtex to matplotlib?  
> (Which I am more than happy to do.)
>
> Regards, Freddie.
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Request For Comment on the mathtex Branch

[Michael Droettboom]

Freddie Witherden wrote:
> Hi,
>
> On 3 Aug 2009, at 17:39, Michael Droettboom wrote:
>   
>> Is there an additional step to install mathtex?  I thought the goal  
>> was to make "python setup.py install" work out of the box.
>> 
>
> This was the goal and I got quite close to achieving it. This latter  
> parts of this thread deal with the specific issues (relating to the  
> directory structure chosen) 
> http://sourceforge.net/mailarchive/forum.php?thread_name=A97F3AC6-1434-4E6D-AF39-9DBD4653BCB4%40witherden.org&forum_name=matplotlib-devel
>
> So I was advised by John to just assume mathtex is installed.  
> Thankfully this is not hard to do -- and is covered in the INSTALL  
> file. It is basically a case of changing to lib/mathtext and running  
> python setup.py build && python setup.py install.
>   
Sorry, I let that message slide through.  I know John may not be, but 
I'm really concerned about the build being anything more than "python 
setup.py install" -- it's going to be hard for packagers and hard for 
end users.

This problem is actually rather straightforward to solve using the 
"package_dir" mapping in distutils.  See here:

http://docs.python.org/distutils/setupscript.html#listing-whole-packages

By adding {'mathtex': 'lib/mathtex/mathtex'} to package_dir, it all 
seems to work as desired.

I've committed this change on the branch so you can see what I mean.

However, after doing that I run into another error importing mathtex 
from mathtext_demo.py:

> >>> from mathtex.mathtex_main import Mathtex
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py", 
> line 2, in 
> from mathtex.parser import MathtexParser
>   File 
> "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/parser.py", line 
> 7, in 
> from mathtex.boxmodel import *
>   File 
> "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/boxmodel.py", 
> line 4, in 
> from mathtex.fonts import *
>   File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/fonts.py", 
> line 5, in 
> from mathtex.ft2font import FT2Font, KERNING_DEFAULT
> ImportError: No module named ft2font
It looks like it's still looking for ft2font inside of mathtex, which, 
of course, isn't there in the context of building in inside of 
matplotlib.  I thought you said that mathtex would use the ft2font from 
matplotlib if it were available -- maybe I misunderstood what you meant.

These sorts of installation issues are hard to test given that installs 
don't clean up after themselves.  Personally, I use virtualenv to create 
"clean" python environments, then install matplotlib in it, and then try 
running examples in that environment.  It's real fast to just blitz the 
environment and create a new one each time for this kind of testing.

I was able to work around this (by installing mathtex directly), but I 
ran into the following because I have "mathtext.fontset" set up 
"stixsans" in my matplotlibrc:

 > python mathtext_demo.py
Traceback (most recent call last):
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
 
line 352, in expose_event
self._render_figure(self._pixmap, w, h)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py",
 
line 75, in _render_figure
FigureCanvasAgg.draw(self)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
 
line 327, in draw
self.figure.draw(self.renderer)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 
46, in draw_wrapper
draw(artist, renderer, *kl)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
774, in draw
for a in self.axes: a.draw(renderer)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 
46, in draw_wrapper
draw(artist, renderer, *kl)
  File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", 
line 1721, in draw
a.draw(renderer)
  File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 
46, in draw_wrapper
draw(artist, renderer, *kl)
  File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axis.py", 
line 757, in draw
self.label.draw(renderer)
  File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/text.py", 
line 515, in draw
bbox, info = self._get_layout(renderer)
  File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/text.py", 
line 279, in _get_layout
clean_line, self._fontproper

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

I looked into this a while ago wrt 2D quad meshes, and it didn't look 
like there was anything built-in to do something like that.  All the 
gradients are 1-dimensional (i.e. between two colors, or a 1-dimensional 
lookup table of colors).  There's nothing to do a 4-way blend like 
this.  So it would have to be from scratch, at least for the colored 
part -- we can still use Agg to render the quad shapes themselves.

Mike

John Hunter wrote:
> On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner wrote:
>   
>> Hi,
>>   I'd like to propose adding a SHADES keyword to the mplot3D routines where 
>> you can supply your own
>> 
>
> The other thing that would be really nice is to have smooth
> interpolation along each face.  Michael, do you have a sense how hard
> it would be in agg (and other backends) to do a linear gradient
> interpolation over a quadrilateral with one RGBA at each vertex?
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

John Hunter wrote:
> On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom wrote:
>   
>> I looked into this a while ago wrt 2D quad meshes, and it didn't look like
>> there was anything built-in to do something like that.  All the gradients
>> are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
>> of colors).  There's nothing to do a 4-way blend like this.  So it would
>> have to be from scratch, at least for the colored part -- we can still use
>> Agg to render the quad shapes themselves.
>> 
>
> What about for other backends (PS, PDF, SVG)?  If there was support in
> the gradient spec for these, it might be worth it to try and write a
> custom gradient function in agg, as suggested by Maxim at the end of
> this tutorial:
>
> http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html
>   
Even with this, the gradient infrastructure in Agg assumes a 
one-dimensional map, and here we need to at least interpolate between 
the three points of a triangle.  It's not impossible, as it's easy 
enough to make a custom shader, it's just that the gradient code won't 
help us.

A possible workaround is suggested by this paper:

   http://www.svgopen.org/2005/papers/Converting3DFaceToSVG/index.html

That is, rather than doing a single Gourad triangle interpolation, just 
overlap three linear gradient patches with alpha blending.  At the very 
least it presents a way to support this in SVG which doesn't currently 
have Gourad interpolation.

PDF and PS support Gourad triangles directly, though supporting it looks 
-- um -- "fun".

Cheers,
Mike


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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.  
Isn't this a no-go for us because it's GPL'd?

Cheers,
Mike

John Hunter wrote:
> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom wrote:
>
>   
>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>> map, and here we need to at least interpolate between the three points of a
>> triangle.  It's not impossible, as it's easy enough to make a custom shader,
>> it's just that the gradient code won't help us.
>> 
>
> I checked in with the antigrain mailing list, as was pointed to
> examples/gouraud.cpp.  This looks like what we want, no?
>
> wget http://www.antigrain.com/agg-2.5.tar.gz
> tar xvfz agg-2.5.tar.gz
> cd agg-2.5
> make
> cd examples/X11/
> make gouraud
> ./gouraud
>   
>
> 
>

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

Nevermind -- this is in Agg 2.4 as well.  Don't know why I missed it 
yesterday.  I'll have a look into this to see how well we can integrate it.

Cheers,
Mike

Michael Droettboom wrote:
> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.  
> Isn't this a no-go for us because it's GPL'd?
>
> Cheers,
> Mike
>
> John Hunter wrote:
>   
>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom wrote:
>>
>>   
>> 
>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>> map, and here we need to at least interpolate between the three points of a
>>> triangle.  It's not impossible, as it's easy enough to make a custom shader,
>>> it's just that the gradient code won't help us.
>>> 
>>>   
>> I checked in with the antigrain mailing list, as was pointed to
>> examples/gouraud.cpp.  This looks like what we want, no?
>>
>> wget http://www.antigrain.com/agg-2.5.tar.gz
>> tar xvfz agg-2.5.tar.gz
>> cd agg-2.5
>> make
>> cd examples/X11/
>> make gouraud
>> ./gouraud
>>   
>>
>> 
>>
>> 
>
>   

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Quadmesh masked values broken on 0.99

[Michael Droettboom]

I've tracked it down to this revision 7395

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395

was was in response to bug *2832575*

http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720

I think this is reaching my limit of understanding of the color mapping 
code, so I'm hoping someone else has a solution that will fix one bug 
without creating another ;)


Cheers,
Mike

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

<>--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

I have experimental support for Gouraud-shaded pcolormeshes with the Agg 
backend only in SVN trunk.  The backend interface will likely change to 
better support PDF, where doing multiple triangles at a time is much 
more efficient.  This is just the easiest and far from optimal way to do it.

I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are 
really sufficient for drawing interpolated quad meshes, because of the 
effect described here:

http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false

Running quadmesh_demo.py, you can see some sharp edges between triangles 
in the same quad, but it's not too bad in all places.  If anyone has any 
ideas about how to ameliorate that effect, feel free to have a crack at 
it.  I just wanted to get a proof-of-concept starting point in before 
heading on vacation for a few days.

Cheers,
Mike

Reinier Heeres wrote:
> Hi,
>
> This looks great! I'd be happy to try and work on this for mplot3d as well.
>
> Ryan: as for your patch, I'll look at it over the weekend or next week
> and see if I can apply it to trunk.
>
> Regards,
> Reinier
>
> On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom wrote:
>   
>> Nevermind -- this is in Agg 2.4 as well.  Don't know why I missed it
>> yesterday.  I'll have a look into this to see how well we can integrate it.
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>> 
>>> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
>>> Isn't this a no-go for us because it's GPL'd?
>>>
>>> Cheers,
>>> Mike
>>>
>>> John Hunter wrote:
>>>
>>>   
>>>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom wrote:
>>>>
>>>>
>>>>
>>>> 
>>>>> Even with this, the gradient infrastructure in Agg assumes a 
>>>>> one-dimensional
>>>>> map, and here we need to at least interpolate between the three points of 
>>>>> a
>>>>> triangle.  It's not impossible, as it's easy enough to make a custom 
>>>>> shader,
>>>>> it's just that the gradient code won't help us.
>>>>>
>>>>>
>>>>>   
>>>> I checked in with the antigrain mailing list, as was pointed to
>>>> examples/gouraud.cpp.  This looks like what we want, no?
>>>>
>>>> wget http://www.antigrain.com/agg-2.5.tar.gz
>>>> tar xvfz agg-2.5.tar.gz
>>>> cd agg-2.5
>>>> make
>>>> cd examples/X11/
>>>> make gouraud
>>>> ./gouraud
>>>>
>>>>
>>>> 
>>>>
>>>>
>>>> 
>>>   
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>> 
>
>   

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

John Hunter wrote:
>
> BTW, it looks like the edges of the polys are aliased in the "masked"
> side of the figure.  Have you noticed this?
>   
Yeah -- the right hand side is still using the old code path, which is 
aliased by default.

Cheers,
Mike

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

I think I almost have a solution.  Just running backend_driver.py now.

Mike

John Hunter wrote:
> On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner wrote:
>   
>> Mike, do you see this on your side?
>>
>> r...@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
>> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
>> 
>
> I'm seeing a core dump on this one (clean build and install of HEAD).
>
> johnh@:svn> cd ~/mpl/examples/mplot3d/
> johnh@:mplot3d> python surface3d_demo.py
> Segmentation Fault (core dumped)
> johnh@:mplot3d> uname -a
> SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc
>   

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

[Michael Droettboom]

Should be fixed in SVN now.

Mike

John Hunter wrote:
> On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner wrote:
>   
>> Mike, do you see this on your side?
>>
>> r...@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
>> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
>> 
>
> I'm seeing a core dump on this one (clean build and install of HEAD).
>
> johnh@:svn> cd ~/mpl/examples/mplot3d/
> johnh@:mplot3d> python surface3d_demo.py
> Segmentation Fault (core dumped)
> johnh@:mplot3d> uname -a
> SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc
>   

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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] open bugs: too many, too old

[Michael Droettboom]

This is a great idea, Eric.  I don't think this is a SF bug, as I recall 
having seen this many since I "got here".  I've usually just stopped 
looking before the 0.91 release or so.  But you're right -- let's clean 
this stuff out.

I've cleaned out a few already, but are there any takers for me to 
assign Mac-specific and Windows-specific bugs?  I'm happy to take any 
Linux-specific ones.

Cheers,
Mike

Eric Firing wrote:
> After ignoring it for a long time, I took a look at the Sourceforge bug 
> tracker, and closed a couple bugs.  Our bug list is a bit embarrassing; 
> there are 52 open ones going back to 2005.  Is any of this an artifact 
> of all the reworking going on at SF?  Did some closed bugs get reopened 
> by accident?  In any case, it would be nice to get the list of open bugs 
> down to a much smaller number, and ensure that the oldest is not very 
> old.  I suspect many of the old ones have long since either been fixed 
> or rendered irrelevant by other changes.
>
> For all reading this list: even if you don't have mpl svn commit access, 
> if you can review a bug and propose a fix, or conclude it is obsolete, 
> or provide some other way of moving us towards getting it closed, your 
> effort would be much appreciated.
>
> Thank you.
>
> Eric
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transAxis attribute of the Axis object

[Michael Droettboom]

It is now stored in the parent Axes object.

  axis.axes.transAxes

Same is true of transData.

Thanks for pointing this out.  I will update the docs.

Cheers,
Mike

jason-s...@creativetrax.com wrote:
> In the documentation for the Axis object, I see that there is supposed 
> to be a transAxis attribute.  However, when grepping for it in the 
> source, the only place it appears is in the documentation:
>
> gr...@tiny:~/sage/local/lib/python2.6/site-packages/matplotlib$ grep -r 
> transAxis *
> axis.py:* :attr:`transAxis` - transform axis coords to display coords
> Binary file axis.pyc matches
>
>
> Has this attribute been removed?  This is with version 0.99.0.
>
> Thanks,
>
> Jason
>
>
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] not clipping objects in a plot

[Michael Droettboom]

I think this is just a vanilla bug that set_clip_on is being ignored for 
collections.  That patch is rather straightforward.

Other developers: do you agree this should be fixed, or is there a good 
reason for current behavior that I'm missing?

Cheers,
Mike

Index: lib/matplotlib/collections.py
===
--- lib/matplotlib/collections.py   (revision 7486)
+++ lib/matplotlib/collections.py   (working copy)
@@ -207,8 +207,7 @@
 transform, transOffset, offsets, paths = self._prepare_points()

 gc = renderer.new_gc()
-gc.set_clip_rectangle(self.get_clip_box())
-gc.set_clip_path(self.get_clip_path())
+self._set_gc_clip(gc)

 renderer.draw_path_collection(
 gc, transform.frozen(), paths, self.get_transforms(),
@@ -1211,8 +1210,7 @@
 transOffset = transOffset.get_affine()

 gc = renderer.new_gc()
-gc.set_clip_rectangle(self.get_clip_box())
-gc.set_clip_path(self.get_clip_path())
+self._set_gc_clip(gc)

 if self._shading == 'gouraud':
 triangles, colors = self.convert_mesh_to_triangles(


jason-s...@creativetrax.com wrote:
> On this thread:
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg05383.html
>
> clip_on was a suggested way of getting around the clipping that happens 
> at the edge of a frame.  In the Sage project, we are always setting the 
> limits on the axes via set_xlim and set_ylim.  Is there any way to get 
> the lines and circles that pass across the edge of the usual clip 
> boundary to still be drawn, even if we have set the xlim and ylim of the 
> axis?
>
> Basically (using an example from the gallery), is there a way to get the 
> scatter plot circles below not clipped, while still having the y-axis 
> only go from -2 to 2?  If not, is there a way to easily calculate the 
> protrusion of the various objects, like the circles below, so we know 
> how much to adjust the axes to just include the circles?
>
> import matplotlib.pyplot as plt
> import numpy as np
> fig = plt.figure()
> x = np.linspace(0r,2*np.pi,100r)
> y = 2*np.sin(x)
> ax = fig.add_subplot(1,1,1)
> q=ax.scatter(x,y)
> ax.set_ylim([-2,2])
> q.set_clip_on(False)
> ax.set_clip_on(False)
> ax.spines['left'].set_position(('outward',10))
> ax.spines['bottom'].set_position(('outward',10))
> ax.spines['top'].set_color('none')
> ax.spines['right'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png')
>
> Thanks,
>
> Jason
>
>
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Merge tracking of v0_99_maint broken?

[Michael Droettboom]

Just catching up with mail now.  Is this still a problem for either Ryan 
or Jouni?  It seems to work for me as well.  All I can suggest is making 
sure the working copy of the trunk is fully updated (but I'm sure you've 
thought of that already).

 > svnmerge avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) 
required.
The merge sources available are:
  /branches/v0_99_maint
  /branches/mathtex
  /branches/v0_98_5_maint


John Hunter wrote:
> On Sat, Aug 22, 2009 at 3:24 AM, Ryan May wrote:
>
>   
>> Same behavior here. I had been having trouble doing any merges, but never
>> had tracked it down.  I guess this is related.
>> 
>
> The following just worked for me
>
>   svnmerge.py merge -Sv0_99_maint
>
> managed to merge almost 15 commits from the branch to the trunk w/ no
> conflicts despite all the docstring changes, etc.  Nice!
>
> JDH
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> 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


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel