[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33848: Store references in SBCL-compiled code are "invisible"
From: |
Mark H Weaver |
Subject: |
bug#33848: Store references in SBCL-compiled code are "invisible" |
Date: |
Tue, 06 Apr 2021 19:21:30 -0400 |
Hi Leo,
Leo Famulari <leo@famulari.name> writes:
> On Mon, Apr 05, 2021 at 09:45:43PM +0200, Ludovic Courtès wrote:
>> The GC’s scanner still gets it wrong though. I wonder whether having
>> 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-system.scm?h=v1.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
- bug#33848: Store references in SBCL-compiled code are "invisible", (continued)
- bug#33848: Store references in SBCL-compiled code are "invisible", Ludovic Courtès, 2021/04/01
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/01
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/02
- bug#33848: Store references in SBCL-compiled code are "invisible", Pierre Neidhardt, 2021/04/03
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/03
- bug#33848: Store references in SBCL-compiled code are "invisible", Ludovic Courtès, 2021/04/05
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/05
- bug#33848: Store references in SBCL-compiled code are "invisible", Ludovic Courtès, 2021/04/06
- bug#33848: Store references in SBCL-compiled code are "invisible", Pierre Neidhardt, 2021/04/06
- bug#33848: Store references in SBCL-compiled code are "invisible", Leo Famulari, 2021/04/06
- bug#33848: Store references in SBCL-compiled code are "invisible",
Mark H Weaver <=
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/06
- bug#33848: Store references in SBCL-compiled code are "invisible", Ludovic Courtès, 2021/04/08
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/13
- bug#33848: Store references in SBCL-compiled code are "invisible", Ludovic Courtès, 2021/04/14
- bug#33848: Store references in SBCL-compiled code are "invisible", Leo Famulari, 2021/04/14
- bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/15
- bug#33848: Store references in SBCL-compiled code are "invisible", Pierre Neidhardt, 2021/04/16
bug#33848: Store references in SBCL-compiled code are "invisible", Mark H Weaver, 2021/04/01