matplotlib-devel Mailing List for matplotlib (Page 3)

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:
> 
>> 2009年2月16日 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

Pauli Virtanen wrote:
> 2009年2月16日 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

On Sun, Feb 15, 2009 at 08:04, Gael Varoquaux
<gae...@no...> 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.
At one point, some of us had a plan to keep all of these "scientific"
extensions collected here:
 http://sphinx.googlecode.com/svn/contrib/trunk/numpyext/
SVN-using projects could use svn:externals to include these in their
projects without diverging the code. I really don't know why this plan
changed. Pauli?
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco

2009年2月16日 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.
-- 
Pauli Virtanen

On Mon, Feb 16, 2009 at 01:26:40PM -0500, Michael Droettboom wrote:
> > 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.
Yeah, I am +1 for that too. 
Thank you for exposing the plot_directive in the MPL importable tree,
Michael. It is going to take a little while for a new MPL release to
trickle down to enough installed computers for people to be abe to throw
away their local copy, but this is clearly the good solution.
Gaël

Pauli Virtanen wrote:
> 2009年2月16日 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

2009年2月16日 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...)
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...
What do you think?
-- 
Pauli Virtanen

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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

a writes:
> Michael Droettboom <mdroe@...> 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(100000)) ). 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

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

I just committed the support of the legend title into the trunk.
See the legend_demo3.py.
Regards,
-JJ
On Fri, Feb 13, 2009 at 3:10 PM, Jae-Joon Lee <lee...@gm...> wrote:
> John and Sandro,
>
> I just had a quick look at the patch. The patch is for older version
> of the mpl, and I couldn't test it yet. Anyhow, it should be straight
> forward to port it to the new legend class. I'll work on it.
>
> Meanwhile, below is a little code one may use to put the legend title
> w/o modifying the mpl.
>
> -JJ
>
> plot([1,2,3])
> plot([2,1,3])
> legend(["test", "test2"])
>
> fig = gcf()
> ax = gca()
>
> from matplotlib.offsetbox import TextArea, VPacker
>
> mylegend=ax.get_legend()
> legendtitle=TextArea( "Legend Title", textprops=dict(size=20))
> mylegend._legend_box = VPacker(pad=5,
> sep=0,
> children=[legendtitle, mylegend._legend_box],
> align="center")
> mylegend._legend_box.set_figure(fig)
>
> draw()
>
>
>
>
> On Fri, Feb 13, 2009 at 7:20 AM, John Hunter <jd...@gm...> wrote:
>> On Fri, Feb 13, 2009 at 3:31 AM, Sandro Tosi <mo...@de...> wrote:
>>> Hello,
>>> a friend point me to [1] asking if there's a way to add a title to
>>> legend without applying this patch. Well, my answer was "not that I
>>> know of" then I start wondering if there's a reason this patch was not
>>> applied and there's a plan to do it anytime soon.
>>>
>>> [1] http://www.mail-archive.com/matplotlib-users%40lists.sourceforge.net/msg05678.html
>>
>> Jae Joon -- will you review this and apply it if it looks like a good
>> addition to you
>>
>> Thanks,
>> JDH
>>
>

John and Sandro,
I just had a quick look at the patch. The patch is for older version
of the mpl, and I couldn't test it yet. Anyhow, it should be straight
forward to port it to the new legend class. I'll work on it.
Meanwhile, below is a little code one may use to put the legend title
w/o modifying the mpl.
-JJ
plot([1,2,3])
plot([2,1,3])
legend(["test", "test2"])
fig = gcf()
ax = gca()
from matplotlib.offsetbox import TextArea, VPacker
mylegend=ax.get_legend()
legendtitle=TextArea( "Legend Title", textprops=dict(size=20))
mylegend._legend_box = VPacker(pad=5,
 sep=0,
 children=[legendtitle, mylegend._legend_box],
 align="center")
mylegend._legend_box.set_figure(fig)
draw()
On Fri, Feb 13, 2009 at 7:20 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Feb 13, 2009 at 3:31 AM, Sandro Tosi <mo...@de...> wrote:
>> Hello,
>> a friend point me to [1] asking if there's a way to add a title to
>> legend without applying this patch. Well, my answer was "not that I
>> know of" then I start wondering if there's a reason this patch was not
>> applied and there's a plan to do it anytime soon.
>>
>> [1] http://www.mail-archive.com/matplotlib-users%40lists.sourceforge.net/msg05678.html
>
> Jae Joon -- will you review this and apply it if it looks like a good
> addition to you
>
> Thanks,
> JDH
>

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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.

