matplotlib-devel Mailing List for matplotlib

On Mon, May 23, 2011 at 12:11 PM, Ben Gamari <bga...@gm...> wrote:
> On 2011年5月23日 09:35:57 -0400, Michael Droettboom <md...@st...>
> 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
>
>
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 2011年5月23日 09:35:57 -0400, Michael Droettboom <md...@st...> 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

On 05/22/2011 05:33 PM, Benjamin Root wrote:
>
>
> On Sun, May 22, 2011 at 4:11 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> 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.
>
> 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?
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

On 05/22/2011 11:33 AM, Benjamin Root wrote:
>
>
> On Sun, May 22, 2011 at 4:11 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> 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.
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