GNU bug report logs - #44254
Performance of package input rewriting

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Lars-Dominik Braun <ldb <at> leibniz-psychology.org>
Cc: 44254 <at> debbugs.gnu.org
Subject: bug#44254: Performance of package input rewriting
Date: Tue, 03 Nov 2020 10:32:16 +0100

Hi,

Lars-Dominik Braun <ldb <at> leibniz-psychology.org> skribis:

>> I guess it’s easy to end up creating huge object graphs.  Here’s an
>> example of an anti-pattern:
>> 
>>   (define a
>>     ((package-input-rewriting x) ((package-input-rewriting y) p1))) 
>> 
>>   (define b
>>     ((package-input-rewriting x) ((package-input-rewriting y) p2)))
>> 
>> The correct use is:
>> 
>>   (define transform
>>     (package-input-rewriting (append x y)))
>> 
>>   (define a (transform p1))
>>   (define b (transform p2))
> that sounds like a section for the cookbook :)

Note that there’s a new section in the manual on this topic:

  https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html

>> It seems to me that you’re redefining a dependency graph, node by node.
>> Thus, you probably don’t need ‘package-input-rewriting’ here.  What you
>> did in Guix-Science commit 972795a23cc9eb5a0bb1a2ffb5681d151fc4d4b0
>> looks more appropriate to me, in terms of style and semantics.
> Okay, got it. My initial concern was that rewriting the graph “by hand” (i.e.
> alist-delete) would be tedious and error-prone.

I haven’t looked closely enough.  If you can define a single procedure
that rewrites the graph, that’s of course better than rewriting nodes
one by one.  Maybe that’s possible, but you need to be careful about
factorizing the transformation procedure as I shown above.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.