GNU logs - #73681, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 07 Oct 2024 14:59:01 +0000
Resent-Message-ID: <handler.73681.B.17283131123823 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 73681 <at> debbugs.gnu.org
Cc: "liliana.prikler" <liliana.prikler@HIDDEN>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Date: Mon, 07 Oct 2024 16:56:50 +0200 (CEST)
Message-Id: <E1sxpAI-0003hS-Gg@HIDDEN>
Received-SPF: pass client-ip=2a0c:5a00:149::26;
 envelope-from=meedstrom@HIDDEN; helo=mailtransmit05.runbox.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Mailman-Approved-At: Mon, 07 Oct 2024 10:58:29 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

Hi, I suggest to maybe amend one of the things done by this patchset:  http=
s://issues.guix.gnu.org/67260

It undoes the hashing effect of the Elisp function `comp-el-to-eln-filename=
`, and that seems likely to cause issues downstream, for example in my Emac=
s package: https://github.com/meedstrom/org-node/issues/60.

To summarize: that function is supposed to generate a filename with a hash =
based not only the filename but the contents of the file.  While it makes s=
ense in Guix to ignore the contribution of the filename, I believe it shoul=
d still output a new filename when the contents change.

Otherwise there seems to be no way for a downstream package to ensure that =
it is using an up-to-date .eln variant of an .el file.

I may have missed something though.  Can someone in the know tell me what h=
appens if you have not updated Emacs (which if I understand correctly, mean=
s ELN-DIR does not change), but you do update an Elisp package, whether thr=
ough Guix or through Emacs' own package managers. Will Emacs then possibly =
load an old .eln?=20=20

I do not believe that user options like `load-prefer-newer` would affect it=
. It would just rely on running the aforementioned function and counting on=
 it to output an .eln filename that does not exist if the source is newer.=

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Subject: bug#73681: Acknowledgement (Maybe partly undo the patch on Elisp
 comp-el-to-eln-filename)
Message-ID: <handler.73681.B.17283131123823.ack <at> debbugs.gnu.org>
References: <E1sxpAI-0003hS-Gg@HIDDEN>
X-Gnu-PR-Message: ack 73681
X-Gnu-PR-Package: guix
Reply-To: 73681 <at> debbugs.gnu.org
Date: Mon, 07 Oct 2024 14:59:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 73681 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
73681: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73681
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 07 Oct 2024 18:04:02 +0000
Resent-Message-ID: <handler.73681.B73681.17283242199438 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Martin =?UTF-8?Q?Edstr=C3=B6m?= <meedstrom@HIDDEN>,  73681 <at> debbugs.gnu.org
Message-ID: <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Mon, 07 Oct 2024 20:02:17 +0200
In-Reply-To: <E1sxpAI-0003hS-Gg@HIDDEN>
References: <E1sxpAI-0003hS-Gg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Am Montag, dem 07.10.2024 um 16:56 +0200 schrieb Martin Edstr=C3=B6m:
> Hi, I suggest to maybe amend one of the things done by this
> patchset:=C2=A0 https://issues.guix.gnu.org/67260
>=20
> It undoes the hashing effect of the Elisp function `comp-el-to-eln-
> filename`, and that seems likely to cause issues downstream, for
> example in my Emacs package:
> https://github.com/meedstrom/org-node/issues/60.
>=20
> To summarize: that function is supposed to generate a filename with a
> hash based not only the filename but the contents of the file.=C2=A0 Whil=
e
> it makes sense in Guix to ignore the contribution of the filename, I
> believe it should still output a new filename when the contents
> change.
There are opposite goals to "make sure that the file hasn't been
tampered with" (upstream) and "to keep files patchable" (Guix).  I
don't think we can easily satisfy both.  Perhaps we could use the
original store path as some kind of key to match the files (since we
compile them in-store IIRC), but that wouldn't work for the "let's
compile our init.el" use case.

As a matter of fact, we've disabled JIT compilation for the very reason
that stuff can break ;)

> Otherwise there seems to be no way for a downstream package to ensure
> that it is using an up-to-date .eln variant of an .el file.
What about aggressive-recompilation-on-write? =20

> I may have missed something though.=C2=A0 Can someone in the know tell me
> what happens if you have not updated Emacs (which if I understand
> correctly, means ELN-DIR does not change), but you do update an Elisp
> package, whether through Guix or through Emacs' own package managers.
> Will Emacs then possibly load an old .eln?=C2=A0=20
We write store paths to a subdirs.el =E2=80=93 unless specifically prompted=
 to
reload that, Emacs will keep using old libraries.  This is by design,
so that updating Emacs does not cause any issues with (byte) compiled
files.