On Fri, Feb 13, 2009 at 3:31 AM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> a friend point me to [1] asking if there's a way to add a title to
> legend without applying this patch. Well, my answer was "not that I
> know of" then I start wondering if there's a reason this patch was not
> applied and there's a plan to do it anytime soon.
>
> [1] http://www.mail-archive.com/matplotlib-users%40lists.sourceforge.net/msg05678.html
Jae Joon -- will you review this and apply it if it looks like a good
addition to you
Thanks,
JDH

Hello,
a friend point me to [1] asking if there's a way to add a title to
legend without applying this patch. Well, my answer was "not that I
know of" then I start wondering if there's a reason this patch was not
applied and there's a plan to do it anytime soon.
[1] http://www.mail-archive.com/matplotlib-users%40lists.sourceforge.net/msg05678.html
Thanks for considering,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Adam: sorry, I didn't mean to just send that straight to you. gmail
decided its default would be to send to you and not the mailing list.
Everyone else: The message that was supposed to go to the list:
I was looking at setupext.py and I am thinking that we could just
change the add_tk_flags function.
My idea is to remove the elif sys.platform == "darwin" section and
always go to the else.
In the except line after trying query_tcltk() we can add a check for
darwin and have it search the normal framework locations, or even put
an if sys.platform == "darwin" that goes for the frameworks in
hardcoded_tclconfig().
In the else line after that we could do a check to see if the returned
tcl/tk libs and version match any normal system framework paths (in
$HOME/Library/Frameworks, /System/Library and
/System/Library/Frameworks) or even just look at the library name or
some
other method to determine if it is a framework and add the "-framework
Tcl -framework Tk" flags to module.extra_link_args and
module.extra_compile_args if they are.
Also, I was looking and I don't actually see any point around here
where it is explicitly checked if the results of query_tcltk()
correspond to a directory that is in basedir["darwin"].
As an aside, we could add to hardcoded_tclconfig() to surf the
directories returned from add_base_flags / basedir["darwin"] instead
of the directories it has. It would probably be best on all systems
to look in the basedir[os.system] directories for Tk as a last result
rather
than /usr/local
Basically, I am just sharing some of the ideas I have been playing with.
Jayson
On Thu, Feb 12, 2009 at 12:45 PM, Jayson Barr <jb...@nm...> wrote:
> I was looking at setupext.py and I am thinking that we could just
> change the add_tk_flags function.
>
> My idea is to remove the elif sys.platform == "darwin" section and
> always go to the else.
>
> In the except line after trying query_tcltk() we can add a check for
> darwin and have it search the normal framework locations, or even put
> an if sys.platform == "darwin" that goes for the frameworks in
> hardcoded_tclconfig().
>
> In the else line after that we could do a check to see if the returned
> tcl/tk libs and version match any normal system framework paths (in
> $HOME/Library/Frameworks, /System/Library and
> /System/Library/Frameworks) or even just look at the library or some
> other method to determine if it is a framework and add the "-framework
> Tcl -framework Tk" flags to module.extra_link_args and
> module.extra_compile_args if they are.
>
> Also, I was looking and I don't actually see any point around here
> where it is explicitly checked if the results of query_tcltk()
> corrsepond to a directory that is in basedir["darwin"].
>
> As an aside, we could add to hardcoded_tclconfig() to surf the
> directories returned from add_base_flags / basedir["darwin"] instead
> of the directories it has. It would probably be best on all systems
> to look in the basedir[os.system] directories as a last result rather
> than /usr/local
>
> Basically, I am just sharing some of the ideas I have been playing with.
>
> Jayson
>
> On Tue, Feb 10, 2009 at 9:54 AM, Adam Mercer <ram...@gm...> wrote:
>> On Mon, Feb 9, 2009 at 17:08, Jayson Barr <jb...@nm...> wrote:
>>
>>> I agree with JDH.
>>
>> Likewise.
>>
>>> Unfortunately, work has been exceptionally hectic so I haven't begun
>>> the patch (if you don't count the hack job I did to install it for
>>> myself).
>>
>> Same here, I'm really busy with work and don't have much time to look
>> into this at the moment.
>>
>>> Hi Adam,
>>> As noted above, I haven't started a patch yet but I would be up for
>>> working with you on one. It sounds like we can get this tested pretty
>>> well.
>>
>> Its on my todo list, so when I get chance I'm going to investigate a
>> better solution. I'll keep you posted.
>>
>> Cheers
>>
>> Adam
>>
>

