From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Bavier Subject: Re: [PATCH 4/4] gnu: matplotlib: Add gtk3 backends. Date: Tue, 23 Dec 2014 11:43:46 -0600 Message-ID: <87oaqudzxp.fsf@gmail.com> References: <878ui8edzl.fsf@gnu.org> <87vblahv6n.fsf@gnu.org> <878uhzkynx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3TUT-0004aT-Kw for guix-devel@gnu.org; Tue, 23 Dec 2014 12:43:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3TUO-0002Au-5Y for guix-devel@gnu.org; Tue, 23 Dec 2014 12:43:25 -0500 In-reply-to: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Federico Beffa Cc: Guix-devel Federico Beffa writes: > On Tue, Dec 23, 2014 at 1:17 AM, Ludovic Courtès wrote: >> I found that “guix build python2-matplotlib -n” triggers a seemingly >> infinite loop (either uses of ‘package-with-python2’ somehow introduce >> cycles, or they lead to very large DAGs), which is what is causing Hydra >> evaluation failures. >> >> I tried reverting 25f9a0 but it doesn’t help. >> >> Could you try to bisect it and revert or fix the problem? If it turns >> out to require more time, could you just comment out the offending parts >> of python.scm so Hydra can resume? > > The build does finish as I've tested it on my machine before > committing the package. However, for some reason, guix needs very long > to generate the derivation. On my machine (quad-core Xeon E5520) > python2-matplotlib takes ca. 31 mins to start building. > Python2-scipy, which includes python2-matplotlib, takes ca. 80 mins.! > Currently I do not understand the reason, but I note that matplotlib, > numpy and scipy are the only python packages with a large number of > inputs. I wonder if this could this be a result of package-with-python2's behavior of recursively creating new package objects for each input in a package. As Ludovic suggested, this could easily create very large DAGs that then need to be processed. This behavior of package-with-python2 was giving me a nightmare when trying to code some improvements to `guix refresh -l`, since there would easily become tens or hundreds of logically identical python package objects floating through the package dependency DAG. The reason I haven't pushed any of those `guix refresh -l` changes is because I haven't yet figure out a way to get output from it in under ~10 minutes. -- Eric Bavier Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html