Website needs love

Development matplotlib-devel
21

I went ahead with the merge conflict procedure, and everything appear to

be ok. I had also noticed a few additional mistakes in the INSTALL file

currently in v1.0.x that I fixed as well. I will double-check the

commit/merge before pushing it up.

I also noticed that the INSTALL doc on v1.0.x provided an equivalent

command of apt-get build-dep for Fedora/RedHat users. I believe this

information should also be included in the install_faq.rst document

(because it only has the debian version). I will make that a separate

commit.

Ben Root

Ben, a quick look at installing_faq.rst shows some anachronisms:

references to installing obsolete versions. This is another worm

barrel. Those anachronisms are not the only problems with the file–or

with installation in general.

Eric

I’ll double-check for that. Note that I am merely moving my changes over to INSTALL, so whatever INSTALL has should be the final version. Below is the current diff between them.

On a separate note, I think there might be some unspecified requirements for building the documentation. On my newly set up Ubuntu machine, the build gets to the thumbnails stage and recognizes that I have no thumbnails, and then the process goes to sleep. Maybe we have an error check missing somewhere?

Ben Root

ben@…965…:~/Programs/matplotlib$ diff INSTALL doc/users/installing.rst
0a1,2

… _installing:

23c25
< Manually installing pre-built packages

···

On Sun, May 22, 2011 at 4:11 PM, Eric Firing <efiring@…552…229…> wrote:

On 05/22/2011 10:07 AM, Benjamin Root wrote:

OK, so you want to do it the hard way?

81c83
< :ref:install_osx_binaries.

ref:install_osx_binaries.
88,112d89
< Installing on Windows
< ---------------------
<
< If you don’t already have python installed, you may want to consider

< using the enthought edition of python, which has scipy, numpy, and
< wxpython, plus a lot of other goodies, preinstalled - Enthought < Python <[http://www.enthought.com/python](http://www.enthought.com/python)>_. With the enthought

< edition of python + matplotlib installer, the following backends
< should work out of the box: agg, wx, wxagg, tkagg, ps, pdf and svg.
<
< For standard python installations, you will also need to install numpy

< in addition to the matplotlib installer. On some systems you will
< also need to download msvcp71.dll library, which you can download from
< http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71 or other

< sites. You will need to unzip the archive and drag the dll into
< :file:c:\windows\system32.
<
< All of the GUI backends run on windows, but TkAgg is probably the
< best for interactive use from the standard python shell or ipython.

< The windows installer (:file:*.exe) on the download page contains all the
< code you need to get up and running. However, there are many
< examples that are not included in the windows installer. If you

< want to try the many demos that come in the matplotlib src
< distribution, download the zip file and look in the examples subdir.
<
142,147d118
< If you have installed prerequisites to nonstandard places and need to

< inform matplotlib where they are, edit setupext.py and add the base
< dirs to the basedir dictionary entry for your sys.platform.
< e.g., if the header to some required library is in
< /some/path/include/someheader.h, put /some/path in the

< basedir list for your platform.
163,178d133
< … note::
<
< If you are on debian/ubuntu, you can get all the dependencies
< required to build matplotlib with::
<
< sudo apt-get build-dep python-matplotlib

<
< This does not build matplotlib, but it does get the install the
< build dependencies, which will make building from svn easy.
<
< If you are on Fedora/RedHat, you can get all the dependencies

< required to build matplotlib by first installing yum-builddep
< and then running::
<
< su -c “yum-builddep python-matplotlib”
<
186c141
< libpng 1.2 (or later)

libpng 1.1 (or later)
216a172,175
:term:wxpython 2.6 or later
The python wrappers for the wx widgets library for use with the
WXAgg backend

219c178
< WX or WXAgg backend

WX backend

242a202,203

246c207
< ===============

==================

22

Right. It looks like INSTALL is a slightly fixed-up version of the now-deleted install.rst. I was referring to install_faq.rst. Maybe that (or large parts of it) should go away, and be replaced by a reference to INSTALL?

Eric

···

On 05/22/2011 11:33 AM, Benjamin Root wrote:

On Sun, May 22, 2011 at 4:11 PM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> wrote:

    On 05/22/2011 10:07 AM, Benjamin Root wrote:

     > I went ahead with the merge conflict procedure, and everything
    appear to
     > be ok. I had also noticed a few additional mistakes in the
    INSTALL file
     > currently in v1.0.x that I fixed as well. I will double-check the
     > commit/merge before pushing it up.
     >
     > I also noticed that the INSTALL doc on v1.0.x provided an equivalent
     > command of `apt-get build-dep` for Fedora/RedHat users. I
    believe this
     > information should also be included in the install_faq.rst document
     > (because it only has the debian version). I will make that a
    separate
     > commit.
     >
     > Ben Root

    Ben, a quick look at installing_faq.rst shows some anachronisms:
    references to installing obsolete versions. This is another worm
    barrel. Those anachronisms are not the only problems with the file--or
    with installation in general.

    Eric

I'll double-check for that. Note that I am merely moving my changes
over to INSTALL, so whatever INSTALL has should be the final version.
Below is the current diff between them.

23

Generating the thumbnails has no additional requirements (it uses
matplotlib’s image module to scale the images). However, it may be a
problem with multiprocessing – the thumbnails are generated in
parallel on multi-core machines. I haven’t had problems myself, but it
seems multiprocessing doesn’t always work in certain environments.

Can you do me a favor? Can you edit gen_gallery.py and replace the
line beginning with “pool.map” to just “map” and let me know if that
resolves this issue? If it does, perhaps we should not use
multiprocessing here.

Mike

··· 
-- Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
24

Given this seems to be one of the longer stages of the build process,
I'd appreciate if if we identified and fixed the underlying problem and
not simply sweep it under the rug.

- Ben

···

On Mon, 23 May 2011 09:35:57 -0400, Michael Droettboom <mdroe@...31...> wrote:

Generating the thumbnails has no additional requirements (it uses
matplotlib's image module to scale the images). However, it may be a
problem with multiprocessing -- the thumbnails are generated in parallel
on multi-core machines. I haven't had problems myself, but it seems
multiprocessing doesn't always work in certain environments.

Can you do me a favor? Can you edit gen_gallery.py and replace the line
beginning with "pool.map" to just "map" and let me know if that resolves
this issue? If it does, perhaps we should not use multiprocessing here.

25

Don’t have a lot of time because I am on travel right now, but I think I figured out the cause. For whatever reason, there was some sort of missing file error that caused the generation of the thumbnails to drop down to the debugger prompt. When within the multiprocessing pool, everything just pauses, but nothing shows because the input is disconnected. After a call to clean, I was able to run the docs with and without “pool”.

I hope that is a useful tip that could help figure out how to prevent a unresponsive process.

Ben Root

···

On Mon, May 23, 2011 at 12:11 PM, Ben Gamari <bgamari.foss@…149…> wrote:

On Mon, 23 May 2011 09:35:57 -0400, Michael Droettboom <mdroe@…31…> wrote:

Generating the thumbnails has no additional requirements (it uses

matplotlib’s image module to scale the images). However, it may be a

problem with multiprocessing – the thumbnails are generated in parallel

on multi-core machines. I haven’t had problems myself, but it seems

multiprocessing doesn’t always work in certain environments.

Can you do me a favor? Can you edit gen_gallery.py and replace the line

beginning with “pool.map” to just “map” and let me know if that resolves

this issue? If it does, perhaps we should not use multiprocessing here.

Given this seems to be one of the longer stages of the build process,

I’d appreciate if if we identified and fixed the underlying problem and

not simply sweep it under the rug.

  • Ben