Hi, Maxim Cournoyer <maxim.courno...@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’.
