On Tue, Aug 25, 2009 at 9:04 PM, Eric Bruning wrote:
> Hi Ariel,
>
> Thanks for the suggestion. Combining John's new makefile with the
> changes to the Python.framework Makefile yielded:
> distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET
> mismatch: now "10.4" but "10.5" during co
Hi Ariel,
Thanks for the suggestion. Combining John's new makefile with the
changes to the Python.framework Makefile yielded:
distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET
mismatch: now "10.4" but "10.5" during configure.
As a general philosophy, I'm a bit hesitant to go abou
On Tue, Aug 25, 2009 at 4:35 PM, Brian Granger wrote:
> Hello all,
>
> While at SciPy this year, the IPython devs began discussing dropping Python
> 2.4 support. Or rational is this:
>
> * New generator features in 2.5 would dramatically simplify our testing of
> our Twisted using components.
>
>
Michael Hearne wrote:
> I just built matplotlib and basemap from source on a RHEL system, with
> EPD as my base Python installation.
>
> The build procedure for matplotlib was fairly straightforward, as was
> basemap (once I read Jeff's documentation on installing).
>
> However, once I try to i
I just built matplotlib and basemap from source on a RHEL system, with
EPD as my base Python installation.
The build procedure for matplotlib was fairly straightforward, as was
basemap (once I read Jeff's documentation on installing).
However, once I try to import basemap, I get an error abou
Hello all,
While at SciPy this year, the IPython devs began discussing dropping Python
2.4 support. Or rational is this:
* New generator features in 2.5 would dramatically simplify our testing of
our Twisted using components.
* Being able to use absolute imports would simplify the packaging of
Hmm,
That might be nothing to do with Sphinx's being very recent. Since that
thread from sphinx-dev list is from Oct 2008 and the guy reporting the
similar issue seemingly using an even older Sphinx version (4.3)
I don't exactly know what would be the advantage of making docstrings numpy
standard
The error is caused by recent versions of Sphinx being more picky about
headers in docstrings. I had to update my version of Sphinx in order to
reproduce your error.
Your fix is adding support for Numpy's custom docstring format? I'm not
sure we want to go down that road just yet. Easier to
OK,
Here comes a self fix:
http://svn.scipy.org/svn/numpy/trunk/doc/sphinxext/docscrape.py
http://svn.scipy.org/svn/numpy/trunk/doc/sphinxext/docscrape_sphinx.py
http://svn.scipy.org/svn/numpy/trunk/doc/sphinxext/numpydoc.py
added the above files under /doc/sphinxext and updated conf.py.
Then w
mdb...@users.sourceforge.net wrote:
> Revision: 7567
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7567&view=rev
> Author: mdboom
> Date: 2009-08-25 15:31:10 + (Tue, 25 Aug 2009)
>
> Log Message:
> ---
> Support Line2D objects without associated Axes objects.
Hello,
The trunk is giving the following error while trying to build the
documentation via "python make.py all"
reading sources... [ 4%]
api/mlab_api
reST markup error:
/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/mlab.py:docstring
of matplotlib.mlab.cohere_pairs:6: (SEVERE/4) Une
Ah -- for some reason the benefit is immeasurable until about 1M
points. I was using fewer points because you can't even get a baseline
measurement with that many -- it exceeds the path length limit in Agg.
I see now why it's superior to the clipping I wrote -- it does a binary
search to find
12 matches
Mail list logo