> I do not believe that user options like `load-prefer-newer` would
> affect it. It would just rely on running the aforementioned function
> and counting on it to output an .eln filename that does not exist if
> the source is newer.
Since all timestamps point to 1970, you are right, `load-prefer-newer'
does nothing.

Cheers

Message sent to bug-guix@HIDDEN:

Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 07 Oct 2024 20:47:01 +0000
Resent-Message-ID: <handler.73681.B73681.172833400912671 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Liliana Marie Prikler" <liliana.prikler@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Date: Mon, 07 Oct 2024 22:46:31 +0200 (CEST)
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
In-Reply-To: <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
Message-Id: <E1sxuch-0007aP-NN@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi, thanks for the prompt response!

On Mon, 07 Oct 2024 20:02:17 +0200, Liliana Marie Prikler <liliana.prikler@=
gmail.com> wrote:
> What about aggressive-recompilation-on-write?=20=20

That works in the init.el case, because the user would be the one writing t=
he file.=20=20

In my package, the use case is instead that it starts sub-processes, each o=
f which should load a file "org-node-parser.eln".  I could ahve made them j=
ust load the output of (locate-library "org-node-parser"), but for unrelate=
d reasons, that seems it would only ever locate an .elc and not an .eln.

So I need to use `comp-el-to-eln-filename` to find the up-to-date .eln (or =
force it to be compiled).  Regardless of whether or not the rest of the pac=
kage has already been native-compiled.

The worst-case scenario is using package version 1.4.1 in the main Emacs pr=
ocess, but 1.4.0 of org-node-parser.eln in the subprocesses.  That leads to=
 unintended bugs.

I suppose the other way around could also happen - using package version 1.=
4.0 but 1.4.1 in the subprocesses - but that'll be my own mess to figure ou=
t :)

> We write store paths to a subdirs.el =E2=80=93 unless specifically prompt=
ed to
> reload that, Emacs will keep using old libraries.  This is by design,
> so that updating Emacs does not cause any issues with (byte) compiled
> files.

Let me know if I understand this correctly: updating a package compiles it =
at the same time, so we can have store paths like

/gnu/store/package-1.4.0/...{.elc,.el,.eln}
/gnu/store/package-1.4.1/...{.elc,.el,.eln}

which sounds like it will be all consistent.  An .eln in the second directo=
ry would never secretly be 1.4.0, for example.

But since you said we disabled the JIT compilation, and store dirs are read=
-only, where do the .eln actually end up, after the user starts Emacs and i=
t does its async-native-compile thing?

(or does it not do any JIT compilation at all?)

I don't have a Guix machine at the moment, but is it a deterministic path l=
ike ~/.emacs.d/eln-cache/29.4-HASH/package-HASH.eln ?  The user in my GitHu=
b issue gets no such path from running `comp-el-to-eln-filename`, but maybe=
 they're on an old Guix Emacs.=

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 08 Oct 2024 04:34:01 +0000
Resent-Message-ID: <handler.73681.B73681.172836202812427 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 73681
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Edstr=C3=B6m?= <meedstrom@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Received: via spool by 73681-submit <at> debbugs.gnu.org id=B73681.172836202812427
          (code B ref 73681); Tue, 08 Oct 2024 04:34:01 +0000
Received: (at 73681) by debbugs.gnu.org; 8 Oct 2024 04:33:48 +0000
Received: from localhost ([127.0.0.1]:50155 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sy1ut-0003EN-G2
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2024 00:33:47 -0400
Received: from mail-wm1-f65.google.com ([209.85.128.65]:45238)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1sy1ur-0003EE-15
 for 73681 <at> debbugs.gnu.org; Tue, 08 Oct 2024 00:33:45 -0400
Received: by mail-wm1-f65.google.com with SMTP id
 5b1f17b1804b1-42cbbb1727eso52399025e9.2
 for <73681 <at> debbugs.gnu.org>; Mon, 07 Oct 2024 21:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1728361956; x=1728966756; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=4SjsSxRn3yjCd80zfZv8VMBus/qY+KuTqKpPi1bfgf4=;
 b=aAxwkCC5eagirDZPvKN98+i+JGwc3hUBCgw1Uh9RXDe7nMjYj0ohy5IHLTfqgjP1xY
 PPG1jr24/d+JXXWwGAlR1PsAJydkoUKJ/VFP3Tl8GcpI9RmMYlOCmTCgy/GMIyQgkTky
 9cOusS54o0p22X4gc/ul19vQKUpK6xJy5r7hqBAlMfR161Zorc4yb8+ZqEBBMKgIL3f0
 afgFGyA4P7A6hEC1eteOhroNwBLv2ipeGl30jWnpFfHDmIgQQywThy2g1j0/99CadSxo
 C4AdLGrUeWhcnB4cxsEjTYqdNO8WKfz7+GOzMUSgpOj3QNz6Byf2kEQLYSh0M1EPdYOo
 kUxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1728361956; x=1728966756;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=4SjsSxRn3yjCd80zfZv8VMBus/qY+KuTqKpPi1bfgf4=;
 b=jCAfyD5aLOUi8h7m6m2v5baGZhxDuRM2hpBlWqAfBSRQdH2aBXmsqx9vn9eLFhznpW
 L6O5JeN6maAFHRkZNfdGCedNvcN0OGXf/3wR2Kz6d4Iy1H7M8ZGh4TXkqPFpklp9tZNW
 EJBeQt9PfUJPayyrzi+rQ8dnkQwzL5GFOshnAUFh4Sexv9a/Ae+OE9c6VllSeMGNHBD4
 B1EF0DJ4t9jGahYp/boSSKiAIAfNzcJ+8Ucdn/YsjuAZCQ9525QYt23AQ4PV62Xpb43A
 p6HkpkchoocPuMHsZ5U7E6JzFkpc+swhpYurZaO9RuJaEn/QLRumksgzT3+zHAmPrxhY
 zBdQ==
X-Gm-Message-State: AOJu0YyP+tefmGC0SQfl6aLchuOAqFv43iO+JunQ7N9WFVEL/yuIPRwQ
 p2cEEl7fkKTkqpRBh4CJYnlpxi+dgth6WwbE7RT1o25yFD62ZtT1KdHk/5uO
X-Google-Smtp-Source: AGHT+IFwlxSd+Dzn07BRSadw12HdpPOk1AQ4MPFIZU+l/ET5RsL0lbQhqHDWxQVg6ZaOKx9Ysoxh7A==
X-Received: by 2002:a7b:c454:0:b0:42f:8ac6:4f34 with SMTP id
 5b1f17b1804b1-42f8ac65216mr67223535e9.35.1728361955456; 
 Mon, 07 Oct 2024 21:32:35 -0700 (PDT)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-42f86b4acddsm112290875e9.44.2024.10.07.21.32.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 07 Oct 2024 21:32:34 -0700 (PDT)
Message-ID: <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Tue, 08 Oct 2024 06:32:32 +0200
In-Reply-To: <E1sxuch-0007aP-NN@HIDDEN>
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
 <E1sxuch-0007aP-NN@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Montag, dem 07.10.2024 um 22:46 +0200 schrieb Martin Edstr=C3=B6m:
> In my package, the use case is instead that it starts sub-processes,
> each of which should load a file "org-node-parser.eln".=C2=A0 I could ahv=
e
> made them just load the output of (locate-library "org-node-parser"),
> but for unrelated reasons, that seems it would only ever locate an
> .elc and not an .eln.
Could you keep track of modifications to org-node-parser and recompile
that on change?  Or is it part of your package already =E2=80=93 if the lat=
ter,
then we should already have it compiled as a package.

> So I need to use `comp-el-to-eln-filename` to find the up-to-date
> .eln (or force it to be compiled).=C2=A0 Regardless of whether or not the
> rest of the package has already been native-compiled.
>=20
> The worst-case scenario is using package version 1.4.1 in the main
> Emacs process, but 1.4.0 of org-node-parser.eln in the subprocesses.=C2=
=A0
> That leads to unintended bugs.
>=20
> I suppose the other way around could also happen - using package
> version 1.4.0 but 1.4.1 in the subprocesses - but that'll be my own
> mess to figure out :)
I think it's your own mess either way =E2=80=93 can't you downgrade to a mo=
del
where you just ask for "org-node-parser" to be loaded, regardless of
compilation?  Then, you wouldn't have to native-compile it.=20

> > We write store paths to a subdirs.el =E2=80=93 unless specifically prom=
pted
> > to reload that, Emacs will keep using old libraries.=C2=A0 This is by
> > design, so that updating Emacs does not cause any issues with
> > (byte) compiled files.
>=20
> Let me know if I understand this correctly: updating a package
> compiles it at the same time, so we can have store paths like
>=20
> /gnu/store/package-1.4.0/...{.elc,.el,.eln}
> /gnu/store/package-1.4.1/...{.elc,.el,.eln}
>=20
> which sounds like it will be all consistent.=C2=A0 An .eln in the second
> directory would never secretly be 1.4.0, for example.
>=20
> But since you said we disabled the JIT compilation, and store dirs
> are read-only, where do the .eln actually end up, after the user
> starts Emacs and it does its async-native-compile thing?
>=20
> (or does it not do any JIT compilation at all?)
We don't do JIT, but even if we did, we should find the one in the
store (and the correct one, as per Emacs load paths).

> I don't have a Guix machine at the moment, but is it a deterministic
> path like ~/.emacs.d/eln-cache/29.4-HASH/package-HASH.eln ?=C2=A0 The use=
r
> in my GitHub issue gets no such path from running `comp-el-to-eln-
> filename`, but maybe they're on an old Guix Emacs.
It's `~/.emacs.d/eln-cache/29.4-HASH/some/module.eln`, with some/module
being the module that you'd load.

Cheers

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 08 Oct 2024 10:42:02 +0000
Resent-Message-ID: <handler.73681.B73681.172838410523933 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 73681
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: "Liliana Marie Prikler" <liliana.prikler@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Received: via spool by 73681-submit <at> debbugs.gnu.org id=B73681.172838410523933
          (code B ref 73681); Tue, 08 Oct 2024 10:42:02 +0000
Received: (at 73681) by debbugs.gnu.org; 8 Oct 2024 10:41:45 +0000
Received: from localhost ([127.0.0.1]:51224 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sy7ey-0006Dw-Hv
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2024 06:41:44 -0400
Received: from mailtransmit05.runbox.com ([185.226.149.38]:44172)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <meedstrom@HIDDEN>) id 1sy7ev-0006Dg-UJ
 for 73681 <at> debbugs.gnu.org; Tue, 08 Oct 2024 06:41:43 -0400
Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com)
 by mailtransmit05.runbox.com with esmtps (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
 (envelope-from <meedstrom@HIDDEN>) id 1sy7eg-00ErBj-PD
 for 73681 <at> debbugs.gnu.org; Tue, 08 Oct 2024 12:41:26 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.eu; 
 s=selector1;
 h=Message-Id:In-Reply-To:References:Date:Subject:CC:To:From:
 MIME-Version:Content-Transfer-Encoding:Content-Type;
 bh=E8xUsoys2Q0vfFwhJt1G7lyLeja5EPtD6itHWJ9pxGs=; b=HdkY9J5d6+v14SSIh2AhvU0Fu8
 60tpUqI01wf/wpylyeTd4R/64l/nzUNZnUvC8gV/lcXlyypQGpOXDii3iuRc7bqOkMdAgFENKWbS1
 vujamJIUrUP7yWCLDXSVIUcsafxb7eF8hOzT8AvAo+vew+9zlVB/6RyVvZet3vYrwEBzNfXz9q+zS
 R3Vqlowu200ajgUMQ6T1pSnGqQab10U32GM7y/6GlV9whetiEXjtrDN1DFZ4ndeXBSenR1SofTbkM
 XeNnAWbc+BZDItGPfTs3WM+sMQap3R6UnLXxzGZoB5bql5FO67G1/OFQSNV445iLLxIGLCRQb+CIx
 WvX2d0Hw==;
Received: from [10.9.9.129] (helo=rmmprod07.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <meedstrom@HIDDEN>)
 id 1sy7eg-0002P9-BW; Tue, 08 Oct 2024 12:41:26 +0200
Received: from mail by rmmprod07.runbox with local (Exim 4.86_2)
 (envelope-from <meedstrom@HIDDEN>)
 id 1sy7eg-0005XF-AC; Tue, 08 Oct 2024 12:41:26 +0200
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received: from [Authenticated alias (1196375)] by runbox.com with http
 (RMM6); Tue, 08 Oct 2024 10:41:26 GMT
From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Date: Tue, 08 Oct 2024 12:41:26 +0200 (CEST)
X-RMM-Aliasid: 1196375
X-Mailer: RMM6
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
 <E1sxuch-0007aP-NN@HIDDEN>
 <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
In-Reply-To: <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
Message-Id: <E1sy7eg-0005XF-AC@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Tue, 08 Oct 2024 06:32:32 +0200, Liliana Marie Prikler <liliana.prikler@=
gmail.com> wrote:

> Could you keep track of modifications to org-node-parser and recompile
> that on change?  Or is it part of your package already =E2=80=93 if the l=
atter,
> then we should already have it compiled as a package.

It comes as part of the package. I don't want to assume that it has been co=
mpiled, since it's fairly performance-sensitive. That's why I'll either use=
 a previously existing compiled object or make a new one.

What I'm getting from this is that it might be safer to just compile the ob=
ject into /tmp and use that, regardless of what may already exist.  At the =
moment, that's necessary for keeping the option open of using an .eln on Gu=
ix.

So let's ignore my package, it is just an example of a downstream use of `c=
omp-el-to-eln-filename` that relied on its hashing functionality.

Let's just discuss that function.

I have to point out that the emacs `load-path` does not include any native =
paths.  When I inspect the value on my non-Guix emacs, I see no references =
to .../eln-cache/..., just references to directories where there are .elc a=
nd .el files.

I infer that Emacs starts with finding a library in load-path, then convert=
s the path with `comp-el-to-eln-filename`, and checks if that file exists, =
then loads it.

And crucially, it is not just about the filepath, the function hashes the f=
ile contents as well. That ensures that the output path is always different=
 if the source file changes.

Since Guix has a patch that removes this effect, it seems like a package co=
uld be upgraded many, many times, without the .eln path ever changing, and =
so the user would stay on that very outdated file.

Is that not a regression/bug?=

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 08 Oct 2024 17:35:02 +0000
Resent-Message-ID: <handler.73681.B73681.172840886014284 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 73681
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Edstr=C3=B6m?= <meedstrom@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Received: via spool by 73681-submit <at> debbugs.gnu.org id=B73681.172840886014284
          (code B ref 73681); Tue, 08 Oct 2024 17:35:02 +0000
Received: (at 73681) by debbugs.gnu.org; 8 Oct 2024 17:34:20 +0000
Received: from localhost ([127.0.0.1]:54253 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1syE6F-0003iK-RN
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2024 13:34:20 -0400
Received: from mail-wm1-f67.google.com ([209.85.128.67]:52435)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1syE6E-0003i8-Kf
 for 73681 <at> debbugs.gnu.org; Tue, 08 Oct 2024 13:34:19 -0400
Received: by mail-wm1-f67.google.com with SMTP id
 5b1f17b1804b1-42cb57f8b41so79609605e9.0
 for <73681 <at> debbugs.gnu.org>; Tue, 08 Oct 2024 10:34:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1728408789; x=1729013589; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=DqeBQlfZ14+DLPHoCkHyZ00/rvMMYgYeZAJgMLtaloI=;
 b=l1WHPrthot+regC5ONiJ3R0WwrhgdGiFJMK+j1Ac24cPbWfHVq8NwrSeWoBme3oMG9
 zMXSLZqk4JPhVEp4/6OkgxqDSegV1Tv4W2QXKJ/oU0RyGygRzMDVF+GKfhUNOVIUHEAI
 FAmLWhWpXUCMHgYz2YNxp2olPhWRSXLCq0oou39mJDqw/SzgegZ3JteOEYURSjHGLlUu
 aZp+Cz3H+sx/1Fn37gRXHCfUoFfhmVKBUvJnpXSE4yVTAs4/GpSiviYmsaY5mFv/yppc
 W9Z3SrhWLKvbKLiTUKq2CwQPvaMlDbXe7YIXTZZC+TUOD2BkLsuRD3PkjKGKz7CZOhOr
 B5zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1728408789; x=1729013589;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=DqeBQlfZ14+DLPHoCkHyZ00/rvMMYgYeZAJgMLtaloI=;
 b=cnxYdnNvW/Rv69f6SS2sM2tnQbzkMB+iYbqVOtCSSolv4/mCDm0ZGT9A2Zk4kW4sGW
 ECUZYCOZomKsKYxk6ErL5oM2Jyi+ZliQ9xQFkfgkYoU5wKQdJmQwYyrMGAlX0Ft24JR1
 T0lrTH3AtaxGMjcySdksNsptKLHydi60PCL4i0+wqFJnnDc7AIUL9aLP2EVhfOLog05B
 ogM89GlzigewNUGBxl3xT4sBzjIsFQ6KMN87yKkm6s0SYoLSrOVtUPQHU4TaeaSXPKJC
 tbTB41QsFM/7D16Lg/vi/9uHQdUJCmgMKmppZY066HcAzKtIa8CMuZVQE2px/CXstLRu
 wllA==
X-Gm-Message-State: AOJu0YzXo1m7ByE2CEIyPVpLp2HYFHOddbKF5e6RXkEGEFu1GWA9nNc9
 oPpb1SJ2/6OmQXPGxU9sCVC6ZuHBmOHwFnrgfOOzlPEOSmaTGzim
X-Google-Smtp-Source: AGHT+IE59XkoBsfiS2HOJ+Me64ZB28v0AKjEKsltFZfM6wPCPOrh/+yK5xEuJeQpZlHnon7ATYXmTA==
X-Received: by 2002:a5d:6e0a:0:b0:374:ce15:9995 with SMTP id
 ffacd0b85a97d-37d0e78253cmr12212588f8f.34.1728408788203; 
 Tue, 08 Oct 2024 10:33:08 -0700 (PDT)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-37d1690fc53sm8599158f8f.4.2024.10.08.10.33.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 08 Oct 2024 10:33:07 -0700 (PDT)
Message-ID: <a96bf29e15108292c31e9cf29f81a7a5150eaeca.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Tue, 08 Oct 2024 19:33:06 +0200
In-Reply-To: <E1sy7eg-0005XF-AC@HIDDEN>
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
 <E1sxuch-0007aP-NN@HIDDEN>
 <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
 <E1sy7eg-0005XF-AC@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Dienstag, dem 08.10.2024 um 12:41 +0200 schrieb Martin Edstr=C3=B6m:
> It comes as part of the package. I don't want to assume that it has
> been compiled, since it's fairly performance-sensitive. That's why
> I'll either use a previously existing compiled object or make a new
> one.
Could you leave that decision to the user?

> [=E2=80=A6]
>=20
> So let's ignore my package, it is just an example of a downstream use
> of `comp-el-to-eln-filename` that relied on its hashing
> functionality.
>=20
> Let's just discuss that function.
>=20
> I have to point out that the emacs `load-path` does not include any
> native paths.=C2=A0 When I inspect the value on my non-Guix emacs, I see
> no references to .../eln-cache/..., just references to directories
> where there are .elc and .el files.
There is a separate load path for natively compiled files, called
`native-comp-eln-load-path'.

