GNU bug report logs - #64746
[PATCH 2/2] scripts: time-machine: Error when attempting to visit too old commits.

Previous Next

Full log

Message #29 received at 64746 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Christopher Baines <mail <at> cbaines.net>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Ricardo Wurmus <rekado <at> elephly.net>,
 64746 <at> debbugs.gnu.org
Subject: Re: bug#64746: [PATCH 2/2] scripts: time-machine: Error when
 attempting to visit too old commits.
Date: Tue, 15 Aug 2023 14:57:29 -0400

Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>>> +;;; The commit introducing the 'inferiors' mechanism; it is the oldest commit
>>> +;;; that can be travelled to.
>>> +(define %oldest-possible-commit
>>> +  "2ca299caf64489f4e1e665ec1158fb0309b0b565")
>>
>> I just tried travelling to that assumed oldest commit (because it
>> corresponds to the introduction of the inferiors mechanism), but it
>> fails like:
>>
>> Computing Guix derivation for 'x86_64-linux'...  Backtrace:
>> -           5 (primitive-load "/gnu/store/b70mihsj9xx0xxp6izliqb5vm4…")
>> In ice-9/eval.scm:
>>     155:9  4 (_ _)
>>     159:9  3 (_ #(#(#(#(#(#(#(#(#(#(#(…) …) …) …) …) …) …) …) …) …) …))
>>    173:47  2 (_ #(#(#(#(#(#(#(#(#(#(#(…) …) …) …) …) …) …) …) …) …) …))
>> In ./guix/self.scm:
>>     932:4  1 (guix-derivation "/gnu/store/yfn2s94i5bvwr7j7r6xcnivwg…" …)
>>     903:2  0 (guile-for-build "3.0")
>>
>> ./guix/self.scm:903:2: In procedure guile-for-build:
>> Throw to key `match-error' with args `("match" "no matching pattern" "3.0")'.
>
> I would pick ‘v0.15.0’ (= 359fdda40f754bbf1b5dc261e7427b75463b59be) as
> the oldest commit one can travel to; it’s a bit newer than the one
> above, but it fails in the same way (to my surprise).  It would be
> interesting to investigate.
>
> That said, we could just as well pick ‘v1.0.0’, which is the official
> warranty-void limit, and which seems to work (it needs to build things,
> though…).

I've picked v1.0.0.  It already seems hard enough to get there (you'd
have to build Python 2 with the hardware clock set to a value in the
past to avoid time bombs in its test suite).

As discussed with Ludovic, it's best to avoid doing work on critical
path, that is, when there is a cache hit for the channel.  I've
implemented their idea to delay such work to within
'cached-channel-instance', where we know if there's a cache hit or not.
Here's a simple 'strace -c' benchmark:

Without this change (Guix commit
985638aea14720e16ed5fd94a0e1382a57dec7ac), on a warm cache, it results
on something like:

--8<---------------cut here---------------start------------->8---
$ strace -c guix time-machine --commit=v1.3.0 -- \
  environment --ad-hoc hello -- hello
% time     seconds  usecs/call     calls    errors syscall
[...]
100,00    0,072028           4     16963      2026 total

With this change (v2 incoming) installed:
--8<---------------cut here---------------start------------->8---
$ strace -c ./pre-inst-env guix time-machine --commit=v1.3.0 -- \
  environment --ad-hoc hello -- hello
% time     seconds  usecs/call     calls    errors syscall
[...]
100,00    0,074576           4     18005      2700 total
--8<---------------cut here---------------end--------------->8---

It seems a small cost to pay for the increased user friendliness.

What do you think?

-- 
Thanks,
Maxim

Previous Next

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