From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 06 19:23:28 2021 Received: (at 33848) by debbugs.gnu.org; 6 Apr 2021 23:23:28 +0000 Received: from localhost ([127.0.0.1]:42461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTv2e-0004Df-Cp for submit@debbugs.gnu.org; Tue, 06 Apr 2021 19:23:28 -0400 Received: from world.peace.net ([64.112.178.59]:46890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTv2V-0004DG-MM for 33848@debbugs.gnu.org; Tue, 06 Apr 2021 19:23:27 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lTv2P-0006ro-FB; Tue, 06 Apr 2021 19:23:13 -0400 From: Mark H Weaver To: Leo Famulari , Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#33848: Store references in SBCL-compiled code are "invisible" In-Reply-To: References: <87eefu30a4.fsf@gnu.org> <87im56l6es.fsf@yamatai> <87wntm8j18.fsf@ambrevar.xyz> <87a6qil4b1.fsf@yamatai> <87a6qiz5b3.fsf@ambrevar.xyz> <871rbtc3j5.fsf@netris.org> <87r1js9udv.fsf@netris.org> <87sg47vp16.fsf@ambrevar.xyz> <875z139liy.fsf@netris.org> <87ft04sefs.fsf@gnu.org> Date: Tue, 06 Apr 2021 19:21:30 -0400 Message-ID: <87mtubngmi.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33848 Cc: Pierre Neidhardt , 33848@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Leo, Leo Famulari writes: > On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Court=C3=A8s wrote: >> The GC=E2=80=99s scanner still gets it wrong though. I wonder whether h= aving >> the grafting code more capable than the scanner could lead to bad >> surprises. WDYT? > > I'm going off-topic, but I've wished we had a generic fast string-search > (and replace?) procedure. Guile has several functions to help with this, e.g. 'string-contains', 'string-replace', 'string-replace-substring', and of course the regexp functions. The grafting code can't use these things because (1) we are not searching for a single string, but rather for arbitrary nix hashes, and (2) we can't easily use the regexp functions because there could be NULs present. > The go-build-system has a slow "one byte a time" implementation because > I couldn't figure out how to re-use the code in (guix build grafts): > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/go-build-syste= m.scm?h=3Dv1.2.0#n269 From a glance, I would think that 'replace-store-references' from (guix build grafts) is directly applicable here. Do you remember what the difficulty was in using it? Alternatively, since you are only searching for a single string to replace, I think you could read the entire file into a single string (e.g. using 'get-string-all' with "ISO-8859-1" encoding) and use 'string-replace-substring'. What do you think? Mark