Re: Dependency cycle issues when using a Gexp-based snippet

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

>>> What is the difference between delayed and thunked? Would a thunked
>>> capture the closure of its environment while delayed not?  Is the
>>> closure useful to access record-bound values such as the version field
>>> of a package?
>>
>> ‘Thunk’ uses an actual thunk (zero-argument procedure) that’s called
>> each time the field is accessed; ‘delayed’ uses a promise, which is
>> similar except that the result is memoized (info "(guile) Delayed
>> Evaluation").
>
> Thanks for the explanation!  Now I wonder why delayed should not always
> be preferable to thunks?  Is there a reason to offer thunked as well?

Thunked fields were introduced pretty much as a hack so one could look
up dynamic bindings ‘%current-system’ and ‘%current-target-system’ and
produce a result that’s a function of that.  (See
<https://hal.inria.fr/hal-00824004/en>.)

>> What would be interesting is a comparison of the performance of
>> ‘package-derivation’, which can be done with something like:
>>
>>   time guix build -d --no-grafts libreoffice pandoc
>>
>> For memory consumption, try:
>>
>>   GUIX_PROFILING=gc guix build -d --no-grafts libreoffice pandoc
>
> Thanks for these "benchmarking" tips :-).  Unfortunately, making the
> 'snippet' field either thunked or delayed causes 'guix build' to stop
> working entirely, peaking the CPU and slowy eating RAM away (looks like
> a typical dependency cycle).

Hmm.  In packages.scm, there’s a couple of places where <origin> are
matched directly, which means that you get to see the raw
thunk/promise.  The solution is to explicitly call the thunk/force the
promise there, like we do for the ‘patches’ field in this clause:

  ($ <origin> uri method hash name (= force (patches ...)) snippet
          (flags ...) inputs (modules ...) guile-for-build)

If that still doesn’t help, please send a patch!  :-)

Ludo’.