Jouni K. Seppänen <jk...@ik...> wrote:
>> Those changes are in the attached patch. It's certainly not a
>> definitive workaround, but it's better than nothing ;-)
>
> Committed; thanks!
My pleasure!

Nicolas Grilly <nic...@ga...>
writes:
> Those changes are in the attached patch. It's certainly not a
> definitive workaround, but it's better than nothing ;-)
Committed; thanks!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 02/09/09 11:59, Gael Varoquaux wrote:
> On Sun, Feb 08, 2009 at 04:08:31PM -0800, Brian Granger wrote:
>> * In the current matplotlib backend wx.Yield() is called in a way that
>> is not safe as far as protecting against recursive calls to Yield. I
>> think it should be called in this way:
> 
>> app = wx.GetApp()
>> if app is not None:
>> app.Yield(True)
> 
> The problem I see with this approach is that arbitrary wx programs will
> always be doing this. The matplotlib guys can fix matplotib not to do
> this. I can fix Mayavi not to do this, but there are many more wx
> programs. And anyhow, most of the time, Yield should not be called, as it
> is a hack. Unfortunately, you often end up having to call it. :(
Just nit picking: You'd really have to modify traits and pyface for 
this. Mayavi doesn't start the mainloop.
cheers,
prabhu

On 02/09/09 05:38, Brian Granger wrote:
> IPython and matplotlib devs,
> 
> Over the weekend I have been playing around to see if it is possible
> to do interactive GUI work with wx from IPython *without using
> threads*. The idea here is to use PyOS_InputHook. Currently, recent
> versions of PyQt4 and PyGTK do this and if we can get wx working, we
> can probably get rid of IPython's subtle threaded shells that
> currently allow interactive GUIs to work.
> 
> I am attaching a Cython module that mostly works. Here is a simple
> example that works in IPython (without the -wthread option!)
[...]
> I don't have any more time to work on this right now, but I at least
> wanted to share my findings with both IPython and matplotlib devs. It
> would be great if someone familiar with wx could try to figure out the
> remaining issues. If there are no takers here, I might eventually see
> if wxpython itself is interested in this code (that is probably where
> it really belongs anyway).
This is cool! It works with mayavi, which is a pretty demanding test. 
I did run into problems with pyximport messing up on some imports but 
manually importing the inputhook.so fixed those. The interactive 
response is not snappy but it definitely works without a problem.
One problem I can see with this is that while it does eliminate the 
threading, there are still issues with multiple toolkits. It would be 
neat if there were a system where you could mix toolkits too -- it looks 
like it should be possible to support this though.
cheers,
prabhu

Hello,
I'd like your confirmation on what I see from
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644
(the download page ofr 0.98.5 release). on that page I see
1. win binary install
2. .egg file
3. source code
4. mpkg file
Now, correlating with operating systems, we got:
1. windows
2. windows only? <-- that's the doubt I have
3. OS indipendent
4. Mac OS X?
In particular I'm interested in egg files: is "easy_install" only
supported for windows? is there any plan/will to extend it to
linux/other OSes?
I'm just asking because I'd like to give right advices in the book :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Jouni K. Seppänen <jk...@ik...> wrote:
> You're right. I committed your patch, but there is another bug that
> makes this a little difficult to test: the font cache doesn't record
> whether it was build with pdf.use14corefonts enabled or not, and the
> font name "Helvetica" happens to match "Helvetica Narrow", whose metrics
> are included with matplotlib, and using that afm file without including
> the font itself breaks the output. I'm too busy with other things to fix
> this now, but patches are welcome. As a workaround, deleting
> ~/.matplotlib/fontList.cache helps if anyone wants to alternate between
> enabling and disabling use14corefonts.
Thanks for committing my patch! I've reproduced the font cache bug on
my machine too. Thanks for your detailed explanation. I've updated the
test case to acknowledge this issue and to set use14corefonts to True
*before* importing pylab (because importimg pylab seems to refresh the
font cache).
Those changes are in the attached patch. It's certainly not a
definitive workaround, but it's better than nothing ;-)
> Unfortunately, this functionality is deprecated in the PDF standard as
> of PDF 1.5, and many publishers require embedding all fonts in PDF
> files. Apparently not all substitutes for the standard fonts are similar
> enough. (The real fonts need to be licensed, so many Linux distributions
> ship with free look-alike substitutes, and who knows what fonts are
> installed on some publisher's systems.)
I'm aware of that deprecation. I agree we'll need to drop that feature
in a not so distant future...
--
Nicolas Grilly