> I infer that Emacs starts with finding a library in load-path, then
> converts the path with `comp-el-to-eln-filename`, and checks if that
> file exists, then loads it.
>=20
> And crucially, it is not just about the filepath, the function hashes
> the file contents as well. That ensures that the output path is
> always different if the source file changes.
I think relying on such implementation details is perhaps permitted if
it's inside of Emacs itself, but even then it clashes with our
expectation that Emacs be graftable.

> Since Guix has a patch that removes this effect, it seems like a
> package could be upgraded many, many times, without the .eln path
> ever changing, and so the user would stay on that very outdated file.
>=20
> Is that not a regression/bug?
The way our load paths are set up, it is actually the opposite (which
still is a bug, just not the one reported).  While `guix upgrade` or a
command to the similar effect will swap out the .eln under the hood,
the `.el` and `.elc` files stay stable =E2=80=93 remember what I wrote in t=
he
previous message about that having caused issues with byte compilation?

We also get a similar-looking bug if our packages aren't actually
native-compiled, but Emacs itself vendors them.  That is resolved by
dropping those .eln-files from the Emacs package.

Cheers

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 09 Oct 2024 15:19:02 +0000
Resent-Message-ID: <handler.73681.B73681.172848710522312 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 73681
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: "Liliana Marie Prikler" <liliana.prikler@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Received: via spool by 73681-submit <at> debbugs.gnu.org id=B73681.172848710522312
          (code B ref 73681); Wed, 09 Oct 2024 15:19:02 +0000
Received: (at 73681) by debbugs.gnu.org; 9 Oct 2024 15:18:25 +0000
Received: from localhost ([127.0.0.1]:57382 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1syYSG-0005no-4c
	for submit <at> debbugs.gnu.org; Wed, 09 Oct 2024 11:18:24 -0400
Received: from mailtransmit05.runbox.com ([185.226.149.38]:40402)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <meedstrom@HIDDEN>) id 1syYSD-0005nX-Gv
 for 73681 <at> debbugs.gnu.org; Wed, 09 Oct 2024 11:18:22 -0400
Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com)
 by mailtransmit05.runbox.com with esmtps (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
 (envelope-from <meedstrom@HIDDEN>)
 id 1syYPq-000tZ4-OS; Wed, 09 Oct 2024 17:15:54 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.eu; 
 s=selector1;
 h=Message-Id:In-Reply-To:References:Date:Subject:CC:To:From:
 MIME-Version:Content-Transfer-Encoding:Content-Type;
 bh=linbsRDj2UYRzL2K8HId+b/n3ba7Vnq7fjGXuW82GEg=; b=GwVz2natrDPDaZudyB1FhG0Kpu
 6SV/248rtVGACYNVXGktY1zp7IJTaoII0nlSe27FHYDETKWSXbB/VxJZ38nA/EwU0AcTJSysGT/IR
 c3BQ1g8IZ7uAODW5fK6k/0GoUDH1l4W1WByjpMoqpl4chhe5Yg6c8h+SvzPpbg7yc1QtBtu7Vazbt
 uBMk3959xAHbWdyC04qAA8Hu9f9sC5yzfYQmK7nZZ1JSqnrlFV2GAxNWztjiqj3/GGbOuvNG/LPUr
 YaepJAr9Qj7udsuZRnw0/HPSPDMpfY+yfvJKEU0zYDQFzucMX5YH70+b/XQdOhku+bOpArebatOTy
 T4KXGZSA==;
Received: from [10.9.9.127] (helo=rmmprod05.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <meedstrom@HIDDEN>)
 id 1syYPq-0001yu-C7; Wed, 09 Oct 2024 17:15:54 +0200
Received: from mail by rmmprod05.runbox with local (Exim 4.86_2)
 (envelope-from <meedstrom@HIDDEN>)
 id 1syYPq-0005iN-A6; Wed, 09 Oct 2024 17:15:54 +0200
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received: from [Authenticated alias (1196375)] by runbox.com with http
 (RMM6); Wed, 09 Oct 2024 15:15:54 GMT
From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Date: Wed, 09 Oct 2024 17:15:54 +0200 (CEST)
X-RMM-Aliasid: 1196375
X-Mailer: RMM6
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
 <E1sxuch-0007aP-NN@HIDDEN>
 <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
 <E1sy7eg-0005XF-AC@HIDDEN>
 <a96bf29e15108292c31e9cf29f81a7a5150eaeca.camel@HIDDEN>
In-Reply-To: <a96bf29e15108292c31e9cf29f81a7a5150eaeca.camel@HIDDEN>
Message-Id: <E1syYPq-0005iN-A6@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi, thanks for info! This email will be a bit long because I'm quite confus=
ed and thinking aloud, so no need to reply to all of it.  But I appreciate =
any attempt to shed clarity!


On Tue, 08 Oct 2024 19:33:06 +0200, Liliana Marie Prikler <liliana.prikler@=
gmail.com> wrote:

> > It comes as part of the package. I don't want to assume that it has
> > been compiled, since it's fairly performance-sensitive. That's why
> > I'll either use a previously existing compiled object or make a new
> > one.
> Could you leave that decision to the user?

I'm considering it, but ran into essentially the same problem.  I need a wa=
y to tell which one was loaded, of the .elc, .eln or .el.

This takes the thread a bit off-topic but ... Do you know how?

Currently I'm leaning towards an algorithm like

#+begin_src elisp
(defun guess-loaded-lib (basename)
  (let* ((el (locate-library (concat basename ".el")))
         (elc (locate-library (concat basename ".elc")))
         (eln (comp-el-to-eln-filename el)))
    (if load-prefer-newer
        (car (sort (delq 'nil (list el elc eln)) #'file-newer-than-file-p))
      (if (and (file-newer-than-file-p elc el)
               (file-newer-than-file-p eln el))
          ;; If elc is newer than el, assume it was compiled from el, and
          ;; therefore is safe to replace with eln
          eln
        elc))))
#+end_src

I don't know how to "leave it to the user" any better than that.=20=20

On Guix, even in the future when we re-enable JIT compilation, this algorit=
hm could never return an .eln, since =3Dfile-newer-than-file-p=3D returns n=
il when both paths have identical timestamps from 1970.

I found a pretty neat built-in:=20

     (symbol-file 'SOME-FUNCTION-FROM-THE-LIB nil t)

but its internals also use =3Dfile-newer-than-file-p=3D and =3Dcomp-el-to-e=
ln-rel-filename=3D, so not sure it is any more reliable than what I have ab=
ove.


> There is a separate load path for natively compiled files, called
> `native-comp-eln-load-path'.

Good to know! I don't know how Emacs consults it though.  I can't e.g. loca=
te an .eln of a given library by calling something like

#+begin_src elisp
(locate-eln-file "org-node-parser")
#+end_src

so it seems I must simply do:

#+begin_src elisp
(let ((el (locate-library "org-node-parser.el")))
  (when el
    (locate-eln-file (comp-el-to-eln-rel-filename el))))
#+end_src

which is functionally equivalent to:

#+begin_src elisp
(let ((eln (comp-el-to-eln-filename (locate-library "org-node-parser.el"))))
  (when (file-exists-p eln)
    eln))
#+end_src


> > I infer that Emacs starts with finding a library in load-path, then
> > converts the path with `comp-el-to-eln-filename`, and checks if that
> > file exists, then loads it.
> >
> > And crucially, it is not just about the filepath, the function hashes
> > the file contents as well. That ensures that the output path is
> > always different if the source file changes.
> I think relying on such implementation details is perhaps permitted if
> it's inside of Emacs itself, but even then it clashes with our
> expectation that Emacs be graftable.

OK, so if passing "file.el" to =3Dcomp-el-to-eln-filename=3D produces a pat=
h with a hash of the content, like:

    .../eln-cache/29.4-HASH/module/file-HASH-BASED-ON-CONTENT.eln

this would make Emacs non-graftable.  Because the hash would change after f=
ile.el is upgraded.  I suppose that makes sense, thanks!

Maybe, as a hack, the graft process could symlink the pre-graft filename to=
 the post-graft filename... so we don't have to alter the behavior of =3Dco=
mp-el-to-eln-filename=3D.

But yea... it's less dev effort to just not pre-compile any .eln files.

Out of curiosity: if Guix does no JIT compilation at all anyway, why does i=
t not let Emacs do it the usual way into ~/.emacs.d/eln-cache, post-install=
ation?  (Aside from the fact it would necessitate reverting the behavior of=
 =3Dcomp-el-to-eln-filename=3D.)

Actually... (with reservation that I may be wasting your time) I'm starting=
 to wonder why the filename needs to stay the same for Emacs to be graftabl=
e?  Realistically, if all Emacs packages get upgraded, and if =3Dcomp-el-to=
-eln-filename=3D works like upstream, we have some paths like

    /gnu/store/emacs-29.4/bin/emacs
    /gnu/store/emacs-magit-OLD/lisp/magit.el
    /gnu/store/emacs-magit-NEW/lisp/magit.el
    .../wherever/magit-OLDHASH.eln
    .../wherever/magit-NEWHASH.eln

Then we start Emacs, and run its =3Dcomp-el-to-eln-filename=3D on the new m=
agit.el, it would correctly return .../wherever/magit-NEWHASH.eln. No need =
for static filenames to swap out.

Is graftability just about the compiled objects inside of  /gnu/store/emacs=
-29.4/share/emacs/site-lisp/ that might be symlinked in from other Guix pac=
kages?

If so, I guess it ties back to my confusion about how Emacs uses the native=
-comp-eln-load-path, because it seems that IF it just converted an .el to f=
ind an .eln as I thought, then grafting would work automatically because th=
e new .el is also symlinked in along with the new .eln, which would result =
in =3Dcomp-el-to-eln-filename=3D returning the new .eln correctly.

No, grafting is about avoiding a world re-compile, right?  So like if packa=
ge-A was built with an old dependency package-B, it does not get re-built w=
hen package-B is upgraded. But does grafting actually ever change anything =
in Emacs?  When you start emacs and it loads package-A which in turn loads =
package-B because there's a =3Drequire=3D statement for package-B, Emacs wi=
ll actually load the fresh package-B from /gnu/store/emacs-package-B, won't=
 it?  So grafting would seem to be meaningless.

Not sure how to feel if it's like this instead: a compiled function from pa=
ckage A, containing a call to some function "package-B-frobnicate", will ac=
tually call some bytecode originating from /gnu/store/emacs-package-A/share=
/emacs/site-lisp/package-B.elc? That's... not what happens, right?  OK, pro=
bably yes if it was a defsubst or defmacro.

So we can have package A using a macro that was defined in an old version o=
f package-B.  I like that not, but the reason I ask is I'm trying to find o=
ut where it is that the file path would influence the graft.


> The way our load paths are set up, it is actually the opposite (which
> still is a bug, just not the one reported).  While `guix upgrade` or a
> command to the similar effect will swap out the .eln under the hood,
> the `.el` and `.elc` files stay stable =E2=80=93 remember what I wrote in=
 the
> previous message about that having caused issues with byte compilation?

I confess I'm puzzled.  Does this just apply to a case like the following?

- Emacs itself is upgraded
- A package emacs-magit is NOT upgraded

so that

- magit.eln is rebuilt
- magit.el and magit.elc stay the same

That would make sense.  Do you mean it's a bug because .elc files are also =
not portable between different Emacsen?

Just checking: is it correct to expect that if you actually upgrade the ema=
cs-magit package, then its .el, .elc and .eln are all upgraded?=

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 09 Oct 2024 17:25:01 +0000
Resent-Message-ID: <handler.73681.B73681.172849465914620 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 73681
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Martin =?UTF-8?Q?Edstr=C3=B6m?= <meedstrom@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Received: via spool by 73681-submit <at> debbugs.gnu.org id=B73681.172849465914620
          (code B ref 73681); Wed, 09 Oct 2024 17:25:01 +0000
Received: (at 73681) by debbugs.gnu.org; 9 Oct 2024 17:24:19 +0000
Received: from localhost ([127.0.0.1]:57521 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1syaQ6-0003nh-0d
	for submit <at> debbugs.gnu.org; Wed, 09 Oct 2024 13:24:18 -0400
Received: from mail-wm1-f65.google.com ([209.85.128.65]:53556)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1syaQ3-0003nS-8u
 for 73681 <at> debbugs.gnu.org; Wed, 09 Oct 2024 13:24:16 -0400
Received: by mail-wm1-f65.google.com with SMTP id
 5b1f17b1804b1-430ee5c9570so36595e9.3
 for <73681 <at> debbugs.gnu.org>; Wed, 09 Oct 2024 10:24:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1728494579; x=1729099379; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=nGcM6ypkWCGVfuUex0/4qocmeUiDhMYxEtANOuKUQDs=;
 b=Bh8xdiCKkAB5HJ/H2LXqWWAfFdtIyXAW6LcZlE68DrTAuXdvKGUQU4DHIeOdhPcdZS
 jTAfIWN+22grKSSX+bFOwlY2dF/kv1gSZCQTKXLAVU+gWhZYmLc3YfDTxS0TZBw0dLAQ
 ZmJSmdFdPQPB7vul21TNCK4EEu2UUMUtdE/bFt368v1Ib63u//Y6gsSHjQH3Gsby/N2S
 5dpdylABvnFjxS2WHE68bJ+ndJHwI7EeMD6NPqTLFpq3MyELAHALiJEV+smIekA6z/bG
 87XJKqV0VoiSeJVER54EDn0O/B5y9HqAolrlmkTtzJtU7jNJoWEKXqPYPTJiCyXFpfms
 pgig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1728494579; x=1729099379;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=nGcM6ypkWCGVfuUex0/4qocmeUiDhMYxEtANOuKUQDs=;
 b=ves4imMF8i+67EgWZp6D/tMpOkNcDQS/H6LffCz2KTqKMrOLd/g064wFbzIeCQ0u1L
 iPUYLLbFfWrWnBciGSYe5xeC17ASxkg+fk4ap+K5OFVBSlH1WEFyH+IoywG7Nov46cpE
 3FdbOR1UvHbQo/SvJJYtmyCvRILyFbo+m5tYqwy5yScWyTHWSC7/G3bxy1VGkLkh+37z
 KuaqvuvTqEQTBGWsp2cuRCd8KEHo835LNdJzTHd1JfqgCWiEYheBrB+LmMepDCu2sQLk
 Zm4ImcgHlpIXQmpF+PiXXwCWriGU1x73hYUyZJC9jKG0WQa6HKa2xMERLcuGUREUtG4e
 cATA==
X-Gm-Message-State: AOJu0YyKU1wBa+GCldfokNl2bOYHtigoy7roKAv5vLeYU9OCpR21Qwxn
 R8YNTkdyCRpYRNwd3BVjWAv5dt2zkn0nGbvJ5UBOFUR0JMR9Rjvf
X-Google-Smtp-Source: AGHT+IFYLJjd+P6Y9gbyMn35KlQw821v0noLmkhHGgQX50np4pkNCwk4fkY/cqOuIwHF+T5u+6YKKg==
X-Received: by 2002:a05:600c:1c0b:b0:42b:ac3d:3abc with SMTP id
 5b1f17b1804b1-430d70b3cb1mr36105745e9.24.1728494578780; 
 Wed, 09 Oct 2024 10:22:58 -0700 (PDT)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-430ccf60953sm26175385e9.29.2024.10.09.10.22.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 09 Oct 2024 10:22:58 -0700 (PDT)
Message-ID: <518988807953a1b77acb5f9833992fa9ced883c1.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Wed, 09 Oct 2024 19:22:55 +0200
In-Reply-To: <E1syYPq-0005iN-A6@HIDDEN>
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
 <E1sxuch-0007aP-NN@HIDDEN>
 <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
 <E1sy7eg-0005XF-AC@HIDDEN>
 <a96bf29e15108292c31e9cf29f81a7a5150eaeca.camel@HIDDEN>
 <E1syYPq-0005iN-A6@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Mittwoch, dem 09.10.2024 um 17:15 +0200 schrieb Martin Edstr=C3=B6m:
> Hi, thanks for info! This email will be a bit long because I'm quite
> confused and thinking aloud, so no need to reply to all of it.=C2=A0 But =
I
> appreciate any attempt to shed clarity!
>=20
>=20
> On Tue, 08 Oct 2024 19:33:06 +0200, Liliana Marie Prikler
> <liliana.prikler@HIDDEN> wrote:
>=20
> > > It comes as part of the package. I don't want to assume that it
> > > has been compiled, since it's fairly performance-sensitive.
> > > That's why I'll either use a previously existing compiled object
> > > or make a new one.
> > Could you leave that decision to the user?
>=20
> I'm considering it, but ran into essentially the same problem.=C2=A0 I
> need a way to tell which one was loaded, of the .elc, .eln or .el.
>=20
> This takes the thread a bit off-topic but ... Do you know how?
>=20
> Currently I'm leaning towards an algorithm like
>=20
> #+begin_src elisp
> (defun guess-loaded-lib (basename)
> =C2=A0 (let* ((el (locate-library (concat basename ".el")))
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (elc (locate-library (co=
ncat basename ".elc")))
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (eln (comp-el-to-eln-fil=
ename el)))
> =C2=A0=C2=A0=C2=A0 (if load-prefer-newer
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (car (sort (delq 'nil (list el=
 elc eln)) #'file-newer-than-
> file-p))
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (if (and (file-newer-than-file-p elc el)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 (file-newer-than-file-p eln el))
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; If elc is newer=
 than el, assume it was compiled from el,
> and
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; therefore is sa=
fe to replace with eln
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 eln
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 elc))))
> #+end_src
>=20
> I don't know how to "leave it to the user" any better than that.=C2=A0=
=20
The user can just use the output of the help function, it will tell
them whether a function is natively-compiled, byte-compiled, or just
interpreted.  Emacs 30 even gives you `native-comp-function-p'.  See
`gnu/packages/aux-files/emacs/comp-integrity[-next].el' for how we
assert that our Emacs loads natively-compiled libraries.

> On Guix, even in the future when we re-enable JIT compilation, this
> algorithm could never return an .eln, since =3Dfile-newer-than-file-p=3D
> returns nil when both paths have identical timestamps from 1970.
>=20
> I found a pretty neat built-in:=20
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0 (symbol-file 'SOME-FUNCTION-FROM-THE-LIB nil t)
>=20
> but its internals also use =3Dfile-newer-than-file-p=3D and =3Dcomp-el-to=
-
> eln-rel-filename=3D, so not sure it is any more reliable than what I
> have above.
I'm not sure these things work the way you think.  IIUC, `load-prefer-
newer' should guard against the case where the .el is newer than the
.el[cn], not the other way round, so it should still load the
compiled/native-compiled variant if they have the same stamp.

> > There is a separate load path for natively compiled files, called
> > `native-comp-eln-load-path'.
>=20
> Good to know! I don't know how Emacs consults it though.=C2=A0 I can't
> e.g. locate an .eln of a given library by calling something like
>=20
> #+begin_src elisp
> (locate-eln-file "org-node-parser")
> #+end_src
>=20
> so it seems I must simply do:
>=20
> #+begin_src elisp
> (let ((el (locate-library "org-node-parser.el")))
> =C2=A0 (when el
> =C2=A0=C2=A0=C2=A0 (locate-eln-file (comp-el-to-eln-rel-filename el))))
> #+end_src
>=20
> which is functionally equivalent to:
>=20
> #+begin_src elisp
> (let ((eln (comp-el-to-eln-filename (locate-library "org-node-
> parser.el"))))
> =C2=A0 (when (file-exists-p eln)
> =C2=A0=C2=A0=C2=A0 eln))
> #+end_src
I mean, the C code is there to read (along with the patch we've made),
but I can't fault you for not going that deep. =20

> > > I infer that Emacs starts with finding a library in load-path,
> > > then converts the path with `comp-el-to-eln-filename`, and checks
> > > if that file exists, then loads it.
> > >=20
> > > And crucially, it is not just about the filepath, the function
> > > hashes the file contents as well. That ensures that the output
> > > path is always different if the source file changes.
> > I think relying on such implementation details is perhaps permitted
> > if it's inside of Emacs itself, but even then it clashes with our
> > expectation that Emacs be graftable.
>=20
> OK, so if passing "file.el" to =3Dcomp-el-to-eln-filename=3D produces a
> path with a hash of the content, like:
>=20
> =C2=A0=C2=A0=C2=A0 .../eln-cache/29.4-HASH/module/file-HASH-BASED-ON-CONT=
ENT.eln
>=20
> this would make Emacs non-graftable.=C2=A0 Because the hash would change
> after file.el is upgraded.=C2=A0 I suppose that makes sense, thanks!
>=20
> Maybe, as a hack, the graft process could symlink the pre-graft
> filename to the post-graft filename... so we don't have to alter the
> behavior of =3Dcomp-el-to-eln-filename=3D.
The grafting process doesn't look that deep into file names.  On paper,
that could work, since the length of the name is preserved, but it'd
also make the grafting process take longer and not really add all that
much to its reliability.

> But yea... it's less dev effort to just not pre-compile any .eln
> files.
>=20
> Out of curiosity: if Guix does no JIT compilation at all anyway, why
> does it not let Emacs do it the usual way into ~/.emacs.d/eln-cache,
> post-installation?=C2=A0 (Aside from the fact it would necessitate
> reverting the behavior of =3Dcomp-el-to-eln-filename=3D.)
There is only one `comp-el-to-eln-filename' to call, you can't (without
a much more ugly hack) have two strategies, and even if you did have
them, it'd be even more error-prone.

> Actually... (with reservation that I may be wasting your time) I'm
> starting to wonder why the filename needs to stay the same for Emacs
> to be graftable?=C2=A0 Realistically, if all Emacs packages get upgraded,
> and if =3Dcomp-el-to-eln-filename=3D works like upstream, we have some
> paths like
>=20
> =C2=A0=C2=A0=C2=A0 /gnu/store/emacs-29.4/bin/emacs
> =C2=A0=C2=A0=C2=A0 /gnu/store/emacs-magit-OLD/lisp/magit.el
> =C2=A0=C2=A0=C2=A0 /gnu/store/emacs-magit-NEW/lisp/magit.el
> =C2=A0=C2=A0=C2=A0 .../wherever/magit-OLDHASH.eln
> =C2=A0=C2=A0=C2=A0 .../wherever/magit-NEWHASH.eln
>=20
> Then we start Emacs, and run its =3Dcomp-el-to-eln-filename=3D on the new
> magit.el, it would correctly return .../wherever/magit-NEWHASH.eln.
> No need for static filenames to swap out.
I haven't linked at the shared objects themselves, but I have strong
hunch that they use dynamic linking between the libraries.  Since we
only update the /gnu/store/emacs-whatever-HERE-WE-HAVE-A-HASH portion
and nothing post that, we get file names that don't exist :)

If you dig into the patch series, it references the bug it fixes.

> [=E2=80=A6]
>=20
> No, grafting is about avoiding a world re-compile, right?=C2=A0 So like i=
f
> package-A was built with an old dependency package-B, it does not get
> re-built when package-B is upgraded. But does grafting actually ever
> change anything in Emacs?=C2=A0 When you start emacs and it loads package=
-
> A which in turn loads package-B because there's a =3Drequire=3D statement
> for package-B, Emacs will actually load the fresh package-B from
> /gnu/store/emacs-package-B, won't it?=C2=A0 So grafting would seem to be
> meaningless.
For example, GTK is a package deep in the world, that gets grafted a
lot and causes Emacs to be grafted as well.

> Not sure how to feel if it's like this instead: a compiled function
> from package A, containing a call to some function "package-B-
> frobnicate", will actually call some bytecode originating from
> /gnu/store/emacs-package-A/share/emacs/site-lisp/package-B.elc?
> That's... not what happens, right?=C2=A0 OK, probably yes if it was a
> defsubst or defmacro.
>=20
> So we can have package A using a macro that was defined in an old
> version of package-B.=C2=A0 I like that not, but the reason I ask is I'm
> trying to find out where it is that the file path would influence the
> graft.
I haven't looked in the ABI stability of Emacs Lisp packages, but most
of them would actually not need a graft.  It's Emacs itself that needs
the grafting :)=20

> > The way our load paths are set up, it is actually the opposite
> > (which still is a bug, just not the one reported).=C2=A0 While `guix
> > upgrade` or a command to the similar effect will swap out the .eln
> > under the hood, the `.el` and `.elc` files stay stable =E2=80=93 rememb=
er
> > what I wrote in the previous message about that having caused
> > issues with byte compilation?
>=20
> I confess I'm puzzled.=C2=A0 Does this just apply to a case like the
> following?
>=20
> - Emacs itself is upgraded
> - A package emacs-magit is NOT upgraded
>=20
> so that
>=20
> - magit.eln is rebuilt
> - magit.el and magit.elc stay the same
>=20
> That would make sense.=C2=A0 Do you mean it's a bug because .elc files ar=
e
> also not portable between different Emacsen?
We had issues, where a major upgrade between Emacsen would cause
invalid bytecode to be loaded, yes.  The issue in Guix is not so much
that a package is not upgrade, but Emacs being upgraded while Emacs is
running.  You'd get a functioning Emacs once you exit the process and
start a new one, but that feels very dirty.  (Imagine exiting Emacs,
because your package manager tells you so, ugh!)

> Just checking: is it correct to expect that if you actually upgrade
> the emacs-magit package, then its .el, .elc and .eln are all
> upgraded?
Yes, the .el, .elc, and .eln files are built as *one* package.  Any
package manager you use with Emacs should provide you with that
invariant.

Cheers

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Resent-From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 18 Oct 2024 16:58:02 +0000
Resent-Message-ID: <handler.73681.B73681.17292706734144 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 73681
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: "Liliana Marie Prikler" <liliana.prikler@HIDDEN>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Received: via spool by 73681-submit <at> debbugs.gnu.org id=B73681.17292706734144
          (code B ref 73681); Fri, 18 Oct 2024 16:58:02 +0000
Received: (at 73681) by debbugs.gnu.org; 18 Oct 2024 16:57:53 +0000
Received: from localhost ([127.0.0.1]:39889 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t1qIS-00014m-S4
	for submit <at> debbugs.gnu.org; Fri, 18 Oct 2024 12:57:53 -0400
Received: from mailtransmit05.runbox.com ([185.226.149.38]:40730)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <meedstrom@HIDDEN>) id 1t1qIQ-00014G-Pq
 for 73681 <at> debbugs.gnu.org; Fri, 18 Oct 2024 12:57:52 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com)
 by mailtransmit05.runbox.com with esmtps (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
 (envelope-from <meedstrom@HIDDEN>)
 id 1t1qFr-00AZaY-2Y; Fri, 18 Oct 2024 18:55:11 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.eu; 
 s=selector1;
 h=Message-Id:In-Reply-To:References:Date:Subject:CC:To:From:
 MIME-Version:Content-Transfer-Encoding:Content-Type;
 bh=XHaP2ebtVtdhiu3RkSUM0YmCQvXI3v9ZVQ6vdqACTsc=; b=dHtfmhF0IAV85UVs1/C3KUyHaE
 1cZesfp+w7eXqiK1Zn1nUZgBepIdLYSrg4sjixcWpRktkpDRNoj8F86FhZ7NqFGG6LdmrU+Rgnji0
 pP9qNxSdDLHf4oi614Jlo4tkFhABumX0IkH+ahYsf0ghJyhLzPiRXIWPwI9OR4jEBDjfADTbELk5G
 aOuEO3ZktQAiVVez4ZvZYGnLXS+paj+sPeMjH2Cu/Dsp4ZAfazcN8IzrBHe5dTUBySY2o7jJOD02h
 lbmNrfw1tGWTz6Vk42UJ/bgt3rN91pKB2N8GsUIhHmWwJ0LWOsTenMQVJ9HGLJ4ueYE9GRD9ydShq
 /Dyr0zoQ==;
Received: from [10.9.9.128] (helo=rmmprod06.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <meedstrom@HIDDEN>)
 id 1t1qFq-0007kh-KN; Fri, 18 Oct 2024 18:55:10 +0200
Received: from mail by rmmprod06.runbox with local (Exim 4.86_2)
 (envelope-from <meedstrom@HIDDEN>)
 id 1t1qFq-000402-Iv; Fri, 18 Oct 2024 18:55:10 +0200
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received: from [Authenticated alias (1196375)] by runbox.com with http
 (RMM6); Fri, 18 Oct 2024 16:55:10 GMT
From: "Martin =?UTF-8?Q?Edstr=C3=B6m?=" <meedstrom@HIDDEN>
Date: Fri, 18 Oct 2024 18:55:10 +0200 (CEST)
X-RMM-Aliasid: 1196375
X-Mailer: RMM6
References: <E1sxpAI-0003hS-Gg@HIDDEN>
 <f228248ece04c00f78590df2ee7bb90e4302090c.camel@HIDDEN>
 <E1sxuch-0007aP-NN@HIDDEN>
 <58598114857dce8a25e3b4d0477d212467a0173f.camel@HIDDEN>
 <E1sy7eg-0005XF-AC@HIDDEN>
 <a96bf29e15108292c31e9cf29f81a7a5150eaeca.camel@HIDDEN>
 <E1syYPq-0005iN-A6@HIDDEN>
 <518988807953a1b77acb5f9833992fa9ced883c1.camel@HIDDEN>
In-Reply-To: <518988807953a1b77acb5f9833992fa9ced883c1.camel@HIDDEN>
Message-Id: <E1t1qFq-000402-Iv@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

In case anyone reads this, I believe I have the right
algorithm now.

First, the trick to locate an .eln regardless of OS:

    (comp-lookup-eln (locate-library "my-library.el"))

Turns out I do not need the trick, because if an OS like Guix
has indeed shipped an .eln and set it up to be loaded,
then `symbol-file` should return that one.

TL;DR: it took a while to figure out, but the following
snippet is how my program chooses an .el, .elc or .eln that
corresponds to currently loaded Lisp definitions, so that we
know the file is safe to be executed by a subprocess.

If the current definitions come from an .el, then it
opportunistically builds an .eln and returns that instead.
=20=20=20=20
    (let ((loaded-file
           (or (ignore-errors
                 (symbol-file 'a-func-from-my-library nil t))
               (symbol-file 'a-func-from-my-library))))
      (if (string-suffix-p ".el" loaded-file)
          (let ((out (comp-el-to-eln-filename loaded-file)))
            (native-compile loaded-file out)
            out)
        loaded-file))=

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

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